Open innovation tactics and incentives applied to software

Published by Sander van der Waal on August 27, 2010 in Community and Strategy and Policy. 0 Comments

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!

Published by Rowan Wilson on August 19, 2010 in Legal. 6 Comments

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

Published by Elizabeth Tatham on August 15, 2010 in Community and Discussion. 0 Comments

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

Published by Sander van der Waal on August 3, 2010 in Community, Development and Strategy and Policy. 2 Comments

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.

My pacemaker will not be tweeting just yet

Published by Rowan Wilson on July 23, 2010 in Legal. 0 Comments

June 2007:the Free Software Foundation (FSF) publish their third ‘discussion draft’ of their proposed new licence, the GPL version 3. Alongside this new draft is published a so-called ‘rationale’, which helpfully explain the changes made since the last draft. Originally the FSF had planned to require all forms of encrypted GPL software to be accompanied by appropriate decryption keys, to prevent device manufacturers from putting GPL software in their products but making it impossible to end users to modify it. Many people had complained about this however, saying that it undermined a lot of legitimate uses of cryptography on software code. The FSF responded by limiting the requirement only to ‘User Products’ in its next draft, and went to a lot of trouble to define this subset of GPL-containing items. In the rationale document(pdf), they commented:

We considered including medical devices for implantation in the human body in the User Product definition. We decided against this, however, because there may be legitimate health and safety regulations concerning inexpert and reckless modifications of medical devices. In any case, it will probably be necessary to convince medical device regulators to allow user-modifiable implantable medical devices. We plan to begin a campaign to address this issue.
Some commentators made fun of this aspiration. Ed Burnette of ZDNet commented:
This paragraph demonstrates both the pragmatism that is creeping into the FSF (concerns for ‘reckless modifications’) and the ‘tin-foil hat’ eccentricity that has always been a part of Stallman’s free software movement. If nothing else, the activities of the FSF and its colorful leader will continue to give us plenty to talk about in the years to come.
Well, years passed and there was little public evidence of this campaign… until this week. On Wednesday the Software Freedom Law Center (SFLC) published research which argues that the US Food and Drug Administration (FDA) should require all manufacturers of Implantable Medical Devices (IMDs) to publish the source to the code in their products. The paper cites many chilling examples of software reliability and security problems with IMDs:
While there has yet to be a documented incident in which the source code of a medical device was breached for malicious purposes, a 2008-study led by software engineer and security expert Kevin Fu proved that it is possible to interfere with an ICD (implantable cardioverter defibrillator) that had passed the FDA’s premarket approval process and been implanted in hundreds of thousands of patients. A team of researchers from three universities partially reverse-engineered the communications protocol of a 2003-model ICD and launched several radio-based software attacks from a short distance. Using low-cost, commercially available equipment to bypass the device programmer, the researchers were able to extract private data stored inside the ICD such as patients’ vital signs and medical history; “eavesdrop” on wireless communication with the device programmer; reprogram the therapy settings that detect and treat abnormal heart rhythms; and keep the device in “awake” mode in order to deplete its battery, which can only be replaced with invasive surgery.
In one experimental attack conducted in the study, researchers were able to disable the ICD to prevent it from delivering a life-saving shock and then direct the same device to deliver multiple shocks averaging 137.7 volts that would induce ventricular fibrillation in a patient. The study concluded that there were no “technological mechanisms in place to ensure that programmers can only be operated by authorized personnel.” Fu’s findings show that almost anyone could use store-bought tools to build a device that could “be easily miniaturized to the size of an iPhone and carried through a crowded mall or subway, sending its heart-attack command to random victims.”
Chilling stuff indeed. The paper goes on to argue that FOSS is inherently more secure than closed source, and that source code for IMDs ought to be available for all to see both for greater security and to avoid problems if a device manufacturer goes bankrupt and disappears.
This is not quite the campaign promised back in 2007, however. Notable by its absence is a call for IMDs to actually be user-modifiable:

Specifically, we call on the FDA to require manufacturers of life-critical IMDs to publish the source code of medical device software so the public and regulators can examine and evaluate it.

