How to Think About Positioning for Open Source

• 

  Andrew ParkEditorial Lead
  Heavybit

Positioning Open Source for Your Community (and Yourself)

Why is Heavybit posting this extensive interview on thinking through positioning for your open-source software startup? While open source has been an enormously positive force in software, underpinning some 70% of modern infrastructure, building and launching a startup around an open-source project seems more challenging than ever.

One of the most important aspects of successfully launching a company is proper positioning–establishing a unique, differentiated place for your brand in the market. Positioning can be even more complicated for open-source companies, because they need a differentiated place for both the project and paid project in the market — and they have to carefully manage the positioning of the two things in relation to each other.

Open-source companies also have more stakeholders (including users, active community members, code contributors, and open-source foundations), each with different profiles and priorities, and there’s a constant balancing act to get those stakeholders in line with all the other stakeholders any company has.

In this interview, positioning expert Emily Omier explains:

• The Psychology of Open Source Communities: The many and varied people in your community, and their differing profiles and priorities
• Fundamental Tensions of Foundations: Open-source foundations can be important players, but their motives aren’t perfectly aligned with startups
• Why Contributions Aren’t “Free”: Huge corporations and individual contributors will “get something” out of your project. What are you getting out of it?
• Changing Markets Mean Expectations Need to Change, Too: Does open source need to leave behind the idea of contributions as “charity”?
• Getting to Strategic Value: Not all interest in projects is academic or recreational–here’s why some parties might have a vested interest in your roadmap
• Answering the Question: “Why Open Source?”: If you can’t answer this question, open source might not be for you
• Answering the Question: “What Does Open Source Mean For Us?”: There’s more to success in open source than having an OSI-approved license and a GitHub repo
• Pivoting in Open Source: Dealing with competitors deliberately going open source as a way to undermine you, and with license changes
• Do This: Build Transparent Community Comms Into Your Roadmap: Your next release needs clear communication with the community as much as a version history
• Do This: Differentiate Product from your Project: When your positioning is strong, you can confidently bill customers–who, if you’ve done things correctly, will be happy to pay

More Open-Source Resources:

• Article: Understanding Business Models & Defensibility with Adam Jacob
• Article: The Power User's Guide to Open-Source Licenses
• Article: How to Successfully Fork an Open-Source Project
• Article: What Success Looks Like for Modern Open-Source Software Startups
• Article: Understanding Legal Issues for Open Source Software Start-ups
• Video Archive: DevGuild Open Source Covers GTM, Security, Licensing, and More

The Psychology of Open Source Communities

Omier suggests that a key step for open-source founders is understanding the psychology of the space. “Open-source communities are like any community–1% or so might turn out to be jerks. And unfortunately, those people are often the loudest.” Sometimes, the negativity comes from a sense of entitlement–including demands for ongoing updates that could be costly to provide.

In fact, the psychological challenges of running an open-source business might be more common, and more of a headache, than founders might’ve heard. “It’s not completely different from running any business–if you’re looking at bad profit and loss numbers, you get stressed out. But there’s an added element: When your community is accusing you of ‘being a sellout.’”

The more popular a startup becomes, the larger its community becomes–which can mean more naysayers. “It can be hard for people who create these projects, and who are running a company around them, who are also trying to pay employees’ salaries–to have people who depend on your software tell you that you're ‘evil’ because you charge money for something. It's not psychologically good for people.”

Fundamental Tensions of Foundations

One of the most subtle, but potentially most challenging tensions in open source may be between foundations and the startups that create and ultimately maintain the projects that are donated to foundations. Omier suggests the conflict stems from different parties having different goals.

“A foundation’s goal is to ensure the long-term sustainability of a project. The challenge is that long-term sustainability often requires a company to be behind it–employing people who maintain the project. But it does not necessarily require the [same] company who created and donated the project to be the one who is contributing the money and time.”

“There’s often a misunderstanding about how aligned those interests are, and also a misconception about what the pros and cons of donating projects to a foundation are–and what that relationship is going to look like.”

Why Contributions Aren’t “Free”

“From my perspective, the open-source community as a whole has a huge problem with framing contributions to open source, whether you're talking about financial contributions, or somebody employed by a company writing code, or writing docs or whatever, as ‘charity.’” As companies tighten their belts in down markets, obviously the charity items get cut first.

A healthier long-term approach might be to stop seeing contributions as ‘donations.’ “If you expect a company or an individual to pay for software, you have to force them to do so. In the case of open source, you need to be getting something out of it if you’re a company–whether you’re an individual sole proprietor or whether you have 5,000 employees.”

So while vendors like Amazon and Microsoft get something out of open source, as do individual contributors, startups also need to have a commercial offering for which customers will pay, and need to make the case that their offering is worthwhile. “That’s why I think that ‘charity mindset’ has to go away if the open source ecosystem is really going to be financially sustainable.”

