Created a dump of our email subscribers, more on that below
Added a bunch of recent new and backdated news articles and events, more on that below
Went through all posts and tagged everything, with a consolidated list of tags (based on software topic, or on AEC discipline)
Renamed all images to be more semantic and done lossless compression
Two things to bring up:
Firstly, because it's not on Wordpress, we don't have an email subscription. Right now, we offer feeds. Arguably feeds are much better (lightweight, pull only, privacy-respecting, tailored to this need), but I suspect there will be users who don't understand feeds and would prefer emails. (And some who would prefer social media - on that note, what accounts do we have and who has access to them?) There are currently 311 email subscribers. We have a few options (note that mass sending emails is easy, we already have a Sendgrid account - but managing spam, email validation, unsubscription requirements, etc is where the work is):
Just stop doing email subscriptions. Maybe the younger generation don't go for that thing.
Build / host our own, though this kinda defeats the purpose of the migration away from complex apps for security and (lack of) sysadmin resources, but if we do this, https://listmonk.app/ might be worth considering.
Secondly, I went through some of the regular suspects (FreeCAD, Speckle, ThatOpen, Blender, etc) in this area and pre-emptively published a bunch of posts and events (some backdated). This will help new users visited who would otherwise see the rather obscure Castle Game Engine post from 2025, then quickly back into 2024 and beyond. And yes, I did use AI to write these posts. And yes, I did actually read them first as well as read the original content. And because this is rather touchy territory, I'd like to explain and run through my train of thought.
Firstly, nobody likes AI slop. I get that. I don't go to a forum to read AI talking to AI, and I don't go to a news site to read AI opinions either. However, you'll notice two things: these posts are very short, 1-3 paragraphs per post, and these posts are merely summarisations (which I have checked) or the original, and I have of course curated what content should be published (I didn't say "AI go out there and find me AEC FOSS news and publish").
The point of the OSArch news is to bring news together on a rather niche topic which would otherwise be spread out on a spattering of various sources. For this purpose, a short summarisation I think is acceptable. Think "Slashdot" style news, or "Hacker News" where mostly it's just a link back to the primary source (albeit both of those websites people stay for the comments I guess). This will also help with our resourcing problem because it is not such a huge burden on the maintainer of the news site, or people who want to submit news, so this can increase our frequency.
Also, looking back at the recent posts (and please someone tell me if I missed anything, especially if it's major), it's pretty cool I have to say compared to 6 years ago when we started when there were mostly crickets. Our industry is changing!
Minor note: I actually really struggled to get news from ThatOpenCompany, the only way I could was behind their paywall? Have I missed something?
I think the RSS feed contains events at the top because their "added date" is recent since I did a bulk add. I'll do a clean up at least to backdate older events.
Starting the discussion for the wiki migration: the wiki is pretty low activity, and (like most of these kinds of wikis) contains great stuff but tends to be outdated. There are a few problems in the Wiki:
big attack surface, even before AI got involved
We had spam, got flagged for it, we followed all the rules and it's mostly OK now, but still.
It's heavy. We get hit by AI which kills the server. You might wonder why the wiki is on a permanent Cloudflare protection mode? It's because of AI / bots / whatever. What's nasty is they especially love the dynamic uncached pages e.g. recent changes. TBH I hate we have to do this and route everything through Cloudflare.
One option is we just make it Someone Else's Problem and pay for a hosted mediawiki. That might make spam / attack / heaviness be something we don't deal with, but it also doesn't solve the fundamental problem of low activitiness.
An interesting insight I had when migrating the news was how fast it was for me, with AI assistance, to retag, clean up images, optimise images, and insert in information like upcoming events etc. Not to mention iterate on layouts for a bit. Wikis were designed for everybody to collaborate and edit in a web browser. And that's the key thing: in a web browser. Why a web browser? It's because anybody can just press the edit button and type away without being an expert in HTML or web development etc. And the wiki markup allowed people to do more complex stuff and abstract away the code.
With AI, I think the technical bar drops, because you still don't need to know HTML, or Hugo, or Markdown, or anything. You just ... get AI to help you. And the more the system is "vanilla", the more AI can do with it because it isn't governed by a predesigned framework. For example, AI couldn't have done what I did so easily within a Wordpress environment. This is of course a biased view because not everybody will think "get AI to spin up hugo on localhost" is easy, but ... I dunno, what do people think?
So this is a long winded way of saying why not just turn the wiki into yet another Hugo-powered static site, and if people want to edit, they can just edit it via Git. We can still have special wiki template tags so that can be preserved. We can still have a big "edit" link that goes straight to editing the page on Git (just like how Sphinx docs have an integration with Git repos).
Things we gain:
Static site means probably Cloudflare goes away and server hits go down
No mediawiki means bye-bye spam and constant sydadmin / security
If Hugo based, one "less" platform to deal with in the future.
Vanilla setup means easier for power-contributors to do custom things or mass things, especially with AI assistance
Git based history means one "less" platform to deal with in the future
Things we lose:
Anonymous edits (admittedly, we barely get any right now once you stop bots - I checked the last 90 days and there was one registration and one edit)
Browser editing, of a sorts. You could still do it, but there is no preview feature, and no instant publish (I guess there is a slightly delayed workflow publish)
It's a wiki! Nope, now it's a website. You're editing a website, mate.
I quite like the idea of a git backed wiki tbh! Would we be able to have a basic form for content submissions or edits so the lay person who doesn't want to tackle git etc can still contribute?
@bsmith yeah a "suggestion" like that might be in the form of an issue (with issue template) that an editor can then use to take it further, that way the user doesn't need to know anything at all.
I know I promised this ages ago and haven't really committed to it yet, but it it still very much my intention to eventually contribute to the wiki or written documentation of Bonsai. I haven't forgotten nor gave up the idea, just haven't yet gotten the opportunity to yet.
From my part I'd totally be ok with doing away with Media Wiki and heavy database based solutions and go for simpler static sites.
Easier to backup and migrate, less attack surface, less spam potential, and anonymous contributions are IMHO never a good thing, they either attract spam or trolls, and long term sustained contributors would always need an account down the the line anyway.
There may be a bit of a steeper learning curve at the beginning, but I think the advantages outweigh the downsides.
The thing I'd miss the most would be easy immediate previews and direct uploading of media, but those might be easy to work around. There are now some WYSIWYG markdown editors around, and I think at least Github offers some markdown preview features for their builtin wiki. Maybe we could cobble something similar up.
@duarteframos that preview-and-upload worry is the one I keep landing on too. It's basically the only thing the browser-based wiki genuinely does better than git, and it's worth not hand-waving away.
But I think it's also exactly the gap the Forgejo direction closes, and honestly I'd go further than "work around it." I think the wiki should just be a repo on hub.osarch.org. A forge already gives you in-browser editing with live markdown preview, an instant "edit this page" button, and full git history underneath, so you keep @Moult's static/git wins (tiny attack surface, no DB, no Cloudflare) without losing the press-edit-and-type ergonomics that made wikis work in the first place. That's not a separate platform bolted on next to the hub. It's the same platform doing double duty, which is fewer things to babysit, not more.
On the uploads specifically, this is where I think it gets nice, and it's the same trick whether we're talking about the wiki or the forum. When someone drops a file into a Threadbare post (or a wiki page), it just gets committed to a repo on hub.osarch.org via the Forgejo API behind the scenes. The user sees a normal upload button and never touches git. Upload a revised version later and git tracks it automatically, so you get full version history for free without anyone thinking about it. The complicated git mechanics stay completely abstracted away. All the user experiences is "I uploaded a file, and here's its history."
And for our particular niche it goes a step further, which is really the whole NativeIFC argument in miniature. Because we're dealing in NativeIFC rather than opaque exported snapshots, that version history is meaningful: git can actually diff and merge the models, not just store a pile of black-box blobs. Drop in an IFC file and it's addressable via an ifc:// URL, so a forum thread or wiki page can embed a live, clickable model viewpoint right next to the text, tied to that exact revision. Neither MediaWiki, Vanilla, nor GitHub Pages can do that for us, and it only works because the data is native. That's the payoff for betting on NativeIFC: the forum, the wiki, and the project hosting all start speaking the same language.
So my pitch is this: if the wiki's going to be git-backed anyway, let's not stand up a separate GitHub-Pages repo. Let's make it the first real tenant of hub.osarch.org, and let Threadbare lean on the same backend for its attachments. Same edit-via-git story Moult's describing, but with previews, uploads, and the NativeIFC bits coming along for free, and one platform quietly carrying the forum attachments, the docs, and the project hosting.
Another update - regarding email newsletter subscriptions, for the moment I've gone with option 2: self hosted listmonk (dockerised), which is relatively self-contained and easy to upgrade. I've migrated our ~300 subscribers and sent out the very first aggregate email (and added an automatic email newsletter generator script). It's open source and privacy aware. It's actually really nice to use and simple to set up.
Just subscribed to the mailing list, at least the confirmation email came through.
The RSS feed also seems to be working too, got a backlog from as far back as 2020 all the way to May 2026.
Man I love RSS feeds, a sorely missed remnant from the origins of the internet that has sadly fallen out of use. I sure hope it makes a comeback now that the world is starting to be privacy aware again.
Comments
A heads up that I've migrated https://OSArch.org to Hugo. Hooray!
Two things to bring up:
Firstly, because it's not on Wordpress, we don't have an email subscription. Right now, we offer feeds. Arguably feeds are much better (lightweight, pull only, privacy-respecting, tailored to this need), but I suspect there will be users who don't understand feeds and would prefer emails. (And some who would prefer social media - on that note, what accounts do we have and who has access to them?) There are currently 311 email subscribers. We have a few options (note that mass sending emails is easy, we already have a Sendgrid account - but managing spam, email validation, unsubscription requirements, etc is where the work is):
Thoughts?
Secondly, I went through some of the regular suspects (FreeCAD, Speckle, ThatOpen, Blender, etc) in this area and pre-emptively published a bunch of posts and events (some backdated). This will help new users visited who would otherwise see the rather obscure Castle Game Engine post from 2025, then quickly back into 2024 and beyond. And yes, I did use AI to write these posts. And yes, I did actually read them first as well as read the original content. And because this is rather touchy territory, I'd like to explain and run through my train of thought.
Firstly, nobody likes AI slop. I get that. I don't go to a forum to read AI talking to AI, and I don't go to a news site to read AI opinions either. However, you'll notice two things: these posts are very short, 1-3 paragraphs per post, and these posts are merely summarisations (which I have checked) or the original, and I have of course curated what content should be published (I didn't say "AI go out there and find me AEC FOSS news and publish").
The point of the OSArch news is to bring news together on a rather niche topic which would otherwise be spread out on a spattering of various sources. For this purpose, a short summarisation I think is acceptable. Think "Slashdot" style news, or "Hacker News" where mostly it's just a link back to the primary source (albeit both of those websites people stay for the comments I guess). This will also help with our resourcing problem because it is not such a huge burden on the maintainer of the news site, or people who want to submit news, so this can increase our frequency.
Also, looking back at the recent posts (and please someone tell me if I missed anything, especially if it's major), it's pretty cool I have to say compared to 6 years ago when we started when there were mostly crickets. Our industry is changing!
Minor note: I actually really struggled to get news from ThatOpenCompany, the only way I could was behind their paywall? Have I missed something?
Cool, is the way to post news to get commit access to this repo and add new markdown files? ..or the same with a pull-request workflow?
Also the RSS feed seems to only contain events, but not news.
@brunopostle yep exactly.
I think the RSS feed contains events at the top because their "added date" is recent since I did a bulk add. I'll do a clean up at least to backdate older events.
Starting the discussion for the wiki migration: the wiki is pretty low activity, and (like most of these kinds of wikis) contains great stuff but tends to be outdated. There are a few problems in the Wiki:
One option is we just make it Someone Else's Problem and pay for a hosted mediawiki. That might make spam / attack / heaviness be something we don't deal with, but it also doesn't solve the fundamental problem of low activitiness.
An interesting insight I had when migrating the news was how fast it was for me, with AI assistance, to retag, clean up images, optimise images, and insert in information like upcoming events etc. Not to mention iterate on layouts for a bit. Wikis were designed for everybody to collaborate and edit in a web browser. And that's the key thing: in a web browser. Why a web browser? It's because anybody can just press the edit button and type away without being an expert in HTML or web development etc. And the wiki markup allowed people to do more complex stuff and abstract away the code.
With AI, I think the technical bar drops, because you still don't need to know HTML, or Hugo, or Markdown, or anything. You just ... get AI to help you. And the more the system is "vanilla", the more AI can do with it because it isn't governed by a predesigned framework. For example, AI couldn't have done what I did so easily within a Wordpress environment. This is of course a biased view because not everybody will think "get AI to spin up hugo on localhost" is easy, but ... I dunno, what do people think?
So this is a long winded way of saying why not just turn the wiki into yet another Hugo-powered static site, and if people want to edit, they can just edit it via Git. We can still have special wiki template tags so that can be preserved. We can still have a big "edit" link that goes straight to editing the page on Git (just like how Sphinx docs have an integration with Git repos).
Things we gain:
Things we lose:
I quite like the idea of a git backed wiki tbh! Would we be able to have a basic form for content submissions or edits so the lay person who doesn't want to tackle git etc can still contribute?
@bsmith yeah a "suggestion" like that might be in the form of an issue (with issue template) that an editor can then use to take it further, that way the user doesn't need to know anything at all.
I know I promised this ages ago and haven't really committed to it yet, but it it still very much my intention to eventually contribute to the wiki or written documentation of Bonsai. I haven't forgotten nor gave up the idea, just haven't yet gotten the opportunity to yet.
From my part I'd totally be ok with doing away with Media Wiki and heavy database based solutions and go for simpler static sites.
Easier to backup and migrate, less attack surface, less spam potential, and anonymous contributions are IMHO never a good thing, they either attract spam or trolls, and long term sustained contributors would always need an account down the the line anyway.
There may be a bit of a steeper learning curve at the beginning, but I think the advantages outweigh the downsides.
The thing I'd miss the most would be easy immediate previews and direct uploading of media, but those might be easy to work around. There are now some WYSIWYG markdown editors around, and I think at least Github offers some markdown preview features for their builtin wiki. Maybe we could cobble something similar up.
@duarteframos that preview-and-upload worry is the one I keep landing on too. It's basically the only thing the browser-based wiki genuinely does better than git, and it's worth not hand-waving away.
But I think it's also exactly the gap the Forgejo direction closes, and honestly I'd go further than "work around it." I think the wiki should just be a repo on hub.osarch.org. A forge already gives you in-browser editing with live markdown preview, an instant "edit this page" button, and full git history underneath, so you keep @Moult's static/git wins (tiny attack surface, no DB, no Cloudflare) without losing the press-edit-and-type ergonomics that made wikis work in the first place. That's not a separate platform bolted on next to the hub. It's the same platform doing double duty, which is fewer things to babysit, not more.
On the uploads specifically, this is where I think it gets nice, and it's the same trick whether we're talking about the wiki or the forum. When someone drops a file into a Threadbare post (or a wiki page), it just gets committed to a repo on hub.osarch.org via the Forgejo API behind the scenes. The user sees a normal upload button and never touches git. Upload a revised version later and git tracks it automatically, so you get full version history for free without anyone thinking about it. The complicated git mechanics stay completely abstracted away. All the user experiences is "I uploaded a file, and here's its history."
And for our particular niche it goes a step further, which is really the whole NativeIFC argument in miniature. Because we're dealing in NativeIFC rather than opaque exported snapshots, that version history is meaningful: git can actually diff and merge the models, not just store a pile of black-box blobs. Drop in an IFC file and it's addressable via an ifc:// URL, so a forum thread or wiki page can embed a live, clickable model viewpoint right next to the text, tied to that exact revision. Neither MediaWiki, Vanilla, nor GitHub Pages can do that for us, and it only works because the data is native. That's the payoff for betting on NativeIFC: the forum, the wiki, and the project hosting all start speaking the same language.
So my pitch is this: if the wiki's going to be git-backed anyway, let's not stand up a separate GitHub-Pages repo. Let's make it the first real tenant of hub.osarch.org, and let Threadbare lean on the same backend for its attachments. Same edit-via-git story Moult's describing, but with previews, uploads, and the NativeIFC bits coming along for free, and one platform quietly carrying the forum attachments, the docs, and the project hosting.
That makes it sound perfect. Self hosted, single back end carrying most of our infrastructure.
I'd have no qualms with that, +1 from me
Another update - regarding email newsletter subscriptions, for the moment I've gone with option 2: self hosted listmonk (dockerised), which is relatively self-contained and easy to upgrade. I've migrated our ~300 subscribers and sent out the very first aggregate email (and added an automatic email newsletter generator script). It's open source and privacy aware. It's actually really nice to use and simple to set up.
For those who are subscribed, check your inbox :)
For those who aren't, I highly recommend subscribing, it's actually super cool - https://osarch.org/subscribe/
Just subscribed to the mailing list, at least the confirmation email came through.
The RSS feed also seems to be working too, got a backlog from as far back as 2020 all the way to May 2026.
Man I love RSS feeds, a sorely missed remnant from the origins of the internet that has sadly fallen out of use. I sure hope it makes a comeback now that the world is starting to be privacy aware again.