Monthly Archives: August 2010

Open innovation tactics and incentives applied to software

Posted on by
3

A very interesting blog post was published on the 100% Open website about 7 tactics and incentives for open innovation. It struck me how well these all apply to open source software projects. So I’ll discuss all 7 of them from the perspective of open source, but make sure you’ll also read the original post for the original, more generally applicable view on these tactics and incentives.

1. Share both Risks and Rewards

When participating in an open source project you are largely in the same boat as all the other contributors to the project, therefore sharing the risks among each other. If a release is delayed or major bugs are introduced in the software, everybody suffers. However, some open source licences allow you to add your own private rewards by building your own customization of the software without contributing it back to the project. It is a bad idea to do so because when you let your code deviate from the project’s code you always end up with more complex migration paths which makes it harder to keep profiting from the efforts of the community.

2. Tap into Intrinsic Incentives

Intrinsic incentives are extremely important for open source software projects. There is still a widespread misconception that open source software is being developed by hobbyists where there is no money involved. This is not the case, because a large majority of the code in open source software projects is being developed by people who are paid by their employers to do so. This is also true in the educational sector in the UK, where software projects are being fund by the likes of JISC and the research councils. Nevertheless, for any sustainable open source community intrinsic incentives are very important. For example in the Apache Software Foundation, when a contributor becomes a committer to an ASF project they personally become one and never as an employee of some company X. Being part of a community that builds cool software is just great and having a culture within the project that feeds into that is therefore extremely important. A nice illustration of this Dan Plink’s TED talk on motivation. He shows in a very powerful way that highly skilled people are not mainly motivated by money, but by being challenged and by the opportunity to develop a mastery.

3. Don’t Expect Something for Nothing

For an open source software project to be truely sustainable, external contributions and engagement from new participants are extremely important. Usually, a public mailing list or forum is the first entry point for potential contributors. Although it is likely that people first ask questions on these lists rather than answering them, in a healthy project all participants help out each other. This makes the project scalable and is one of the reasons why it does not necessarily takes a lot of time to open up a software projects to the outside: if you manage to engage new people they will help out others and that way a truly sustainable community can develop.

4. Ask Engaging Questions

People or companies that are involved in open source projects never have completely overlapping problems and therefore it is not always clear which solution is the most appropriate for all of them. Moreover, if you encounter a project that provides a lot of the functionality you need but not all of it, there are very effective mechanisms to discuss the features of the project. Mailing lists and forums are used widely to engage in discussion and find ways of merging features different people need. Of course, if you require a specific piece of functionality, it is up to you to build it and contribute it to the project. But discussing the requirements and problems of different people can lead to interesting insights that can be valuable to the whole project. Due to the distributed nature of open source software projects people with very different backgrounds will bring their own viewpoints, which can lead to more creative solutions and spark new ideas.

5. Build Business Empathy

Open source projects can thrive or be damaged by reputation just like businesses. The plea in the original post for an honest and human approach is very well applicable to open source projects. But in many cases it comes more natural to open source projects to have that approach because, as mentioned earlier, there is already a focus on individual contributions incorporated in the dna of many projects. For new projects or projects that are working towards sustainability it is important to define processes that support this approach and to fix it in a governance model document, so it is clear to everybody what they can expect from the project, thereby providing a more level playing field.

6. Target Quantity before Quality

This tactic is well-known in software where it is more commonly known as the ‘Release early, release often’ mantra. If you are active in a young open source software project that is still in its infancy, getting a release out is a very effective way of engaging new contributors and is therefore a huge opportunity to let your project grow to become sustainable. Releasing early makes the barrier to entry lower for new users, albeit that the first few releases will be of lower quality and contain less features. As long as this is clearly communicated to the (prospective) this need not be a problem but can help the project as a whole move forward more quickly.

7. Find Your Top 1%

In the original post the 100% open team explains that out of 100 users, there are usually only 10 who are really engaged and just 1 who will provide a substantial contribution. Although the percentages may vary, also in open source software projects it is very important to identify the users of today that are most likely to become the contributors of tomorrow. It is essential for any open source project to engage those users and try to have them contribute to the project and perhaps even become a committer to help achieving sustainability in the long run.

OSS Watch community development manager Gabriel Hanganu published an excellent briefing note recently, in which he explains how the sustainability lessons can be appied to research infrastructure. Gabriel’s analyis shows that a lot of the tactics and incentives for open innovation are also important in that space.

Oracle vs Google: Triple Damage!

Posted on by
6

In Norse mythology it’s predicted that the final days of the world will see a supernatural wolf called Sköll swallow the sun before helping to kill Odin, the mightiest of the Gods. In a move that will surprise no ancient Vikings, Oracle – the gigantic database corporation that up swallowed Sun Microsystems – has made a wide-ranging patent and copyright infringement complaint (pdf) against the mighty Google Inc. that may or may not indicate that the world will soon end.

