DRAFT: Revenue sharing model

This is a topic based on today’s chatroom discussion regarding a revenue sharing model proposed for Hostea. Here is a draft of what could be proposed for inclusion in the Governance and decisions category.

Revenue sharing model

Hostea is a non-incorporated, horizontal collective of individuals and organizations that provides services (hosting and clinic) on Gitea. For each Gitea instance hosted on Hostea a recurring income will be received and for those healed in the Clinic, the doctors will receive payment. How is this income accounted for and how is it shared among Hostea members?

The following rules define a revenue sharing model that aims to:

  • Compensate everyone in proportion of the work they do and the expenses they incur
  • Dedicate a share of the income to develop Hostea so that it can evolve over time
  • Dedicate a share of the income to sustain the Free Software projects that Hostea depends on
  • Rely on the decision making process defined by the Hostea governance to resolve disputes between members and prevent abuse

It is a declarative (i.e. each member declares their income and expenses) and informal understanding between Hostea members. It has no legal implication (i.e. if a member does not comply, there is no legal recourse). When members indirectly derive an income from Hostea it is their decision to submit this income to the Hostea decision process. If they chose not to, they must publicly explain why in a public declaration of financial interest.


There are three categories of work:

  • Servicing Hostea (e.g. restoring backups after an outage at Hostea.org, working a Clinic case, etc.)
  • Improving Hostea (e.g. developing new functionalities, adding new features, refactoring to improve maintainability, etc.)
  • Contributing to dependencies (e.g. contributing to Gitea, librepages, Enough, etc.)

The work performed by members is measured in hours. For a member to claim that they spent X hours working in the context of Hostea they must file an issue in the organization repository including:

  • The number of hours
  • Permalinks to proofs of work (commits, discussions, etc.) for auditing purposes
  • The category of work (Servicing Hostea, Improving Hostea, Contributing to dependencies)


Each member is responsible for updating a spreadsheet in the organization repository with their own Hostea related income and expenses. Expenses are either:

Example: Loïc Dachary’s spreadsheet

When a member chose to not mention an income derived from Hostea, directly or indirectly, they must publicly explain their decision in a declaration of financial interest published on Hostea. If they fail to do so, their expenses are not eligible to be paid.


Members are entitled to receive payment for their expenses, from the account in which the income was earmarked for the corresponding category:

  • Servicing Hostea
  • Improving Hostea
  • Contributing to dependencies

If the money held in the account is not enough to pay for all expenses, it is distributed equally.

Example: Hostea has 100€ in the Improving Hostea account. First member ask for 20€, second 80€ and a third 90€. Each member receive 20€. There is 40€ left and the second still needs 60€ and third member still needs 70€. They get 20€ each and are still owed another 40€ and 50€ respectively. In the end the first member was paid in full for 20€, the second an third member were not paid in full and got an equal share of 40€ each.

Since Hostea is a non incorporated collective, it is ultimately for each member to invoice each other. A spreadsheet compiled from the individual spreadsheet of each member is updated on a regular basis to show which member owes how much to other members.

A Hostea member is required to pay what they owe to other members at least once a year.


A Hostea income is money held by a member and earmarked to be spent according to the Hostea revenue sharing model. This money may originate from payments made by people renting a dedicated Gitea instance on Hostea.org, services provided via the Clinic, donations etc.

Example: Easter-Eggs received 250€ for upgrading a Gitea instance.
Example: Easter-Eggs donated 2,000€ to Hostea

All income is divided in separate accounts earmarked with a category of work:

  • 50% Servicing Hostea
  • 25% Improving Hostea
  • 25% Contributing to dependencies

Dependency right to veto

The owners of a Hostea dependency have a right to unilaterally veto a claim of work from a Hostea member. Their veto must be expressed with “I veto this work” in the issue associated with the claim in the organization repository with an account linked to the email that proves they own the dependency project.

The right to veto expires eight weeks after the claim of work was published.

Expense dispute

Members who dispute a claim of work must do so by commenting in the issue associated with the claim in the organization repository. Eight weeks after being published, the claim of work cannot be disputed anymore.

Members who dispute an invoice submitted as an expense by another member must do so by opening a new issue in the organization repository.

Disputes are settled by a vote to decide if the expense is legitimate or not. An expense that is ruled to not be legitimate cannot be added to the member spreadsheet and cannot be paid.


Would it be simpler to dedicate a fixed percentage of the income to dependencies?

It would actually be more complicated because:

  • The percentage would have to be agreed upon on a regular basis, for each project
  • Figuring out how much money a project needs to move forward is time consuming

This is to be compared to the decisions members need to make with this model:

  • Each member donates as they see fit, globally capped at 25%
  • A collective decision is only required when a member feels there is a problem

How can this provide a stable income for a given dependency?

It requires that two conditions are met:

  • There is enough income to provide such a stable income
  • Hostea members collectively decide to donate money to the dependency that translates into a stable income

It is ultimately up to each member to donate and submit this donation as an expense, for the benefit of the dependency. The stability is therefore only relative to how members value the dependency.

What if a member claims money that would otherwise go to a dependency?

If a Hostea member claims payment for doing work contributing to a dependency, it may mean less money for the dependency. Since the global amount dedicated to dependencies is capped to 25%, the following situation can happen:

  • The total income of Hostea is 100 and 25 is dedicated to dependencies
  • Hostea member A donates 25 to a dependency
  • Hostea member B contributes to the same dependency and claims a payment of 25 for that work
  • The dependency gets 25/2
  • Hostea member B gets 25/2

