Sunday, May 27, 2007
subversion: overdue good-bye?
I discovered subversion before it got to 1.0. I convinced people working with me then to switch. At that time we were using ClearCase. Simplicity and speed of subversion was in comparison exhilarating. I even wrote couple of simple ruby scripts to bridge official ClearCase and our subversive repository. Even the name was perfect. Let's just say that even my undeniable sense of humor and personal charm failed to mend strained relations with Release Engineering group (yeah - it was a big company).

When I started working in Pingtel sipx developers already had been using subversion. Since it was about the time we needed to create our first real branch I took upon myself figuring out how to use svnmerge. We never looked back.

If that was not enough Producing Open Source Software that Douglas made me read at one point practically defined the way I think about my job. And it's written by Karl Fogel - yes - the subversion Karl Fogel.

I am writing all that to prove that I really like subversion. So it saddens me to realize that my favorite tool is most probably no longer the best tool.

As a part of my daily job I am committing patches sent by contributors. From time to time I create branches for people who want to experiment with sipx without breaking mainline. And slowly I begin to think that my job would be easier with a different tool. And that with a different tool sipXconfig and sipx would get more contributions and better contributions.

With subversion - or any other centralized SCM - there are always two categories of people: those with commit access and everybody else. Committers and patch senders. In-crowd and followers. Eloi and Morlocks.
As a patch sender you have to create your working copy, make your changes, send the patch - and - never use this working copy again. At least not until someone with commit access actually commits your patch. If the patch gets not accepted in its original form and you want to fix it, you are losing the history. You cannot somehow save your changes locally and than make changes on top of your changes. At least if you only have one patch you can keep updating the working copy and track the mainline. If you have more than a single patch however you are doomed. Subversion does not make life easy for you. I wonder how many useful contribution sipx is losing just because it's too hard to contribute anything more than a simple patch.

But even once you get commit access the problems do not stop. Before you get commit rights your every step is watched, every patch reviewed, every extra space corrected. Once you do not have to send patches for approval anymore it changes. It's not about becoming sloppy. It's about the lack of feedback. Even if someone does review your commits, and people do, once you check something in, it's in. Official. With good chances to survive forever without being looked at. One of the biggest benefits of open source, constant peer code review, is not the default option.

I started thinking about it after reviewing several patches last week. I took some. I rejected some. I sent comments or my own fixes on top of those patches for review. I knew what I was doing with subversion all the time but somehow it felt like I am working around my SCM rather than using it.

I thought of darcs which I discovered when trying out buildbot (sipx nightlies are courtesy of buildbot). That lead me to git, mercurial and others. It quickly became obvious I was not alone. Mozilla chose Mercurial over Bazaar (both distributed). They did not even shortlist subversion. Linus with his usual flair refers to subversion as the most pointless project ever started. He has a point. Open source project should never use anything but distributed SCM.

Source Control Management history follows the script leading to more freedom to modify and experiment: "lock-modify-commit" gets replaced by "copy-modify-merge-commit" (no locking) which in turn morphs into "pull-modify-commit-push" (no central repository).

If only I could figure out how this tailor thing works, I would set up mercurial mirror of sipx and encourage contributors to use it. Exciting.

Powered by ScribeFire.

Monday, May 21, 2007
Sometimes it's just better to let go
Contrary to what many people think open source applications are not created by a bunch of crazy, willing to work for free volunteers. At least not only by them. Read Linus's biography to find out more. Often open source contributors are engineers employed by big and small corporations.

There are many reasons why a for-profit corporation might consider sponsoring or developing open source projects. Ensuring support for a project that is outside of company's core strategic interest and assuring the customers that they are not vendor-locked are the most commonly cited ones. Another reason - probably not so often discussed - is cooperation with your business partners.

Software companies often engage in shared deals, shared developement, strategic partnerships. It's a not-so-well kept secret that deals like that often fail, generating little more than several widely discussed press releases. It's usually the clash between corporate cultures and internal politics that prevent even reasonable deal to go forward.

The situation changes when companies cooperate within the realms of on an open source project. Especially, if it is a well established project with wide community of users and developers. First of all the rules of cooperation are commonly understood, established and transparent. The roles of sponsors, contributors, reviewers, project coordinators are well defined. It's really no that different from having a standard API interface - only these times it gets applied to people and processes not to software components.

Simple things that can take ages to establish like 'how I can get your source code' and 'what format is your documentation' are already resolved.

The biggest improvement though is in the area of day to day communication. Engineers and product managers are forced to discuss their ideas openly to get them implemented. The usual management structures that in closed source world lead to exchanges like 'tell your boss to talk to my boss before talking to me' expose their absurdity under the open source light.

No side of the deal is afraid that the other side is going to steal IP. Reciprocate licenses eliminate the false temptation of competive advantage that can be allegedly achieved by stonewalling.

This is what big bosses like best: you reduce your risk by outsourcing your communication and product management to someone who just does it better than yourself. In this case it's an open source community.

Powered by ScribeFire.

Monday, May 07, 2007
AudioCodes gateways support is here
I am kind of relieved that AudioCodes gateways support achieved the stage when it's actually useful. To tell the truth I had my doubts it would ever happen. Also the more I work on those blue boxes the less I understand how one can configure them without sipXconfig. There is so many settings that have to be set in a very specific way for the entire setup to work. Simplicity clearly was not a goal here.

The good news is now you do not have to do that anymore. There is some bootp/DHCP magic that I am going display on wiki, but once you configure that it becomes a plug-and-play affair. So call you proverbial mothers to setup your VOIP networks. See wiki for more info.

Powered by ScribeFire.

Powered by Blogger