going to try to summarize some thoughts on open source product, which i spend a lot of time thinking (and ranting) about. this will be fairly high level, as all projects/companies have a unique set of problems to solve, but i believe there are some overarching thematic ones.
first, what makes open source products different than enterprise products of the past? the main distinction is that in the past, the users and the buyers of products (think: storage, servers, routers) were generally the same person.
there are now also more functional buyers with real budget, as IT has become unbundled and generally less centralized, with cloud delivery models as a major enabler.
there was a buyer, with a pain point, and you could build a roadmap starting with an MVP that added more features, that would result in an increasingly higher price point, solving more and more problems, and the process was fairly linear (oversimplifying this, but bear with me…).
what’s different in open source? your user and buyer, while at the same company, are typically very different people. they may not even talk. your user is a developer, using your open source project, and your buyer is someone that’s management level in eng, IT, security, etc.
your user looks at hacker news, your buyer probably reads gartner. your user cares about solving very particular issues, ease of deployment, and the community. your buyer cares about SLAs, role based access, SSO integration, auditing, and myriad other security related things.
the things that these people care about are drastically different, and so you essentially have two products, each with their own roadmap, user personas, pricing/packaging models, and sales and marketing models.
(I would go as far as to argue that most companies should have two product teams — the open source / distribution focused product team, and the enterprise product team. who reports to whom depends on the company).
features that one group cares about might even seem openly hostile towards the other. it’s not an open source product, but a lot of these dynamics are the same in any bottoms up product.
remember when Slack allowed auditing and everyone blew up because for a lot of people the whole point of slack was secrecy? that’s what we call an enterprise feature. :) https://www.nbcnews.com/better/business/slack-updates-privacy-policy-employers-can-read-private-dms-without-ncna862811
the challenge of open source, thus, is harmonizing these two conceptual products within a single organization.
this requires two things: the first is creating a project and product that a ton of developers want to use, to solve real production challenges (doesn’t *have* to be prod, but sure helps).
the second is answering “then what?” that is, if all of these developers start using our product, what do we sell the *enterprise* to enable the safe and scalable use and management of the open source, and how do we do that in a way we can build a company on top of?
the open source/distribution product team this team probably looks as much like a developer relations team as it does a traditional product team. their job is to ensure developers love every aspect of the product, and they are deeply engaged with the community.
they are the ones that provide community leadership (not control) and are the face of the company developers. their north star is awareness, education, and adoption.
the enterprise product team looks a little like a more traditional product team — deeply buyer engaged, focused on understanding pain points for enterprise buyers, and mapping open source usage trends upon which they can layer on sellable, manageable enterprise products.
the resulting sales and marketing motions for your *distribution product* and your *enterprise product* are entirely different because they speak to and serve the needs of distinctly different audiences.
these audiences expect to be marketed to, sold to, and supported very differently. plus, you’re potentially not monetizing your distribution product at all!
it’s because of this that having a strong grasp of where monetizable value in your product might be in the future is key to your entire company’s roadmap, including the open source project, so that you don’t accidentally give away the company opportunity for free.
things that are nice to haves for the community can be large enough enterprise pain points to build a company around.
doing this without burning the community is a fine line, but it’s my view that the real money making opportunities fall outside of what most of your developers care most deeply about.
ultimately, the company building opportunity is how you take a broad look at community usage patterns with your product today, what they will do with it in the future, and how you layer on top sellable products that support their usage in enterprises with large budgets.
the question you should ask yourself is “If this is being used all over the place in key production use cases, what is the thing we can then sell the CIO for $1M?”
the answer to that question is probably a mix of SSO, role based access, logging, replication, disaster recovery, and, everyone’s favorite, single pane of glass dashboards. maybe a hosted service.
and maybe you sell services (you WILL sell services, whether you charge for it or not. so don’t be afraid to charge for it).
many of these are things that your open source community does not care about, or in some cases, will even overtly disdain (and make fun of on twitter).
while nothing described above is particularly mind blowing, what makes this so hard to get right is that a company’s early DNA rarely has both the developer persona and the enterprise persona.
“enterprise” is usually a thing you add later on when you hire a VP Sales, VP Marketing, etc. while it can be done, and does work in some cases, it’s a less than ideal approach.
there’s a lot of organized chaos in this, and it’s why a strong product sense is invaluable early on. It’s not trivial to understand what a project might ultimately become, how it fits into the stack, and to then determine what a theoretical buyer may eventually want to purchase.
it’s even harder when you’re getting a lot of very vocal feedback from your community, who, while important, aren’t the people that you need to make happy to create a big business.
to be clear, you do have to make them happy — but making them happy is not enough. a universally happy community might be a great project, but it does not ensure that you have a great company.
this is probably a good time to mention that most projects shouldn’t be products, and even fewer should be venture funded companies. most projects just do not provide enough value that matters to would-be customers.
as a closing thought, the sooner you start answering the question of “when everyone starts using our project in production — then what?” the better off you will be. I believe it’s the central issue of every open source company.