Encouraging Open Source Project Programmers to Be Active Without Sacrificing Code Quality

Question

I have an open source project which I had been actively developing

JStock - Free Stock Market Software

From programming side point of view, most of the time, is solo work.

This worry me. As for long term growth of JStock, is is not healthy.

Although I do have a few programmers as team members, they are not actively involve. Most of them are just one or two times code contributors. After that, I received no news from them.

The main reason I think they are not active, is due to some strict rule which I had imposed :

No commit write being given. All the changes must be submitted as patches, and reviewed by me

See, even myself also doesn't like this strict rule.

I had removed this rule once, and let the programmers have the freedom to commit the code as they like. As a result, just after a few days, I found the code being messed up (Being messed up mean, cann't even compile). I have no way, but quickly stop the commit access, and recover the source code manually.

I feel that :

1. Too much rules, bad for programmers. They will not contribute.
2. No rule, bad for end users. They will be using product built from messed code.

I know in current situation is totally unhealthy for JStock. May I know how do you all encourage the programmers to contribute code, at the same time maintain certain degree of code quality?

Currently, JStock do have

1. Feature Tracker and Bug Tracker. They are actively being used.
2. Forum for developers.
3. CVS

Is Developer Guide PDF file is something must have, in order to let newly joint developer to understand the code? Or I shall let developers explore the 50,000 lines of code by their own?

Thanks.

Answer 1

Hm. Your project looks pretty nice. Also the website is quite attractive (If it was mine, I would get rid of the Google Ads but that's down to personal taste).

Maybe you should create a specific page section "developers", serving news, specific info, CVS snapshots... At the moment, it's very hard for an interested developer to find out more about how the project is developed, who is leading it, coding conventions... The blog is a start but it's not actively inviting participation. One would have to contact you and maybe that's already too much of a commitment for some before knowing more details about the project.

Do you have a feature wish list?

Can people put up bounties for desired new features? It's stuff for a longer discussion whether that is good and healthy to do in an Open Source project, but just as an idea. I mean, when I need to keep track of the stock market, I'm likely to have some extra dough lying around, don't I?

Answer 2

Move from CVS to a distributed source control system (e.g. git, mercurial). That way anyone who wants can hack at the code, with proper source control, but commits to your code line have to be pushed to you explicitly.

Answer 3

Maybe you should work with branches.

I'm not an expert on the field but I used it once and it worked well. We used launchpad to host our project and bazaar for source control. (which is nicely integrated in launchpad)

Anyone can mess up with the code in their own branch, and you can apply some control when you're merging a branch back in the main branch. This way developers have more freedom, without putting in danger the project.

Answer 4

Within web2project - http://web2project.net/ - we use Sourceforge's Subversion for the primary/official code, but I've just launched us on Github for the unofficial one - http://github.com/caseysoftware/web2project

So far it's serving as a way for both a) core contributors to share unfinished pieces and b) community members to share patches without compromising the integrity of the core repository. As seen in our 'network', I've already applied one patch from a contributor and even created a branch based on what another community member has shared.

Of course, NOTHING goes into the master (and gets merged to trunk) without undergoing the same code review we do for everything else. Further, we have 200+ unit tests that are run regularly (continuous integration is next) and we're also working on contribution guidelines with the hope that people will filter out the worst stuff before we even see it.