đź’ľ
OCV Public Handbook/đź’ľBuilding the Product

Building the Product

 

Licensing & distribution

MIT is the preferred open source license and using the same license as the open source project is the best practice.
An open core company’s product has one distribution that includes both open source and proprietary code. The entire distribution should be publicly available. The proprietary code is source-available and the features in the proprietary codebase are activated by a paid subscription.
Proprietary features should be stored in the same repository as the open source code in a subdirectory called /proprietary. Avoid naming the subdirectory /ee or, /enterprise-edition. For example, GitLab’s proprietary code base is a subdirectory. The subdirectory is in the same repository that contains the open source code.
The licensing for a repository should be stated in the master directory of the repository in a document titled `LICENSE` (example). The license document should describe explicitly which directories fall under which license and where specific software is proprietary. When different portions of a repository have differential licensing, it is best to be explicit about that differential licensing.
The licensing can be described in the subdirectories themselves under separate license documents referenced in the master directory in the format of:
All content that resides under the "subdirectory/" directory of this repository, if that directory exists, is licensed under the license defined in "subdirectory/LICENSE".

Activating the proprietary features and code

The customer instance talks with your entitlement service. They report statistics (customer id, number of users, aggregate usage numbers of certain features) and you report to them how many users they are entitled to. Don't have license files, it should be an online check.
  1. Use Unique ID for each customer (probably, UUID)
  1. Customer ID comes from your sales software (Zuora, Salesforce, etc.)

Product roadmap

TODO Explanation of key points when developing a product roadmap.
 

Avoid Second System Syndrome

Second system syndrome refers to the tendency to overcomplicate and over-engineer a new version of a product or system. This syndrome occurs when the creators of the second system try to address all the perceived flaws and shortcomings of the first system, resulting in a bloated and ineffective solution.
To avoid falling into the trap of second system syndrome, it is important to follow these guidelines:
  1. Focus on the core functionality: Identify the most critical features and prioritize them over secondary or nice-to-have functionalities. Keep the system lean and focused on delivering value to users.
  1. Iterate and gather feedback: Instead of aiming for a perfect and fully-featured system from the start, adopt an iterative approach (see
    🏂
    Founder Onboarding    ). Release early versions of the system, gather feedback from users, and make incremental improvements based on their needs and preferences.
  1. Stay aligned with user needs: Continuously engage with users to understand their requirements and ensure that the system remains aligned with their needs. Avoid adding features or functionalities that are not directly relevant or valuable to the target users and avoid building in isolation (see
    đź”­
    Finding customers    ).
  1. Keep the team focused and accountable: Maintain a clear vision and goal for the second system and communicate it effectively to the development team. Encourage collaboration, open communication, and a shared responsibility for delivering a successful product.
By following these guidelines, you can mitigate the risks of second system syndrome and create a well-designed, user-centered system that effectively addresses the shortcomings of the first system without introducing unnecessary complexity.

Decision-Making Criteria on New Features

  1. Don’t listen to the last objection.
  1. Product features should be weighted based on their source in listening to customer feedback and informed by customer discovery and not necessarily on the frequency of requests.
    1. Ideas for features and functionality can come from users, but the end result of what the product will do is defined by the product team.
    2. 90% of the product scope will come from the product team.
  1. Potential customers never buy because of product features
    1. Overvaluing the requirements of a potential customer can be a high effort and deprioritize more meaningful improvements.
    2. Someone who has never used your product can’t really know how to make it better - their suggestions may in reality be low priority when actually using the product.
  1. The heaviest users will give the best feedback - they understand the limitations of the software and will be more likely to have submitted pull requests for modifications and issues.
    1. Visibility into that feedback through contributions by heavy users is an advantage of open core products.
  1. Sales requests are important but will not make up a significant amount of feature development. Product and sales should have a list of the 5-10 most important requests that they revisit every quarter.
  1. Prioritize features requests based on effort vs value - focus on high value low effort changes.
  1. Working closely with large customers tends to yield the best new features. Large customers have knowledge, expertise and ask for things other customers want.

Releases

Announcing new releases

Commit to a regular communication schedule for release updates. A monthly blog post is recommended. The blog post may include a changelog and should highlight new features and notable improvements.
Publishing a monthly release post is a chance for you to share your product story. As a bare minimum, it’s important to proactively share with users and customers any changes to the product. But a release post can also be a powerful marketing tool. Take your release post a step further by explaining why the improvements are helpful to users and customers, how they fit into the overall product vision, and share prompts for getting started. Reiterating your product roadmap and vision helps generate excitement and can encourage folks to contribute.
What to include in a product release post:
  1. New feature highlights describing what the feature is and how to use it
  1. Roundup of all the changes and improvements made since the last release. Note anything that has been deprecated or any required upgrades
  1. Pictures and gifs showcasing new features and improvements
  1. Community contribution section thanking anyone who contributed to the most recent release
Release post titles
Avoid overly generic release post titles like “Acme 1.0 released” and instead tell the reader about something interesting you shipped. A better title may be “Acme 1.0 released with feature 1, feature 2, feature 3” giving examples of new features. An even better title leads with what the user can do or a problem solved via updates in the release. For example, “Develop faster with Code Suggestions.”
Good
Better
Best
Acme 1.0 released
Acme 1.0 released with Feature 1 and Feature 2
Acme 1.0: Developer faster with Code Suggestions

Premium/Enterprise Release

A premium or enterprise release for an open core company software will usually be a version of that software which includes a software as a service option (which is hosted) in addition to source available and open source versions. The features which are a part of that release should be informed by sales efforts with features developed specifically to deliver on customer needs.
On premises offerings with releases should be evaluated on a case by case basis for companies and generally is more useful for infrastructure projects. Certifications and data locality can represent a challenge for implementing on-premises offerings along with the possibility of functionality degradation.
Replicated helps software vendors with delivery of on-premises solutions.

Working with open source projects

Building a commercial company around an open source project gives you an immediate audience but it doesn’t give you immediate access to that audience. You need to find a way to reach them. For example, you can’t expect a project maintainer to give you access to their email distribution list just because you are building around the same project. They may have no initial interest in partnering with you or promoting your product.
Some ways to reach your built-in open source audience:
  1. Community contributions: Spend time making meaningful contributions to the project and helping other contributors out.
  1. Services instead of alternatives: Provide services to the project through hosting the project or working on the specific needs of businesses using the project.
  1. Content marketing: Write about the project and how you’re contributing to it, using it, or planning to improve it. It gives the project and your company visibility with the audience.
  1. Hacker news: Join Hacker News and start engaging with relevant conversations and creating content the community would find interesting enough to share and comment on. Use “Show HN” to share something you’ve made that people can interact with. “Ask HN” when you have questions the HN community can help you out with.

Community contributions

To be efficient with capital, build with the community. Engaging the open source community around your project and product is an advantage for open core companies—use it!
Plant seeds by shipping a small minimally viable change (MVC) and asking the community to help mature it. Shipping functionality that is incomplete to expand the scope sometimes goes against instincts. However, planting those seeds, even in an incomplete state, allows others to see the path and contribute. With others contributing, iterations happen faster. While MVCs come with a low level of shame, they allow the wider community to contribute and people to express interest.

Increasing contributions

  1. Keep review turnaround time under a week. The faster the turnaround time, the more encouraged people will be to keep working on your project.
  1. Generate awareness of your project through content marketing.
  1. Host a hackathon. If you don’t already have a significant social following, you can host a hackathon Devpost.com, Hackathon.io, and Dev.to
  1. Start a discourse forum. It’s good for SEO and you can create a custom domain for your forum.

Improving contribution acceptance rates

General guidelines when you (the founder) are the only or primary maintainer:
  1. Give the community direction by generating high-priority issues for them to work on.
  1. Hire a contributor success person to review and manage community contributions.
  1. Provide documentation with guidelines and tips for contributors.
Specific guidelines for when the project is (1) maintained by someone else (2) maintained by a foundation or separate company (3) PRs/MRs need to go through a lengthy approval process because the project is mature or there are many approvers:
  1. If a foundation or a community of maintainers maintains your open source project, help maintainers by providing resources.
  1. Pair someone with the maintainer when he goes through it on Zoom call (live) and do a write-up of what was wrong and in the next MR, share what you changed.
  1. Instead of asking them to document => pair with someone to do the documentation for him
  1. Help improve the processes and culture that slow PR review and acceptance.

When to hire a contributor success manager

 

Competitors in open source

Given the nature of most OCV companies, we may encounter competitors contributing to or leveraging the same underlying open source project.
The general guideline is to accept competitors’ code contributions if they’re good. Faulty codes and/or if they’re difficult for the open source community to maintain would be reasons to reject or request rework.

Competitors conversations

Once the company takes off, it will likely draw attention from direct competitors in the market. General recommendation is not to take competitor calls for the following reasons:
  • If the outreach is from Business Development or Corporate Development, it’s likely a fishing expedition to acquire the business early (at a pre-mature, low valuation). It would not be a good use of time if you’re not planning on selling the business now. You’re also at risk of giving away competitive information about your own product roadmap. Engaging in this would put a bigger target on your back.
    • You should only talk to Corporate Dev if you’re looking to sell the business now (either the company is doing really well or really badly). See Paul Graham’s full article here.
  • If the outreach is from Product Teams seeking guidance on integrating open source components into their product, it doesn’t require a meeting. Kindly ask them to read the open source documentation and let you know if they have any questions.
It may be beneficial for the competitor to engage with the open source project assuming they’re also making contributions to the project and doing their own engineering work. Again, you don’t need to take a meeting for the competitor to integrate the open source project into their product.

Tech stack recommendations

  • AWS for hosting the platform.
  • Github for publishing the open source code.
  • There is no current recommendation for hosting the front end of the website. Netlify and Github Pages are some possibilities.
Some of the software above is available at discount for OCV companies
 
⬇️
Distribution
🛣️
Product Roadmap
©️
Software Licensing Terms
📱
Tech Stack Recommendations