The Serendipity of Open Source Innovation

As you'd expect from a team which has BT's Head of Open Source Innovation at it's helm, we often find ourselves in challenging debates about how best to innovate with open source, and expose these benefits to the business. It's a fascinating subject, and to some extent we're blazing a new trail here.

We're deliberately positioned at the edge of the network (some distance from core business operations), partly so we have the freedom to experiment without threatening said core. But, while we have this freedom, we also have to justify our existence as a group to those in the business who will ask for evidence of our innovation, and ask us to demonstrate how our efforts are helping BT.

What's unique about our situation isn't that we're using open source in the enterprise. There are plenty of enterprises doing that already. What's unique is that from the start we were directly plugged into an existing open source project which is both relatively young and has such high potential for growth, expansion and innovation. Also we're plugged into BT at a senior level, which means we have a high profile in certain parts of BT.

The net result is that expectations from both the community and the company are probably much greater than if we were just plugged into e.g. a Linux distro project. And the pressure to delivery quality and value quickly through innovation is higher as a result. These expectations and the pressure are entirely justified.

So how do we go about reconciling these expectations and pressures with the noble and valuable notion that we behave like external open source developers? As covered in a previous post, this means all team members assuming whatever role they wish in the community, and this is arguably the most effective route to innovation. But we ought to consider whether some compromise is in order; that we should seek consensus on our priorities and be willing to use internal authority* to get unpleasant-but-necessary work done.

In my view this reduces the chances of the team producing innovative output. Prescribed work by it's nature is anticipated, and innovation is generally more serendipitous in nature. That isn't to say that innovation can't emerge under these forced circumstances; of course it can. An open minded approach to a well known problem may result in a new idea. But it's surely less likely.

For a team such as ours, and for other similar teams attempting similar approaches, I believe the correct approach to be one where authority* is used as sparingly as possible. Sometimes work needs doing that no-one would do voluntarily, for the greater good (and the nature of these building blocks sometimes means that innovation can follow in it's wake) - and this is the time to use authority. But the more limited these occasions arise, the more we improve the innovation potential of the team overall.

* I use the term "authority" loosely here; in this context it means anyone doing something that they wouldn't otherwise do, given complete freedom of choice.