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.