When offered a platform to put open innovation topics in front of business readers — and presumably burnish my public visibility and consulting credentials — I immediately thought of a topic that I have been researching, blogging about and doing academic research on: the issue of sponsored open source communities. The subtitle “letting go is hard to do” captures the key dilemma that I (and others) have identified in our open source research: firms don’t want to let go, but they must if they want to capture the full benefits of external collaboration.
In trying to cover the issues of a 6,000 word journal article (or several) in a 900 word column, I had to speak in shorthand or leave things out entirely, so I thought I would provide (another 900 words of) literature references to my academic readers in case they wanted to follow up on any of the ideas. (More detail on the cases are given in my Open IT Strategies blog.)
First, of course, is the idea that a firm-sponsored open source community is an example of open innovation. When you consider open source research, there’s certainly a lot of it from the user innovation perspective — particularly from Karim Lakhani of HBS. User innovation exactly captures the “scratching an itch” mantra of open source maven Eric Raymond, and exactly describes the origins of a few projects like the Apache web server and the R statistics software.
While there is a clear overlap between user innovation and open innovation, as I have argued in this blog the two concepts are certainly distinct and efforts to blur the distinction are unfortunate.
In the 2006 R&D Management paper that first brought me to open innovation — co-authored with Scott Gallagher — we showed how firm involvement with open source nicely fit the open innovation paradigm — both the inbound use of external technologies and the outbound commercialization of internal technologies. (Alas, we tended to blur the distinction between open and user innovation.)
Fast forward to 2009, and the second R&D Management special issue on open innovation. In their introductory article, Ellen Enkel, Oliver Gassman and Henry Chesbrough suggest there is a third open innovation mode beyond the inbound and outbound mode, which they term a “coupled process”:
The coupled process refers to co-creation with (mainly) complementary partners through alliances, cooperation, and joint ventures during which give and take are crucial for success. Companies that establish the coupled process as key combine the outside-in process (to gain external knowledge) with the inside-out process (to bring ideas to market) and, in doing so, jointly develop and commercialize innovation.Although it’s not cited, the West & Gallagher paper shows how this process is used by firms to cooperatively produce a shared good in a process we called “pooled R&D”. We argue the main difference between this and normal cooperative R&D is that the open source license means that firms are unable to fully appropriate the returns of their efforts, which freely spillover to participants and non-participants alike. (Obviously, this is most suited for commodity technologies that are necessary but provide little opportunity for competitive advantage.)
Another paper that anticipates the Enkel at al argument is my paper with Karim Lakhani — in a 2008 special issue of Industry and Innovation — which focuses on the importance of the community construct in open innovation research.
But the specific insight that motivated the Business Week article was the long effort of Siobhán O’Mahony (now at Boston University) and I to capture how sponsored open source communities are different from organic ones. In particular, our 2008 paper (in that same special issue) focuses on the difference between nominal and actual openness of these communities, and the difficulty that firms have in letting go.
Here are two paragraphs from the conclusions of the paper that summarize our findings:
By studying the design decisions that sponsors made when creating a community, we identified three dimensions that affected participation: (1) the organization of production, (2) governance and (3) intellectual property. In doing so, we showed that the participation architecture of a technical community is determined not only by its technical architecture, but also by community design decisions made by the community’s leaders. …Not surprisingly, the Business Week column came to the same conclusion as the West & O’Mahony paper: managing this tension is difficult and thus rarely successful. The rare exception is the Eclipse Foundation, which is studied by firms setting up other sponsored open source communities.
We showed that sponsors’ community design decisions on these three dimensions reflected the inherent tension between two conflicting goals. On the one hand, firms wished to retain control over technologies fundamental to their business success. On the other hand, providing the opportunity structure for others to participate was a prerequisite for gaining the benefits from developing an external community. Thus, when designing a participation architecture, firms mediate between surrendering control and offering opportunities for outside participation that could lead to community contributions and growth.
So far, I’m unaware of any academic paper that looks at the process by which Eclipse developed this industry-leading shared governance. (Siobhán and I talked about writing one from our extensive interviews, but neither of us had the time.) Even if it couldn’t be published in an “A” journal, I still think the Eclipse exemplar is interesting enough that someone should do it — and, if well done, I think it would be cited.