New collective setting to select plan

[xdamman]

• This only applies to new "host less" and "self hosted" collectives
• Existing collectives are grandfathered
• Collectives created under a host (such as through the open source flow) are free accounts since we will be charging the host (which is effectively a collective with the "network plan").
• I like the idea of using total amount managed (introduced by @BenJam) as a way to separate the different plans. I think it makes sense at the level of a collective and it shows that the cost is only 1%.
• I'm introducing here the concept of (sub) collective (open to other name suggestions). It's basically a collective linked to your collective. ie. Webpack is a subcollective of the Open Source Collective. But likewise, XR-Belgium could have a collective for different working groups to keep the budget separated (e.g. a communication working group/collective, a legal working group, etc.)
  There is possibly an infinite "hierarchy" of collectives: XR -> XR Belgium -> XR Brussels -> XR Brussels Communication Working Group (and it can be circular, so it's more a graph than a tree, webpack is both part of the open source collective and the javascript foundation for example). So each sub collective's plan could be covered by itself (starting with the free plan) or by one of their parents.

As you'll notice, the concept of host is totally removed. Because this should be a separate conversation. First one is we need a platform to keep track of our budget transparently and record the money that we receive in cash (for most offline groups). Then as we grow, we need to figure out how to open a bank account and self host or find a host. Different stage of the lifetime of the collective.

[alanna]

So even if they have no host and are entering everything manually, we will still charge them the same as Collectives with money actually flowing through the system?

I agree this looks like a good approach for self-hosted and un-hosted Collectives. We will just need to be careful about how people end up on this page, and make sure that Collectives actually joining an existing host do not see this info as it will be very confusing for them.

Sub-Collectives are really confusing this for me. I don't feel comfortable including anything that we haven't fully defined and agreed to include. That whole topic should be a seperate issue. I really don't think we should couple figuring out that complexity to making progress on the business model. It's a big change in how the whole hierarchy or relationships of Collectives works on the platform. If we want to add that later, we can, but it needs its own discussion.

I disagree that this always will come about chronologically:

"First one is we need a platform to keep track of our budget transparently and record the money that we receive in cash (for most offline groups). Then as we grow, we need to figure out how to open a bank account and self host or find a host. Different stage of the lifetime of the Collective."

In fact there are many, many, many Collectives that actually want to join and existing host right away. Almost all Collectives that have been created up to now in fact. The majority of groups do not get money in cash and they need banking services immediately. That's the key reason people come to Open Collective to get started and they value we provide. They find us specifically because they are experiencing this pain point.

I realise you're trying to create space for groups that will record things manually but these groups will be small and hardly have any money, not our priority customers from a business model point of view. What evidence do we have that these groups even exist and want to use such a system? This needs validation before we start building.

I would advocate for focusing on two main pieces of work here:

1. Fix the whole experience for self-hosted Collectives, including incorporating a pricing model like you've shown here.
2. Fix the flow for Collectives seeking an existing Host, so they never see this pricing model and are smoothly onboarded into the Host that works best for them. This requires us shifting the business model to the Host-pays concept, so these Collectives only need to consider what the Host charges not any platform fees.

[piamancini]

Sub collectives is not a terminology we use today and I don't think we need to. They are all collectives.

Webpack is a subcollective of the Open Source Collective.

No, webpack is a collective hosted by the Open Source Collective Organization. It is not dependent from the OSC.

There is possibly an infinite "hierarchy" of collectives: XR -> XR Belgium -> XR Brussels -> XR Brussels Communication Working Group (and it can be circular, so it's more a graph than a tree, webpack is both part of the open source collective and the javascript foundation for example). So each sub collective's plan could be covered by itself (starting with the free plan) or by one of their parents.

The complexity of this is infinite. Let's come up with an alternative way of seeing this. It can be circular, seems like a particular kind of implementation nightmare.

They are all collectives and they should be differentiated by name. So XR Belgium is a collective and XR-Belgium-Working-Group-A is another collective under the same host.

As you'll notice, the concept of host is totally removed

Yes, but it shouldn't be something in stages of growth. I agree with @alanna that it won't happen chronologically. It should be in parallel in different flows / steps of the oboarding process

First: Great, I can create a collective, add people, it's up and running, has my images, I can submit expenses, I can manually add funds I already have. Free up to $1000, great I can try it!
Second: I want to raise funds through Open Collective, how can I do this? Oh cool I can connect a Stripe or a PayPal (one day, if the universe allows) account that I own. Done!
Third: hmmm I don't have a paypal account / stripe for my community, I'd like someone else to to do this for me --> Discover a great host for you!

--> #2295 (comment)

I would advocate for focusing on two main pieces of work here:

Fix the whole experience for self-hosted Collectives, including incorporating a pricing model like you've shown here.
Fix the flow for Collectives seeking an existing Host, so they never see this pricing model and are smoothly onboarded into the Host that works best for them. This requires us shifting the business model to the Host-pays concept, so these Collectives only need to consider what the Host charges not any platform fees.

I agree.

Final thought: host-less and self-hosted are the same thing in muy view. There's always a host, the difference is if the host accepts donations via stripe or not. But we need to de-link being a host from having a stripe account.

Then you reduce the complexity to two alternatives:
you are self-hosted
you are fiscal sponsored by a different organization .

[xdamman]

Thanks for those comments.
Ok let’s not introduce the concept of “sub collectives”. It’s complex enough like this.

And yes, collectives are independent from their host. It’s a very good reminder. Hosts are just contributors whose contribution is “holding (part of the) money” for the community. Hosts (like any contributor) can come and go, but the collective remains. It should be fluid.

I don’t think there should always be a host (at least in the future as you should be able to create a collective and only use it for getting an email address so that people can reach out to your group, for having a GitHub issues equivalent, for having a place to record and publish your expenses transparently, ...) but you are absolutely right to say that we should decouple Stripe from being a host.

So the simplified version becomes:

1. You can create an open collective without a host
2. If you want to start collecting money online, you need to connect a Stripe account to a user or an organization (that will effectively act as your host in our current infrastructure).
3. If you want to record money that you have received “offline”, you need to specify who is holding the money for you (can be again an individual or an organization that will be considered as a “host” in our infrastructure, eventually, you should be able to have “multiple hosts”).

If you reach more than $1,000 of budget managed, you need to start paying $10/m.
If you are a host and you want to access the host dashboard to help you with the fiscal sponsorship process, you pay according to #2251.

There is still the question of the different flow to help hosts onboard new collectives as @alanna rightly pointed out. I would see that in two main ways:

1. From the website of the host (e.g. womenwhocode.com, oscollective.org) people should be redirected to the create collective flow where the host is already predefined.

2. From opencollective.com, when you create an open collective, we should offer different “templates”.

   • A generic one,
   • One for an open source project,
   • One for a Women Who Code chapter,
   • One for an Extinction Rebellion chapter (or working group),
   • etc.

Based on that template, the host will automatically be defined (and will have to be manually approved by the host or automatically based on some rules such as the 100 github stars one for the OSC).

3- In case you have created a generic open collective without a template, when you reach step 2 (start collecting money online), we should offer you to either connect a stripe account or to use a fiscal sponsor that we can recommend based on tags.

[alanna]

I am very nervous about the multiple hosts idea being slid into this project. I think it introduces way more complexity than you might expect. For example, Collectives in c3 legally may not have multiple hosts and all funds for the project must be held by one entity. I agree it's a cool idea, but we need to step back and think it through and plan it properly, and it's not currently a priority. Can we please treat the multiple hosts idea as a seperate topic and not keep introducing more complexity into this project?

Another thing I think is important but is probably out of scope of this project: Self-hosted Collectives should not need a seperate host entity. Hosts have budgets and teams and updates and everything a Collective has. They should be Collectives themselves, with added functionality. Hosts having to create another Collective for themselves and manually add host fees is confusing. If we're trying to onboard more self-hosted Collectives, this is something we'll need to fix eventually.

If you reach more than $1,000 of budget managed, you need to start paying $10/m.

By "you" you mean "the fiscal host" right? Not the Collective. I thought we were designing the business model so the hosts are the paying customers.

If you are a host and you want to access the host dashboard to help you with the fiscal sponsorship process, you pay according to #2251

Are you implying we will have hosts on the platform without access to the dashboard and normal functionality for hosts? If so, how will that work? They will accept and hold funds but not be able to pay expenses? This seems like a complex duality to design and maintain.

From opencollective.com, when you create an open collective, we should offer different “templates”.

I don't quite understand what this means. Can you explain in more detail how it would work? Like a form question saying "Is your group associated with an organization, network, or movement already on Open Collective? If so, which one?" And then suggest hosts based on their answer?

I would rather take a step back and workshop the host discovery process itself. I think we can do a lot better than how tags currently work. I think that's an important aspect to this onboarding flow project but would be better served by treating it as its own sub-project.

[xdamman]

For example, Collectives in c3 legally may not have multiple hosts and all funds for the project must be held by one entity

Good reminder. Thanks. (I'm still not entirely sure why this is the case, I'd love to dig into this at some point, but that's another topic).
We could enforce one host for now to keep things simple, but knowing that this constrain will eventually go away (and must go away to really reflect the nature of a collective which should not belong to any host).

By "you" you mean "the fiscal host" right? Not the Collective. I thought we were designing the business model so the hosts are the paying customers.

Yes but moving forward, anyone can be a host. No need for a Stripe account, no need to host more than one collective.

Self-hosted Collectives should not need a separate host entity (...) Hosts having to create another Collective for themselves and manually add host fees is confusing.

I agree with you that the current situation of having a host create a collective makes no sense. However, money should always be held by a legal person or entity to reflect reality, that means a user or an organization on open collective. A way to simplify this would be to make sure that a user or an organization should be a collective themselves so that we can follow the money coming in and out (such as host fees). The good news is that this is already the case in the background (in the database).

For the rest, I think it's time to move on to wireframes otherwise we will keep turning in circles.
We can gather more feedback at that stage.

[alanna]

After working with @xdamman yesterday, I have done a draft of an onboarding flow. It was too complex to draw on paper so I did clickable mockups in Balsamiq.

View it here.

Goals:

• make the self-hosted Collective onboarding experience as simple as possible
• introduce the new $10/mo plan for accepting funds outside Stripe (bank transfer payment type and add funds manually)
• only show users info they need to be concerned about (esp anything about hosting)
• have a clear pathway for Collectives looking to join OSC (and other hosts) as they are still the majority of our new Collectives

Questions:

• where does user login or account creation fit in?
• is the OSC use case still too obscure if they start from the homepage instead of the OSC page apply button? I'm concerned OSC Collectives won't find their way. I felt like I had to add help text for them which might be a sign the design could be improved for that use case.

@xdamman I know we debated about allowing users to add existing funds before they need to decide if they want to raise more by turning on the $ features. However after thinking about it, I really feel that adds too much complexity. Almost all Collectives come to us because they want to raise $. However, I think we should add a setting so Collectives can turn off the financial contribution option if they want. I suggest we do that and then if that use case turns out to be common, we think about how to address it in onboarding.

[znarf]

• I don't see the point of asking the currency so early in the process. Currency should ultimately be the one from the host, otherwise its proved to be highly confusing for everyone - and the system. However, we discussed the ability to define a "cosmetic" currency for the frontend.
• Warning on the invitation by email: we need to make sure this doesn't create new accounts by default, and this should ideally primarily be a search with auto-complete.

[alanna]

Currency select: because in this flow they will often be creating a new host in the background as part of the setup, and we need to know the currency. We don't want to emphasise awareness of this whole "host" thing so we'd like to just automatically create it. If they are heading toward joining an existing host, we also need to know the currency they want so we know what host options to show them. If we don't ask currency at the beginning, where do we ask it?

I agree about not creating duplicate accounts. These designs assume the "select existing" module that we need for many things will be in place. If it's not, we might need to rethink the design. I believe that even if you can't select the existing user, you should be able to invite them by email and then if they already have an OC account, the person being invited should be able to click "accept invite" on the email and then log in and associate the new role with their existing account. This is how most other tools I use work.

[znarf]

We should be really careful in the details around currency selection. For example, if I pick "euro" early in the process, I should not be prevented to see "Open Source Collective" as an option. IMHO, by default, we should not even try to filter hosts based on currency, it matters more to have an host that align with your mission, than align with your desired currency. My opinions are based on my experience with the current "host picker" which is currently doing a pretty bad job at surfacing relevant hosts.

[xdamman]

Thank you Alanna for putting this into a balsamiq and thanks François for your input.
I have now enough feedback to work on it and come back with a first wireframe proposal.

@alanna I understand your concern. You are right to presencing that today most collectives are joining because they want to raise money. However, the goal of this redesign is to open new avenues for open collectives. I’ll make sure that we don’t negatively impact the OSC through this new flow.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. We want to keep it in our todo list but haven't had the time to address it yet.
Thank you for your contributions!

[piamancini]

Implementation issue here #2662