Every time we get a support ticket asking for a trial extension because “14 days isn’t long enough for the community to take off” a tiny part of me dies.
A decade ago, community builders recognised that 6 months probably wasn’t long enough for the community to take off and they were ok with that. They understood that community building is a long game and the play starts well before launch. In today’s world dominated by social media and Discord, people are losing the art of true community building in favour of amassing followers. This miscategorisation of an audience as a community doesn’t take into account how complex the social systems underlying online communities are.
Serious community builders know that communities are ecosystems; they have a lifecycle that needs adaptive strategies.
That lifecycle stretches from **Inception** – which begins well before the free platform trial stage – and continues all the way through to **Mitosis**, which is what ultimately happens to healthy communities that enjoy longevity.
Not all communities will reach this final stage, but an example of one that has is the first community I ever joined and subsequently went on to manage – [The SitePoint Forums](https://www.sitepoint.com/community/?ref=blog.discourse.org). Although it’s been over a decade since I left, I have a deep and lasting connection with that community, which is still thriving today. As well as providing the support I needed to learn the skills to pivot into a new career, it offered lasting personal friendships, a strong professional network, and a long-standing customer.
For this to improve, community platforms need to better support the inevitable last stage in a community’s lifecycle: archival. Right now there are no good options to transition a community from a dynamic platform to a static archive that can persist online without ongoing maintenance or server costs.
I’ve experienced this as both member and administrator of a community that for me was a great example of bringing people together online to advance a shared cause. I’d love to see it preserved as an archive and reference on the web, but it’s difficult to implement in practice.
It would be powerful if Discourse could lead the way here and support communities through their entire lifecycle, helping us build a web that honors and preserves the communities that formed, even after active engagement has ended.
I wonder whether you could work with the Internet Archive to develop a standard to help them archive the content of forums. Different forum software operates differently but there are obvious things that are the same. Your experience in migration from other forum software should be useful.
I am saving my whole instance at wayback machine everyday until the end giving power to user delete his content but keeping history of yours editions it’s a good way for that I always say one day I not can’t keep so I am teaching my staff these stuffs but this will take a long time so for awhile saving what I can
Can you elaborate a bit on this? Currently we offer an option on our hosting to archive the site in read-only mode for perpetuity, but we obv can’t do that for free because there is an ongoing cost to us.
For site managers, read-only mode means you don’t have to actively moderate, but it’s not the same as archiving. It turns off interaction, but technically everything else stays the same. You need to host the instance, keep it updated, maintain the same servers.
True archiving means moving from a dynamic app and database setup to static HTML. There are a few community scripts out there, but trying it in practice showed me how complex it actually is. I think it’s too hard for individual communities to solve from scratch. Providing standard migration solutions that also address UI representation and data privacy handling could go a long way toward better preserving communities.
There’s also a conceptual dimension: if community platforms supported the full lifecycle from the start, it would likely lead to better systems overall, in ways we might not even have in focus now. In regular product design, planning for a product’s retirement is just part of good design.
On a smaller scale, groups are a good analogy and similar use case. Right now sites often end up with dormant or abandoned groups, or groups disappear without a trace. If we had expected lifetime and sunset planning in group setup from the beginning, it could support site managers to be more purposeful and organized with groups overall.
A Discourse to standard markdown converter would give a lot of flexibility. Category, tag, author, visibility, etc metadata could be stored as frontmatter. A custom or existing static site generator could convert the markdown files to HTML. Files could also be read locally with note-taking apps that support markdown. Discourse could also provide a markdown → Discourse migration script to allow archived sites to be converted back into forums.
The markdown approach would let Discourse promote the idea that a forum’s content is independent of Discourse the application. It would make it conceivable to think about posts created on Discourse being read 100 years in the future.
There are cases where people come together online for events that have a natural beginning and ending. For example, preparation and followup for an online seminar. Discourse could be an appropriate tool for this. By making the lifecycle explicit and providing an archive of the content, a forum that generates say 5 topics and 100 posts over 2 months could be seen as a success instead of a failure. I suspect that an explicit end date would also make some people more willing to sign up and participate in the discussion.