The Key to a Flourishing Career in the 21st Century
Some time ago, I noticed something missing in our discussions about open source software development. A few somethings, in fact. Nobody was talking about product management as it pertains to open source development. Admittedly, this was spurred by a question from a product management team member who was confronted for the first time by the reality of working with an engineering team that runs an open source project. Her question was simply, “So… what should we be doing?” Her question was born of a fear that product management had no role in this new regime and thus rendered her unnecessary. I had to think for a moment because I, experienced open source project hand that I was, wasn’t quite sure. For quite some time, my standard response had been for product management and other “corporate types” to stay the hell away from my open source project. But that didn’t feel right. In fact, it felt darn right anachronistic and counterproductive.
Over the next few weeks, I thought about that question and gradually realized that there was no defined role for product management in most open source projects. As I looked further, I found that there was startlingly little in the way of best practices for creating products from open source software. Red Hat had made a company by creating efficient processes designed to do just that, but most industry observers assumed (wrongly) that they were the only ones who could do it. Lots of companies, even large proprietary ones, had started to use open source software in their products and services, but there was very little in the way of sharing that came from them. Even so, many of them did a poor job of participating in the upstream communities that created the software they used. Shouldn’t these companies get the full benefit of open source participation? I also came across a few startups who wanted to participate in open source communities but were struggling with how to find the best approach for open source participation while creating great products that would fund their business. Most of them felt that these were separate processes with different aims, but I thought they were really part of the same thing. As I continued down this fact-finding path, I felt strongly that there needed to be more resources to help businesses get the most out of their open source forays.
This was the seed for creating the Open Source Entrepreneur Network, my personal passion for the past year. Yes, there have been a smattering of articles about business models and some words of advice for startups seeking funding, but there’s been no comprehensive resource for businesses who want to prioritize and optimize for open source participation. There’s also a false sense of security that comes from adopting modern tooling. While I’m glad that devops practitioners argue forcefully for better automation and better internal collaboration, it misses the larger point about external collaboration with upstream communities and how to optimize your engineering for such. Articles about licensing compliance are much-needed but are but one small part of the larger picture of building a business.
As I’ve spoken with many folks over the last few months, I would break down open source business, or entrepreneurship, into 4 basic components, which I’ll describe below. If you look at the diagram above, you already know their names: Automation, Collaboration, Community and Governance. You’ll find much that overlaps with methodologies and practices from InnerSource, devops, and community management, but I think that an open source entrepreneur needs to at least understand all of them to create a successful open source business. And I don’t mean only for startups – this applies equally well to those who lead teams in large companies. Either way, the principles are the same.
Automation
This part focuses on tooling and is probably the best covered in the literature of the four components. Even so, startlingly few enterprises have gone far in adopting it wholesale, for a variety of reasons, ranging from team members’ fears of becoming redundant, to middle management fears of same, to a perceived large one-time cost of changing out tools and procedures.
Collaboration
If you’re a devops or innersource practitioner, this will be your gospel. This is all about breaking down silos and laying the groundwork for teams to work together. I’m always astounded by how little teams work together in company settings, even small ones. So much would change if companies would simply adopt community management principles.
Community
One might think that this is the same as the above, but I’m thinking more in terms of external collaboration. To be sure, there are many differences between them, but companies that are bad at one of them tend to be awful at the other. The corollary is also true: companies good at one tend to be good at the other as well. There’s also the matter of how to structure engineering and product management teams to reduce technical debt and learn how to optimize for more upstream development.
Governance
This is all about licensing, supply chain management, regulatory compliance, and how to get your legal team to think like an open source entrepreneur. It’s not easy. In many companies, a lack of understanding from business affairs, legal, and software asset management serves as significant obstacles to open source collaboration.
So there you have it – open source entrepreneurship in a nutshell. A successful product owner, engineering manager, CIO, CTO, startup founder or investor will need to understand all of the above and demonstrate mastery in at least 1 or 2 areas. This is the subject matter for both my Linux Foundation Webinar on August 1 and the Open Source Entrepreneur Network Symposium, co-located with the Open Source Summit on September 14. The webinar will be an hour-long introduction to the concept. The symposium will feature talks from myself on open source product management that reduces technical debt, Stephen Walli on creating a business through better engineering process management, Shane Coghlan from the OpenChain project on building a compliance and software asset management model, and VM Brasseur on FOSS as an emerging market that companies need to master.
-
Get your ticket for the OSEN Symposium ($149.99)
-
You can also register through the Linux Foundation’s Open Source Summit registration system
-
For all co-located events at Open Source Summit, see this page.
-
