Ringing in the changes

With a new year upon us, you would expect to see a few changes, possibly even resolutions, appearing. A leisurely break over the holiday season does give one time to reflect. Time I hope I have put to good use. So what have I resolved to do differently over the next year? Here are a few of my resolutions.

  • implement David Allen’s Getting Things Done (GTD) methodology rigorously
  • make a serious contribution to an open source project
  • make openness a reality in each of my project/work environments
  • learn a new programming language and improve on one of my current ones

Oh yes, and I’m also going to learn French, lose weight, and run a sub-60 minute 10km race. So, same as last year, I guess 🙂

Counting for at least two

I like everything I do to count for at least two. It’s something I recommend to everyone in my team. But what do I mean by counting for at least two? Here is an example.

A colleague is about to review a recent O’Reilly publication on developing projects in PHP. She could simply read the book and write a short review highlighting its strengths and weaknesses. That would be letting her effort count for one. How can it count for two?

I know that this colleague has a long term training goal of developing her skills as an open source software developer. That’s not terribly surprising coming from a member of the OSS Watch team. Is there a way to combine these projects?

For a start we could try installing the Eclipse IDE along with its PHP plugin. Version 1.0 of the the PHP plugin for Eclipse is due out in June 2007. It is currently at release number 0.7. Usually a 1.0 version number is used to indicate that the developers believe their project is ready for the real world. Of course most open source software is in use long before it hits the 1.0 release, but 1.0 is symbolic of something, and it is a curiously persuasive number for people that wear suits. Still, why not put both Eclipse and its emergent PHP plugin to the test? We might just learn something.

But what can we test?

Everyone in my team is encouraged to find an open source project that they can contribute some development time toward. How do you pick a project that is right for you, for your current skill level and one that meets your particular set of criteria for a stimulating project environment? That’s going to be a personal thing, but there is no time like the present to get out there and find that first (or second, or third) project.

Then all you need to do is pull it into Eclipse, begin exploring and, ideally, start contributing code.

Okay, those last couple of steps went rather quickly, but you get the idea.

Now we’ve got a project that will

  • review a publication
  • provide continuing professional development for a staff member
  • probably generate a further review of both Eclipse and its PHP plugin, and (in the best of all possible worlds)
  • provide a nice case study about a specific open source project and what it was like getting involved.

Oh, and if it all works out the project will have gained a committed contributor.

So now that one task – writing a review of an O’Reilly publication on PHP – has spurred a whole host of related efforts. That’s what I mean when I say that everything should count for at least two.

Now you are asking yourself, what else does this blog item count for besides a short homily on practical efficiency?

Expecting the Unexpected

Google has come up with a Google Browser Sync extension for Firefox which enables syncing of bookmarks, cookies, history, even passwords between multiple Firefox instances on multiple machines and operating systems. The data can be passed to Google encrypted (and probably should be).

At first glance this looks like the ideal solution to that pesky problem of multiple desktops and operating systems. Indeed it might also be seen as a direct hit on del.icio.us‘s unique selling point. However, I think there is more to this story.

My move to del.icio.us this past January was indeed prompted by the fact that I switch frequently between 5 different desktops and operating systems. There just wasn’t a practical way to manage my bookmarks. Even a Google personalised homepage quickly becomes unwieldy (especially if you want to use that to handle your rss feeds). So del.icio.us had all the appearance of a solution for me. One web page that easily handles all my bookmarks, and a straightforward system for adding new bookmarks.

But this new Google Browser Sync extension also appears to answer my previous needs. So why not go with that?

This is where things get interesting.

The use of a technology changes one’s expectations and requirements. Prior to using del.icio.us I did not have much time for social software. What was the point? I’m just not that friendly and, frankly, strangers are usually called strangers because they are strange. But since embracing the open sharing concept employed by del.icio.us I have begun to both appreciate it and want more of it.

Using del.icio.us has changed my expectations and my requirements.

I now like the fact that I can trace my way through the other users of del.icio.us to find like-minded individuals whose bookmarks I can appropriate. And I like the openness that comes of using my real name for my del.icio.us page. (Of course that is not a requirement for use of del.icio.us, but I felt it was more in keeping with the spirit of openness to use it that way. The same goes for my blogger.com blog, obviously.)

Have my requirements now changed so much that a perfectly adequate solution (to my needs 6 months ago) such as the Google Browser Sync no longer suffices?

If so, then perhaps there is a lesson here for us all, and for the IT industry in particular. A simple reminder of how difficult it is to anticipate how change changes the underlying conditions.

Really using Subversion

I have been using Subversion for more than three years. I use it every day. It is the version control system of choice within Oxford University Computing Services (OUCS). But until recently I hadn’t really used Subversion. Or, at least that’s one way of thinking about it.

