Getting your team on board

A last post in this series about moving from closed source to open source. And today I want to talk about getting your team on board with the change.

Chances are pretty good your engineering team knows wtf open source is about. But chances are bad that your sales or marketing team has previous experience running their respective functions in an open source company. And that… matters.

It’s important for your entire team to understand your open source strategy.

I’m finishing my series about moving from closed to open source, but the above is true for companies that have always been open source, too. Often the engineering teams knows what open source is all about but the non-engineering people don’t have experience with, for example, selling in an open source startup context.

If you, as a founder, have in your head a very clear idea of the framework between project and product, the business benefits your company gets from the open source project and the difference in target market, outcome and core differentiation between project and product, you’re already ahead. But it must, must be written down so you can share it with the team. A positioning canvas like this one can help, but it isn’t sufficient — it doesn’t address the core business outcomes you’re getting from your open source project, for example.

If you don’t have a clear idea, even for yourself, of what the relationship between your project and product is / would be after releasing an open source project… you need to figure that out first, and then you need to make sure it can be written down and disseminated to your team.

Your team can not do their jobs if they don’t understand your open source strategy as it relates to their role in the company. And they will not understand that strategy unless you tell them.