Author Archives: Ross Gardler

Open source innovation

In June 2010 I chaired the inaugral TransferSummit Conference (report) in Oxford. The byline for that conference was “Open Source, Open Development, Open Innovation”. In September this year we are running TransferSummit again. The tag line this year is “Open Innovation Everywhere.” I’m proud of the conference we have created.

Jay Lyman, Senior Analyst at The 451 Group recently twittered that the “overwhelming message @ Oscon so far is open source now driven mostly by innovation.” This in turn prompted Brian Proffit of IT World wrote:

if you put yourself in the right mindset, this kind of innovation is easier to spot than ever. Open source isn’t “just” the alternative anymore, it’s becoming the mainstream technology in a lot of areas.

When we created TransferSummit the objective was to highlight the fact that open source is open innovation in software. However, unlike most open source related conferences we are not interestedin preaching to the converted. Open source and the innovation it brings is important to everyone and TransferSummit is designed for everyone, no matter their existing level of open source knowledge.

TransferSummit 2011 has the same goal and has an equally impressive range of speakers for you to engage with and share ideas. We have:

  • 2 days’ trainings
  • 2-day conference across three tracks
  • Mobile focus, virtual track
  • Government summit
  • Hands-on learning and break-out sessions
  • Gadget playtime
  • Gala dinner
  • On-site housing
  • Intimate setting, limited to 300 participants

This is the must attend event for 2011, tickets are selling fact so register now.

Writing good software

OSS Watch recently ran the second Open Source Junction a series of events connecting industry and academic innovation in open source mobile technologies. The event series seeks to make these connections through software developers.

Stephen Walli, the Technical Director of the Outercurve Foundation attended both events and, during the internal evaluation phase in which OSS Watch consider how to improve the next event Stephen kindly took the time to provide some really valuable feedback. This post attempts to encapsulate this feedback and frame it in the context of the work OSS Watch are doing, alongside others in the sector. I’d like to thank Stephen for giving me permission to quote large sections of his emails to the OSS Watch team.

Good software is developed by good software developers.  It involves a discipline not found in most developers.  Rigorous version and config management, checklist for style and review, desk checking reviews before commits, automated builds, fully automated tests are all necessary steps to successfully, reliably delivering binaries that work, and most importantly when a binary fails you know exactly how you created it from what tool chain (and conceivably what version of the tool chain) and source using what version of the recipe so you can reliably rebuild the failure and fix both it and the test environment.   Great developers may be great architects, but every great developer is a good disciplined developer first, and they really don’t know how to build software otherwise.

Personally I couldn’t agree more. I have long argued that we suffer from a significant lack of good software development discipline. As my Software Engineering lecturer told me, far too many years ago, “I’m not going to teach you to build software systems. Even a modest software system is as complex as a small town. I’m going to teach you how to make a dog kennel, or if you are really good a shed, we don’t have time for more than that.”

I, like most students, was taught the waterfall method of software development, a method that wasn’t in common use when I was a student and is in even less use now. Furthermore, most students leave University without any knowledge of version control, testing, continuous integration, build tools, issue tracking or any of the other disciplines Stephen wants to see in a good developer.

In general most students graduating from university have been taught how to build a kennel and are unaware that to build a tower block they need cranes, forklifts, jack-hammers and many other tools. These are the tools that we have to learn about when entering our first real software development team. In such teams, if we’re lucky, there will be one or more developers who understand the importance of the correct tooling, rigour and discipline in software engineering.

I’ve been fortunate enough across the ~25 years I was around software development projects (IT) and products (ISV) to always have at least 10% of the organization and sometimes as high as 30% be such good developers.  The rest of the team had an easy time contributing appropriately because of the culture at the top set by the few.  We all know what needs to be done — just few of us do it.

Stephen goes on to observe that he is not one of these developers. Sure he can develop software, he knows how to use the tools and he knows the discipline needed in good software projects, but he looks to others to enforce the necessary discipline on his work, and that of others (for the record, so do I).

Without such discipline at the top, I believe no project can succeed regardless of whether it’s academic, IT, or government.  This is why Apache and Eclipse and Linux have such well defined and documented engineering disciplines around them, and why they succeed.