For that to be fair, the Hostea member work must be open to a third party audit. This is a requirement as per the Hostea governance since all work done requires radical transparency. And also because each Hostea member is required to submit a Declaration of Financial Interest. If there is any suspicion of a conflict of interest, the work done by Hostea member B is audited and can be disputed.

Why measure work in hours at a fixed rate?

Because it makes for a simple revenue sharing system.

How is the hourly rate revised?

The revenue sharing model is subject to the decision process defined by the Hostea governance. So is the hourly rate because it is included.

1 Like

This draft is the outcome of various discussions in the chat room. Unless there is an objection, I’ll propose this as a first decision in the governance category within the next few days.

1 Like

@realaravinth I added a FAQ section that reflect my view. I know you have a different perspective and it would be great of we can reach consensus before submitting this as a governance decision.

Feel free to edit (it is a wiki) and/or write down your concerns.

1 Like

We’ve had discussion on similar lines, but I just found another scenario to support my argument:

Imagine Hostea becomes profitable, has members who contribute to dependencies and are claiming a major, if not the whole dependency quota.

In projects like Gitea, this is fine because as you mentioned the chatroom, Gitea has excess revenue, so they appreciate code contributions just as much as financial contributions.

But if the dependency has financial interests(dependent on downstream projects for revenue or they themselves sell their software), withholding donations will have adverse effect. They might switch to a non-Free license, as Elasticsearch did to prevent Amazon from reselling their software and keeping all the revenue generated to themselves.

If a Hostea member is contributing to dependencies, then, at least in cases where the dependency has a financial interest, giving the dependency full control over how they want to use their share of the Hostea revenue will avoid conflicts.

If a Hostea member is very involved with the dependency project, they could apply to become co-maintainer. As co-maintainer of the dependency, the Hostea member will have access to the dependency’s share of Hostea funds. Sharing in this case will have to be negotiated by the Hostea member with the developers of the same decency project.

Or the Hostea member could seek employment with the dependency organisation, if the organisation has such options.

Hostea’s horizontal structure allows both of arrangements stated above.

Re-selling someone else’s work should be handled with care, even if the license permits it. In such cases, treating the dependency as an opaque entity and giving them full control over their share of the revenue will simplify a lot of things and avoid conflicts.

If the dependency goes non-free, the damage won’t be just to Hostea but to the whole free community who use it.

In the Amazon vs Elasticsearch case, they were competitors, trying to sell the same service. Should that be the case for Hostea and one of its dependency, there will be a tension, indeed. And a significant one, regardless of how the Hostea revenue is shared with the dependency, I suspect there will always be someone very unhappy that it is not more than X% whatever X is.

What kind of additional control are you thinking about? In the proposed model every Hostea member (which could include people involved in the dependency organization if they care to join Hostea) can decide to donate to the project. And submit this expense to be paid from the 25%. The dependency is also granted a right to veto work hours claimed to be to the benefit of the dependency without any justification. It could be that they think this goes against the best interest of their project, for whatever reason.

There are a zillion ways this can go sideways. For instance if a dependency abuse their control to get the majority of the money from the 25% account although they are only a minor dependency. Should that happen it may require the most active Hostea members to intervene. But I genuinely do not see how money or work hours can be paid in a way that goes against the dependency best interest.

1 Like

Something doesn’t feel right, and I am unable to put my finger on it. But it shouldn’t block adaptation of the model described in the top post.

I hope everything works out, and we don’t face any significant issues. If we do, I’m confident we’ll figure something out.

As always, thank you for tolerating me :slight_smile:

1 Like

There is no urgency in getting this finalized. Let’s take all the time you need to figure out what does not feel right. Feel free to throw random thoughts or impressions: they may be crumbs that will help formulate things more clearly.

Here is one of the reason why I think it is beneficial to have a long standing discussion on the matter. End of last year you voiced how important it is for any Free Software business model to properly compensate dependencies. While this was something I very much had in mind at the time, it never occurred to me that it should be prominently engraved in how an organization defines itself.

The various conversations we had on that topic in the past months led to the Hostea revenue sharing model and however imperfect, there is no doubt it takes the sustainability of dependencies very seriously. I would have drafted something different six months ago: the sustainability of the dependencies would have been implied and not explicitly stated.

1 Like

I think Hostea is designed to be small. It won’t scale and does not need to because it can and should be replicated, copied. It is designed to make it easy for a competitor to start from scratch. On a given year, Hostea should not have more than 100 members (out of which 10% are active, 90% occasionally active) and no more than 1000 customers. In a sociocracy/holocracy Hostea would be a single “circle” and stop growing when the need for other circles begins to emerge.

Maybe that shed a different light on the revenue sharing model?

1 Like

Makes sense. Thank you for your patience in this matter. I had some time to think about the model and how we share our revenue. I don’t have the comeplete picture about what a dependency developer would expect in terms of contributons. I couldn’t find any clear resources that could give me insights into how the Free movement would eveolve going forward. Also, I don’t know what it us like today. So I shouldn’t have speculated on what is fair and what isn’t.

We have something good going on right now and I think if anyone atubles upon Hostea, they will get a feel for what we are trying to do with revenue sharing. And the fact that we are building mechanisms into the model to adapt is good.

So as with the MVP, let’s put this out there and see where it takes us :slight_smile:

1 Like