I've been writing for a while on topics related to product and supply chain management in the context of open source communities, and I've noticed a few consistent themes in my articles and blog posts. Most notable is the call for companies to move from the "not invented here" syndrome to a more externally focused view. After all, if so much innovation is taking place in open source projects, why not take advantage of it to the fullest extent possible? You can see this theme manifested in the following ways:
- Open source program office and management: This is all about providing structure for creating and implementing open source strategy, including programs and systems to help engineering teams meet legal requirements for participating in external open source communities. This is only valuable if the company places strategic importance on influencing external communities.
- Open source product management: The practice is designed to add value to open source software and platforms, consisting of dev/test procedures, packaging, support, risk management, and anything geared toward creating a reliable product or service that customers pay for. The subtext here is that a company relies on external open source code for its product development.
- Open source supply chain management: Much like in product management, the subtext is the reliance on external software to fulfill product development requirements. This is the process for procuring external software and building contingency plans into the process to account for changing community dynamics that could have a negative impact on product development.
The common thread is the emphasis on external origins for core software that's utilized strategically, either for product development or internal consumption. This is why I started the Open Source Entrepreneur Network: I noticed a distinct lack of consensus around best practices in these areas. As I delved more into this area, I discovered a wealth of literature around the concepts of business ecosystems, but in a different context.
The difference is that now, in addition to businesses filling out a set of ecosystems with a variety of competitive and cooperative touchpoints, there are nonprofit organizations and foundations that round out the mix, adding layers of complexity to an already complex system. Whereas before you had to learn to make strategic alliances with some companies to move forward with a business, already a difficult process, now you also need to identify which communities and open source ecosystems to align with to drive both higher efficiency and the base rate of innovation.
Furthermore, there is a difference between merely consuming external software and actively participating in its creation. The former is now widely regarded as a necessity in today's business climate, but the latter is still a dark art, long slagged as a marketing ploy, something to spread warm fuzzies and other non-specific fluffy benefits long associated with brand development and other marketing activities without a well-defined ROI.
What I hope to communicate more broadly is that there are tangential benefits to expanding one's outlook to both consumption of external software sources as well as active participation and influence in these communities, and it's not just brand awareness and a talent acquisition pipeline.
Fear, uncertainty, and doubt
The primary obstacle to adopting this worldview is simply a lack of knowledge of what happens in these upstream communities and their relevance to business goals and product development. And yet, there's been a significant amount of research and discussion about business ecosystems, which apply just as easily to our new open source world order. The "bible" in this area is The Death of Competition by James F. Moore. I've recently discovered a new entry that I've added to my reading list: Platform Strategy by Reillier and Reillier. The basic premise of these books is that ecosystems drive innovation, and smart businesses learn how to benefit from this process.
If you extend the discussion topic to include geographical supply chains and ecosystems, the literature is even more extensive, with Geography and Trade by Paul Krugman a seminal entry in this field. This area of study stems from the analysis of old-fashioned brick and mortar ecosystems, such as the panoply of companies in the American Midwest that made up the automobile industry, as well as the manufacturing ecosystem currently powering China's economy. One would do well to learn from these examples. In each case, there are base platforms (e.g., steel, glass, plastics, energy) around which several areas of business develop. Instead of eradicating the importance of geography as once thought, the internet age affirms it. Witness the continuing growth of Silicon Valley and other technology hotspots, in spite of the fact that telecommunication enables easy collaboration across national borders.
So, what's to be learned from this? Take the lessons from geography and ecosystems and apply them in an open source context. What are the ecosystems that make the most sense to you? Do you have a critical mass of developers in the hotspots where most of the development in a particular ecosystem takes place? Do you have the processes in place to take advantage of the rapid innovations happening in these ecosystems? And can you change them should the community dynamics change? These are the questions that need to be answered in the 21st century if you're growing a business and want to extend your viability far into the future.
Comments are closed.