The paper uses the argument that FOSS is more secure to underpin a request for publication, not full FOSS-licensing. Presumably any errors detected in the code would have to be notified to the manufacturer for actual repair. This is, of course, not particularly surprising. Calling for the FDA to allow individuals to flash their pacemakers to tweet their heart rate would probably attract the same kind of ridicule that Ed Burnette engaged in three years ago. While some activists – including possibly Stallman himself – may regret this reticence, it is probably necessary in order for the request to be taken seriously.

The increasing importance of open source for the EU

Published by Sander van der Waal on July 22, 2010 in Community, Discussion and Strategy and Policy. 1 Comment

An interesting video message from Neelie Kroes, European Commissioner for Digital Agenda, was published last week. The message was recorded in support for GNOME and its events, such as the upcoming GNOME Users’ And Developers’ European Conference.

In this video, she reflects on times when open source was not considered in public organisations, because of issues that were perceived such as lacking technical support and worry about IP infringement issues. The consequence was that officials were discouraged from selecting software on merit. There may have been open source products out there sufficiently fulfilling the requirements, but this was not enough to be considered by public organisations.

But times are changing and it’s meaningful that Kroes, who is also the Vice-President of the European Commission, acknowledges this. She mentions a few developments to illustrate this point. For example, OSOR provides unbiased advice and guidance on the use, development, and licensing of free and open source software (sounds familiar?). It also contains a ‘forge’ providing a home to open source software projects.

Kroes also mentions the European Interoperability Framework (EIF) as an example. This is interesting because there is a lot of debate and lobbying going on regarding version 2.0 of EIF. A few months ago Glyn Moody analysed a leaked draft of EIF 2.0 highlighting the confusing and vague references to openness and open source software. More recently, the New York Times wrote how companies like Google, IBM and Red Hat are lobbying for inclusion of open source software in the document, which is perceived as a strategy to break Microsoft’s hold. It probably won’t be until the end of the year before the final version 2.0 of the EIF document is released. Although the closeness around the drafting process of this document does not look very promising, it may be a good sign that Kroes includes the framework in this speech.

Additionally, Kroes stresses the importance of strong communities and the role they play in shaping Europe’s digital future. And now the EU commission has the opportunity to put the money where their mouth is, as it recently announced to fund projects worth 1.2 billion Euros to be launched in 2011. This is a genuine opportunity to invest in open source software and in open source companies to make sure that the open source offering can compete better with companies that offer proprietary alternatives.

Grow your own veggies and keep an eye on your neighbour’s

Published by Gabriel Hanganu on July 14, 2010 in Community, Event and Strategy and Policy. 0 Comments

Last Saturday I happened to watch a TV program on the Hampton Court Flower Show. Among this year’s winners of the garden design competition was the Bangladeshi Allotment, a small garden designed by Jeff Travers with help from the Adelaide Community Gardening Club in Camden, N. London.

As Jeff explained, about 20 years ago the central Camden residents were offered a gardening plot in an attempt to counter the effects of the visually appalling derelict buildings and tall blocks of flats that dominated the area. People started growing vegetables, and over the years the plot became the hub of a thriving gardening community.

Bangladeshi women in particular became effective users of these allotments. They grew vegetables for their daily needs using techniques they had learned from their parents and grandparents in Bangladesh. For them gardening was a key source of food, and over the years they became experts in producing sustainable gardens with minimal financial investment. One way of increasing cultivation space was to build ramshackle supports that favoured the 3D expansion of the plants.

It was these string-bound wooden structures that intrigued Jeff Travers in the first place. He examined them with his architect hat on, but at the same time he was curious about their role in increasing vegetable production. By growing his own plants next to those of the Bangladeshi families, Jeff learned a lot about sustainable gardening using traditional techniques, such as saving seeds and using recyclable natural materials.

Jeff’s collaboration with the Bangladeshi women gardeners brought him a silver medal. The right topic in the right place at the right time, one might say. However, according to Jeff, designing and building the garden was not such a simple task:

