Switching to the open-core model

[jackycute]

Dear markdown hackers,

Thanks for your long-standing support.
Reflecting on what we learned over the past one and a half years, we decide that we want to move CodiMD and HackMD into the open-core model to better address the needs of the community.

What did we learn?

Back in October 2017, when we forked HackMD enterprise edition (EE) from HackMD community edition (CE), we had two goals: In addition to supporting ourselves, we wanted to keep the HackMD open source community active.

To achieve the second goal, we promised not blocking any pull requests, even those with features similar to HackMD(EE). We kept patching vulnerabilities and fixing bugs. And we invited two community members to be the community's advocates. They did a great job moderating CE and making sure we kept our promises.

Still, due to the lack of clear communication with the community at large on our part, the confusion between the two versions persisted, even after we changed the name of HackMD(CE) to CodiMD. Issues were posted in the wrong channel, same questions regarding the forking decision got asked over and over again, and extra burden were placed on our community advocates to explain the naming, the difference, and the history between HackMD and CodiMD. Moreover, the uncertainty of our continuous support for CodiMD deterred contributions. We've seen the activity of the community decreased.

From studying other successful open source projects, we learned that for an open source community to thrive, continuous support and maintenance promise from an (often commercial) entity is essential. It is imperative that we show strong commitment to the project, take full responsibility directing the open source project as well as the commercial one, and keep the fine balance between the two goals.

What do we mean by open-core model?

The HackMD production service at hackmd.io and HackMD(EE) had gone through major refactoring since the fork. It is now written in Typescript for easier maintenance and its performance improved to support the users on our production server. We will create a new "HackMD-core" repository, which contains the core code base of HackMD. We will then refactor CodiMD and replace its core with the HackMD-core.

Current and future features on both HackMD and CodiMD will be offered as modules that could be plugged into the core. All current CodiMD exclusive features will be refactored as modules and offered with the core as a work-out-of-box bundle. These include:

• Dark mode
• CLI
• Minio image upload
• OpenID authentication
• MatterMost Authentication

Some current HackMD exclusive features will be added to the CodiMD bundle as well. These plug-ins will also be open source. They include:

• Book mode
• Profile page
• User settings
• Embedded note
• Speakerdeck rendering
• Google drive integration

We will uphold the following principles during and after the migration of the CodiMD project:

1. the database should be backward compatible so there would be no worries over existing CodiMD content.
2. the code base should be modularized and API would be clear so the community could build cool things on it.

Open-Core Road map

Here's our preliminary road map to the migration:

1. Modularization pilot:
   • Authentication module
   • Book mode
2. Core refactoring and performance improvement
3. Modularizing:
   • Profile page
   • Full-text searching on profile page
   • Settings
   • slide mode
   • Publish mode
   • Editor mode features
   • Embedded note
   • Permission improvement
   • Change notification

License

The HackMD-core repository and all free plug-in modules will be licensed under Apache 2.0, while paid modules will be licensed under our own commercial license. The license of CodiMD and CodiMD exclusive features will have to remain AGPL v3 even after we finish refactoring.

Discussion

We want to thank the community for your patience over the past one and a half years. We hope to better support the community by this switch to the open-core model. Please give us a thumb-up emoji if you think this is a good idea, or let us know how you think by leaving a comment below.

[davidmehren]

I like this. Even though it's yet another change to the relationship of CodiMD and HackMD, a "standard" open-core model is way easier to explain to people.

Regarding the repo-structure: I understand there is going to be one HackMD-core repo. Is the current CodiMD repo going to be obsoleted? Will there be one repo for each plugin or one big monorepo for everything?

[ccoenen]

There's power in the choice of AGPL-v3. And while I understand the reasoning of choosing apache license from a business point of view, this is the point that's keeping me from jumping in joy right now.

I would also like to enquire how "the community activity has decreased" is measured?

[kindfulkirby]

There's power in the choice of AGPL-v3. And while I understand the reasoning of choosing apache license from a business point of view, this is the point that's keeping me from jumping in joy right now.