I’m lucky enough to have worked with Scott Wilson at CETIS on the Apache Wookie (Incubating) project. Scott is a visionary and he loves to understand and work with open standards. Like me he loves to bring people together and get them to collaborate, this makes him the visible driver of the Wookie project. I’m there to mentor the team in the Apache Way, to ensure they understand what needs to be done. However, neither of us are the ones who are moving Wookie towards being a truly great software project. A project that is attracting commercial engagement. Sure, we have our strengths, but neither of us are the disciplined software engineer needed to ensure the success of the software itself (which is different to the success of the concept hawked by Scott).

Over beer the other day Scott and I were both happy to sing the praises of Paul Sharples on the Wookie team. Without Paul and his rigorous attention to detail Wookie would not be on the verge of it’s first official Apache release. Without Paul we would not have the  rigour needed to go through the various IP and quality control processes of a good open source software project. Without Paul, Scott and I would probably be telling everyone how great it is whilst gradually making the code decay with our endless hacks.

Scott and I raised our glasses to Paul and all the good software developers out there. It is my hope, and I believe that of Stephen’s, that OSS Watch will continue to seek out teams that have a “Paul” in them as well as a “Scott”, through those teams we can create true academia-industry links that will benefit all.

OSS Watch and OpenDirective team up to deliver training

A couple of weeks ago I left OSS Watch as manager. However, I promised
that I would still be around and working closely with OSS Watch for
the foreseeable future. Today we are pleased to announce one of the first
collaborations between OSS Watch and our new company OpenDirective.

In September, at TransferSummit (Oxford) and in November at ApacheCon
(Vancouver) Sander van der Waal (OSS Watch), Steve Lee (OpenDirective)
and myself (OpenDirective) will be delivering a new training course
for people looking to either procure or engage with open source
software. The course is based on work done by OSS Watch on a Software
Sustainability Maturity Model (SSMM), a model which can be used to
formally evaluate both open and closed source software with respect to
its sustainability. The model provides a means of estimating the risks
associated with adopting a given solution. It is a tool for resource
planning and risk management when procuring software solutions for
implementation and/or customisation, as well as for reuse in new
software products. It is also useful for project leaders and
developers, as it enables them to identify areas of concern, with
respect to sustainability, within their projects.

The idea for this tool was the product of a workshop run by OSS Watch
in 2008 called “Levelling the playing field: developing a mixed economy for software procurement”. Attendees at the workshop made it
clear that one of the problems they faced when evaluating open source
software was understanding the difference between a truly viable open
source solution and some code that just happened to have been uploaded
to the web. This sentiment was echoed in the findings of the OSS Watch
national survey in 2008 and 2010. In late 2010 we published the
first outline of our Software Sustainability Maturity Model.

These training days will deliver the first complete version of the
, however we don’t intend to stop there. OSS Watch are currently
working on extensions to the model that will help guide Total Cost of
Ownership calculations while OpenDirective continue to refine the
model through practical engagement with customers.

It is through collaborations such as these that OSS Watch and
OpenDirective seek to meet the needs of the academic sector in terms
of both the use of and production of open source software. OSS Watch
remain free at the point of use and look forward to working with you
and your organisation.

All Change Please (situation normal)

Today I would like to make it public that I am no longer the manager of OSS Watch. However, I’m pleased to say I won’t be going too far, more on that later.

It gives me great pleasure that one of my own hires, Sander van der Waal, has agreed to be my successor. Sander has been a key part of the team for some time and is well equipped to take over from me as manager. I have no doubt that Sander will continue to deliver, through the brilliant OSS Watch team, an advisory service designed to ensure our sector benefits from, and contributes to, open source.

Before explaining what I’ll be doing next I want to explain why I’m leaving.

Difficult Times

The academic sector is changing. It’s changing in fundamentally important ways. Most importantly, for OSS Watch, the funding models for services like ours is changing. For some time I, as manager, have been seeking to ensure all staff within the OSS Watch team have a level of job security that our current funding model is unable to provide as we move forwards.

