Greenheart
commented
2 years ago Had a really nice discussion tonight about this with Stefanie and Chris that sparked some thoughts.
It would be awesome if we could use GitHub's features for collaboration, since it is strongly connected with open source. And it will simplify the project compared to hosting one central CMS server that everything depends on and we need to maintain.
Since we most likely only need content that can be deployed statically, using GitHub and a solution like Netlify CMS would make more sense.
Let's explore this more.
Analysis of what changing the CMS and collaboration would entail:
Pros of Netlify CMS
- Has support for relationships between content, which is a critical requirement we need.
- If netlify CMS has a good github integration with great collaboration opportunities, that would be nice since it would integrate contributions in one place
- Netlify CMS would not require a deployed server with maintenance and costs
- Netlify CMS would give everyone contributions on github
- Netlify CMS would integrate nicely with Git to save the raw content, and then make it possible to build content to a optimized format in the app (if we need that at all, perhaps not!)
- Netlify CMS would move collaboration to github and make it easier to use the Discussions feature. Everything would be integrated
- This would give us a powerful review feature where the community can transparently chip in on what they like or not.
- If we use Vercel with preview deployments, we could see how the content changes look live in the app, to aid the review process
- This would give more contributions on the GitHub graph, and make the project more alive, likely building more momentum
- Netlify supports relationships between items in the CMS, so it would still be possible to link skills, categories, tools, and stories
- Github offers community guidelines and best practices for how to use their collaboration platform. Otherwise we had to create it ourselves
- Can be deployed as a static SPA! Basically hosting collaboration and the live app entirely for free
- Longevity of the project is more easily ensured, since we don't need infrastructure to maintain.
- Not ideal for translations / i18n - but it does work. We've used it for 29k and that worked pretty well when you think about it.
Cons of Netlify CMS
- Netlify CMS (and Github) is more complex to get into, but also more powerful for long time contributors
- Since its based on git, it requires more knowledge. It also might cause merge conflicts
- Not as intuitive or clean UI as keystone
Pros of Keystone
- Built on an relational database = great support for relationships between content. And flexible DX added to that which is awesome.
- Nice UX in the editor for collaborators
- Dynamic and flexible, especially for real time (but that's not what we need, we're even scraping the GraphQL API to build a static JSON file already...)
- Cool tech
Cons of Keystone
- With Keystone for a large public community, we have to build our own tools and processes for how to review. We have to build a lot ourselves to support the collaboration features that GitHub specializes in. And this in addition to building the actual IDG.tools project and community.
- Hard to know what happens if multiple people try to save at the same time. I'm afraid they might overwrite each other's work, which would be catastrophic.
- Requires deployment and maintenance of servers. Possible security risk
- Complexity of when and how to build content - when do
- How do we review other people's changes, or keep track of if someone is misbehaving / making inappropriate edits? How do we give constuctive feedback and encourage dialogue and co-creation?
- Complexity of GraphQL and building a backend, when in reality the app would do fine with pure JSON files editable in Netlify CMS
- Can not be deployed statically as a SPA
- Users need separate account for code contributions (and likely project discussions) and the actual community. They might get contributions showing up in the IDG.tools project - if we build a custom solution for that, again adding complexity to a project with already limited resources... However, users don't get the lasting contributions in the standard open source format on GitHub. This might be a lack of incentive.
- We can't (unless we build it ourselves) keep track of exactly who wrote exactly which piece of content, within a entry for example. Git supports this natively. Let's embrace it.
- Complexity with local development environment and more steps that code contributors need to take to for example set up a local database, configure environment variables in both client and CMS.
- Lack of translations support. We'd have to build it ourselves for now. Or use another tool, but that would add even more complexity and likely another account. We can have a larger impact by focusing on serving the community, rather than trying too hard to build with a specific technology.
Summary
After evaluation and reflection, it's clear that some of the problems we've faced with Keystone are not worth solving for us right now. Keystone is an amazing technology, with a nice DX and UX for editors. But it's primarily built for teams where you have a given set of members and contributors.
Netlify CMS is combined with git and GitHub is much more aligned with the spirit and the practices of successful open source communities. This asynchronous and decentralized approach will help us scale the co-creation beyond a small core team, which is ultimately what we want. It brings too many collaboration benefits that this is hard to ignore.
Thus, my suggestions going forward are to:
- Make use of the collaboration features already provided by git and GitHub combined with Netlify CMS, so we can invest our time where it makes a larger impact.
- Focus on the IDG.tools content, the UX and supporting and learning together with the community who are using and co-creating the content library.
- Keep the deployment costs low and simplify the development and maintenance as much as possible.
- Focus on scalable co-creation that isn't depending on a central server, core team or organization. Rather leave the community open to explore and innovate.
Co-creator flexibility is a top prio to make this possible to scale.