Pivoting: case for shared hosting

I read Eric Ries’ learn startup management recently. The author proposes a mechanism of running recurring small scale experiments and basing business judgements (pivot or commit) based on the results.

When we started work on Hostea, we assumed that there is a need for manages Gitea hosting. The UX research lead by @dachary concluded otherwise, but we ended but building Hostea anyways.

But if we are to be economically viable, we’ll have to determine if there is indeed a market for Hostea. I know that the UX research concluded otherwise, but it would be cool, if we could show it off to early adaptors and see if it is something that they would want to use.

Ries says customers don’t really know what they want. I am not a marketing person, but I think there is some logic to it: how will someone know if they require something if they didn’t even know it existed? Or if it was even possible? So we could re-test our assumption by reaching out to another early adopter group. We tried sysadmins and that didn’t work so another group, IMO, would be FOSS project owners. git.my-project.org is hallmark of well-established FOSS projects, so who knows, a dedicated server might be on their bucket list? A FOSS project leader might have the necessary skills to self-hosting but its worth a try.

That said, I was never big on managed hosting. Shared hosting was what got me excited in the first place and I believe there’s market for it. This is an assumption that needs to be validated but here’s my reasoning: Codeberg, framagit and other libre and gratis source code hosting from reputable nonprofits exist and yet people are willing to pay for paid services like Sourcehut. I am personally a big fan of sourcehut and Drew DeVault’s work(I use a bunch of his software every day) but their offering(email-based collaboration) is much more radical than what’s already out there(GitHub family of forges). So I believe there is marker for paid, FOSS, GitHub family forge shared hosting.

To validate my assumption, I propose we hack together a very minimal shared hosting setup:

  1. compute disk usage per user
  2. CI build minutes per
  3. modify dashboard to implement payments shared hosting

And release it to early adaptors(who? gratis or not? If gratis, will we requite investment? How much?).

1 Like

Codeberg and framasoft (the parent organization of framagit) also derive a revenue (donations) from their usres.

In the spirit of hacking, the pricing could be displayed and computed manually with a few scripts. And an invoice sent via the dashboard. A gitea instance could be created on Hostea (convenient :+1: ) and reaching out to users could start right away, very much in the lean startup spirit :rocket:

I’m not going to do the reaching out part because I switched back to dev mode. But that sounds a sensible thing to try.

1 Like

Sounds like a plan! :smiley:

I initiated this experiment, so I’ll do the marketing bit. Surely if I apply the same methods that I use when I write code, I’ll be able to come up with some marketing strategy that could work, can’t I? Even if I fail, we’ll have very little to lose. :slight_smile:

2 Likes

What about I setup a Gitea / Woodpecker instance with 8GB RAM, 4 vCPU and 50GB disk on the current libvirt hypervisor, under the name foobar.hostea.org or whatever name you think fancier. That should get you started, shouldn’t it? Growing it when needed can be done in a matter of minutes.

Yeah, that’ll be great! I propose git.hostea.org, clean and intuitive but doesn’t clash with the meta gitea.hostea.org.

I have exams this week(ends on August 1), so I’ll be busy till then. I make a list of tasks that I think we will need to try out shared hosting and share it for your review.

1 Like

The CI will be ci.hostea.org

1 Like

Am I right in assuming you intend to use git.hostea.org / ci.hostea.org as a throwable / hackable setup for the purpose of a MVP for trying to demonstrate that there are people willing to pay for shared hosting?

When I write throwable / hackable I mean that it is 100% outside of the managed hosting & Enough scope. You will manually do things on this machine instead of working with playbooks, implement tests etc. Which means that from then on, Ansible won’t be run on the machine, as it could revert manual changes you’re experimenting with.

The machine is monitored to be up and can be resized to grow if you need, but that’s all.

Does that match your expectations?

1 Like

I’m not sure what I’m going to do yet. I would like to identify an early adopter group before I plan the work, that way we can make assumptions as to the core features that they’d like.

So is it possible to disable Ansible later when required?

1 Like

Yes, absolutely. Just make sure you say the word before engaging in manual hacking of this instance :slight_smile:

1 Like

@dachary I have been thinking about shared hosting recently, and I have a few questions. I’d appreciate it if you can share your thoughts on it:

  1. Can an organisation have non-paying members too or are we going to require that all members buy subscription?
  2. How do we account CI/CD time?
  3. Do non-paying members get CI/CD time?
  4. If organisations can have non-paying members, how is CI/CD time accounted for?
  5. How is CI/CD time accounted for non-paying, external (to the organisation) participants.