Won't CodiMD remain under AGPL, though? I'm not sure there is a downside to opening HackMD to an open-core model, but I might very well be missing something.
(And I'm just a user, not a dev 😉 )

[ccoenen]

The currently available CodiMD codebase remains under AGPL, that's right. There's two things that worry me about this. First:

We will then refactor CodiMD and replace its core with the HackMD-core.

This would mean that this will be the end of CodiMD (AGPL) based on this repo under this organisation here. Of course, anyone is allowed to fork and use the code that's here right now. But it also sounds as if the HackMD team also intends to run the open core under the name "CodiMD".

This is a somewhat unprecedented step, and I believe this must be an error introduced in translation or something like that. All open core projects I know run under something like "MySQL Community Edition" or "Zimbra Collaboration Open Source" or "GitLab Community Edition". I believe replace to be a typo for two reasons: It would basically squash the existing development effort under AGPL but also dilute the HackMD brand. Basically everybody loses, and I don't think that's intentional.

So we come to the second thing that worries me:
Let's assume we have HackMD-CE (Apache) and CodiMD (AGPL) from now on going forward. The licenses are incompatible[1] and prohibit any easy exchange of code. Basically, all work that's done on one can't (without extra work by the individual author) be applied to the other. While I would object to "decline in community", it is still a small community. And this community would surely split between those who keep using CodiMD (AGPL) and those who want HackMD-CE (Apache). So, in essence: CodiMD (AGPL) may well be at stake.

[1] Aside: the licenses:
This is not a fault of either license, nor is it an accident. It is part of their different design goals. As stated before, AGPL gives a lot of power to the community and to its users. One of these powers is, that the code of your service can't be hidden from you. You as a user (any user! Not developer, not Admin. Any regular user!) is entitled to a copy of the source code. Apache is very different in that regard.

[SISheogorath]

Hello Community, hello HackMD team,

First of all I want to tackle the problem from a very practical perspective: AGPL is complicated, AGPL pushes free software, AGPL is great. When we have an Apache licensed core, and the CodiMD parts remain under AGPL, then the end result is still licensed under AGPL.

• Apache -> AGPL ✔️
• AGPL -> Apache ❌

That's how it works and that's why we originally decided to use AGPL. This means that whenever you decide to keep any plugin under proprietary license, it becomes incompatible with all CodiMD plugins. In other words people either run a CodiMD-only version or HackMD re-implements all features in CodiMD. Effectively, it either destroys the purpose of this issue's idea or it makes CodiMD obsolete in general which makes the whole idea of opening an issue here, except for marketing purposes, pointless. Sorry for stating it that clear, but boils down to that, and I already pointed that out in the previous conversation we had, even when I wasn't that clear on this.

One of the reasons why I'm personally far from happy with this idea in general, besides the license issue, is that it literally throws away more than a year of work by the community in order to bring HackMD and CodiMD together with the intention to monetize the CodiMD community. Which is in a way pretty much against what you purposed in 2017 when you decided to let the community organize itself.

To be clear, no one wants to prevent you from making a living, but it should be done in a fair and reasonable way and this idea is basically "Let's change the license from AGPL to Apache" (of course by taking care of the problem, that AGPL in general doesn't let you do that, which is tackled by bringing a core component under a different license).

And you as HackMD team, as well as I, know that this idea didn't came from nowhere. It came up all of the sudden, when I asked you about your feelings about moving this repository along with other repositories to an own CodiMD organization, since the community is organizing itself anyway.

I would love to see more contributions from your side, but I understand that you have to focus on making a living with HackMD. What I don't understand is what hinders you on pushing your changes to CodiMD instead of an own core repository. Sure, things would be AGPL licensed, but since you are the copyright holder of your parts, it wouldn't matter when you run that parts as a proprietary product on HackMD.io. The only difference would be that you can't take the advantages of community contribution, but that again would allign with your commitment from 2017 about taking the communities fruits.

[davidmehren]

After my initial positive comment I thought about the other comments and AGPL in particular. I must say, I probably misunderstood the goal of this issue.

I have to concur with @SISheogorath and @ccoenen. You can't just take over a community project and throw all work that has been done out of the window.

I somewhat understand the "with AGPL we can't make money with proprietary addons" thing. But OwnCloud tried that and (at least I would call that) failed. Nextcloud explicitly does not use an open-core model but solely makes money by selling support around Nextcloud. Maybe something like that would work for you?

[kindfulkirby]

Ah dang, you're right, I missed the part about how they'd change everything but "CodiMD exclusive features" to be Apache licensed… I figured it would be dual-licensed and remain AGPL (or triple, I guess, if they want to sell some of it?)!

[jackycute]

OK, let me clarify this.

What we're proposing is to keep the CodiMD and all previous contributions' license "as-is" (AGPL).
And we will extract the HackMD-core as a separate repo (licensed under Apache 2.0) from HackMD (EE) which will be refactored and open source.
Then we will try to refactor CodiMD to use HackMD-core and make all features pluggable (all CodiMD's plugins will be licensed "as-is", AGPL).

I believe the licenses will be compatible in this way.

Also, we will keep maintaining HackMD-core, so that CodiMD can use up-to-date, enterprise level core and install or write any plugin that they love.

From above points, you can see that HackMD (EE) is the version that installed exclusive paid plugins (close source) that extends HackMD-core.
And we hoping to open source those paid plugins one day and this proposal can make that possible when the time comes.

[SISheogorath]

@jackycute well, while it may is not intended, but at the end of the day it would mean that we would swap out large parts to the current code base in order to make it compatible with hackmd-core. And while our codebase is AGPL licensed the hackmd-core would be Apache licensed.

In other words, large parts of our codebase would change their license from AGPL to Apache. Maybe not with exact intend to do this, but at the end of the day, that's the result.

And yes, we could integrate an apache licensed core into CodiMD but the question is: What is left from CodiMD when we swap out the core? Looking at the features that were listed above that would be 5 JS files, let's be grateful and they we end up with 20 things that are CodiMD exclusive. This would basically destroy the foundation of the community around CodiMD, which has a strong relation towards free software, in order to move people towards HackMD-core which runs on a simple permissive license.

And to state it clear, nothing is preventing you from open sourcing features like book mode or user profiles. It just doesn't make a lot of sense, from a business perspective, which is probably the reason why it didn't happen, but it's also uncool to bring it up here like you couldn't do it otherwise.

[pferreir]

I think there is a choice here, between:

• HackMD CE, which would probably mean a gain in the short term, but also that the project remains tied to HackMD as a company and so does its feature plan;
• CodiMD, which means leaving the mothership for good and remaining a community-driven project;

This is my personal opinion: as already discussed on Matrix, as a user and occasional contributor, I think there is already enough evidence that while Open Core does tend to work finance-wise (so, from the PoV of sustainability), it also alienates a great part of the FLOSS community and increases the likelihood that larger players will just try to crush you. Look at ElasticSearch and what is now going on with AWS. Or MongoDB.

But those who contribute the most should be the ones taking the decision (@SISheogorath in particular).

[SISheogorath]

Okay, maybe all this got a bit dramatized yesterday, sorry for that, but I wanted to make a hopefully reasonable point. Let's come down to a bare technical question:

@jackycute what do you expect that CodiMD repository will look like after the refactor?

[jackycute]

Thanks for all your feedback, they are well received. The fundamental reason we started the discussion of the open-core model was hinted in the issue above, but probably not as clear as it should be, or got overlooked. Let me try another take here: We think CodiMD deserves more love from the HackMD team. Now the question is how?

These are our constraints:

1. We have to make a living as well. Our team size and team composition do not allow us to balance purely selling support and improving an open source HackMD at the same time.
2. Maintaining two markedly different code base is just too much a burden for a startup of four developers, and it just feels duplicate and wrong.

Therefore, open-core model seemed like a great solution to us.

Yet, your sincere feedback forced us to come down to the very essence of our assumption. Is open-core model really the only way? AGPL does provide very good protection and assurance for the community, can we love CodiMD more while respecting that? Lastly, nobody likes the project they had worked on being hollowed-out (even it's replaced with a better version), we have to respect that as well.

So we think of another way:

1. HackMD team will now, like where everything started, officially maintain CodiMD.
2. CodiMD will still undergo a refactoring, but not as major. We will focus on making sure the API and database schema are in sync with HackMD, so we could minimize the effort maintaining two very different code bases. The ultimate goal here is to make porting features from HackMD easier.
3. CodiMD will remian AGPL. Since the refactoring is just work we do on CodiMD and it doesn't share code with HackMD, the HackMD team could still keep our proprietary source closed and commercially licensed.

Hopefully this addresses most of your concerns that were valid. Let us know if you like this plan better by giving us a thumb-up emoji, or leave your comments below.

[pferreir]

@jackycute it's great that you have listened to the community's concerns and that you're considering taking the harder path to keep us all happy. Thanks!

At the same time, there's something that has never been very clear and is even less clear to me now: who owns CodiMD? Is it the Open Source sibling of HackMD? Is it a community project that HackMD happens to contribute to?
That may seem like a detail, but it makes all the difference with regards to governance.