Archive for April, 2007

Does sustainability in open source require commercial activities?

Published by Ross Gardler on April 26, 2007 in Community and Development. 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 Community and Development. 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 Community, Legal and Standards. 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 Community and Development. 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 ;-)

The machine is us[ing us]

Published by Ross Gardler on April 11, 2007 in Community and Discussion. 0 Comments

Web 2.0 is about the machine using us…

No…

Web 2.0 is about the machine being us…

This video will explain all.

Rich Ajax Platform (RAP)

Published by Ross Gardler on April 8, 2007 in Development and Software. 0 Comments

It’s not that often I get to do some real, exploratory hacking anymore. It’s a shame, I love just playing with new stuff, but other responsibilities keep me away from it much of the time. However, recently I had a play with the Eclipse Rich Ajax Platform (RAP) project (currently in the validation phase of the Eclipse incubation process), boy is it cool.

RAP provides a wide range of of GUI widgets for creating web applications with a very rich user interface (using AJAX for those who care). So what? There are plenty of AJAX libraries around, what is special about this one?

There are a number of things that make RAP interesting. One of the key issues, the one I focus on here, is that the API of the RAP widgets is drawn from the Eclipse Standard Widget Toolkit and the JFace User Interface framework. Couple this with the excellent OSGI framework and you have a delivery platform that allows you to deploy your application as a desktop or a web application with the drop in replacement of the user interface plugin.

If you have already developed a desktop application using the Eclipse Rich Client Platform then you will be comfortable with RAP almost immediately.

Add to this mix the Eclipse Embedded Client Platform (eRCP) and the same application can be quickly deployed on mobil phones or PDAs.

The Rich Ajax Platform is not the best choice for every application. It scales reasonably well, but if you are looking at 100,000+ simultaneous users it’s not really for you due to the heavy server load, but for apps that you want to deploy in many different guises it could be the answer.
I’m looking forward to having a proper play with this as the application framework for the forthcoming OSS Watch project, Simal (more on that soon).

GPLv3 and Apache License Compatibility

Published by Ross Gardler on April 6, 2007 in Discussion and Legal. 0 Comments

As most readers will know by now the GPLv3 third discussion draft is available.

For me it contains one very big surprise, this is discussed on page 33 of the rationale document for the third draft which contains the following words:

We regret that we will not achieve compatibility of the Apache License, Version 2.0, with GPLv3, despite what we had previously promised.

Why is this such a surprise (not to mention disappointment) ? Well the clue is in the quote above, specifically:

despite what we had previously promised

I was originally very excited to hear that one of the goals of the FSF with respect to the GPLv3 was to achieve compatibility with the Apache License (see the transcript of Richard Stallman speaking at the 5th international GPLv3 conference). I was very distressed to discover that this had not been possible in the third draft.

Allison Randal is a member of the board of the Perl Foundation, she is one of the first high profile experts within open source brave enough to comment on this issue. Remember, Perl is dual licensed under GPL and the Artistic License, so one would assume she is not overtly biased towards the Apache License, therefore, I reproduce her conclusion below. I strongly suggest that readers visit her full blog entry since it provides much more detail.

Is the FSF saying that when a downstream company takes on the legal burden to indemnify a piece of GPL software, they expect the developers to also take on that legal burden? Or, in the case where the FSF is the copyright holder, that they intend to take the legal burden of indemnification themselves? Somehow that seems unlikely, but they claim that the GPLv3 differs from the Apache License on exactly this point.

I give them the benefit of the doubt, but it sounds to me like the FSF really had to stretch to find some terms that might make the Apache License incompatible.

The good news is, this is not the end of the line. There is another draft to come from the FSF, the ASF are working hard to see if there is anything that can be done on their side of things, and, as you would expect dialogue also continues between the FSF and ASF.