As background consider that OSS Watch staff, including myself, have been on rolling three month contracts for nearly a year. Naturally, under these circumstances it has been very difficult to provide a valuable service to the sector. I’m extremely proud of the OSS Watch team and what we have achieved under these circumstances.

I’m not interested in complaining about the lack of security for our staff. The reality is that the economic and political environment of the last couple of years is the root cause of these difficulties and it’s pointless to suggest that the problems could/should have been avoided. The fact is OSS Watch is a minuscule part of this whole sector and nobody is to blame for how things have affected us. In fact, rather than complain I would rather state, loud and clear, I have nothing but praise for those with a direct influence on our work.

The JISC, through our programme director Matthew Dovey, have done everything in their power to ensure OSS Watch remains viable. Similarly our host, Oxford Universities Computing Services, have been faultless in their handling of staff contracts. There were a number of times that OUCS could have legitimately cancelled our employment contracts, but this was never seriously considered. On behalf of the OSS Watch team I want to thank the JISC and OUCS for taking responsibility and not sweeping important services like OSS Watch under the carpet.

Similarly, I want to thank the OSS Watch team. Despite extremely difficult circumstances the team have stuck by me and my plans for the future of OSS Watch. This is a testament to both the value they place in OUCS as an employer and to their commitment and contributions to open source advice in the academic sector.

So, if I am so happy with our funders, employers and team why am I leaving?

An OSS Watch Spin-Out

During the last year I and the team have been working to secure additional funding streams for OSS Watch. We’ve had plenty of success in attracting funding for specific support activities in key projects, this has enabled us to significantly reduce our demands on the JISC. In addition, I’ve had success in generating interest in an OSS Watch like service for the private sector.

As a result of this interest from the private sector I’m leaving OSS Watch in order to start a new company, OpenDirective, with Steve Lee as a partner. Our goal is to connect the smart folk in the UK research domain to the people who can take their software developments to market.

Both Steve and I will remain engaged with the OSS Watch team to ensure our services are complementary.  Through our collaboration we will seek to identify opportunities for technology transfer and, in so doing, generate alternative streams of revenue for open source activities within the academic sector.

What Does This Mean to You?

First and foremost, OSS Watch continues to provide free, at the point of use, advisory services to the UK Higher and Further Education Sector. OSS Watch remains fully independent of commercial interests and as such continues to provide unbiased, non-advocacy advice. However, these services will remain advisory only. That is OSS Watch will not tell you the best course of action, nor will they actively engage with the implementation of your chosen route. OSS Watch seek to enable you to choose and act upon the right option.

OpenDirective, on the other hand, are able to provide more proactive and engaged services. We won’t just advise you of your options, we’ll be willing to tell you what you should do. We’ll even help you do it. Naturally we’ll explain our reasoning, but we’ll be spending more time on making your project succeed than deliberating over all possible alternative actions. OpenDirective will not be free at the point of use, but our contracts are performance based, that is we’re happy to put our time and money where our mouths are.

Interestingly, one of OpenDirectives first clients is OSS Watch. For the foreseeable future, Steve and I will remain a part of the OSS Watch project support team. So, if you are part of a project that has Steve or I are assigned to then things will not change a great deal for you. At the same time, a couple of our initial contracts are injecting funding and community development work back into OSS Watch projects.

Taken together we believe that the combination of OSS Watch and OpenDirective give you a new range of options that should enable you to reach your goal state in the most appropriate way possible for your unique position.

Rave in Context

At OSS Watch we recommend that software be split into reusable components wherever possible. Furthermore, we argue that projects should work to make their components attractive to third parties. This is good software engineering and open development practice that can lead to more sustainable software since it enables open innovation.

Unfortunately, software development teams often claim that the effort required to properly architect reusable components and to build community interest in those components requires resources beyond those available within a typical research project’s budget. It’s hard to argue against this view when the research team is only tasked with solving the immediate problem, and not tasked with the long-term sustainability of the software involved.

Since we were not having significant success in making this point, we set out to demonstrate through practice. We wanted to show that it is possible to solve the immediate problem as well as ensure the long- term sustainability of software outputs and, perhaps more importantly, the research team. All that is required is some forward planning and some new skills.

