Author Archive for Randy Metcalfe

Upskilling OSS Watch’s use of Subversion

Published by Randy Metcalfe on May 23, 2007 in Development, Discussion and Community. 0 Comments

For some years the OSS Watch team has been using Subversion. In fact, OSS Watch was the first team outside the Systems Development team (commonly called Sysdev here) to migrate to Subversion at Oxford University Computing Services (OUCS). No need to go into the reasons why OUCS switched to Subversion for version control since I’ve detailed those elsewhere. However, it is worth pointing out that OUCS was already using version control across a large set of websites, including OSS Watch’s, prior to the switch to Subversion in 2003. The change was therefore merely one in the minutia of working practices rather than philosophy. Most sites at OUCS used, and continue to use, a distinction between preview and publish. Preview is the internal or possibly development version of the site, and Publish is the live version of the site.

In those early days we were simply using the version control system supported by our host institution. And since we were so small and focused more on awareness raising than practical software development support, the way we used subversion was not that important to us.

Latterly OSS Watch’s focus has changed. In the past year we have grown significantly and now offer a substantive practical consultation opportunity for JISC-funded software development projects. As our attention turned to the practicalities of software development environments, especially open source development environments, we naturally began to reflect on our use of Subversion. Did our use of Subversion represent best practice? No. In fact, due to the way we had used Subversion over the first three years, there was no history preserved between preview and publish. There was also no easy way to simply change our working practices to use more standard Subversion commands such as svn merge or svn copy.

Of course most members of the team were perfectly capable of using Subversion differently in any software development project in which they might happened to be involved. Just how you use Subversion correctly is best explained in the freely available book (and Creative Commons licensed) Version Control with Subversion. Our questions instead were: Could we use Subversion this way within OSS Watch itself? What would justify the change-cost? And who would manage the process?

OSS Watch is nothing if not a learning team. So we sat down at one of our monthly full-day team meetings and thrashed out all the issues. Could we move from our current preview / publish set-up to the more traditional trunk, branch, tag set-up outlined in the svn-book (above)? Yes, but at some cost. After discussion with Sysdev, we concluded that the only way to make the move was effectively to start again from scratch and set it up right this time.

In the proposed new arrangement, trunk would become the new preview. Our new publish would be a branch, suitably named branch/publish. There were also a host of legacy issues with how we had been using the old preview - essentially it had become a dumping ground for content we wanted to share across the team but had no intention of putting on the website. That’s another challenge which we have safely shunted to another day by moving the old preview into branches/legacy.

So, we had a possible plan, but what would the positive benefits be that would justify this effort? I think the benefits boil down to two:

  • re-enforcing best practice in Subversion use across the OSS Watch team
  • beginning to use Subversion as a communications tool

Since we use our version control system every single day, the first benefit would be quickly realised. Our knowledge of using Subversion in much the way the svn-book recommends would become second nature. That would put every member of the team in a better position to help a JISC-funded software development project that might be wanting to use Subversion and needing some guidance. It also supports continuing professional development (CPD) for team members. It would be somewhat embarrassing to go off to a new job after having used Subversion for years while working for OSS Watch only to discover that you had never really got to grips with the fundamentals of Subversion use.

The communications point is not something that is exploited by all those who use Subversion. However, it is used as a communications tool in many software development projects. By arranging for Subversion to send a ‘commit’ email to a mailing list each time someone commits a change to a file, you can very quickly build up the ‘commit then review’ work practice. Of course we already had that practice within OSS Watch in that we would often send an email to the rest of team when we had made a substantial change to a document on the site and were looking for internal feedback. But now we could automate this. For example, this is how the Apache Forrest project uses Subversion. I have certainly found that such a use of Subversion aids participation for newcomers who can more easily see changes as they are being made. It’s a good practice that can, in software development projects, also aid the development of community. For OSS Watch it would serve to reduce the number of steps that previously had been involved in the commit then review process. But it would also serve the double purpose of supplementing our working knowledge of how best to use Subversion for community building in software development projects.

