Daniel Brookshier's Blog

Controlling code in your open source project

How do you manage an open source project? Part of the problems is that most owners of projects fear uncontrolled change. The second problem is really that no one wants to change code because they are afraid of breaking an unwritten rule. The key is as simple as writing downs a few rules that both make project owners feel safe to open up their software and second for contributors to feel that they can contribute source code. Rules also give owners a way to kick off a contributor that is not following the rules.

The following rules and process can be copied to your project's home page. They represent what we have seen on several successful open source projects. These rules can be modified to suit your needs, however these have been proven time and again. If you are a member of a project which has no code submission process or rules, please email a link to this blog to your project owner.

So, without further ado are the rules:

------ cut here -----------------------------------

Code Submission Rules
This is an open project so anyone that is a member can submit an issue and/or attach code to an issue to resolve an issue. However, not all code or issues will be accepted by the owners and existing developers of this project. Issues, code, comments, and documentation must be well written and pass a review by at least one of the developers and may be vetoed by any developer or the project owners. In addition we have the following code submission process. Failure to follow the process may cause you to be removed from the project.

Code Submission Process
1) All changes must be in reference to a issue to resolve a Defect, Patch, Task, Feature, or Enhancement.
2) All code to resolve the issue must be attached to an issue for review prior to committing to the database
3) All changes must be reviewed by at least one other member with developer status or the project owner
4) Any reviewed code that receives a negative review or request for modification cannot be committed until either a discussion of the code and issue reverses the negative review or that the code is modified to remove the objection. You may also be required to include comments, changes to documentation, and unit tests before code can be committed.
5) When code is posted to CVS, in the submission comment you must reference a short description of the issue, short description about the change, the issue number, and the developer ID of the reviewer.

Note: All members can submit issues and attach code modifications to the issues for review. If code is reviewed positively, you may be granted a developer role at that time or someone will post the code to CVS for you.

------ cut here -----------------------------------

Resources

For help on the issue tracker, go here: http://www.dev.java.net/scdocs/ProjectIssues#aboutIZ
Help for using CVS: http://www.dev.java.net/nonav/scdocs/ddCVS.html

Requesting membership/roles in an open source project: http://wiki.java.net/bin/view/Gelc/RequestingMembership
Rules/Process for code submissions: http://wiki.java.net/bin/view/Gelc/ChangingCodeInOpenSource

Comments

• The problem with trying to be perfect, or correct, in an open source project is, that you can be happy finding able developers that want to dedicate a huge amount of their free time to the project. So your rules would not work for most developers with open source projects, I assume strongly. This is what may experience says.

  Posted by: klausikm on February 23, 2005 at 02:16 AM

• A good trick is to maintain the developers separated in different modules, i.e., to avoid distant people changing the same code...

  A few number of developer members can also help in to the source code maintenance.

  I have had success discussing with the developers which part they should work on... But I'm very lucky because the number of active members in my projects are bellow 20 per project.

  good topic - is very important to discuss these strategies...

  best regards,

  Felipe Gaúcho
  http://wiki.java.net/bin/view/People/FelipeGaucho
  

  Posted by: felipegaucho on February 23, 2005 at 05:24 AM

• You can modify these instructions for different situations. I am sorry if you saw these rules as absolute. They do work in the average case and are indeed a good place to start you own rules.

  As for the "super coder" or times when there is a lot of coding going on. In order to add a lot of code you sometimes need to apply a review to a version and before the version is released put issues toward it that most be completed prior to release.

  You might also apply this to a branch and have the review prior to merging the branch. Prolific coders should indeed be coddled to but only if you trust them. Review is a healthy in any case, so it is highly recommended that all posts to the cvs, whether in mass or patches, be reviewed.

  Posted by: turbogeek on February 23, 2005 at 10:18 AM

This work is licensed under a Creative Commons License.