Actually Starting an Open Source Project

I’m a little late to the party, but I just got around to reading Starting an Open-Source Project and, as someone who has started several reasonably successful projects, I wanted to publicly disagree with, essentially, the entire article.

The article outlines seven pretty big steps to take before you can even consider open-sourcing a project.

1. Identify your goals
2. Choose a license
3. Organize your code
4. Write documentation
5. Set up a mailing list
6. Use version numbers
7. Organize contributors

Most of those have several substeps. For example, Organize contributors includes considering a CLA and contributor hierarchy.

This is scary. I really need to do all that to open source some code? Forget it!

No, you don’t. In my experience there are exactly two things you need to do:

1. Choose a license
2. Put the code somewhere!

In fact, some people even get away without #1 (but you shouldn’t).

Choosing a license can seem daunting, but after you’ve done it once or twice, you can do it pretty quickly. To me, the most important question is whether you want a copyleft license or not, after you’ve decided that, there are a few options, but the details matter less. And if there’s a community standard, you can generally use that (e.g. BSD-3 for Django apps).

Then just get the code out there. Honestly.

If you just know that you’re releasing a huge, successful project, maybe it’s worth putting in more of the effort up front. But that knowledge is pretty rare.

Here are a few examples.

OOCurl

I wrote this 5 years ago because I was annoyed with the PHP cURL bindings. I stuck an MIT license in the source and put it up on my website and a public SVN repo.

As far as I know, no one used it. That’s OK. Maybe someone did? I don’t know.

Then a few years ago I shut down my SVN server and moved all the projects to GitHub. I had no intent to, as the article says “continue developing the code,” and that’s also fine. With a project like that, you have two options: put it somewhere public or don’t. If you don’t, odds are you will lose it over time. If you do, maybe someone finds it and finds it useful, maybe they don’t.

Since putting it on GitHub, I’ve gotten a few patches from folks, so I know it’s out there. It’s helping people, and I skipped six of their steps!

Bleach

Bleach was always intended to be open source. I don’t think that affected very much at the outset, though. Pre-1.0 versions are pretty rough (especially pre-0.3) but it was always open, on GitHub and up on PyPI.

Since it was useful and solved a problem, people stumbled onto it. GitHub and PyPI have weight with Google, so just being there and having a half-decent description of what the code does was enough. I also tweeted about it from time to time, but who even reads Twitter?

I point out Bleach because it has all the goals the article mentions (it’s useful to the world, is under active development, and accepts contributions) and all of that happened without any thought to the rest of their steps. And now it’s a reasonably successful project, well-known within the Python web community.

Waffle

I literally woke up one Saturday morning, thought to myself “hey, I bet that would work,” and wrote the core of Waffle in a couple of hours. And put it on GitHub with a BSD3 license.

Now, it’s shockingly (to me, anyway) popular, and gets contributions from all over the place.

(Humble) Bragging?

The point of all this isn’t to brag, it’s to point out that you can start a perfectly successful open source project with almost no effort.

Later, after you’ve established that something is useful, to you, at least, start talking about it more, maybe set up more of the infrastructure. It depends on how the community of contributors grows.

Don’t sweat the other stuff. Write code. Stick a license on it. Put it out there.

The rest can all come later, if it needs to.