USER GROUPS DRAFT V2
Changes from v1:
- Payment structure overhauled
- Prefix changed from ^ to +
Feedback welcome.
Functionality
User groups will use the + prefix, similar to today's ~ prefix for
users, and will be able to own resources across the site. For example,
"git.sr.ht/+sourcehut/core.sr.ht".
Group membership is divided into subgroups. All users in the SourceHut
group would be a member of +sourcehut, and by default there would be an
additional subset called +sourcehut/admins which defines who can modify
group membership. The admins subgroup cannot be removed, but other user
groups can be added by admins as necessary. These groups can be fed into
access control lists throughout the site as a shorthand for a group of
people, e.g. +sourcehut/todo/committers or +sourcehut/staff. A user can
be a member of any number of groups and subgroups.
At first, only admins will be able to create new resources (like
repositories) on behalf of the user group. In the future, it might be
useful to expand the number of rights which admins can delegate to other
groups.
Payment
Still open to suggestions here, but the general idea is:
Whether or not your account requires payment is tied to whether or not
you "own" resources on SourceHut, such as git repos, todo trackers, etc.
Submitting CI jobs will also require payment. Users with unpaid accounts
can participate - be included in ACLs, submit bugs, send emails, etc -
but cannot own any resources of their own.
Groups can have members which are both paid and unpaid, but all group
admins have to have paid accounts. Groups may sponsor the fees for their
members, and sponsored members effectively become normal paid accounts
with all the privileges that entails.
User groups have a limit on the number of resources they may utilize,
e.g. no more than 10 git repos. Additional resources may be bought
ala-carte. I'm also thinking about giving away paid memberships as you
pay for more resources, since paid memberships are a proxy for making
sure groups are financially invested in the platform. If you would like
to host an organization on SourceHut, please tell me your current scale
in terms of number of resources you'd need, and give me some idea of
your budget. The goal is to balance the needs of small FOSS projects
with the needs of businesses.
Also, I'm planning on offering dedicated CI slots. Your access to the
shared CI slots is part of your normal account subscription, and subject
to demand. However, if you need dedicated CI slots, or require slots
with more resources (CPUs, RAM, etc), I intend to let you buy reserved
CI slots. My plan is to run the numbers and price this so that every
reserved CI slot paid for also pays for another shared CI slot for the
rest of the community to use. Some back of the napkin estimates show
that builds.sr.ht can be very competitive with other CI providers with
this pricing.
API access
For now, API access won't be affected in any special way - anything you
can do on the web, you can do with the API. In the future, I would like
to add more fine-grained API access controls for OAuth clients in
general, so you can for example choose only a subset of your git
repositories to offer to third-party applications. When this overhaul
takes place, it might make sense to revisit the interaction between the
API and user groups.
Migration plan
I plan on making it possible to move any resources (repos, mailing
lists, and so on) which you already have on a user account to a group
account, if you so desire. Some people have also registered special
organization accounts as a stop-gap solution, I will also help you
convert these to user groups later.
This looks good. The user vs org pricing distinction is great and much easier to imagine scaling.
What are the implications for an organization looking to self-host SourceHut? Is it fine as long as they are within the GPL?
What happens if a user or org would stop paying? Are their resources (eg. git, wiki, lists) still active? Do they turn read only? Would there be a grace period?
On Fri Feb 28, 2020 at 4:09 AM, Cosmo Borsky wrote:
> What are the implications for an organization looking to self-host
> SourceHut? Is it fine as long as they are within the GPL?
SourceHut is mostly AGPL licensed, and that's not going to change.
Anyone can self-host it under the terms of the AGPL.
> What happens if a user or org would stop paying? Are their resources
> (eg. git, wiki, lists) still active? Do they turn read only? Would there
> be a grace period?
There's likely to be a short grace period, then they'll be made
read-only, and perhaps eventually archived and put into cold storage.