It’s quite an architectural problem to translate Bangladeshi allotments to suit the Hampton Court setting. We’ve used the intensive Bangladeshi horticultural techniques in the growing of the plants, but we’ve arranged them in a way that conforms to the written rules of 18th century potager of which the garden of Hampton Court Palace was modeled.

This story is a good illustration of open innovation facilitated by connecting groups with apparently disparate sets of skills. To design his prize-winning garden Jeff put together the knowledge networks of the traditional Bangladeshi gardeners, the skills of their British offspring who adapted these techniques to the London context, and his own ‘architect-cum-gardener’ ability to translate these in the lingo of a professional garden design competition.

In fact such processes happen all around us at various levels. As Roland Harwood pointed out in his recent keynote at TransferSummit:

Many organisations are beginning to embrace more open and collaborative approaches to innovation. Inspired by the success of open source products such as the Apache web server and the Firefox browser, many multinational companies such as Procter and Gamble, Orange and IBM have made ‘open innovation’ – the sharing of the risks and rewards of the product development process with partners – a top strategic priority.

Academic institutions had been there long before the businesses:

The open source software movement has been a pioneer in product development which many others have sought to emulate. Like the open source movement, academic institutions have laid the foundations for a model of shared knowledge and incentives based upon reputation rather than ownership.

Increasingly however this academic model is fading out. As recent evidence demonstrates, especially in academic research funding and publication-driven assessment distort the natural balance between peer recognition and institutional hierarchy:

Research assessment exercise encourages individuals to publish independently, to keep things secret while there can be many advantages to their career, no matter if they have been funded publicly or not, because by doing that they appear to be better by the criteria used for measurement of the research assessment exercise. That’s a major cultural problem, because it makes it too difficult to persuade scientists to be open with their data, they fear losing it, and therefore their current position.

TransferSummit revealed that both academic and business teams are seeking inspiration from open development practice. More and more academic departments and businesses understand that by pooling together the expertise of their diversely skilled people they maximise opportunities for mutually beneficial innovation.

But understanding diversity in terms of domain or product expertise is not enough. While brainstorming with inter-disciplinary or professionally diverse teams can be productive, we need to bear in mind that innovation is not just generating new ideas. In fact, as Roland suggests, in the context of our expanding access to global knowledge, one’s expertise is becoming less important:

The cost associated with finding new knowledge is falling fast, to a point where in the not too distant future we can reasonably assume that all knowledge will be in principal accessible [...]. In this scenario our knowledge will no longer differentiate us as individuals or organisations.

The professional diversity of the innovation teams will remain important, but increasingly cultural diversity will become their true unique selling point. As Jeff’s success story implies, his prize-winning garden was less the result of him acquiring in-depth knowledge of Bangladeshi gardening techniques, and more of him experiencing this knowledge in action, in the ways his Bangladeshi gardening mentors had internalized and used it for their daily needs.

In other words, what is becoming important is the diverse cultural practice of the innovation team members, rather than just their external expert knowledge. More than just being clued in about growing veggies differently, the ideal candidates for open innovation will be eating their own grown.

TransferSummit – making open accessibility connections

Published by stevelee on July 8, 2010 in Community and Event. 0 Comments

Being involved with the TransferSummit was one of those experiences that I will look back on with great pleasure for years to come. Not only was the theme of innovation and collaboration through open source something  I have for long time wanted to see become reality in the accessibility arena, but being part of such a great team has been of enormous personal benefit. If only I could have concentrated more on all the talks and BOFs, but that would have required the TransferSummit to run 3 times so I could attend everything.

Of course one of key values of such conferences derives from the connections and discussions that go on between the presentations. Having spoken to some of the people who attended from the open accessibility space I’m really pleased to hear they wasted no time in connecting up. For example Garry Paxton of Straight-street.com said he found it extremely valuable and hooked up with folks like Matthew Lee of Pengwern Mencap National College. I’m extremely pleased to see the strong community of open accessibility collaborators that is forming in UK HE. I understand from those of the community present, that they found TransferSummit provided them ample food for thought and discussion opportunities.

