Now the Open Core model is what we used to call ‘proprietary extensions’, meaning that the open source code is supplemented with closed source paid add-ons for those that want them. In a way it is similar to the shareware model that did so much for PC gaming during the 1990s, bringing games like Doom to offices everywhere. One often cited problem with the Open Core model is, however, that users of the open source ‘core’ are at liberty to build competing open source versions of your proprietary extensions. Indeed you can find that ideological opponents of the partial freedom that Open Core embodies may be motivated to compete simply because of that ideological opposition, essentially enforcedly ‘opening’ the parts of the project functionality that you wish to keep closed. The only really effective defence against this risk is to be the best-resourced and most skilled team working on the code, thereby ensuring that your extensions cannot be easily replicated by competitors. So Open Core is an interesting strategy, in that it has drawbacks from both the purely ‘open’ point of view and the more traditional closed source approaches to software exploitation. In the past it has been accused of attempting to benefit from the ‘Halo Effect’ of open source while in fact leveraging closed methodologies for value realisation, but the fact that Nginx has managed to achieve so much in such a short period makes it a technology and a company to watch.

An example of how you can get more back by working together occurred recently with a series of projects that OSS Watch has been involved with. It’s an example of how by working in an open development context you can innovate faster and get results quicker, with everyone benefiting.

This example begins with the University of Bolton, who created the Wookie Widget environment as a result of an EU-funded project. This is now a project in the Apache Incubator.

The Wookie Widget environment formed the basis of a project funded by the IPO. That project built a widget making use of the Wookie server, to display a walk-through to guide users through the different issues concerned with open licensing. Most of the content that was used in this project was previously created by OSS Watch, and we therefore profited ourselves from this project.

Separately, the Rave in Context project built a templating system usable in the Wookie environment. By working with the Wookie community the Rave in Context project received more value through validation and testing of the template system and some additional functionality, such as the
option to change the order in which overridden content is given preference in template-produced widgets. On the other hand, the Wookie community profited from getting a templating system that makes it much easier to create widgets that are usable and accessible out-of-the-box, thereby increasing chances for uptake of the project by new potential collaborators.

Now OpenDirective are about to embark on creating a self-learning widget to help users assess the openness of open source projects. This new widget will be used by OpenDirective as a tool for supporting their clients and has value for OSS Watch in supporting our projects as well. This new ‘openness widget’ will be based on an improvement of the original IPO widget and on the Rave in Context templating system. This feeds features of the templating system back to the IPO widget. For example, it now works well on small screens, which was out of scope on first version. It benefits OSS Watch, because it enables us to use our content on assessing the openness of projects in a new and easy-to-use tool. It is beneficial to the Rave in Context templating system and therefore to the Wookie community, because of the extra validation of the templating system and additional functionality that the approach with the IPO widget offers.

On a very small scale, all of these projects provide value to each other by collaborating with the other communities and reusing what has already been produced. It demonstrates that you don’t need a huge project with big budgets to reap the fruits of open developments!

One question that remained with me, even as I contemplated spending more unwise pounds, was what Canon’s attitude was to this project. After all, some of the functionality that CHDK contains can be obtained from Canon in its more expensive models. They could close the technical loophole that allows the additional software to be run fairly easily, so one must assume that they do not see the existence of open source expansions of their equipment as a threat to their business model. Might they even see it as a selling point? Certainly it seems that running CHDK is likely to void your warranty, so perhaps the existence of a group of customers who opt out of expensive warranty provision is seen as a bonus.

Discovering this went some way towards alleviating the guilt of my spending. After all, I had got a large amount of functionality at essentially half price. But… if you want to run long scripts then you really need the attachment that lets the camera run off mains power. That’s not such a bargain. I could also probably do with a better tripod… Oh dear…