Open innovation tactics and incentives applied to software

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.

3 thoughts on “Open innovation tactics and incentives applied to software

  1. Jovita Cruz Quan

    Certainly in the development of open source software the risks are taken on by everyone along with the gains. It is still a win-win situation, benefits for all and risks spread out as well.

  2. engelous

    “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.”
    Where I have been able to read about it?

Comments are closed.