Equally pleasing was that the TransferSummit hosted the rather impromptu introductory launch meeting of REALISE, a new JISC funded project exploring open innovation in accessibility software. EA Draffan and Peter Cudd from the lead institutions of Southampton and Sheffield met with Ross Gardler of OSS Watch (and chairman of the conference committee). There could not have been a more perfect setting for this first REALISE meeting.

I’m sure there must be other stories of successful connections made at the TransferSummit. Please do let us know about them in the comments to this post

TransferSummit – Industry and the Open Source Community

Published by Alastair Harper on July 5, 2010 in Discussion and Event. 0 Comments

Buildings that last are always open

How is the open source model like Oxford’s Sheldonian Theatre? Ross Gardler, in his introduction to the TransferSummit conference this June, put forth this theory: the Sheldonian, Christopher Wren’s greatest early work, required a huge range of transferred expertise and what was then the latest technology in its construction. A swath of different individuals’ skills were employed to produce a cutting-edge building that, finished in 1668, is still used today. The end result was not only a magnificent building but also new construction and architectural techniques shared with the craftsmen brought in. Ross’s point is that the University of Oxford looked outwards to leading figures in construction and architecture to fulfil their needs – and, with open source, this relationship between academic and business interest continues to flourish today.

A shared future

Traditionally, universities have been seen as research institutions not unduly concerned with value. But Ross hoped that at TransferSummit, those working in academic institutions and non-profit communities, and those working in industry, could show, over the course of two days, how both can work together to their mutual benefit.

These are exciting times to be involved with open source. As many mentioned over the two days of TS, the average person encounters Linux ten times a day without even knowing it, all thanks to a quiet revolution in industrial attitudes to the open source community. Many talks recounted the difficult journeys taken by companies over the last ten years, learning how and why to use open source software to deliver the most innovative products to their consumers. If companies are to produce their own Sheldonians they must look to open source.

Why industry is becoming more open

Matthew Langham spoke of his own experience of combining two very different worlds – the corporate and the open source. He remembers back in 2000 the difficulties he had as a software developer in getting his boss to embrace a new, apparently insane business plan: ‘We give away our code for free?’ But Matthew, who now runs a company connecting the corporate and open source worlds, explained the benefits of going open source: the strength the company would derive from allowing other people to improve its code, the advances made in their software that they could never have come up with alone, and, ultimately, how much more use their software would enjoy by being offered in this way. Open source provided their company with hugely increased exposure, and allowed them to make a good profit by offering support for their freely available products. Having proved the commercial viability of going open source, Matthew started suggesting these benefits to other companies, inspiring them to have a go too. He has found it easy to persuade them to try it out, but perhaps one of the biggest challenges has been getting them to admit that they do so. Phone companies, big banks and other organisations all embraced open source at a developmental level but were wary of admitting it to their employers and certainly of being evangelical about its benefits.

Of course, this is set to change. Matthias Stuermer’s talk investigated the ways in which Nokia has been playing with open source and Linux for the last ten years and how since 2005, they have been openly working with the open source community. One benefit of that relationship came about when the Nokia 770 was hacked to allow the use of flash cards as RAM – something Nokia’s own developers thought couldn’t work. They were then able to adapt the design to allow the feature.

An army of R&D

This ability to innovate as a community is also something that Phil Andrews spoke about. If SourceForge were to pay, as R&D, the 50,000 people they have involved in their community, the annual wages bill would come to £4.5 billion. He also pointed out that the number of coding errors generated within an open source community is much smaller than those produced by a closed company.

This change in approach can be seen outside of coding, too, as Roland Harwood from 100%Open pointed out in his keynote speech. His organisation encourages businesses to look at sharing their skills with very different industries, investigating how technology can be deployed in new and unrelated contexts. This use of ‘open innovation’ has led to companies such as McLaren F1 having their software used in hospitals and in air traffic control towers. Roland pointed out other examples – organisations like Virgin Atlantic embracing an unofficial group of around 50,000 customers who started their own community analysing the quality of Virgin’s services, from the website to their planes’ seating. By reaching out to and working with this community, they improved their services at an estimated 10% of the cost of doing so in-house.

But why should the open source community get into bed with business?

If the benefits of open source are clear for business, another question was raised and dealt with during the two days of TS  – what’s in it for the open source community?