1 Like

I have not thought about that. What do you suggest?

This can be calculated by getting information from woodpecker or GitLab runners.

Yes, I think all non-paying members should get generous but limited storage & CI/CD time. Freemium works best when most users get what they need for free and the minority can pay for additional resources.

It depends what an “organization” is. If a single account is used by many people that’s easy. If an organization is the paying member covering the costs for a number of individual accounts, it gets more complicate.

Same as above.

1 Like

I don’t have any idea either. But I think some flexibility in this area would be nice. We can limit CI/CD time to non-paying members’ activity but allow them to create repositories within the organisation if 50% of its members are paying. What do you think?

I was thinking about something similar too. I don’t have any idea as to how GitLab runners work, but we could set up a proxy to authorise CI/CD events based on the customer’s quota. Shouldn’t be very difficult and won’t require any changes to Woodpecker. The alternative is to listen/poll for events and cancel builds by unauthorised parties, which doesn’t sound very clean.

A name space/Gitea organisation. For instance Hostea - Gitea: Git with a cup of tea is an organisation.

I’m not sure I understand. Say there is an organization and there are projects in this organization. By default all projects within the organization are subject to the limitations that apply to everyone (individuals or organizations). For instance Gna! - Gitea: Git with a cup of tea is an organization Loïc Dachary - Gitea: Git with a cup of tea is an individual.

If Gna! - Gitea: Git with a cup of tea needs more resources for CI/CD and pays for them, it will apply to all projects under this organization, regardless of who has permission to use these resources. It is up to the people running the organization to decide who has access and therefore who is entitled to spend the extra CI/CD time that was paid for.

How would your suggestion regarding 50% of the members be implemented in this context? Or do you have another context in mind?

Yes. And a simple first step would be a tool to collect the number of minutes from the GitLab / woodpecker runners and feed them to the dashboard. Restrictions based on those quotas can be implemented once the data is available.

The 50% idea is for use in Sourcehut-like freemium model:

Sourcehut allows patches and bug tracker participation from the public without requiring an account through mailing lists. Their approach is cheap as it doesn’t require significant resources to accommodate a project’s community: paying customers get code hosting and other related services and the public gets to interact with the project gratis.

We can’t mimic Sourcehut using Gitea, since participation on Gitea requires an account. But we can allow participation without requiring a purchase. For that, we can provide forking for free but creating new repositories should require payment.

This is an interesting way to look at it! I was thinking that all individuals will use their individual quotas while working under organistions. I think this is how both github.com and gitlab.com operate: employer pays for pro individual accounts and the individuals will have forge-wide access to pro features and not just on the employer-owned organistion.

In this context, let’s say person A and B are part of Org X and are both have pro accounts. Person A pushes a commit to an Org X repository and triggers the CI, we deduct CI/CD resource from person A’s quota. If person A sends a PR to Org Y and triggers CI/CD, the time CI/CD resource will again be deducted from person A’s quota.

Now, if person C, who has a gratis account, is sending a PR to Org X and triggers CI, we can account resources in three ways:

  1. Let person A or B donate their quota to run person C’s PR build
  2. Give organisations a free quota if 50% of its members are paying.
  3. Let organisations purchase resources, like you say

I don’t know how much a relaxed freemium model will cost us and hence the stinginess.

I better understand the idea, thanks for clarifying this. This is all going to be a two step process, since there is an agreement for a freemium model based on resources consumption.

The first step is to get people to trust and use Gna! And for an extended period of time (months, if not years) they won’t exceed any resource quota. But these quotas will be set because it is what keeps the resources contained, this is what shields Gna! from the problem of an infinite growth.

The second step will be to refine who will pay for additional resources and how. It may be what you suggest: it makes sense. Or it may be different depending on how people are actually using Gna! There will be a need for flexibility and imagination so the pricing is accepted and feels justified.

1 Like

Makes sense. I implemented the policies I mentioned here, but the script is flexible, and it can be adapted to use a different set of policies.

1 Like

Great, that will be useful down the line :+1:

1 Like

Shared Hosting Customer Workflow

  1. Signs up on Gitea instance
  2. Clicks “upgrade” button in the navigation bar(minor Gitea frontend modification):
    image
  3. Authenticates on the payments software using their Gitea account
  4. Selects a plan and pays for it, just like Hostea/dashboard

Subscriptions

I am investigating subscriptions on Stripe but for now, I propose we use cronjobs like we do with Hostea/dashboard.

1 Like