Changing Markets Mean Expectations Need to Change, Too

Omier reflects on how open source has evolved, and how attitudes about contributions being free-of-charge, with no strings attached, may need to as well. “I think open source is less about those ‘true believers’ than it was 30-40 years ago. I recently read something on the topic of ‘hobbyist contributions’ vs. ‘corporate people’ who contribute because they’re getting paid to.”

“I'm not 100% convinced there are fewer hobbyists in terms of projects out there that are maintained by somebody doing it for fun. However, there are a lot more commercial open-source interests than there were 30 years ago. There are also a lot more projects. There's a lot more interest in software engineering. And there are a lot more software engineers.”

“Open source might have been a fairly niche thing 30 years ago, and it’s much less a niche thing now. I'm also a bit of a pragmatist. A lot of open-source projects are really complex–but there are still expectations that professional software engineers are going to work on them in their free time. To me, it's ludicrous.”

“If you expect open-source projects to be good, you want them done by professionals–who spend all day at their computer–but might want to spend time with their family at some point.” You may hear people argue a company is ‘evil’ because they’re getting paid to do what they do–even though people want to use the software, and expect it to be secure and reliable.”

“Even if distributing software doesn’t mean there’s less to go around, it still costs somebody their time to create, and that time is still valuable.”

There are a lot more commercial open-source interests than there were 30 years ago. There are also a lot more projects. There's a lot more interest in software engineering. And there are a lot more software engineers.”

Getting to Strategic Value

“Whether it's an ‘I will answer the phone if you call me at 3:00AM because there's a problem,’ situation, or an ‘I will build a custom extension for you because I have a services model’ situation or a ‘You don't want to manage the infrastructure, so you can use my cloud-hosted SaaS’ situation–we have enterprise-licensed products for that kind of thing. So there has to be something else that's valuable.”

“When we discuss ‘contributions’ from engineers or documentation writers or other people, an open-source company has to be getting something out of this. So why would they want to contribute code? Often, it's because they want something in this project. They want functionality that isn’t there yet. Sometimes they want visibility and control over the project's roadmap.”

“So if you strategically depend on an open-source project, and you have a company of any reasonable size–not just huge companies like Amazon–you might want to employ people to be involved with the project. If it's important enough to your company's health–you’ll want to have a seat at the table if there are important roadmap decisions being made.”

“The point is, there has to be value. It can't just be that everyone is expected to contribute because ‘we want to do a good thing.’”

Answering the Question: “Why Open Source?”

There’s nothing wrong with starting from the goal of creating an open-source startup, but founders who specifically want to create an open-source product need to ask hard questions. “The first question I’d ask is: Why? I’d need you to justify it for me, and for yourself. How is your idea a good fit for open source? And how is it going to give you a competitive advantage?”

“It’s also OK to build an open-source startup because that is fundamentally the kind of company you want to build. I actually think this is a very good reason to build an open-source company, as long as you are honest with yourself about your motivations and the risks and benefits that come with building an open-source company.”

Planning should start from determining the ways your open-source project will deliver value. “Like a restaurant menu, it’s not unlimited. You can pick more than one option, but you should not try to eat everything on the menu. That's a recipe for failure. So you need to decide on a hypothesis: How is an open-source project going to help your business?”

“Also, your hypothesis might be wrong. But if you are at least aware of this possibility, you can adjust in the future. But I still see people starting from the premise of ‘We’re making a devtool. Devtools should be open source. So, let’s create an open-source project, I guess.’ OK, but why? Does your project work as open source? And how will you know if it's not working?”

Answering the Question: “What Does Open Source Mean For Us?”

Omier is blunt: “I do not think that all devtool companies must be open source. But there are reasons you might want to be an open-source company. If you execute correctly, it can help with distribution. It can get you into customer accounts with whom you would otherwise have a lot more trouble getting your foot in the door.”

“Open source can provide transparency. There are some markets where there are not many open-source players, and companies want transparency into what's going on under the hood. This is especially the case for software that you're going to sell to government customers. It is a very powerful way to build a community.”

“And not all open-source companies build a community. If you’re just making a transparency play for the sake of it, you may not care about a community. But building a community can have huge downstream benefits for your company.”

“But just releasing a project with an open-source license on GitHub does not ‘build you a community.’ There's other actions you have to do as part of a community growth strategy that can really pay dividends. Maybe not next week, but after a year or two, a community can provide a massive distribution channel, and amazing amounts of evangelism and loyalty that you just can't get any other way.”

“Another reason to have an open-source project is to stay close to your users to get product feedback, so you can iterate on your product faster. Those are some reasons that you might want to take an open-source route, but it's a good idea to be clear about what your reasoning is.”