Certainly, Simon Phipps fears that unscrupulous business practices can often destroy what makes open source brilliant. Having worked with Java and Sun Microsystems before becoming a board member for the Open Source Initiative, Simon has seen both the good and the bad of open source companies. He believes that the nature of open source is being undermined by some companies taking the benefits of others’ innovation without giving anything up of their own – such companies declare themselves to be ‘open core’ , which he sees as a euphemism for traditional closed software.

To Simon, in fact, such businesses are reptiles without souls or ethics. They can’t embrace the principle of openness for any reason other than to benefit from the growing marketing power of the term ‘open source’. They use open source as a way of making short-term savings rather than to generate long-term freedoms.

Companies must be honest

Some of these issues were dealt with by Gerv Markham from the Mozilla Foundation, which focuses on ensuring that no one company has control of the internet. Mozilla has an unusual corporate structure – a charity that wholly owns a number of conventional companies. Gerv has many suggestions as to how companies can be ethically involved with the open source community – for instance, Mozilla makes no distinction in worth between their paid members and those who volunteer. Even one of their security managers was not allowed into the Mozilla security discussion group until eight weeks after he had been hired – he had to prove his worth to the whole community, not just those who paid his salary, before he made the grade. Markham is also deeply aware of the importance of having a clear and transparent licensing scheme. It took many years to refine, but now users of Mozilla’s code get the choice of three different licences.

He also understands the ethical difficulties inherent in persuading volunteers to sign over copyright to an organisation, though, as Rowan Wilson pointed out, in his talk, that assignment of copyright is not the only way to manage IP in open source. Still, many companies have betrayed their volunteers’ trust by deciding that their ‘open source experiment’ has failed and absorbing the work of outsiders as they turn back into closed companies. Companies must avoid abusing open sourcers’ trust if they are to succeed in the open source world.

How companies are learning

The issue of earning and preserving trust is familiar to many previously closed developers attempting to make the transition to open source. Matthew Langham mentioned that it took about a year for his company to become welcome in the open source community, and that many large companies just don’t get how it works, expecting it to be an online pool of free employees. David Woollard, a senior software engineer at NASA, encountered similar difficulties. Only in 2005, where NASA used the skills of two big open source developers already on their staff (Sean Kelly and Chris Mattaham), did the necessary cultural shift begin within their section of NASA – and it took five years until they were finally able to enter the Apache Incubator in January 2010. The largest problem they faced during this time was persuading their own lawyers that, as publically funded organisations, they should be giving away their resources (i.e. their code) for free. The next problem was persuading contributors to mix in. They dealt with this by creating a clear framework to define how to get involved, what is expected of contributors and what they can expect in return. Finally, this transparency is reaping its reward – their community is starting to take off.

Open source communities – the future of society?

But the future of open source, as discussed at TransferSummit, should soar far beyond its relationship to industry. As Simon Phipps argued, in inspiring terms, it could well be the future of society. In the past, we have been accustomed to a societal model involving a group of individuals centred around one powerful ruler, or, after the Industrial Revolution, one large organisation, whether a company or a parliament. Open source removes the need for this central figure, allowing all members of a society to contribute in different ways. But if the idea is potentially so revolutionary, how should the open source community ensure that it is strong enough to achieve its ends?

As Steven Pemberton’s keynote on the first morning of the summit made clear, a good open source community will involve everyone, not just coders. After good content, what users want most from the websites they visit is good usability. Programmers, typically, cannot achieve good usability alone – they need designers, writers and testers to create a new structural way of ensuring that open software addresses the needs of the general public. Like the Sheldonian, any successful open source project will need to draw on a broad spectrum of expertise.

Led by none, led by all

Bertrand Delacretaz acknowledged this in his own talk, explaining the studies he has made as to who is most involved in various open source projects. Showing visual maps of people’s involvement, he demonstrated that it was rarely the originator of a project who was the most influential – as the project grew, so did the community’s input and influence, drawing it away from the originating individual.

