Archive for April, 2007

Does sustainability in open source require commercial activities?

Published by Ross Gardler on April 26, 2007 in Development and Community. 2 Comments

Phil Nicholls recently blogged about my presentation at a JISC eLearning programme induction day. He has some nice things to say about my presentation, but one thing caught my eye and prompts this blog response (I’ve made some other comments in Phil’s blog).

Phil asserts that communities “grow when the common interest appeals to outsiders.” I fully agree and this is why having a complete tool set (such as mailing lists, version control, documentation and issue trackers) is critical in open source. Without them too much remains invisible to outsiders. This was the main point of my presentation.

However, Phil then goes on to state that “genuine sustainability comes from having a solid business case.” Here I do not agree. There is more than one route to sustainability in open source.
There are many sustainable open source projects that are not built on a profit driven business case.

Consider any project owned by a non-profit foundation, for example. Sure, non-profit does not mean there is no business case, but I think Phil is talking about a profit making business case since he states “Software Development costs money - pure and simple”.

[Phil, I’m sorry, if I misrepresent your intent here - either way the rest of my blog is still relevant since I will argue that the costs of the development need not be borne by the project]

I mentioned non-profit foundations. The one I will focus on here is The Apache Software Foundation. This focus is not because it is better or worse than other software foundations, but because as a member of the ASF I feel confident in describing its inner workings.

As a non-profit the ASF can accept cash donations, however, none of this money is used to pay developers. To do so opens up an opportunity for sponsors to influence the foundation’s direction and independence. All income to the ASF is spent on running the foundation. That is, it covers things like legal fees, accountants fees, bandwidth and infrastructure. Not a single penny goes to the projects or people working on those projects. So none of it can be said to be spent on software development, so who pays the software developers?

Well, if you are a committer on an Apache project you must be putting food on your table somehow, usually you will be being paid by someone. You will be an independent contractor, or you will be employed by small IT company, or a large IT company, or maybe, like me, you are paid by JISC and Oxford University funds via OSS Watch. The point is no ASF project is dependent on any one company. In fact, to graduate from the Apache Software Foundations Incubator you are required to show that the project has a wide committer base that is not dependent on a small number of employers or funding streams. In other words, you have to show that there is no single business case that is supporting the project.

So, ASF projects are sustainable because they provide a need to those “outsiders” and because there is a governance model and infrastructure that allows those “outsiders” to become “insiders”. The projects themselves have no business case.

Some OSS projects survive because the software itself is the business case (MySQL being a common example), but many others are sustainable because they enable a number of different business cases, and they are released under an open source licence that encourages (and enables) people enacting those business cases, which may be non-profit,  to cooperate on code that strengthens their individual organisations.

ITU recommendations available free of charge

Published by Stuart Yeates on April 23, 2007 in Development and Standards. 0 Comments

For a trial period, ITU recommendations are to be available for download free of charge. The ITU has more than a century of experience standardising communication systems and is now a UN body. In the computer world it is perhaps best known for the X.509 Public Key Cryptography and X.1141 Security Assertion Markup Language (SAML) standards.

It’s great to see the ITU taking steps to make the standards more widely accessible. Hopefully this will lead to an increased take-up and better implementation of it’s great security and privacy standards. Easy access to the standards is crucial to correct and robust implementation, and in the past even relatively low financial barriers to accessing standards may have limited access, especially to open source and academic developers.

Release Early, Release Often

Published by Ross Gardler on April 20, 2007 in Development and Community. 3 Comments

“Release early, release often” is a well known mantra of open source development. There are many reasons why it is important to release early and release often. Some of the more important ones are:

  • Early and frequent feedback from users
  • easy access to the latest and greatest features
  • Builds developer confidence
  • Shows genuine project activity
  • Manageable upgrade path for users

One of the projects I work with is Apache Forrest, that project has just released version 0.8. This version took nearly two years to get out the door. We released early, but have failed to release often.

Why did it take so long? In my opinion, perfectionism was the main problem.

We wanted the 0.8 release to be close to perfect. However, since a number of developers use the software daily new features were being added all the time, often with limitations that we wanted to remove for a public release. We were suffering from the “shiny new toy” syndrome.

This pursuit of perfectionism in the project has caused considerable harm to the community. No releases means no visible progress, which means less interested users, which means less developers, which means less chance of releasing. It’s a vicious circle.

In the end we decided that enough was enough and we had to release Forrest as is. The catalyst in this decision was the imminent publication of a book on Forrest and an interview with a technology magazine that shamed us with the question of “why is 0.8 taking so long?”. The community put in a few weeks of hard work ensuring there were no really bad bugs left and we now have a release, new users, new feedback and, potentially, new developers.

Sure, there are some rough edges, but show me a closed source application that has no rough edges at the time of a new release. The advantage here is that Forrest is open source, if the edges are too rough for you help us smooth them over. The important thing is it works for the common use cases and a question to the user list will usually help identify a workaround if you hit a problem.

Release Early, Release Often is part of building a sustainable open source project, releases produce users, users sometimes become contributors, contributors make the project stronger. The downside of releasing early and often is that you need to manage your user expectations. Be clear about the true status of your release and make any known bugs clear in your documentation. Users don’t mind working around issues, if it is clear what issues there are.

Sun loses Java vote amid contractual issues

Published by Stuart Yeates on April 18, 2007 in Legal, Standards and Community. 4 Comments

Sun has lost a significant vote in the Java standardisation process, with the Java Community Process (JCP) document defining the next version of the Java language being voted down by other Java industry players. The key issue appears to be that with the contract for the Technology Compatibility Kit (TCK). The TCK is used to ensure that all implementations are compatible and that software can be written once to run anywhere, on any implementation of the Java technology on any platform. As it stands, the TCK contract appears to prevent full third party implementations of the Java technology being released under open source licences such as the Apache Licence and the GPL.

The issue came to a head when the Apache Software Foundation (ASF) wrote an open letter and a FAQ to Sun outlining to them frustration at the lack of progress on the issue. Members of the JCP Executive Committee also abstained from the most recent JCP vote. Red Hat, one of the JCP Executive Committee members, hinted that no further JCP vote would be supported until the issue was resolved.

There are some complex issues here, but what is clear is that Sun is being blocked from moving forward with it’s future Java plans by the other Java community members until it does what it has said it would do, and irons out the contractual issues as they relate to open source.

The impact of this on end-users in the short to medium term will be negligible, even if the dispute drags on for years, because the vote was for the next version of the Java language (version 6) and many end-users are only now getting up to speed with the very significant changes introduced by the current version (version 5). The impact on commercial technology partners may be more noticeably, since on-going difficulties with Java would enable alternative languages to increase their gains.

The impact of a resolution to this that allowed full open source implementations of the Java technology would be hugely increased support for Java on open source and POSIX platforms such as Linux, MacOS X and FreeBSD. In the medium to long term these implementations are also likely to prove cheaper and more robust alternatives to some of the commercial Java implementations, saving the commercial players money.

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 ;-)