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)
  2. 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.