Our first step was to work with the University of Bolton, who had implemented a W3C Widget server as part of a much larger EU project. We helped the Bolton team, headed up by Scott Wilson, to take their code into the Apache Software Foundation’s Incubator. Since Wookie’s entry into the Incubator we’ve been working to build a community around the project. Bolton alone has received in excess of £700k in further funding relating to Wookie and the project itself has received many code enhancements from the community.

Our work on Wookie led directly to the extraction of more code components from three separate projects, two in the US and one in the Netherlands. This created a second project in the Apache Incubator called Apache Rave, which provides a platform for the creation of web applications built with OpenSocial Gadgets (reusing Apache Shindig) and W3C Widgets (via Apache Wookie). This is a relatively new project, but already the collaboration of all partners is leading to yet more reuse and collaboration.

One example of this is a new project (funded by the JISC) called Rave in Context. This project uses both Wookie and Rave to provide a new user interface to the popular MyExperiment scientific workflows application. By leveraging the widget features of Rave and the API provided by MyExperiment we will be demonstrating how user interfaces can self-adapt to different hardware devices and user environments. We’ll also be building widgets for accessing Simal and OpenDOAR with the same interface.

Of course, this project is itself an open development project. We will be extracting a series of generic widget templates for common web application features. These templates will be donated back to the Apache Wookie and Rave projects (as appropriate), whilst feature-specific implementations will be offered to the MyExperiment, Simal and OpenDOAR projects.

It’s taken us nearly two years to reach this point. Along the way various sub-projects and related teams have secured funding. Each of these projects has highlighted the open development approach as a major component of its sustainability plans. We’ve also engaged commercial partners in these projects, providing further resources to ensure the ongoing support of the open source code and the research teams that depend on it.

We hope that this practical demonstration of openness as  a sustainable academic research practice will encourage you to budget for sustainability in future proposals. Of course OSS Watch is here to help you at bid-writing stage.

PS We’ve just had a third project relating to the Open Grid Computing Environment (OGCE) accepted into the Apache Incubator. Watch this space for more info on Apache Airavata.

Widget Bashing

Last week JISC CETIS put on a WidgetBash event. OSS Watch pitched in since W3C Widgets are an area we are particularly interested in having taken some code from the University of Bolton into the Apache Software Foundations incubator as Apache Wookie (incubating).

This two day event focused on getting people up to speed on building widgets. Our approach was to give some very light touch training and then get our hands dirty on code. Overall the two days were extremely successful.

in the run up to the event I had committed a few new widget templates to Wookie in order to make it easy for people to get started. This turned out to be a great tactic. Some attendees used these templates as a base for their work, looking to enhance them, one attendee even submitted a patch to fix an error in my work (which I have now committed to the project, thanks Sam Rowley). Another attendee reported that one of the tutorials was misleading (another issue I have now addressed, thanks Simon Booth).

A team from the Manchester Metropolitan University enhanced a widget they had already created to tell students which labs had available PCs in them. Now it’s a fully geo-locating widget that sorts the results by proximity to the users position (interestingly using the tutorial Simon helped us improve). Another team from Strathclyde enhanced the Moodle Plugin for Wookie; now widgets are able to get a little more context from Moodle and thus provide more targeted information to the user. We hope to see patches and contributions from both these teams.

Many other participants who had never build widgets before reported that they’d learned a great deal. There were plenty of “almost working” enhancements to our templates as well as completely new widgets. Again, I look forward to applying their patches.

Why not come and join us on the Wookie project and find out what it’s all about.

You can read more about the two days on Sheila’s blog.

Rave proposal brings together US and European partners

There are currently three separate open source implementations of extensible and lightweight Java platforms for the hosting, serving and aggregation of Open Social Gadgets and services. These platforms are the engines for internet and intranet portals and form the building blocks to provide context-aware personalization and collaboration features. Each of these three implementations has its strengths and weaknesses.

At ApacheCon 2010 Ate Douma and I discussed the possibility of bringing these engines together under a unified project banner. Taking the best from each and producing a single engine that all parties could work together on. This was never going to be easy, but we felt the effort would be worth it.

