Let demand steer early-stage open core product development

The first questions I usually get from first-time founders are, “Which features should be open source, and which should be proprietary?” Followed by, “How do I balance the development of each?” The intent behind the questions is earnest. Transitioning from an open-source passion project to an open-core company with funding opens many doors. For some, the sheer number of new possibilities can be overwhelming and muddy the path to getting started.

Answering which features should be open source and which are proprietary is straightforward. Use the buyer-based open core framework to place features based on the most likely user. To answer the second question, look to your users and buyers.

What are people asking for? This is the first indication of what you need to build. Some founders will say, “I’ve heard so many requests for this feature it was clear that it was the next thing we would work on.” Sometimes hearing the same thing over again is enough to know that feature is the highest priority. Some founders think they need to first decide which features will be open source and which will be proprietary before they start building. My advice is to follow demand.

Building with open source has the benefit of a direct line of communication with the community. You don’t need to look far to understand what customers are requesting. An issue tracker with hundreds or thousands of open tickets is a goldmine for understanding your users’ needs and how to prioritize them. Organize that list and talk to customers. Figure out what people are asking for the most. This is what you’re building next.

Stack rank the list

Ranking features based on demand is the simplest way to start. Then, there are all kinds of additional qualifiers to consider, like how implementing one feature can enable other features. The qualifiers you use will be unique to your situation but in general, they answer if, how, and when you will implement the features on your list. Knowing the first question will be “How often do I hear this?” some additional qualifiers may be:

1. How hard is it to implement?
2. Who is asking for it?
3. How much will they benefit?
4. Will it enable other features?
5. Is it easy to communicate the value?
6. Is there an obvious way to pay for it?
7. Does it help qualify the market?
8. Is it easy or hard to train people to use it?
9. Will it complicate the user experience?

Implementation difficulty as a first-order qualifier will let the easy stuff rise closer to the top. It’s usually a good idea to do the easiest thing at the beginning of development. It provides momentum for you and your customers. If three features keep coming up again and again but one of them can be implemented in a day, do that thing first.

Identifying who’s requesting a specific feature will help you understand if the feature is more likely to drive project adoption or if you can monetize the feature. It may also shift your perspective on demand. For example, is the request primarily from startups or big enterprises? On the surface, a feature with hundreds of requests from startup users may appear most in demand. However, if a handful of highly qualified enterprises request a feature it may impact tens of thousands of users.

Price based on user

Once you have stack ranked your list, apply the buyer-based open core framework to each feature. Whether that feature is open source or proprietary depends on who is most likely to use the feature. Features that appeal most to an individual contributor are open source and free, and features that appeal most to a manager or an executive are proprietary. This will give you a clear picture of your open source and proprietary feature mix. People are more likely to request enterprise features when the project is in good shape, and open source features when the project is lacking basic functionality.

Looking at your features list from this view will expose how to build proprietary features on top of open source ones instead of creating two separate products. Technically, open core is one distribution with two licenses and all of the code exists in a single code base. A single use case can serve many personas because proprietary functionality is built on top of existing open source features. For example, you might make an open source collaboration feature even though it’s lower on the list because it introduces the concept of teams and approvals.

Don’t overcomplicate

Asking “Where should I focus first?” is inherently right but splitting focus by “open source” and “proprietary” is a flawed framework. Segmenting work into “open source” and “proprietary” might seem to provide a neat organizing structure. It also introduces unnecessary complexity when you just need to start building. Getting caught up in the open source/proprietary delineation doesn’t get you closer to your customers.

Focusing too early on the technical delineation between open source and proprietary prioritizes the technical aspects of a feature over the end user. The emphasis is on answering, “What repo does this feature go in” and “How hard is it to make this feature” instead of asking “Who is this feature for?” It’s a fast track to developing second system syndrome where the “proprietary version” becomes an over-engineered version of the original. The most likely result is that development moves too slowly, or creates a worse version, and you run out of money before ever getting a first customer.

In the beginning, there are only two priorities: Make the basic functions of the software work and add basic enterprise features. To know where to start, follow the demand, stack rank the list, and price features based on the user.

Do the easy thing now

Being able to chase after what you’re hearing the most—the thing that comes up in every customer call or that has hundreds of upvotes—is unique to early-stage startups. Making product decisions will only increase in complexity over time. Don’t artificially try to balance open source and proprietary development. Just listen to what users and buyers are asking for at this stage. Eventually, you will need to balance maintaining the open source project and the needs of investors. That’s a future problem. Focus on the things that need to be fixed right now. Talk to users and ship software.

You already know what features to create. Start with the basic software functions, what are you trying to do with it, and does it do that thing? Then, there are the basic enterprise features. You don’t need to reinvent the wheel to get started on enterprise features—there’s a list of the most common features software needs to run within a large organization. Depending on the project’s current state, a company could focus half a year or more on developing enterprise features or spend its first year improving the open source project. The question becomes “How do I balance making the project more popular and profitable?” To answer this, follow the demand.