It is worth a brief digression to consider why we use Subversion within OUCS. I’d like to say it is because we went through a thorough procurement process, arrived at the best possible solution for our needs, and then implemented the action consequent on that conclusion. That’s the ideal. But the dreaming spires of Oxford are just as bound by the contingencies of the real world as anyone else. Prior to switching to Subversion we used Perforce as our version control system. Perforce is an excellent solution – if you can afford the licence fees. I’m not certain of the sequence of events that took place (my role within OUCS doesn’t have me moving in those circles). The upshot was that suddenly we would have needed to pay about 100 thousand pounds if we were to continue using Perforce. Maybe other institutions manage their finances differently, but in Oxford it would take a miracle to change the budget for a sub-unit like Computing Services at short notice. And let’s be honest, 100 thousands pounds was just not going to happen. Not for something invisible like a version control system. So, we needed a solution, we needed it quickly, and, effectively, the solution was not permitted to have any impact on the overall budget.

Do you face these kinds of choices? They are not ideal. But in this case we were lucky. Just at that time a new open source version control system was coming on the scene. For many years CVS had been the standard version control system in the free and open source world. Subversion, an initiative from CollabNet, was being designed from the ground up as the next generation replacement for CVS. Subversion is also an open source project. That solved the cost-to-acquire issue. Its pace of development was substantial, and has continued to be so. And the community of users and developers around it was already large and growing. All that was left was to do some stress testing and then gradually roll it out, one project at a time.

OSS Watch was one of the first groups with OUCS that began using Subversion. Back in those days I had no familiarity with non-Windows operating systems. So I needed to interact with the Subversion repository via a Windows client. Fortunately there is an excellent one, whose development has followed pace with Subversion itself: TortoiseSVN. (TortoiseSVN is released under the GPL licence, whereas Subversion itself is released under an Apache/BSD style licence, even though they both come out of the same development house – a good example of the fact that choice of licence should be on a project by project basis.) TortoiseSVN installs as an extension to Windows Explorer. It takes only a moment or two to install it and barely any longer to learn how to use it (probably even faster if you already have a grasp of what version control systems are meant to be doing).

And since then I’ve used Subversion via a GUI client nearly every day.

But recently I began wondering how open source development projects use Subversion. My guess was that they use it differently than I have been using it. And I was correct.

At OUCS we have greatly simplified our interaction with Subversion. In part that was because we needed to bring along dozens and dozens of staff who were going to find, what I described above as blindingly simple, a challenge. So we went with a simplistic preview/publish distinction and left it at that. We didn’t even insist that publish would need to be a branch or tagset of preview. So there is not necessarily any trail of history between equivalent files in preview and publish. Again, a contingency necessitated by our install base. Probably everyone faces such challenges.

In order to learn how to really use Subversion for code development, I turned to the best source possible – the documentation written by the developers themselves. Version Control with Subversion is an online free publication that details nearly everything that you could possibly want to know about Subversion. I have learned about trunks, branches and tags. I have even discovered just how easy it is to use Subversion directly from a terminal window. It is all very straightforward and immensely logical.

I confess it has been a revelation for me.

In Producing Open Source Software, Karl Fogel claims that developers are unlikely to take your project seriously if it does not use version control with at least minimal competence.

I think he is right.

Mailing list archives

When I begin investigating a new software project, one of the first things I do is explore the archives of the mailing lists. They are treasure-troves of information about the project and its development community. As such, they naturally excite the interest of academics bemused by the open source phenomenon. But my interests are entirely pragmatic.

First, I want to know whether the archives of the list are public. Is this an open project or isn’t it?

Next, I want to see the pace of discussion on the development list. Are there frequent exchanges between the developers? And what is the nature of these exchanges? Do the developers appear to be thinking through the development process on the list itself? Or is this merely a platform for pronouncements? If the latter, then I begin to suspect that the real development list is a private one somewhere else. Again, is this an open project or isn’t it?

How do the people on the development list respond to questions? How do they respond to suggestions? How do they respond to contributions?

My interest is not academic. I want to know how I am likely to be treated in this community. The world is full of open source projects which might value a bit of my time. I want to know whether this is one of them, or whether I should move on.

Of course the list archive is also a narrative history. It has characters who shape the narrative arc. It may be punctuated by events or even conflict. In the best examples, the archive strips away the personalities of the contributors until the code itself becomes the character of interest, undergoing change, facing its own trials.

Software development projects, of course, are not alone in making best advantage of public archives of mailing lists. Take the license-discuss list of the Open Source Initiative, for example. Delving into the archive there can be exhilarating as figures of legend appear, and inevitably appear all too human.

In an age of blogs and Internet Relay Chat (IRC) and podcasts, I suppose that public archives of email mailing lists sounds a bit 20th century. Possibly. But for the foreseeable future they will continue to be a defining feature of open source projects.

Oh, and one other thing.

Everyone remembers the first time they post to a public open source development list. I know I do 🙂