Yesterday Ate, after a great deal of hard work, posted the Rave Proposal to the Apache Incubator. This proposal is a joint effort between:

  • Hippo – Netherlands, CMS provider
  • MITRE Corporation – US, manages federally funded research and develelopment centres
  • Open Gateway Computing Environments project – NSF-funded collaboration between Indiana University, San Diego University, San Diego Supercomputer Center and Texas Advances Computing Center
  • SURFnet SURFConext Portal project – Netherlands, next generation collaboration infrastructure
  • OSS Watch – UK, Open Source Software advisory service
  • and several other individuals.

We are starting with three code bases from MITRE, SURFnet and OGCE and aim to have a single product within six months. This prevents the unnecessary duplication of effort across each of these organisations and ensures a viable shared infrastrcuture product for each participant.

In addition to these initial codebases the project plans to utilise code from Apache Wookie (Incubating). Some time ago OSS Watch helped the University of Bolton take their implementation of the W3C Widget specfication into the Apache Incubator. In the Incubator the project is able to focus on building community around its code and prove to the world that it is a viable open source project upon which people can build real systems. It’s been slow going for Wookie, the original Bolton team are ploughing forwards and have generated plenty of funding revenue from the project, but there still is no vibrant community around Wookie. This is due in part to the fact that the W3C Widget standards it implements are still not recomendations, but the project continues to develop and attract interest.

At OSS Watch we are really excited about this proposal. Not only will it provide signficant opportunity for the Wookie team to make their code more accessible for new use cases but it also brings together a signficant number of commercial and academic interests from across Europe and the US. The outputs of this project will be of significant value to our sector as we seek to produce userc configurable and context aware interfaces to new systems.

Is UK education policy being dictated by publishers?

OSS Watch is funded by the Joint Information Systems Committee (JISC) to provide advice and guidance to the higher and further education sector with respect to open source software. The JISC is funded by the Higher Education Funding Council for England (HEFCE) who recently conducted a review of the JISC.

The HEFCE report was published yesterday. In the main I find it to be sensible and realistic and I welcome the vast majority of its recommendations. However, there is one paragraph that I find to be ill informed, and as a result, dangerous. In this post I wish to focus on that paragraph.

Before highlighting the offending text I would like to share, by way of background information, a few thoughts about the JISC and its relationship to open source software.

The JISC and open source

The JISC does some great work in relation to open source software. In particular it has funded OSS Watch since 2003, long before I joined the team in 2007. Our remit is to understand how and when open source is applicable to our sector. The goal is to help ensure the sector benefits from open source whenever and wherever appropriate.

In 2003 open source was not widely respected as a viable software development methodology. It was also thought that open source was somehow the opposite of commercial. Major closed source software companies attacked the open source development model rather than competing with specific open source products; at the same time SCO was trying to kill Linux in the law courts whilst marketing machines portrayed open source developers as long-haired, bearded social misfits working out of back bedrooms (usually in their parents’ house) – they weren’t to be trusted.


Today it is difficult to understand the foresight shown by the JISC in 2003.

Today there are a significant number of highly successful open source companies, some of which, such as Xensource, were born within universities (xensource was sold to Citrix for $500M in 2007). Furthermore, modern software development teams embrace the open development model found within successful open source projects. Even Microsoft, once the most vocal of anti-open source companies, is seeking to engage with open source communities and products as a part of its closed source business model.

As a result of the JISC’s desire to understand reality, rather than succumb to marketing messages from big companies back in 2003, it has been instrumental in the creation of policies and practices which have started to level the playing field for open source suppliers in our sector. It has successfully done this without shutting the door on closed source companies. The result is increased competition, which any good capitalist will know leads to improved quality and reduced costs.

The JISC has also worked hard to ensure that software outputs from research projects are sustained through open source models, where applicable. It has encouraged the debate about open source and open development of software, ensuring that the sector is better informed and capable of making important decisions.

