Thoughts on branching an open source project

I think any good manager will tell you that looking back over the choices you've made is an important step to improvement. In an effort to improve myself (and help anyone in a similar situation) I wrote this post with a few thoughts about branching an open source project (in this case branching Pootle to make Verbatim). My goal is not to criticize anyone's past decisions, including mine, but just to review the pros and cons and what I would do differently in the future. So, a few thoughts late on a Friday: When I started the planning for branching Pootle I was very focused on scalability (or lack thereof) and most of my initial goals were to improve that including replacing flat files with mysql, creating a cacheable URL structure, etc. In hindsight, I should have realized that this project wasn't going to be getting nearly the traffic load some of our other sites were getting and my priorities were out of order. What I should have been thinking about was usability and interface improvements. Due to my lack of foresight the project launched with enhancements in both areas but I think the time we spent on scalability was premature and the user interface suffered. Whether it's writing more comments than code or making sure meetings have agendas I'm a huge fan of communication. When branching a project, particularly when there are plans to merge the branch back into trunk, communication is vital. I think our meetings are productive but communication on a smaller scale is still a struggle. Both Pootle and Verbatim ended up writing the same code in a few cases which could have easily been avoided. In this particular case the timezones can make it difficult to synchronize but it's something I'll work at more in the future. Something we have done a good job with is making a schedule and updating it with new developments. I really want to expand our effort here though. I think one of the difficulties of someone joining a project like this is direction; what are the goals of the project and how are we getting there? Several of us have talked about it on IRC and we all have a good general idea but for someone that isn't as involved it's hard to follow. Once we get over the next big hump (replacing jToolkit) I think this will begin to fall into place with smaller bugs/features revealing themselves and providing a way for volunteers to get footholds on the project as a whole. Lastly, it might be obvious, but if you're planning on maintaining the branch or merging back to trunk make sure you get along with the lead developers. I'm fortunate to work with the Pootle developers who clearly care deeply about the project. From talking to them it's obvious they have the end users' best interests in mind and are excited that we can all work together to improve the end product. And really, that's what open source is all about and it's great to be a part of it.

Verbatim Alpha Release

Last week I connected Verbatim to the addons.mozilla.org SVN repository and with great help from #verbatim on IRC the blocker bugs have been ironed out. Special thanks to Rubén Martín (Nukeador) for making the maiden commit. The server is a bit more unstable than I'd like[1] but it's usable. If you'd like to give it a shot to localize the latest AMO changes follow these steps: Log in with your LDAP</a> account (no need to register separately)</li> Click "change options" and choose "addons.mozilla.org" and your language Join #verbatim on IRC and let me know you registered and I'll make you an admin for the locale. After that other options will appear in the interface. </ol> One side note: To update the .po file from SVN or commit your changes to SVN you need to click "Show Editing Functions" when viewing the LC_MESSAGES folder. I'm coming up with a plan to make both the registration process simpler and the updating/commiting more intuitive but for now that's what we've got. If you'd prefer to keep updating the way you're used to feel free; this is an alpha version and I'm primarily seeking feedback (and hopefully offering some convenience). If you're interested in learning more about Verbatim there is information on the wiki including the current time line in the meeting notepad section. [1] Due to the way jToolkit works I have to restart the server every time I push a code update which breaks everyone's sessions.

Committing to SVN securely from a web application

Verbatim is the second project I've been the lead on recently where the requirements included people committing to SVN as themselves via the application. At first glance this means storing the authentication tokens of the user in plain text since we'll need to pass them along to SVN whenever they commit. I wasn't happy with that solution so after a bit of thinking we came up with an idea that leaves everything encrypted and doesn't cache any credentials. It involved minimal code in Verbatim and minor work on the SVN server.

Planning your API is important

I'm upgrading some code I wrote to talk to a new version of the Citrix NetScaler's API. The NetScaler's manuals (that's right, plural) weigh in at a combined 1114 pages so documentation isn't a problem and their implementation is a breeze using WSDL over SOAP. However, some of the core changes left me scratching my head. Case in point:

ThreadBubble 0.8 Released

A new version of ThreadBubble is available. Changes include: