Strengthen Joplin’s resilience beyond a single developer

First of all, thank you for the impressive work that has gone into Joplin. It’s a promising and reliable alternative to apps like Evernote, combining open-source freedom, local control, multi-platform support, and strong privacy—a rare and valuable set of qualities.

I’ve been experimenting with Joplin and using it occasionally with appreciation. At the same time, I’m seriously considering migrating my entire Evernote archive of around 60,000 notes. What’s holding me back—and what I’d like to raise as a constructive suggestion—is the project’s dependence on a single lead developer for its continuity and infrastructure.

This is not meant as criticism, but rather as a friendly appeal: would it be possible to introduce some form of shared responsibility or governance within the Joplin project? For example:

  • appointing co-maintainers with access to critical infrastructure (build systems, app store accounts, servers),
  • documenting essential development and deployment processes,
  • or even establishing a small foundation or trust around the project.

None of this would need to be large-scale or bureaucratic, but small steps in this direction could greatly enhance confidence in the project’s resilience. Especially for users like me, who are considering entrusting their entire knowledge archive to Joplin, such a structure would offer long-term reassurance.

Thanks again for what has been built so far—Joplin is truly something special.

Just giving my 2 cents:
The main reason I use Joplin is because it does not rely on any critical infrastructure. If tomorrow Laurent shuts down the project, the Joplin app and any sync service I use will continue to work (with the exception of if you are using Joplin cloud). If I was using Joplin cloud, I can still switch over to a self hosted Joplin server instance (the code for this is open source as well).

If no-one steps up to fork the project, I would have ample time to look for an alternative for when at some point I might update my OS and the app no longer works - rather than being given short notice that my sync will stop working.

In my case, I probably have enough skill to make compatibility updates to the apps myself, as they use a well established technology stack (React, React Native, Electron) which would likely just need upgrading. But if you're not a developer, there are plenty of developers with the necessary skillset, so you could pay a contractor to do these upgrades for you.

There is also documentation available for how to build everything yourself, and the automated build and deploy process is all defined in code, which can be run on any Github account. So there is sufficient documentation for others to fork and continue the project, if any account / access permissions are not currently shared

2 Likes

To answer to these specific points:

  • appointing co-maintainers with access to critical infrastructure (build systems, app store accounts, servers),

All critical parts of the projects have multiple administrators (npm, GitHub)

  • documenting essential development and deployment processes,

We do that - https://github.com/laurent22/joplin/tree/dev/readme/dev

  • or even establishing a small foundation or trust around the project.

There's a company to back the open source project.

5 Likes