Omier points out that in the same way having a GitHub project doesn’t magically create a community for you, building a community doesn’t magically build up a neverending source of business leads. “That’s also a misconception that exists among people–including those who get VC funding.”

Your hypothesis might be wrong. But if you are at least aware of this possibility, you can adjust in the future.”

Pivoting in Open Source

“I talked to Kelsey Hightower recently and he suggested that startups should consider defaulting to not going open source. And I kind of agree with him. If you don't have a philosophical reason to build an open-source company, if you can't point to any specific benefits you're going to get–then yeah, you can stay closed source. I would say that's the easiest route.”

“However, another thing I see is closed-source companies whose competitor releases an open-source project that works out very well for that competitor. In other words, the competitor has a specific business outcome they want to get from releasing the project, and it works, meaning they are eating your lunch in terms of distribution, mindshare, or even concrete sign-ups.”

“That is a situation where you really need to evaluate your open-source strategy. (If your competitor has just released an open-source project and that seems to be taking off, that’s a situation where you should call a consultant like me!)”

And what about when your open-source startup is experiencing pressure to pivot to a different license, or away from open source entirely? “Do you need to pivot away from open source? It's hard to do, but as long as you have the copyright to all of your code, you can. Usually, companies will do this when they do a major new release.”

“However, you have to very carefully review all your dependencies. You should have a clearly-defined hypothesis about why you're doing open source and you should measure yourself against it. Let's say that two or three years into your company's life, you realize your hypothesis was wrong. Everybody makes wrong bets, so there's nothing ‘evil’ about moving away from open source.”

Do This: Build Transparent Community Comms Into Your Roadmap

Omier recalls examples of open-source-to-proprietary pivots that were handled reasonably well, and others that were disasters. “I’ve seen companies where their communication strategy was a trash fire. But there have also been license changes that were not a trash fire, because those companies put a huge focus on communication strategy.”

“Obviously, to change your license and change your product from open to closed requires technical work and legal work. But cases where the whole company focuses on communicating appropriately to their users and their customers, about why they are doing this and what the ramifications are–those tend to work out much better.”

“One of the core values of open source is transparency. This is actually why I think some license changes aren’t a disaster–because they are transparent. If you are transparent at the very beginning, and you communicate ‘This is why we're open source,’ that will go a long way towards reassuring people.”

“The reason that the open-source community will be gun-shy is because they might think that you are just another founder who doesn't have a plan. They think you’re a founder who will mess around with open source, and then raise a Series A and realize that you can't keep messing around with open source, and then change the license.”

“But you can communicate with your community. You can explain: ‘This is why we're involved with open source. This is how we understand the difference between open-source users and customers in terms of our target market. This is the added value you get from the commercial offering.’”

Omier notes that while services and support may not be as scalable as separate software features, they are entries on the ‘menu’ of ways that open-source companies make money, and shouldn’t be completely ignored in conversations about open source companies.

“If you don’t communicate this type of message, the community may look at your company and say, ‘I don't believe that these people have their business model figured out. And therefore, I can't trust them.’ But if you can make the case to the community that you do have a business model, or at least a hypothesis, and open source fits in it, that's going to help a lot.”

“What I do when I work on product strategy for companies is create a product roadmap that includes that information. And you can be more or less transparent, but I think it's a very good idea to at least have a central document, a real product strategy document that outlines why you think the open-source project is going to help your business.”

Do This: Differentiate Your Startup and Product

Omier suggests that one thing all open-source companies have in common is that their revenue comes from the delta in value between what paying customers get versus what open-source users get. “Since this is what would make you money, you have to be super-clear about what the difference in value is. So, you have to know your differentiated value in the market for your project and also for your product.”

“It’s super-important to pay attention to both things, compared to your competitive ecosystem and also compared to each other. The same thing goes for your target market. Your target market is not a complete overlap for your user and your customer base. Know what the relationship between your user and customer base looks like.”

Clearly communicating value, and clearly communicating your business plans to the best of your ability, can mean the difference between winning valuable deals and having a vote of no-confidence wiping out your sales. “You'd be surprised how many customers would say, ‘We love this open source project, but we need this company to have a business model that works.”

“Customers will hesitate to become a customer because if they do, they want to make sure you have a business that works. They’ll ask: ‘Will this open-source company still be here in two years? We’re prepared to pay, and we expect to be charged for the software, because we want the company to continue to exist.” But if your company isn’t charging for the software, they may think that could be seen as a risk to your company's sustainability.

“Customers will hesitate to become a customer because if they do, they want to make sure you have a business that works. They’ll ask: ‘Will this open-source company still be here in two years? We’re prepared to pay, and we expect to be charged for the software, because we want the company to continue to exist.” But if your company isn’t charging for the software, they may think that could be seen as a risk to your company's sustainability.