For us, the above was sufficient to warrant the change-cost. The final question was simply who was going to to manage the change? I’ve already hinted that this was a team decision. The practical steps - working up our migration plan, liaising with Sysdev, testing, support - were put in the hands of Ross Gardler and Stuart Yeates. Ross and Stuart are probably our most experienced Subversion users, at least with respect to software development projects. The migration project itself also served as an excellent opportunity for Stuart and Ross to work together on a tight, time-limited, core mini-project. So, once again, good for the team.

I’m delighted to report that the migration has gone well. The whole team is now working with the new set-up, ably supported by Ross and Stuart. I think it already qualifies as a success.

Is that the end of it? No. But it does lay the foundation for what we will try next. Soon we will start using tags to correctly indicate versions of a document that make it into support packs distributed to projects at OSS Watch events (call them releases if you like). There are even more steps planned, but slow and steady will get us there.

So why a blog post about this? Because I wanted to provide an insight into how OSS Watch grows as a team, learns new things, revises its work practices, and succeeds together. Maybe that’s something we can share with other JISC projects as well :-)

More than 900 students involved in Google Summer of Code 2007

Published by Randy Metcalfe on April 13, 2007 in Development and Community. 0 Comments

More than 900 students will be involved in Google’s Summer of Code (GSoC) this year (2007). It’s an impressive number no matter how you look at it. And it says a lot for Google’s commitment to building free and open source software communities. Makes me wish I was a student again.

Each of the students will have a mentor from within the community that he or she will be joining. So the headline figure here could just as easily be 900 mentors involved in Google’s Summer of Code. That too is a very impressive number. Communities need connectors - people who will aid the introduction of new members and guide them in the practices of the community they are joining. Google gets that. Makes me wish I was going to be a mentor for a student on one of these projects. Maybe you are thinking that too (either wishing you were a student or wishing you were a mentor). I can only urge you to join in. Find a project that has a welcoming community, of a style you like, and connect with it.

Some of the projects that caught my eye in the GSoC this year include:

There are lots more - about 150. In fact it begins to look as though Google’s Summer of Code is becoming a marker for something. I think it is something to do with openness, approachability, a certain kind of community that flourishes in the free and open source world. The projects that get involved all need to have the ability and the commitment to work with newcomers to their communities. And the focus, as much as it is on “Code”, is really on community.

Finally, just in case you were wondering whether anyone in the UK is involved in GSoC, take a look at Google’s map (requires Google Earth). I’m also delighted to report that Ross Gardler of Apache Forrest will be serving as a mentor again this year. I’m delighted about this because Ross is also one of our own - OSS Watch’s most recent member of the team. Still, I wish it was me ;-)

Reporting on UK university open source engagement

Published by Randy Metcalfe on February 14, 2007 in Development, Legal and Strategy and Policy. 0 Comments

Oxford University Computing Services (OUCS) recently published its Annual Report 2005-2006. Normally this might be a non-event, despite the great work that the staff at OUCS do (I kid you not, this building is packed with absolutely brilliant folks). But I think this annual report is worth special note because of one small section at the end of the main service reports.

3.27. Report on open source involvement at OUCS

OUCS staff make extensive use of open source software to deliver services, and take advantage of the freedom to examine the source code, fix it, and enhance it. The department recognizes that participation in community open source development is valuable for both staff development and enhancement of the University’s reputation, as well as improving the software itself for the benefit of all. However, the copyright in code created during this process by University staff typically belongs to the University, and is not distributed outside the institution without due permission.

Staff who wish to contribute to open source projects seek the permission of the Director before doing so. Requests are normally approved if the software is relevant to departmental work, and the Director is satisfied that the University is free to contribute the software in question. A catalogue of open source involvement approved in 2005-2006 is listed below.