In today’s world, where governments around the world are adopting open source policies, the JISC, through OSS Watch is, in my somewhat biased opinion, one of the best sources of unbiased, balanced information about open source methodologies, not just in the UK, but in the world. I firmly believe that our sector is better equipped to implement the government’s open source action plan than any other sector in receipt of public money.

More to do

Despite the JISC’s foresight there is still much to be done. Whilst the sector is better informed than most we still lag behind other countries and the private sector with respect to our successful adoption of open source, both as users and as developers. Here at OSS Watch we’ve long been aware of the need to provide a vehicle whereby software produced in our sector can be exploited and developed in the private sector, whilst still being of value to the education sector. We’ve been working to make this happen, and welcome the implied message in the JISC review to continue this kind of work.

Last year we ran the first edition of TransferSummit, a conference bringing together academic and commercial partners. This conference was 60% funded by the private sector; this year, when we run it in September, it will be 100% funded by the private sector. We have helped take software, such as Apache Wookie (Incubating) from the dark recesses of university repositories to the bright lights of successful open source foundations, where it has a chance to flourish amongst some of the world’s most important software projects and the commercial organisations helping fund them. We have advised and engaged with projects ranging from six-month prototype developments to multi-million-pound international collaborations. We’ve worked with universities, not-for-profits and for-profits.

We’ve done all of this, and much much more, because the JISC understands that open source has its place and is here to stay.

Signs of Rot?

OSS Watch was created under the previous government. Today we have a new government. A government that faces significant economic challenges. A government that has an opportunity to improve things, cut out the fat and really push things forwards. A review of the JISC was not just inevitable, but in my opinion, necessary. The review has now been delivered, and  is available for comment on the excellent JISCPress site (which is, by the way, is powered by which was JISC-funded and open source).

The report is timely and, in the main constructive. I find myself agreeing with most of the recommendations and am happy to report that, under the JISC’s guidance, OSS Watch is already well on the way to doing their bit to implement many of the recommendations.

However, there is one paragraph that I am, quite frankly, appalled to see in this report:

“JISC’s promotion of the open agenda (open access, open resources, open source and open standards) is more controversial. This area alone is addressed by 24 programmes, 119 projects and five services.[7] A number of institutions are enthusiastic about this, but perceive an anti-publisher bias and note the importance of working in partnership with the successful UK publishing industry. Publishers find the JISC stance problematic.” (see this paragraph in context on the JISCPress site).

I’m going to skip over the fact that UK publishers (private sector) should not be dictating how HE/FE spends its money (public sector). Instead I’ll focus on the fact that this demonstrates an unbelievable lack of understanding and a significant lack of research on the part of the review committee.

In this post I will remain focussed on my own area of expertise, open source, leaving others to comment on the open access, content and standards parts of this paragraph[1].

From an open source perspective I want to know:

Since when has the “UK publishing industry” been able to dictate how our sector produces and consumes software?

Open source software is a software development methodology which is protected by a software licence [2]. It is a methodology that many believe brings significant benefits including increased innovation, reduced costs and increased quality of software, increased potential for self service or mixed economy support, empowerment of both small and large businesses, sustainability of research outputs and the breaking of monopolies. It drives economic growth and encourages the sharing of tacit knowledge.

In short, open source software is, in today’s world, an important fixture of the information technology and research industries.

Closed source software companies are no longer running scared from open source. Even the most aggressive of proprietary software companies are embracing open source as a fundamental part of their business models, both in driving markets and in university collaborations. Some are making multi-billion-dollar acquisitions in order to be able to do so.

The JISC knows what is right

The JISC is a thought leader in relation to openness in the higher and further education sector. I trust that in its planning of future activities it will strike this paragraph from its mind and continue to explore all aspects of openness in a balanced and unbiased way.

Failure to do so will be a considerable blow to the sector.


[1] I'm avoiding the ethical arguments for Free Software so as to remain focussed on the economic arguments;
    however, we really should keep the ethical arguments in mind
[2] Please feel free to post comments and link to your thoughts on the other aspects of openness
    in this paragraph - I feel certain you are just as angry as I am, make your voice heard

Open Source: we are buying, but are we engaging?

