I am considering open sourcing a project that I've been working on. Ideally, I'd like to create a hybrid structure that allows for a community edition & enterprise edition (much like Kafka, Gitlab etc). The community version will have the basic features while the enterprise edition will have some premium features and workflows.
I'd love to hear from the community on how do we, as a team, split the code and/or how do we structure the code to keep the community versions & enterprise versions independent, clean and maintainable.
For reference, the technologies we use are Java11 & React.
Look forward to learning from your responses.
Top comments (5)
Sorry I have just seen this post.
It is great to hear that you are considering open source your project. In the past when I have consulted with developers and business, I have always given the same advise - what is it that you are looking to achieve?
You need to start with what you are hoping to achieve by open sourcing, not in technical terms, but from the perspective of how open source can help/enable certain business (or project) outcomes.
Open source is not a business model, and from the wording of your original question you need to be careful if that is your assumption or belief. I am very happy to have a more detailed conversation with you if you want to discuss in more details.
Thanks for your response Ricardo. I agree with you that open source is not a business model. But we need to create a revenue stream for the company in addition to the open source project. Hence, the need to keep some features proprietary.
Our main objective behind open sourcing our project is because I believe that something like this should exist in the world. Today, I see a lot of proprietary solutions solving the problem we are working on and not enough open source alternatives. It's an endeavor to give back to the community.
I'd love to discuss this with you in more detail. Can I DM you?
Sure please do.
Generally, regardless of tech stack, I would design a plugin based architecture. The essential parts of the software would be part of the "core", including the plugin host. New functionalities can be added by extending the software with plugins.
This way, the plugins source code does not necessary have to live in the same repository as the "core" source code. Proprietary plugins can be hosted, e.g. in private repositories.
The "core" parts can be licensed under open source license. You can license the plugins under your own terms, and depending on your business model, you could also let community develop open source plugins for your software. You could also ship plugins that fall under the same open source license as the "core".
Thanks a lot for your response Galuh. The problem with a plugin approach is that it's hard to make everything in the platform a plugin. There are large swathes of code that can be converted into a plugin, but making "everything" a plugin is hard. There will always be a corner case that doesn't fit this bill.
I'm considering this approach and over the last few months, we re-factored some parts of the codebase as a plugin-based architecture. But, increasingly I'm of the opinion, that this is not a 100% foolproof solution.