I've been publishing HashPost's code publicly since its inception; however, it's certainly not open source; there is no license associated with the code and all rights are reserved which makes it more source available than open. Recently I've been thinking about what the pros and cons of open sourcing are as well as how HashPost will sustain itself. The two questions inevitably have some overlap.
I have no plans or announcements in this post, just thoughts.
Monetization
At the end of the day HashPost has to make money in order to stay online. There's a lot of different ways that could happen but the subscription model has caught my eye because of its analog to HashPost's cost model.
Cost Structure
HashPost has two kinds of costs: recurring and usage.
Recurring costs are often more simple but sometimes scale with usage. For instance, as HashPost grows it will either need more servers or more powerful servers. In the tech industry we call this horizontal vs vertical scaling. Both result in a cost that semi-correlates to demand.
Usage costs are more complex. They're often tied to the number of users or the amount of data processed. For instance, as HashPost grows it will need more storage.
HashPost has a little bit of both of these categories. Those costs are fairly predictable per user.
The Moderator Economics Problem
The other "cost" to HashPost is the business model of paying moderators. I still haven't worked out exactly how this will work but I lean in the direction of a subscription model. Discord and Reddit have both been very successful with this model, however, a large chunk of their costs are tied up in engineering salaries. Neither of them actually pay moderators although Discord does give communities an avenue to monetize themselves. What that actually means in practice is a bit of a mystery.
For engineers on the more senior end of Senior Engineer the average cost per engineer is nearly half a million dollars when you go all in with benefits. Of course, the thinking goes that in a successful software business every engineer makes or saves the business some multitude of their salary if executed correctly.
HashPost's premise is slightly different: in the age of AI fewer engineers can leverage LLM technology and tools to maintain a larger amount of code and distributed systems. What this actually looks like is that stuff I used to need help with or would take me weeks to figure out, I can now knock out in a day or two with the right prompts and tools.
That leaves more money on the table to pay for costs like moderators that can work for a commission. Instead of needing five engineers to maintain a complex system, maybe you only need two, and you can redirect those salary savings toward moderators.
Again, the specifics are what I'm still fuzzy on but I'll keep writing about it as my thinking evolves.
A Working Example: SourceHut
There's actually a good example of this subscription model working in practice. SourceHut is a code forge like GitHub and GitLab but it's also distributed as open source. You can freely download a copy of SourceHut and run it yourself. The overlap SourceHut shares with HashPost is that it's both small and subscription based, eschewing advertising and data brokering models that most social media platforms leverage to keep themselves afloat.
Like HashPost, SourceHut maintains their own code, provides a service, and has a subscription model. From what I understand SourceHut does have a core group of engineers that help drive the advancement of the project. From what I understand they have an umbrella company that does consulting work that they use to fund the development of SourceHut itself. In that way our models aren't all that different; I plan to keep my day job while also running HashPost. This is something I have to coordinate with my employer but given that I have never worked in social media it hasn't been a problem.
For all the things that make SourceHut viable they also have threats to their business. For instance, the smaller you are the more vulnerable you are to bumps in the road or attacks by much larger entities than yourself. SourceHut experienced a fairly devastating DDOS that left them down and exposed - ultimately some of the bigger vendors they used were not willing to help them the way they probably would've helped a larger company like GitHub. Additionally, since SourceHut's infrastructure is physically colocated in their data centers that necessitated physically shipping servers to their new Amsterdam location. Servers which were ultimately lost and also have been unable to exercise insurance on. Drew has written about some of the challenges they've experienced being small.
Open source
The subscription model is one thing, but the question of whether to open source HashPost is another entirely. When someone says open source to me the last thing I'm thinking about is money. There's a lot of ink I could spill on this topic but ultimately I think about open source in a couple modes:
- a way in which companies codevelop software
- a way in which people share software freely
That's to say there's a "communal" aspect to open source as much as there is a "corporate" aspect. Neither of these modes actually make money themselves. There are some companies that have managed to develop beyond "open core" models which seek to blend those two modes. SourceHut, which I mentioned earlier, is one such company. They count on a certain number of volunteers to help run the service.
How they get paid or if they do at all is a bit beyond me. I do think it is somewhat of an acknowledgement that a business like HashPost is possible but there will be big challenges.
The risk to open source is that anyone can run a different version of HashPost under their own name. I'm not fundamentally opposed to the idea and it might encourage a future where HashPost can be part of a federated network of HashPost servers. Federation, however, is not in my current plans or designs and brings a lot more new problems than it solves.
I do like the idea that many people could be responsible for the advancement of HashPost. How or if they'd get paid for their efforts is an open question. It is also possible that people would just be motivated to build the future that they want regardless of whether that gets them paid. I'm not a huge fan of relying on good vibes to deliver a product though.
Eight years ago Reddit closed their source. While I somewhat disagree that people seeing what you're building before its released is a bad thing, the point about spam protection is a good one. Additionally, Reddit made a fundamental architectural shift: they moved to microservices. Microservices are a big old buzzword in the software industry but it's a situation that leaves you firmly in the camp of horizontal scaling that I mentioned earlier. As an architectural pattern it also makes "fire and forget" deployments much more difficult for the average consumer of software and muddies your architectural landscape. Service oriented architecture (SOA) is probably a healthy middle ground between monolithic architecture and full blown microservices.
The difference in complexity is striking when you compare them side by side:
Service-Oriented Architecture (SOA)
Microservices Architecture
In any case, I could see an argument for licenses like AGPL or GPL to at least leave that door open. Solving the spam problem is a big one; I could see a novel use of plugin architecture to solve exposing spam protection code. Instead of baking anti-spam measures directly into the core codebase, you could design HashPost so that spam detection runs through pluggable modules. That way the core platform logic stays open while the specific spam-fighting techniques remain private.
Putting It All Together
This post is a long way of saying that I have ideas and there's examples out there of how all the things I want to do with HashPost are possible. The subscription model provides a sustainable path forward that aligns costs with users, the AI advantage creates room in the budget for paying moderators, and there are viable approaches to open sourcing that don't compromise the platform's ability to fight spam.
The specifics are still evolving, but the foundation feels solid. Whether HashPost ends up fully open source, source available, or somewhere in between will depend on how these economic and technical pieces fit together in practice.