The complaint concerns the use of Java-related technologies in Google’s Android mobile Linux platform, and the details are ugly indeed. Ever since Sun released Java back in 1995, they (and now new owners of the Java IP Oracle) have been looking for ways to make some money off it. Java was intended to provide a solution to the problem of platform fragmentation – the unfortunate situation that means software developers have to write many differing versions of their code to cater for all the different varieties of computing environment out there (Macs, Windows, Unix etc). Sun’s Java provided a layer of virtualisation, so that in theory you could write your Java code once and have it run anywhere, confident that the virtualisation layer (or ‘virtual machine’) on each system would handle the complexities of translating your program for use on the local hardware.

It didn’t help that the technology grew in ways that Sun had not really predicted – seeing far more adoption on the server than in the client area at which it was initially targeted. When mobile phones and set top boxes began to become more powerful and able to run consumer software, Sun launched a ‘Micro Edition’ (ME) of Java that was intended to coalesce this massively fragmented market. This ought to have given Sun a strong, commercialisable position as gatekeeper between software developers and a wide spectrum of hardware platforms, but in the event the technology was not equal to the vision and developers still needed to tweak Java ME software to run efficiently on each platform, causing much woe and despondency. Nevertheless, the mobile market remained Sun’s core focus in the struggle to wring money out of Java. At the same time, Sun was positioning itself as an open source-friendly company, and was therefore receiving quite a lot of pressure from the open source community to put its money where its mouth was and release Java under an open source licence. In 2006, when Sun finally did release Java as free software, the strategy to monetise mobile was still very clear in their licensing choices.

The standard edition of Java – designed to run on desktop computers and servers – was released under the GNU GPL with the so-called ‘Classpath Exception’. This was a licence created by the Free Software Foundation’s GNU project to cover their own free software implementation of the core Java-compatible class libraries (essentially toolkits of functionality for building complex applications). The exception meant that you could use the GPL-licensed libraries to build your applications without having the copyleft requirements of the GPL transmit to your own code. However for the ‘Micro’ edition of Java, Sun used a dual licensing model, leaving out the exception from the GPL version and selling commercial licences for device manufacturers and developers who wanted to write mobile software which was not compelled to be GPL.

Thus, when Google decided it wished to use Java as the development language for software on their eagerly anticipated mobile Linux platform Android, one could argue that it should – finally – have been a huge payday for Sun. However it was not to be. For whatever reason, Google did not want to go down the road of licensing and mandating the use of Java ME. Instead, they took an open source implementation of Java called Apache Harmony and made some variations to it of their own. First they created their own virtual machine called Dalvik, which ran a different kind of code to a standard Java virtual machine (a tool in the Android development kit converts standard Java ‘byte-code’ to the new Android format). They also added many new libraries to support more modern functionality such as Bluetooth and the 3D graphical acceleration technology OpenGL. Everyone – except Sun – was happy. Developers did not need to buy commercial Java ME licences from Sun but could still use the Java skills they had developed over the last decade. Google did not have to rely on another company to mediate their relationship with developers and handset manufacturers. Sun had lost out again. Perhaps their previous highly-publicised love affair with open source meant that they could not easily start suing a competitor over a piece of open source software? Finally in early 2010 a financially embarrassed Sun was acquired by Oracle.

Oracle itself has some open source credentials – they run a proprietary/open dual licensing model for the product Berkeley DB. However the majority of their business is unashamedly closed source and therefore ever since they acquired the Java IP with Sun there has been much speculation that they would come after Google over Android and Dalvik. The complaint that has finally emerged is a wrathful document indeed, accusing Google of wilfully infringing on Sun/Oracle’s patents and copyright and seeking the seizure of all infringing devices, code and even advertising materials. Due to what they see as the egregious cheekiness of the infringement, Oracle want punitive triple damages.

What makes this case interesting – apart from the enormity of the two combatants – is the range of the counts. Along with seven fairly generic technology patents dealing with program compilation and execution, Oracle are also alleging copyright infringement. This would normally imply – in the case of software – that Oracle believes that Google (and quite possibly Apache Harmony) have incorporated verbatim sections of their code in their own products. Here, though, it’s hard to see how that could be the case. As an open source project Harmony’s source has been available for the world to see for many years, and one might have expected any literal code inclusion to have been noticed and acted upon a long time ago. As for the parts added by Google, it seems extremely unlikely that a company with Google’s resources would risk any kind of ‘code contamination’. Dalvik has been widely reported to have used ‘clean room’ reimplementation in its creation – meaning that no-one with any experience of (in this case) Java’s internals would be allowed to contribute any code to the project. The only point of connection between the original and the new code in a clean room reimplementation is the specification – the detailed but high-level description of how the software should operate. Could Oracle be suing over the use of the specification?

Oracle’s complaint says this:

38. The Java platform contains a substantial amount of original material (including
without limitation code, specifications, documentation and other materials) that is copyrightable
subject matter under the Copyright Act, 17 U.S.C. § 101 et seq.