We recently completed our 2010 national survey of open source in the UK academic sector (the full report is currently being finalised). This post examines the extent to which suppliers to, and staff of, UK universities and colleges contribute to open source as a matter of course. This kind of engagement is important, since it realises the maximum benefits of open source software.

Our 2010 survey has shown that there has been another significant increase in the number of organisations with a policy to consider open source solutions during procurement. This is due to a combination of factors, such as the government’s open source action plan, our own work here at OSS Watch and the sector’s success with open source Virtual Learning Environments (Moodle has once again taken a significant share from closed source Blackboard/WebCT).

Alongside this increase in open source friendly policies, we are seeing a smaller, but still significant, increase in the amount of open source in use within these institutions. However, the balance is still firmly with closed source solutions. The reasons for rejecting open source remain fairly consistent with previous years’ results. The top three reasons for rejecting open source are lack of support, interoperability/migration problems and lack of staff expertise.

This is a pattern that is also visible in non-academic sectors. Put simply, people are becoming increasingly comfortable with open source as a viable way to develop software, although there is still room for improvement where suppliers are concerned. As a result, new companies are springing up to fill the gap and  venture captialists are happy to support them as shown by the increasing level of investment in open source related companies.

All this is very comforting. It means that as we move forwards, universities and colleges will be able to satisfy more of their needs using open source supplied and supported by appropriate third parties. However, in some cases, particularly for Higher Education, where IT departments can be large, a reliance on external providers may be a limiting factor when considering the benefits of open source beyond lower licence fees.

One of the key advantages of open source is that enhancements can be made to the software and then submitted upstream. A good open source company will manage this process for you, but in these circumstances the customer remains insulated from the core product in much the same way that they are with closed source software.

This is not necessarily a problem and can certainly bring the benefit of reduced costs that result from a more efficient development process. However, it often makes sense for staff to become actively engaged in the projects, particularly where the product has been modified for local use.

UK universities and colleges already innovate around teaching and research methods. Organisations like the JISC exist to manage investment of public money for such innovation. Open source provides a means for these innovations to find their way directly into the software in use and thus increase the return on investment in those solutions by making them available to all.

Whilst we are seeing an increase in open source friendly policies and actual use, we are not seeing a similarly strong growth in universities’ policies relating to staff engagement with open source software development. Where local innovation is taking place, it makes sense to actively engage with the open source community. For example, Stuart Lee, director of Oxford University Computing Services, told audiences at the recent FutureCampus event in Kuala Lumpur: “We have to develop our own systems off the shelf for things like tutorial recording.” Being able to integrate those systems with other software in use at the institution is critical to their success; this is what Oxford is doing with its Sakai Virtual Learning Environment and it is certainly reaping the rewards.

Ensuring that local innovations are closely embedded with the upstream project helps ensure that upgrades of systems are reasonably painless and it enables others to use, maintain and develop the innovative new features. It is therefore important that when procuring open source software solutions you also plan to properly resource collaboration work.

The JCP is Dead to me, Long Live Java

I’m a great believer in community, openness and transparency. I have lived the majority of my life believing in teamwork, collaboration and honesty.

When I was a schoolboy I played Volleyball. My coach taught me the importance of working hard within a team and, as a result, I was lucky enough to be selected for the England Schoolboys Squad. During the final squad selection process I suffered a pretty bad injury that prevented me from participating in the traning sessions. Rather than sit at home sulking I took my coaches advice and helped the remaining players demonstrrate their skills. I worked hard to both hide my frustration and ensure that the team was prepared to play without me.

On the day the final squad was selected I was the first to be called into the Managers office. Naturally I expected to be dropped, I wasn’t fit. Instead of dropping me the Manager explained that a team needed motivators and leaders as well as raw talent. Apparently he had seen two of those three qualities. To my amazement he asked me if I would take the role of Vice-Captain, focussing on team spirit and cohesion.

I was proud and amazed, but more importantly I’d learned a great deal about the importance of teamwork and collaboration.

A few years later my fun seeking took a turn towards some of the less healthy pursuits in life. Music became more important to me than sport and, after a series of false starts, I ended up managing a Dub Reggae band based in the crescents of Hulme in Manchester. This area was a horribly run down and deprived area, but it was a place of wonderful community and togetherness (if anyone cares the ExHulme site is devoted to how the area was back then, there’s even a photo of the band in its early days, with a very flattering although not quite true heading).

The band was called Community Charge, a play on a hated Tory policy of the time and a call to arms for the community to rally and charge against such policy. Through my time building the band and crew to a team of 16 people I learned that a handful of individuals with passion, vision and talent could rally huge numbers of individuals for a cause, entertain, have fun and even earn a living.

Fast forward a few more years and I discovered FidoNet and open source software as a means to reducing costs in organising and managing our tours. I immediately felt at home, the whole idea of people coming together to share skills in order to achieve more just felt “right”.

A few more years later endless touring had taken its toll. I went to University as a mature student in order to reinvent my career. I learned more from open source communities than from my lecturers. I became a committer on my first Apache project and I took an unexpected career move into academic research. My open source mentors helped keep me ahead of the curve. I contributed back and was rewarded with recognition and support that would have been far too expensive otherwise. I became an independent contractor and never looked back.

As a Java weenie I rejoiced when the 1998 creation of the Java Community Process (JCP) promised to allow the future of the language to be openly defined. Whilst the language itself wasn’t open source, at least the process for defining the language was open and reasonably inclusive.

More fast forwarding and Sun Microsystems announced that they were going to open source their Java implementation. The licence they chose was not a license I like to use, but OpenJDK is a free and open source implementation of an openly defined language. What’s not to like?

I’ll tell you what’s not to like – there’s a trap.

A trap that many in the community were not recognising. There are hidden restrictions that mean I (and you) can’t modify OpenJDK to suit our needs. If we do modify it we have to choose between either remaining protected from patent litigation or conforming to the GPL, the chosen licence for OpenJDK.

Similarly you can’t create an independant open source implementation of Java and protect users from patent litigation whilst also conforming to the Four Freedoms and/or the Open Source Definition.

This trap was put in place by Sun Microsystems and The Apache Software Foundation (ASF) fought hard to remove it. The ASF has served on the JCP Executive Committee for the past 10 years, winning the JCP “Member of the Year” award 4 times, and recently was ratified for another term with support from 95% of the voting community. The majority of the EC members, including Oracle, have publicly stated that restrictions on distribution such as those found in the Java SE 7 license have no place in the JCP

Sun did not remove the trap (despite a contractual obligation to do so) but they chose not to trigger it either. instead they chose to keep it primed for a day when it might be sprung.

Today Oracle own Sun Microsystems. One of Oracles first actions was to make it clear that they were not going to change the licencing terms for Java (despite a contractual obligation to do so). Even worse, Oracle sent clear signals about their strategy for Java – they were going to trigger the trap.

Since none of my business activities have ever made me rich I’m not about to tell Oracle how to run their business. However, I do claim to know a thing or two about openness, transparency and fairness.

Oracle are free to play the closed game with Java, but I object to being lied to.

The java specification is not open, OpenJDK is not open – Oracle should stop the lies.

I’ll skip over the fact that Oracle objected to the trap when they might be caught in it, but are willing to use it now they own it.

I’ll also skip over the fact that James Gosling, the creator of Java, has quit Oracle over their handling of the Java language team (Gosling told eWeek that “Oracle is an extremely micromanaged company. So myself and my peers in the Java area were not allowed to decide anything. All of our authority to decide anything evaporated.”)

Instead I’ll just add my support to The Apache Software Foundation who have resigned from the JCP EC. I’ll also add my support to the two distinguished individual members, Doug Lea and Tim Peierls who have resigned in protest over the same issue.

I object in the stongest possible terms, to Oracle claiming that Java is open when in fact it is “proprietary technology that must be licensed directly from the spec lead under whatever terms the spec lead chooses.”

The JCP is dead, will Java continue as a proprietary technology or will the community step up?

Disclosure: I'm a member of the Apache Software Foundation. In this post I speak entirely as an individual, 
not as a member of the Apache Software Foundation or as a member of the OSS Watch team.