Date Staff Member Description
April 2006 Ray Miller Perl scripts for configuration management, configtool and rb3.
April 2006 Oliver Gorwits Net::MAC - Perl extension for representing and manipulating MAC addresses.
July 2006 Barry Cornelius Meeting Room Booking System (MRBS).
August 2006 Oliver Gorwits Net::Appliance::Session - interactive (SSH) session to network appliance.
September 2006 Barry Cornelius MoinMoin wiki software.
September 2006 Barry Cornelius WebCalendar application used to maintain calendars.
November 2006 Oliver Gorwits Development of our wireless services, including OWL-VISITOR

Many universities across the UK use open source software on a daily basis. For some idea of just how many (and how much) it is worth taking another look at the OSS Watch Survey 2006. use is the key word there. They use open source software, but do they engage with it?

It is virtually inevitable that infrastructure use of software at universities and colleges will throw up use cases that have not been anticipated by the software developers. Call it a feature or call it a bug, the truth is that occasions regularly arise in which staff need to write patches to fix some software for the local deployment (obviously I’m talking about open source software here; fixing proprietary software is a whole different ball game). Sometimes this really is a completely local fix, a workaround for some quirk in the way the local infrastructure was set up in the first place. But just as often a staff member is writing a patch that would be a genuine improvement to the software being used. The question you want to ask is just how hard is it for a IT staff member to contribute code to an open source project as normal part of their work?

The answer, of course, is that it varies from institution to institution. At the University of Oxford, the Computing Services took the view that this process needed to be regularized, simplified, and most important, made clear to staff members. Reporting on progress in the OUCS annual report brings us full circle.

Is OUCS unusual in getting its engagement with open source sorted? Perhaps not. What would be great though is if I had two dozen more examples of sensible practices at universities and colleges across the UK. If you know of one, do let me know.

Claiming the muddle ground

Published by Randy Metcalfe on February 5, 2007 in Discussion. 0 Comments

A muddle is a state of confusion. You can find yourself in a muddle. And one of the causes of muddles is unclear writing that blurs or jumbles things that ought to be distinct. Muddles are ever so hard to avoid creating when you try to explain difficult, complex or subtle concepts.

Would you be surprised to learn that a lot of writing out there falls into the muddle category? Indeed, much as we try within OSS Watch, I would even guess we inadvertently generate our fair share. Of course we try to prevent this through careful editing of our documents. And we also review our documents on a regular basis to see, as with fresh eyes, whether we have overlooked a muddle. It’s an ongoing process and we appreciate it when someone reading one of our documents spots a muddle and let’s us know.

The key feature of these muddles, however, is that they are inadvertent.

What if your intent was to create a muddle perhaps in an attempt to manipulate a market space? Although such a malicious action might involve outright lies, there is necessity for that. A little understatement. Damning with faint praise. A few real cases where something has gone wrong for the other guy. And you are in. Because the object is not to get you to believe a falsehood, only to prevent you from learning and believing the truth. The deliberate intent to create a muddle for some other ends is sometimes called FUD; the sowing of fear, uncertainty, and doubt by one competitor or its proxies in an attempt to a manipulate a market space.

I honestly don’t know how much FUD happens. But I do know a muddle when I see one. And since most people do not wish to inadvertently perpetuate a muddle, a tell-tale sign of whether you are dealing with FUD or merely a benign muddle is how the author responds to having the muddle pointed out to him or her.

So this is a plea for everyone to claim the muddle ground. And we’ll work together to clear it up.

UNV Online Volunteering

Published by Randy Metcalfe on January 8, 2007 in Community. 0 Comments

UNV Online Volunteering co-ordinates online volunteer efforts around the world. This isn’t about going to some developing or transitional country yourself. It is about sitting in your comfy chair at home and putting some of those hours you might have otherwise spent playing World of Warcraft to work for someone else. Whether your skills are website design and development or translation of documentation, there is plenty of opportunity to put them to good use. What a nice idea!