39. Without consent, authorization, approval, or license, Google knowingly, willingly,
and unlawfully copied, prepared, published, and distributed Oracle America’s copyrighted work,
portions thereof, or derivative works and continues to do so. Google’s Android infringes Oracle
America’s copyrights in Java and Google is not licensed to do so.

…so specifications are explicitly listed as a variety of copyright work Oracle considers itself to hold in Java. This is of course true – specifications are copyright works as they are original and complex. The documents themselves are clearly ownable and their owners rightly get peeved if people copy and distribute them without permission. Here’s another quote from the Java Specification Participation Agreement – the agreement which allows third parties to get involved with defining and implementing new parts of Java:

For any Specification produced under a new JSR, the Spec Lead for such JSR shall offer to grant a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, irrevocable license under its licensable copyrights in and patent claims covering the Specification (including rights licensed to the Spec Lead pursuant to Section 4.A and 4.C) to anyone who wishes to create and/or distribute an Independent Implementation of the Spec.

(JSRs are Java Specification Requests – basically descriptions of new features). Taking the language of the complaint along with the language of the participation agreement, it seems quite possible that Oracle are going to argue that any implementation of their specification is a derivative work of that specification and therefore needs a licence from them. This kind of copyright action – essentially claiming a high-level copyright in the design of the technology – is controversial and difficult to win. The more abstract the entity for which you are trying to claim copyright ownership, the harder it is to show indisputable infringement. Verbatim code copying is fairly easy to spot and demonstrate; the duplication of structures and interfaces is harder to demonstrate and is always open to arguments that there is no substantial relationship between the design and the implementation.

Of course, it may be that Oracle does have evidence of more concrete low-level copyright infringement, despite my personal instinct that that is unlikely. However if they will be arguing on the difficult basis of ‘specification infringement’ I have to wonder why. Is it a plan to bolster a set of patents they are unsure about? Somewhat selfishly part of me hopes that the case will play out publicly and not be settled behind closed doors, if only to clarify this controversial area of copyright.

Top tips for a successful open source project

Posted on by
Reply

Damien Katz, whose Apache CouchDB recently hit 1.0, provides some excellent tips on creating a successful open source project in his blog Getting your open source project to 1.0. Drawn from five years’ experience, the tips include general advice interwoven with examples from the project. He begins with the fundamental question, Why?, explaining that a successful project needs a reason for being – a clear idea of what problem it solves – and you need to figure this out and explain it.

Almost as important as knowing what you are is knowing what you’re not: ‘Stating clearly what your project isn’t trying to do or be helps make it much easier to explain what you can’t implement or change …. and to focus on what you actually are.’ Next, he advises, ‘don’t expect to attract anyone to your project until you have a substantial amount of working code that isn’t a big ball of spaghetti’. Code comes first, but don’t try to do everything (well), as you’ll probably never actually release anything: ‘You’ll need to pick a few things that you do really well and execute on those things.’

On the subject of community, Katz encourages you to ‘make sure the people who show a strong desire to contribute aren’t ignored, and feel like their efforts will eventually amount to something’. But bear in mind, he warns, that community is often incompetent. You will sometimes need to hurt people’s feelings for the sake of the project because ‘the quality of the community is more important than its absolute size’. ‘Our committers,’ he stresses, ‘are our first line of defence against poor code and design.’

In the end, though, it’s up to you to use your brain and ‘figure out what’s actually important to you, your project and its community … Projects can’t follow cookie cutter rules.’

One tip that could be added to this list is to contact OSS Watch. We can help you create a successful open source project by providing advice every step of the way. In addition, our briefing documents offer invaluable information on everything a new project needs to consider, including governance models, sustainability, how to build an open source community and licensing.

Why it makes sense to sustain your project beyond its initial funding

Posted on by
2

Scott Wilson from CETIS, University of Bolton showed in a very compelling way at TransferSummit/UK 2010 how it can be strategically important to sustain your publicly funded software project beyond its initial funding period. The figures in Scott’s slides say it all: by investing a tiny survival budget to sustain their Wookie project after the funding would run out they managed to secure about £700k of new funding from two European (FP7) projects.

How they achieved this? Their overall project, although being a bit specific, implemented the emerging W3C widget standard which is relevant to a wider community. They managed to attract some interest from outside the initial project group. OSS Watch helped them with community development and identifying potential sources of value and funding. A good home for the project was found at the Incubator of the Apache Software Foundation, thereby attracting much more interest and contributions from parties inside and outside the academic sector.

Currently, Apache Wookie (Incubating) is a thriving project and has seen many bugfixes and new features contributed by the community. It resulted in a lot of visibility for the University of Bolton outside the regular channels, leading to new partnerships with the commercial sector and universities inside and outside of the UK. Last but not least they managed to secure a lot of new project funding from European sources.

Sustaining your software project beyond funding is not just morally right or something that should be done so your money is not spent wastefully. Scott’s example shows that it is very much in the interest of the institutions and the project team to sustain the project. So think about how your software development project can be sustained after the funding has run out or which part of it is most potential to generate a viable community. And get in touch with OSS Watch; we are here to help.