2010/02/01

If you’re going to start a new OSS project, do your research first

I’m a fan of open source software the same as many developers.  So much so that I like to subscribe to the RSS feeds from sites like Codeplex to keep an eye out for new and interesting projects.  I have to admit that there’s some cool projects that look like they could have some real potential, but the I’m noticing that the projects fall into one of the following categories (ordered by perceived number of projects)

  1. So-and-so’s utility class(es)
  2. So-and-so’s school project.  This includes user group projects.
  3. Control(s) for a popular product (typically Sharepoint)
  4. Contrib projects to existing projects (both open & closed source)
  5. Port of another project (typically projects that are in another language)
  6. Proof-of-concept project
  7. Other minutia that generally has only one-off type usage.

The reason for this post is the prevalence of projects that fall into number 5 above.  I’ve come across a number of projects that are ports of Rail’s Migrations into the .NET space.  The problem as I see it is that a couple of them were started up because the originator of the project wasn’t even aware that other projects existed.  I’m all in favor of the competition is best for the consumer approach, but having multiple projects that do nearly the exact same thing because neither was aware of the other just creates lots of rework for no good reason.

So if you’re thinking of starting up an open source project, please spend at least 10 minutes flexing your Google-fu muscles to see if a project already exists that can fit your needs.  If there are similar projects, but lacking some key features, at least contact the developers behind the project to see if it’s on their list of features to implement.  If they’re not going to implement them, then either code the feature up and contribute it back to the project yourself, or fork the project and go down your own path with it.  If you can’t find a project that’s going to fit your need, then by all means do your own project, but at least acknowledge similar projects and explain how yours is different.  Not only does this help show that you’re intentionally going down a path that’s probably been trodden before, but it also establishes who your arch-enemy projects are going to be.  Don’t be afraid to have an arch-enemy project as it gives a great frame of reference in what you’re looking to achieve with the project.

2 comments:

Fabio Maulo said...

btw to have different options for the same goal is the heart of the evolution.

Unknown said...

@Fabio: I agree that having different options is a great thing for evolving/progressing a project, but having multiple (newer) projects that are accomplishing the exact same tasks with just a (sometimes) different syntax doesn't exactly help foster innovation. In that case you have at least two developers essentially slowly spinning their wheels on the same tasks when they could be working toward the common goal much quicker. Of course the possibility that the developers want to take the project down entirely different paths may come along, so that's when it should be forked. At least then there's a solid reason why two similar-but-different projects exist.