Fog Creek Software
Discussion Board




how to run an open source project?

anyone know of any articles on this subject? there is something i might start.

Patrick
Thursday, August 19, 2004

I presume you have already thought about this a bit so why not tell us where you got to and where you got stuck.

gwyn
Thursday, August 19, 2004

Just start releasing the code.  Post updates on a website.  If people are interested they will come.

Don't expect hordes of people.

Be sure you link to your projects website every chance you get, in all of your signatures on email, forum postings, etc.  Participate in related email lists, (i.e. j2ee lists if its a j2ee app, mod_perl lists if its a mod_perl app, etc) all the while keeping the link to your project in your signature.

Don't expect hordes of people.

You'll still do 105% of the work yourself.  And I say 105% because some of the contributers will do more harm than good, and you'll need to pore through the patches and help and that will take you more time than it would have to do it yourself.

Once its up and running though, with a good community, it will practically run itself.  Its getting that community that takes time.

Not sure of any good books on running an Open Source project though.  I learned this by watching and participating in Scoop ( http://scoop.kuro5hin.org/ )

Andrew Hurst
Thursday, August 19, 2004

Be prepared to spend a lot of time dealing with e-mails/mailing list posts.

Get ready for people contributing brilliant code and then disappearing off the face of the Earth, particularly when you need them to make a minor change.

John Topley (www.johntopley.com)
Thursday, August 19, 2004

Sourceforge might be a good place to start.

Edward
Thursday, August 19, 2004

i looked at sourceforge and will read more. no problems yet - i haven't started it!

Patrick
Thursday, August 19, 2004



Yeah, I'd say that before you try to run one, you might want to participate in one on Sourceforge.

It seems like involvement happens in spurts.  If you get some attention (Slashdot, Sourceforge's Project of the Month, etc), you'll get a flood of people... few of which do anything except complain about lack of features and/or ask for help.

Release often and keep a bug database active and visible....

KC
Thursday, August 19, 2004

This book:

http://cvsbook.red-bean.com/

Has lots of information about running an open source project (as well as CVS). The CVS chapters used to be free and the open source project information was in the purchased version, but now the complete text of the 3rd edition is online. It's a good start.

The best advice I can give is to make things accessible for developers and users. Have clear documentation, a tutorial, examples, sample data, whatever else you think might help, and go out of your way to make it easy for people to get started. They will appreciate the effort you took to save them time exploring your project, and be more inclined to investigate further.

Rob Meyer
Thursday, August 19, 2004

"you'll get a flood of people... few of which do anything except complain about lack of features and/or ask for help."

That is SO true...

John
Thursday, August 19, 2004

I've run (very loosely) a few Perl open source projects. Aside from the good advice from Andrew I have another small item. Probably the main way to attract people to a project is to make the project ridiculously easy to get acquainted with. This means a post-download installation time of less than five minutes. (It also means a quick start guide and tutorial for a simple application, but that's a separate post.) Sounds crazy, but it works because IME a lot of people use initial startup as a proxy for whether a project has some smarts behind it.

As a nice side-effect this forces you to decouple and/or abstract some pieces of your system. Does your depend on a SQL database? The five minute rule means your install won't work -- by the time people remember what database they have locally or get whatever users/databases you need, you're past the limit. So figure out how to use an embedded database (example: SQLite for C and scripting languages, HSQLDB/McKoi for Java) and hook that into your system. Or even have a 'mock' mode that stores objects in memory instead of a database. Will that scale? Who cares -- that's not the point. The point is to quickly show people that your project works. This goes a long way to establishing initial credibility. You can still throw that credibility away by having a crappy product, but it's a start.

For a great example of this, check out the commercial product JIRA (http://www.atlassian.com/software/jira/). It's a very sharp issue tracking system that you can have running after the download in less than a minute (more if you have slow disks and it takes longer for you to unpack the tarball).

Chris Winters
Friday, August 20, 2004

*  Recent Topics

*  Fog Creek Home