Starting an Open Source Project?
Tags: 
Date: 4 September, 2007 - 10:52

Since 2001 or so (according to SourceForge) when I got involved in Open Source, I've joined a handful of projects and had roles varying from a general advisor/reviewer to Core Developer to Newbie Wrangler. Yes, that last one was an actual title. But the interesting thing is that I've never started an Open Source Project myself. I've worked with projects that were established, already had communities (some quite small), and already had some structure in place. Recently, a number of opportunities have come to light and one of the interesting ones - but not the most interesting one - involves preparing a small application for release as Open Source... so I find myself considering and evaluating what it would take.

First, I'm a firm believer in that it must be useful now. As great as SourceForge is, I'm not willing to add yet another project that has a grand vision that doesn't do anything. That said, it doesn't need to be perfect. I don't think the application needs to do everything and fully encompass the entire vision in the first release... but it needs to do something useful immediately.

Second, I believe the project has to have somewhere to go. If the first release covers the entire roadmap, it's a development success, but doesn't seem like a good Open Source candidate. In this case, having active users will help you define what the next steps are (and potentially do them), but you may still want to have ideas to seed the discussion.

Next, the code needs to have a certain level of quality. Sometimes I cringe when I look at code I wrote years ago or under a tight deadline or worse yet when both are applicable. I'm never quite sure what I'm going to get and I can't help but think "well, that was dumb!" So what level of quality is required? Not a clue... but it can't be embarassing. That will vary from person to person. I'd also check for some basic security, etc here. If it's compromised moments after release, this sounds like more of a liability as opposed to a project.

Finally, I think some company's cast off project is a bad idea. I don't know how many times I've heard about a company losing market share, considering killing a failing product line, and what's the answer? Open Source it! Bzzt. Wrong. If your customers don't want it, odds are that the community doesn't want it. Yes, most likely some of your customers will want the code to customize and expand upon, but they're going to pursue their goals, not necessarily yours...

What do you think? What are your critieria for starting or joining an Open Source Project?


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

One counter example

It would be hard to disagree with your first rule. The last thing the world needs is one more partially complete proof of concept on source forge. Two and three I am more ambivalent about.

One clear counter example to your cast off rule though is Firefox. Proprietary cast offs can work, but Netscape did a lot more than fling its collective hands in the air and say "OK we give up, but here is the source" and did not see an immediate avalanche of support.

Eclipse might also fall into the same category.

Sourceforge...

where Open Source Projects go to die. ;) That's one of the things that drives me nuts about SourceForge in general. There's so much crap that it can be hard to find the useful bits.

I think having somewhere to go can be key to building the community aspects. Sure, if it's "complete" you might get a lot of downloads, but you're unlikely to get much involvement, etc from others.

I'm not sure how to get around the code quality aspects... sure, releasing crap can give you *lots* of room to grow, but it's likely to be a liability in the meantime.

As for #1, I think a

As for #1, I think a contributor to the problem is that some people get on there with absolutely no intention of ever writing code. They're hoping that some brilliant, motivated programmer will jump on it and suddenly they'll get the software they want.

But yes, someone should at least be able to do something with your code right away (if possibly after a little tweaking).

I would also add "use meaningful version labels" as a rule. I've seen a lot of projects out there that are something like "version 0.7 stable." I guess that could mean 70% of the features you think the project should have are included. However, if you're "stable" and people are using it, the "0.7" bit is almost entirely ambiguous. Start with Version 1 and rate the stability: alpha, beta, release candidate, stable, mature.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <br> <img> <p> <blockquote> <strike>
  • Lines and paragraphs break automatically.

More information about formatting options