Mark Johnson looked in detail at the process of how an open source community comes together and develops in the talk he gave about his involvement with the Moodle project. Beginning with his initial experiences of working on simple bug fixes, he told his audience how the satisfaction of working within a community and getting recognition for his work got him hooked on using their issue tracks and forums to contribute more and more.

Becoming part of a bigger world

Excited, valued community involvement was also a preoccupation for Noirin Shirley, employed by Google but talking about her work with Apache. Given a good community of forums, bug trackers and credit always being given where it’s due, a project will inevitably be stronger. Noirin argued that to get people involved in your project, the best rules of open source communities are actually much like those of kindergarten – share your toys, don’t be selfish and always be generous with praise. Also, don’t expect people to dive into the complexities straight away. She pointed out that it’s wise not to bother fixing the simplest bugs in your code, but to leave them for the community, so that – as was the case with Mark and Moodle – someone else will fix them, derive confidence and satisfaction from doing so, and get to grips with understanding the more challenging aspects of your project.

From military tech to the schoolyard

Given a strong, multi-skilled community, there is very little to which an open source project cannot turn its hand. Miles Berry hinted at the breadth of the spectrum by arguing the usefulness of greater open source involvement in schools, not just in dedicated ICT lessons. Berry made a commanding case for the positive impact open source could have in all classrooms, from geography lessons using open source gps software, to language work using Moodle. His case was greatly strengthened by the fact that he had masterminded such a broad, school-wide adoption of open source software at the St Ives Prep School, where he was formerly headmaster.

Code speaks louder than words


What the two days of TransferSummit made abundantly clear is that with a strong community, a mixture of disciplines and a willingness to embrace and pursue innovation, open source can do just about anything. But as Bertrand Delacretaz argued, its potential best displayed not in the giving of talks but in the writing of code. So the most exciting glimpse at what the future might hold for open source happened during the Birds of a Feather meetings – informal, community-led gatherings at which attendees and speakers exchanged ideas, learned from each other and arranged to pool their projects. From visual communication tools for those who don’t speak the same language, to ideas as to how universities can better reach out to industry, the groups’ advice to each other showed conclusively that for open source communities, the sky’s the limit.

Transfer Summit – Innovation Track

Published by Sam Jordison on July 2, 2010 in Discussion and Event. 0 Comments

I’ve just returned home after a fascinating two days writing the live blog for the Innovation Track, one of three tracks at the TransferSummit, a conference sponsored and organised by OSS Watch. This track was billed as a ‘top-level immersion into the world of open source’. It delivered comprehensively.

Far too much ground was covered to hope to include every detail in a piece like this one. Hopefully, the live blog should demonstrate how informative the discussions were. You can also get a good feel for the breadth of the talks if you click through the links on the TransferSummit programme to look at the speakers’ slides. Here I’ll just aim  to provide a few general impressions.

Keble in the sunshine

The first thing to note is how pleasant the whole event was. Even though I was working hard to keep up with the blog, I enjoyed myself. True, when I had to pull down a blind to stop the strong sun shining on the screen of my laptop, it gave me a slightly sad feeling – but being at the conference still beat being in the office. It was certainly far more interesting than the average day’s work. Indeed, bathed in that sunshine, in the beautiful Victorian Gothic enclosures of Keble College, there was a feeling of respite from the problems of the world.

That’s not to say that delegates didn’t have such troubles in mind, however. The budget cuts faced by projects across the education, public and commercial sectors were clearly causing serious concern.  Even so, the overall atmosphere was optimistic. There was a a definite sense that progress was being made in the arguments for open innovation – and indeed that in a time of financial hardship that case becomes even stronger.

As Steven Pemberton said in his keynote speech, Open Source Is Not Enough!, ‘we are through the first stage’ in getting open innovation technology accepted and now the main task is to make it better.

Of course, there are still difficulties and complexities relating to the use of open innovation. Martin Michlmayr in his talk on The State Of Open Source Licensing and How To Improve It and Mark Taylor in his talk on FOSS Business Models ably demonstrated the tangled wood of licences and legal complexity faced by anyone hoping to launch an open source project – as well as providing a good route through.

