<< >>
justin = { main feed , music , code , askjf , pubkey };
[ <<< last (older) article | view in index | next (newer) article >>> ]

October 9, 2005
(Perhaps Obvious) Thoughts On Being an Individual Software Developer (Part II)

Part II - Making Open Source Work

From my experiences, there really seems to be a right way and a wrong way to begin an open source project.

The Right Way

    + If you haven't already, write a usable working proof of concept of your software.

    + Do NOT create a sourceforge.net project for your software (see below).

    + Make a simple web page for your software. Provide downloads for the source and (if it runs on Windows or Mac) binaries. Perhaps even bundle the source with binaries, if it's not too big.

    + Put an email address on the web page with a link that says "send updates/patches/requests/etc to ". It often is also useful to put a list of things that you are intending to add, i.e. a "todo" list.

    + Continue to update and USE your software.

The big push here is that a sourceforge.net project should only be created for a project once it has enough people working on it to warrant it (i.e. more than a few).

From my experiences it is much easier for developers to get involved with a project if they can download a source tarball or ZIP file, make their changes, and send them back to the project owner, who can then merge changes appropriately. While the project owner should definitely be using some sort of version control, setting up a CVS server for other contributors isn't really that important, at least until other people start doing a very big percentage of the work, and having it as the recommended mechanism for access initially is a really bad idea, because the barrier of entry is higher.

The other things I suggest are:

    + If you use other SDKs/libraries, include a text file with the names, versions, and (preferably) download links for those SDKs/libraries.

    + Try to use only the most common libraries, to make it as easy as possible for other people to run and build your code.

The ideal scenario is, you create the initial version of software and thus begins the cycle:

    + Someone finds out about your software

    + That person wants a particular feature or functionality, so they add it

    + They send you a patch, you merge it into the main release

    + Repeat.

That's really all there is to it. Later on, if you have many people actively working on your project, you might want to consider public CVS etc, but even that isn't really that helpful, as you'll only want people whose code you trust to have commit access.. anyway, hope this helps people! I know it might obvious, but hey, that's why I named this post what I did.








1 Comment:
Posted by dimovich on Mon 10 Oct 2005 at 00:50 from 193.231.30.x
IMHO, sometimes sourceforge.net can be the right choice because people will find your project faster ( by doing a search ). Whereas if you host your project somewhere else, it will get time till google.com will list your site on the first search page, or sth. like that...


Add comment:
Name:
Human?: (no or yes, patented anti crap stuff here)
Comment:
search : rss : recent comments : Copyright © 2024 Justin Frankel