This is a blog post draft to conclude the MVP and announce hosting is open to the public. For now I propose to be the one receiving the payments and I’ll update the spreadsheet in accordance to the revenue sharing model. @realaravinth once the organization you are creating is ready, you can be next. I’m expecting that nobody will actually subscribe, not at this stage. But nothing should stop that from happening. There are a zillion things missing for Hostea to handle more than a handful of paying users but we can worry about that when and if that turns out to be the case.
In the spirit of dogfooding I’ll be a Hostea paying user as well as the one receiving the money. I’m not sure yet what the Gitea instance will be used for but it will be used for something real, again in the spirit of dogfooding. Maybe as a Gitea instance with federation enabled, just that?
What do you think?
Hosting a Gitea instance on Hostea is now possible, although experimental. It is meant to be a minimum viable product: anyone should be able to create a new dedicated Gitea instance within minutes and pay for it on a monthly basis with a credit card. It also includes a dedicated CI based on Woodpecker. The smallest instance costs 10€ per month (2GB RAM, 10GB disk, 1CPU) and will be a good fit for a freelance up to a team of five people but bigger instances are also available if more RAM, CPU or disk is required.
The service is 100% infrastructure as code, published as Ansible playbooks within Enough. It can be self-hosted on bare metal (with libvirt) or in the cloud (with OpenStack): follow the quick start, configure playbooks for hostea and the dashboard.
The organization supporting Hostea is a horizontal collective of individuals and organizations. The revenue sharing model requires that 25% of the income (not the profits) is dedicated to help the Free Software projects Hostea depends on such as Gitea, Enough, Django etc.
In February 2022 the project of running a dedicated Gitea hosting service was proposed to the Gitea project and other organizations and plans were drafted. After a month of discussions it turned out to not be a good match for various reasons.
It was suggested a few times to create a new project from scratch instead of joining an existing organization. However, in order to be sustainable, a hosting service needs customers willing to pay for the service. And that required skills that no-one involved in the project had. So it was decided that the project was to be terminated because there is no point is creating a technical stack that’s not going to be used by anyone.
The most common mistake technical people do when creating a new piece of software is to overlook the fact that they have absolutely no idea how to let their intended user base know about it. Maybe the reason it happens so often is because it is very difficult to resist the compulsion of creating something. Because that’s what technical people love to do: create things, even when they have no clue if they can be useful to anyone. So it was decided to create a technical stack that can spawn a Gitea hosting service, knowing full well that it won’t have any users.
To keep this madness contained and enjoyable, it was decided to set a deadline to July 1st and to define precise and realistic technical goals. It turned out to be a good experience: everyone learned a lot in the process and the outcome is something that can be reproduced. Most MVPs are a brittle pile of hacks designed to last a few weeks and be thrown away. But since a major goal of the project was to create a self-hostable technical stack, it had to implement that feature and therefore be reproducible.
One of the goals of Hostea is to deploy federated forges, even when the implementation of these features is experimental. Instead of creating a centralized organization to support Hostea, it was decided to create horizontal collective instead. It feels like a contradiction for a project committed to decentralization to be governed by a centralized organization.
The collective is composed of individuals and organizations but, unlike exclusively volunteer based Free Software projects, it is for profit. Customers rent Gitea instances by the month and the income is used to pay for expenses. There is however a difficulty: by nature a horizontal collective cannot be incorporated as it would create a level of hierarchy. The revenue sharing model is set as an informal agreement between members where one of them can receive the income and distribute it to the others, depending on their Hostea related expenses.
It also requires that 25% of the income (not the profits) is dedicated to help the Free Software projects Hostea depends on such as Gitea, Enough, Django etc. It can either be via a donation, by upstreaming a bug fix or any kind of work that is beneficial to the dependency.
In the spirit of dogfooding, the people who created the technical side of Hostea will use it for themselves on a daily basis. It will be open to the public as well but realistically at most a handful of customers will subscribe.
Since the focus of the authors is on forge federation, they will add federation support in Hostea. And this will be their primary motivation to improve and maintain Hostea: it is the only hosting platform where this can happen.