Jilles’ weblog

Developing… I’d like to contribute!

I’ve made small contributions to open source projects. Someone on the translation front, others by contributing idea’s and/or actual code. But I’d like to do more (after all I’ve been using open source software so much!). One of the things I always dread is to ‘get into the project’. You have to read so much: how is the architecture, get all the dependencies, read the policies regarding commit access, testing, etc. So I’m trying to select a project on which I want to focus for the next few months, trying to come up with some useful patches in my free time. A couple of candidates: Apache, Subversion, Anthill, Phing/Binary Cloud, PHP5 and Mozilla. All these projects touch my professional work as well, and that is A Good Thing^(tm). I’d like to walk through these projects one by one. (This it actually not to inform you of something I’m going to do, just my ‘internal’ decision making process, exposed to the rest of the world. Read it or disregard it as you see fit :-o).

What would I like to find in a project on which I’m going to work in my (so scarce) free time?

Multiplatform: I’d like to do something that I could use/develop on Linux as well as on windows (the latter having less priority of course).

Perspective: It should be a project that has a lifetime in front of it (not something that is going to be replaced in a few years, e.g. CVS).

Language: Preferably a compiled language (C/C++/Java/etc.) instead of an interpreted language (PHP/Perl/etc) because that’s what I work with professionally. I’d like to keep my skills sharp over the entire line.

Documentation: A project with a good organization has the advantage (e.g. RFC’s/bug reports etc. are input to a starting contributor). A HACKING file or some other documentation to orientate starting developers is an advantage!

Easy Compile-Run-Debug cycle: I’d like to contribute to the Linux kernel but compiling the kernel, installing it, rebooting it… that’s too long a cycle for yours truly.

Coolness factor: this property of a project is undefined but working on some projects is just cooler than working on other projects (e.g. Linux kernel is way cool, writing man pages is definitely not :-?).

Need for developers: some projects are developed into their 2.x versions. Clearly they don’t need the developers as much as a 0.1beta project. If you want to contribute something the latter has more need of you.

Albright, here is my decision matrix^(tm).

^{(Blab bla: my opinion, would like comments, this is my opinion, these values may or may not be based on the truth)}

Well if you’d take this table, I’d go working on Subversion… I’d like that very much. But, this table itself is not definitive. So if you, the reader, know any topics on which the above projects should be judged, before choosing a project, please tell me and I’ll include them in the above table. The same goes if you know of any projects that might be cool for me to join. Mail me! or place a comment here, or backtrack, whatever you like.

First I’ve got some other stuff to finish, and in the meantime I can read documentation and stuff, to get into this new project…

I’ve been playing around with SCM systems (Software Configuration Management) earlier (played around with CVS, VSS and BitKeeper). Of these three CVS has in my opinion the best thing going for it (large, very large, adoption easily extendable, etc.). At that time (a few years back now) I already noticed Subversion, abbreviated to SVN. At that moment they had all the plans ready (architecture, etc.) and I think they were in their 0.1x’s (version). Now I’m running a decently sized project on CVS I’m keeping my eyes open for alternatives, and SVN is one of the best candidates (BitKeeper looses it because of the licenses).

One of the best features of SVN (in my opinion) is the branching strategy they’ve taken. Although I already had experience with CVS, other team-members didn’t have that when we switched to CVS. Explaining all the stuff and the command line options is simple enough. But the one thing I’ve noticed that is the hardest to pick up for new users is branching. Of course, you’ll draw some pretty tree-like pictures and start explaining the stuff; everyone says he/she gets it. But when it is put to practice I see enough things going wrong regarding branches. One of the biggest obstacles, imho, is the fact that branches are on another dimension in CVS. People forget to switch between branches and trunk because it’s not obvious on which one they are working. This is not the case in SVN, here a branch is just a full copy of the trunk, originating from a certain revision. You can do stuff like this with SVN:

\Project1
\trunk
\src
\doc
\branches
\feature1
\src
\doc
\jilles-playing-ground
\src
\doc

This is a huge improvement over CVS and it will be so much easier to explain this to people new to SCM/CVS/SVN. Perfect. Another improvement is very obvious: every change to the repository results in a new revision of the entire repository. This way directories and such can also be versioned.

Why am I still using CVS? Well, I’m still missing some features from SVN, but those will come in time. There is a nice cvs2svn script that I will check out sometime. But paraphrasing Joel Spolsky: a good tactic to convert people to your product is to make it easy to switch back. That’s why I’d like to see a svn2cvs script. Having such a script enables people to easy switch back to CVS once they decide that they like that better (unlikely) or they decide that SVN doesn’t have the features they want yet (more likely that the previous reason).

One other disadvantage of SVN: the tags. Under CVS a branch and a tag are two different beasts. Under SVN (as far as I see it/read it in the docs) they are both the same. Besides the directories ‘trunk’ and ‘braches’ you can create a directory ‘tags’ and essentially create branches. So far so good, thanks to SVN’s shallow copying technique this is fast and doesn’t consume much disk space. My take on a tag is “a constant snapshot of the tree at a certain moment”. Note the word constant. Once I declare version 1.4 of my product and build, package and ship it I do not want the option/feature of changing the 1.4 tag in the repository and thereby creating a difference between the 1.4 version in the tree and the 1.4 version that is installed at the customer. Of course, an administrator should be able to move that tag around in case of an erroneous tag command but this should not be made easy. But in subversion a tag is tag only because of the way the developer looks at it. I’d like a command in SVN that would enable me to “freeze” a branch: such that once I create a tag (read: branch) I can freeze it and thereby disallowing all developers from committing to that branch, ensuring that version X in the tree is the same version X that I’ll ship.

(Of course, I know that if you create a ‘tag’ and some developer commits changes to it, you can easily back out of those changes, but that would just be mending your wounds instead of preventing the wound ever from taking place.)

All in all though, I like SVN (much better than CVS). I’m just biding my time till they reach a version more close to their 1.0 release