It should also be noted that delegates again and again returned to the point that although open innovation may reduce some costs to close to zero, it shouldn’t be seen as a free for all. Andrew Savory, the open source manager for Limo Foundation, stressed in his talk about the Economics Of Innovation In Mobile Technologies, that open source is not an ‘all you can eat buffet’. It works best when the companies that use it give something back. It’s then that it does offer real cost savings, as well as access to reservoirs of talent that couldn’t otherwise be tapped, and an economy of scale begins to build up.

On that note, Steven Pemberton gave the famous example of wikipedia compared to the  hugely expensive Encyclopaedia Britannica of old and how ‘little things’ (such as the many individual wiki contributions) can join together ’to make a big thing better and better’.

The savings that open source software (OSS) can deliver in all sectors were also widely referred to, but one of the most striking examples of its benefits came from the fiercely commercial mobile technology sector. Andrew Savory pointed to the smartphone market, where consumers are demanding ever more features for ever less money, meaning that we have now reached a point where companies are having to invest more than they get back from their technology. So those companies have now started to look more seriously at open source software. They have discovered that it brings not only reduced costs to the acquisition of software, but also reduced costs of access to innovation and - crucially – reduced costs of software ownership (since there is a greatly reduced maintenance burden for true OSS). So it is that HTC has leapfrogged the competition thanks to its use of open innovation.

Clearly there is going to have to be a big cultural shift among companies who are generally secretive, and who are unused to the meritocracy that exists within OSS development, but evidence that OSS is the way forward is beginning to stack up. Andrew also highlighted the Mobile Open Source Economic Analysis white paper, showing that it’s even cheaper for companies to merge early and contribute early to OSS development streams – rather than ‘forking’ off and trying to keep their own innovations with regard to the software to themselves for as long as possible.

Coming back to the question raised by Steven Pemberton, about how to make open innovation work better, there were a number of well-attended talks about how to build up and value communities. Paul Walk of UKOLN stressed the simple importance of giving recognition to the work that developers do and helping them better explain their ideas and projects to the world away from the keyboard. Gianugo Rabellino, the former CEO of Sourcesense told us that if we recognise communities as places ‘where individuals come together to reap a reward …  we come to understand why collaboration works so well – and why people are producing open source software’. Gill Rysiecki gave excellent practical examples of how the Technology Strategies Board initiative, Knowledge Transfer Partnerships, can help academic developers reach out to the business community – and vica versa. Scott Wilson, the Assistant director of CETIS also made the important point that ‘inclusion and openness depend on collective responsibility’. open source works when people feel they have a stake in it.

In his keynote speech on day two Roland Harwood also gave powerful arguments about the importance of community  - and how effective exchanging ideas with different companies can be – a particularly striking example being how the McLaren Formula 1 team were able to help improve processes in A&E at Great Ormond Street Hospital. To emphasise his point he quoted the proverb: ‘If you want to go fast, go alone, if you want to go far, got together.’

Happily, this latter theme was well demonstrated by the conference itself. The buzz was all about open innovation and how best to achieve it. All the delegates I spoke to were deeply involved in the subject and determined to use the conference to learn as much as they could. They were also eager to make those vital connections with people heading in the same direction. There was just as much debate at lunchtime as there was in the formal talks and plenaries.

Naturally, since this was a gathering of technologists, there was also a lot of interest in the ipads, smartphones and various pieces of kit that people had brought with them. Samuel Klein, speaking as a a volunteer Trustee of the Wikimedia Foundation (who had been re-routed into the Innovation Track after being delayed in Boston),  provided a great firsthand account of the history and development of wikipedia and many of its related projects – and how MediaWiki has scaled up using open source methods.  However, he caused the biggest stir with a demonstration of one of the first new OLPC XOs that also run Gnome, which he had with him as he is also the director of outreach for One Laptop per Child.

Samuel Klein and the new OLPC XO

Yet even when it came to gadgets, the conversation kept coming back to licensing and the openness of various software platforms. My own HTC phone was several times singled out for approval (gratifying for a technological layman such as myself). But it was the arguments rather than the compliments that left the strongest impression. The innovation track had generated a real feeling that open source is only going to become more important in the next few years.