Proposal: Backer Badges and Premier Listings

[coderberry]

Problem

tl;dr - Companies need more incentive to contribute on a regular basis

Recently, OpenCollective asked their core contributors where they need help the most. The results came back with the following concerns being their top 3:

1. Need help with marketing collective
2. Need to bring in more big sponsors
3. Encourage the collectives to support upstream/downstream (dependencies)

Speaking as someone who communicates that contribute to open source every day via CodeFund, I have a pretty good idea on why these collectives are being unnoticed and underfunded.

Collectives thrive on charitable contributions from other developers and companies. I believe that most non-contributing companies are well intentioned. However, the people who are likely inclined to contribute to open source projects (other maintainers, software developers) are not the ones that have an influence over the company budgets.

Our biggest problem to solve here is that we need to justify (and essentially sell) the opportunity of contributing to open source to those in companies that influence spend.

What Businesses Want

Contributors to open source primarily become involved due to altruistic reasons: sense of giving back, being a part of something bigger than themselves, etc. Giving back is in our blood.

Companies don't think the same way.

For most companies to justify a recurring expense, they need to be able to quantify the value that the spend brings back. Advertising is a perfect example of this. The company spend $1,000 and expects $1,250 in return.

I believe there are other quantifiable gains that we should address:

1. Recruitment costs
2. Brand awareness
3. Customer loyalty

OpenCollective (and this project in particular) is in an excellent position to provide these highly sought after items to companies. Best of all, it can be packed and sold.

Proposal

I propose we extend this application to include three new features:

Provide ability to purchase support packages for stacks.

When I search for my organization within backyourstack.org, I should be presented with an option to "Back My Stack". This will list out the benefits of backing my stack overall. The contributions made via this recurring donation will be distributed amongst all collectives that appear in my stack.

Here's a crude mockup:

Create a 'Stack Backers' list

This list will include all of the stack backers and will be displayed in the order of donation amount. This will provide some competition and will reward those that have higher contributions.

This page should also be used by developers as a reference to learn best companies to work for. The more this message is made known, the more valuable the placement on the site will be. THIS is the return that companies will pay for.

'We Back Our Stack' badge

I propose we build a badge that is displayed via dynamic SVG. This image is shown when a script is run that hits the opencollective servers. The script will verify that the backer is still backing their stack. The badge could have many different forms (including GitHub shield), but it's critical that the image itself is dynamic.

This will be a tool companies can use on their "work for us" pages, as well as in their footers. It's a badge of honor. Remember, it's an opportunity to back your stack!

[open-collective-bot]

Hey @coderberry 👋,

Thank you for opening an issue. We will get back to you as soon as we can. Also, check out our Open Collective and consider backing us.

https://opencollective.com/backyourstack

PS.: We offer priority support for all backers. Don't forget to add priority label when you start backing us 😄

[xdamman]

This is a great idea. That was the initial plan with "Bulk support" that you can see in the left sidebar, but this is a much better implementation of it.

We could use the collective of the Open Source Collective 501c6 as the place to collect those bulk donations (https://opencollective.com/opensource). We would just need to attach to that donation the github organization of the backer and, using backyourstack, automatically allocate those funds to the dependencies.

The problem with this is that it opens a can of worms: how do we split among the different dependencies? Not all are equals... So what's the weight associated to each dependency? How do we compute that? Not all projects need funding, etc...

Here is what I'd suggest to get us started: a first version could require a minimum of $100 per project per month (or $1000 per project per year). If they want to change the weight and give more to different dependencies, they could add a backyourstack.json in their repo (or sustain.md or a sustain attribute in the package.json) to fine tune it.

If we want to get fancier, we say that this is the Bronze package.
The silver package is minimum $500/dependency/month and Gold minimum $1000/dependency/month).

Behind the scene, there would be only one single monthly/yearly transaction to the host (Open Source Collective) and therefore only one vendor/invoice to make it easy on the company side.
This will create a virtual prepaid card that will be used to donate to the different dependencies.

[coderberry]

@xdamman Thanks for replying on this. I agree with your pricing strategy, although I believe the competitive side of it will drive higher donations. We should allow a free-form amount to distribute for companies.

The problem with this is that it opens a can of worms: how do we split among the different dependencies? Not all are equals... So what's the weight associated to each dependency? How do we compute that? Not all projects need funding, etc...

I agree that this is a can of worms. Based on your suggestion, how would the funds be distributed? I believe the funds should be divided equally amongst all active collectives that are dependencies. We would rely on OpenCollective's collective approval process to ensure that the projects being paid are qualified. Of course, having them specify with the backyourstack.json will supercede this.

[xdamman]

I agree on the free form amount (hence the backyourstack.json to fine tune the amount), be we also need a suggested amount, otherwise people just don't know how much they should give.

It's a good idea to have a list of top backers for the competitive aspect of it. People will be able to see it on https://opencollective.com/opensource#contributors
We should be able to export that data to be directly integrated in the backyourstack interface.

I agree that this is a can of worms. Based on your suggestion, how would the funds be distributed?

Basically minimum should be $100/dependency/month, then people can tweak it with backyourstack.json. And that's how the funds will be distributed automatically. Keep it simple while allowing customization if people are willing to put the extra effort.

Question is: how do we manage when (1) new dependencies appear in the company repo (2) when existing dependencies that weren't on open collective create an open collective.

Maybe to handle that we just send an email to ask the company to update their total contribution to take them into account (and update if they want their backyourstack.json).

[piamancini]

I like the approach @xdamman: essentially it's a minimum of $100 per dependecy. We already have them organized in the most depended upon ones, so if you give $100 you only support the first one, $200 the first two, etc.

Question is: how do we manage when (1) new dependencies appear in the company repo (2) when existing dependencies that weren't on open collective create an open collective.

We should have a job that checks new dependencies on open collective on a periodic basis. For open repos, shouldn't be too difficult. For private ones we can send them an email every 2 months or so asking them to upload a new file so we can update. This is tedious but good enough for a first iteration.

[coderberry]

I think you are going to lose a lot of possible contributors if you set a minimum of $100 per dependency. If that's the case, I believe they will lose interest in going this path. The message should be "we are supporting our stack". That's the message that will bring on additional funders.

[xdamman]

@coderberry what do you suggest then?
People set the amount they want? What if I have 100 dependencies and I give a budget of $500/month? How do you break it down? The default is $5 per month per dependency?

There's got to be a minimum. But maybe it's $10/month/project?

[piamancini]

I see the point, but for us distributing $1 per dependency is not really going to make a lot of impact. I'm ok with a $10 minimum. At one point we need to stop dividing the funds, or not?

[coderberry]

I see the point, but for us distributing $1 per dependency is not really going to make a lot of impact. I'm ok with a $10 minimum. At one point we need to stop dividing the funds, or not?

I agree that $1 is not a lot for a dependency, however, if we get hundreds of companies that each have $1 for that dependency, it would become impactful. I believe the implementation we decide on will determine the scale that this will grow. If we solve the distribution problem on the OpenCollective side (minimum $100/mo for companies), than the amount of companies that become involved will scale. If we put limits to their contributions, we will have higher targeted distributions, however it won't scale nearly as well.

I believe that the goal here is to provide a common, community supported system where companies can contribute to their stacks, regardless of the amounts. At first, it may not be impactful, but as more and more companies come on board, it will become even more impactful than the first option.

My 2 cents.

[piamancini]

ok - @znarf @BenJam can I ping you here for comments?

[coderberry]

Ping

[piamancini]

Thanks @coderberry for the ping. I've been off the past week but I'll resume this with @znarf this week

[piamancini]

We've made progress here last week. @znarf please update when you can.
(For later this same mechanism can be used for OS collectives not just companies to spread down there contributions)

[znarf]

Here is what we're thinking about.

Open Collective / Open Source Collective side

1. We'll create a new Tier monthly tier named "Back Your Entire Stack" or similar
2. When donating to this Tier, donator will attach a summary of their dependencies (as HTTP link or as upload). The format of this JSON file will be simple and documented.
3. Each month, the money will be dynamically dispatched following the information from the latest version of the JSON file.

Implementation details

The end user doesn't need to care.

1. At first donation, and later each month, when the payment complete, an hidden "prepaid card" will be created for the donating organization.
2. Based on the information fetched from the JSON file, the money from the "prepaid card" will be used to generate all the sub-transactions (one time donations) to each collective.

What needs to be build

• The ability to add extra meta-data to an order (the link to the JSON file)
• The ability to trigger events once the payment complete
  • Creation of the prepaid card
  • Fetching the JSON dependency summary
  • Dispatching the money between all dependencies

Back Your Stack side

We'll give organizations the ability to create their profile and surface the dependencies they want to support. After "Sign In with GitHub" and verifying they are admin of the organization:

• Let them select the repositories they want to include (if any)
• Let them upload additional dependency files (if any)
• OPTIONAL: Let them weigh the dependencies

Then:

• Save the profile (data will be persisted in an S3 bucket)
• Click a button to "Back Their Stack" with Open Collective (redirect to Open Collective "contribution flow").

Also:

• They should be able to download the JSON to edit it manually
• They should be able to do the whole process without "Signing in with GitHub"

[coderberry]

@znarf I love it. Thank you for speccing this out.

The other half of this is to build a badge that they can place on their site. The badge would link to their donations page, and would only be visible while the subscription is active.

[xdamman]

This pattern of collecting a lump sum amount and then giving it back to the community based on consumption is not new. That's the model of Spotify, Medium Member, etc. You basically pay a monthly subscription and the platform redistributes to the content creators based on what you have consumed (without much transparency, not clear how much they keep, apparently a lot if you ask artists on Spotify).

In many ways, open source projects and developers are like music creators or content producers on Medium.

So here is what I'd suggest to make this sustainable for all parties involved:

We create 3 different tiers for companies: $500, $2,000 and $10,000 to "back their open source stack" (that would generate 3 different badges: bronze/silver/gold backer, we can brainstorm about the name for those tiers, another idea would be to make this amount a percentage of the revenue of the company, which would be ideal but not sure how to pull that off).
I'm not a fan of giving an amount per dependency because companies need visibility for their budget. They would much rather pay a fixed amount every month / year.

We would give the majority (70%) to the different dependencies and keep 30% for the platform.

This will pay for the development of the feature to get a good representation of the different projects that a company is depending on and to automate the distribution of the funds.

This will help all open source projects automatically receive money without having to waste a single minute to reach out to potential sponsors. That's totally worth a 30% cut. Maybe even more? I took the 30% because that's what https://resonate.is cooperative is taking for their music service platform, it's also what developers are paying on the App Store to get distribution. So it feels like a good number to start with.

How does that sound?

[coderberry]

I like this idea, except you are cutting out small businesses. I think you need to have a $100/mo plan as well. I believe smaller companies (startups) are more likely to be the ones who adopt this initially, however the minimum price point of $500 will completely cut them out.

I also am not sure a 30% cut is justifiable. This seems like a lot, especially if the distribution becomes automated. Perhaps closer to 15%?

[piamancini]

@xdamman why would you introduce a new business % here?

I think we need to keep this simple, we want to increase the number of subscriptions on the platform and want to attract more companies who don't want to think about distributing funds, they just want to pay a subscription. Adding a different amount here, will make the conversation about that instead of the Back your dependencies narrative.

30% seems a lot for something we mostly do already and the goal is to automate this. Specifically, how would you propose dividing it with the OSC? It's the OSC who would be handling the funds and re distributing manually initially.

[xdamman]

Because I'm thinking about ways we can make OC sustainable, which we are not (yet).
I'd hate to have to raise more money with investors which would jeopardize our independence. I don't think that anyone in the community wants that. Also, since we are preaching "sustain open source", maybe we need to start with our own open source project :-)

And also because this is a very good occasion to justify asking for money for the platform because this is a very common scheme. You are basically interfacing on one side a lot of small producers with consumers that don't want to directly give money to each of them because it's too much trouble, individual transaction cost is too high. So they want to pay a fixed amount (like your Spotify subscription) and then let the platform figure out a fair way to compensate the producers based on different signals. As a reference, Spotify is only giving 52% and the actual artists receive 7.8% to 26% of the total! (That's why https://resonate.is exists!)

Spotify typically pays a record label around 52 percent of the revenue generated by each stream, or play, of a given song. The label, in turn, pays the artist a royalty of anywhere from 15 percent to, in some cases, 50 percent of its cut. (source)

So far OSC has been solely a fiscal sponsor. As such, they should get 5% of the total money coming in their books. That's the simplest way to look at it.

Now in the future, I think it would be great for the OSC to own the relationship with companies, do the outreach, purchase order process, etc. That would justify a higher percentage.

I could also see the OSC take the full commission, but for that they should be the ones financing the development (and the maintenance) of such feature. Not sure if the OSC is ready for that yet.

I also am not sure a 30% cut is justifiable. This seems like a lot, especially if the distribution becomes automated. Perhaps closer to 15%?

@coderberry why is 30% not justifiable? How much is codefund taking for the same service of matching companies (advertisers) with a network of publishers?. It's the exact same scheme. It's not really fully automated, there has been already a lot of work (and still ongoing work) to reach out to companies, bring them onboard, work with their purchase order process, reporting, etc.

From the perspective of the collective, it's new money. They didn't have to do anything to get it. It's exactly like on Codefund where they have no direct relationship with the advertiser.

I think you need to have a $100/mo plan as well. I believe smaller companies (startups) are more likely to be the ones who adopt this initially,

Sure, maybe we can think of a startup plan at $100/month. Good idea.

[xdamman]

(sorry I didn't mean to pick on Codefund. What you do is truly amazing and you have a super fair model, I just wanted to highlight the similarity of the scheme and the need to make sure that all parties involved in sustaining open source are also sustainable themselves without having to raise $40M VC money. Let's make sure that codefund and open collective are both sustainable, we will all win as a community 😊)

[piamancini]

Because I'm thinking about ways we can make OC sustainable, which we are not (yet).
I'd hate to have to raise more money with investors which would jeopardize our independence. I don't think that anyone in the community wants that. Also, since we are preaching "sustain open source", maybe we need to start with our own open source project :-)

We obviously all want this, it doesn't mean we have to do it in any way. Plus, we are not preaching, we are doing. Big difference. This seems more like a quick hack to make more money than a serious strategy for sustainability.

For example, how is this different from Gift Cards, Matching Funds, events or bulk payments? What's the justification for charging more here?

This is a subscription model for a donation, it's no different to what we already have. If the goal is sustainability then I think we need to increase fees in spaces where we add something different (ie job board, manage support contracts, getting hosts to pay platform fees or some fee, or laser focusing efforts on the communities that are growing our revenue etc) I find it hard to justify an increase in fees in a donation system tbh.

We are not going to be hiring a sales team to sell this, is another feature we create for making it easier for companies to give funds to collectives. That is the business we created for a 5%. Increasing that amount imo is justifiable when there's new business offer/model. This is not it.

We are spending more funds at the moment in trying to onboard a new vertical with features like 'no fees / tipping model' - reaching sustainability has many paths.

You are basically interfacing on one side a lot of small producers with consumers that don't want to directly give money to each of them because it's too much trouble, individual transaction cost is too high

This is what we already do with bulk payments and OC in general imho.

Now in the future, I think it would be great for the OSC to own the relationship with companies, do the outreach, purchase order process, etc. That would justify a higher percentage.

The OSC is not asking for a higher percentage or more work the flip-side is that it is paying 5% platform fees.

I could also see the OSC take the full commission, but for that they should be the ones financing the development (and the maintenance) of such feature. Not sure if the OSC is ready for that yet.

Why? Are we expecting XR to fund the tipping model?

My opinion: because we wan't to be sustainable, is not really an answer. I don't see how 30% is justified here as this is spec'ed out, I think we risk alienating our community. I would proceed as we it's spec'd as a first step with the goal to increase the number of subscriptions on the platform and recurring based revenue.

[xdamman]

how is this different from Gift Cards, Matching Funds, events or bulk payments? What's the justification for charging more here?

The biggest difference is that in all those examples, the collectives are still the one responsible for marketing their page.

In the case of a subscription model where we automatically distribute funds based on dependencies, we enable collectives to automatically receive funds without having to reach out to potential sponsors. It’s exactly like an ad agency business where publishers don’t have to reach out to advertisers (hence the reference to Codefund which keeps 50% commission if I’m not mistaken). It’s also like the Resonate.is model (30%) and Spotify (52%). In each of those cases, the producer doesn’t have to reach out to the buyers (companies) and the companies don’t have to reach out to each individual producer.

If all of those other services demand more than 30% for such service, why wouldn’t it be justified for us? What am I missing?

I think we would do a disservice to the community if we don’t think enough about our own self sustainability.

And yes of course there are also other avenues to bring more money to the platform that we should explore, but I think it’s safe to say that the Open Source « vertical » should be self sustainable on its own.

What would be the best way to test our assumptions here?
I feel like we could use some external advice here. We could also ask for feedback from companies who would be interested in that feature. Getting more different perspectives would help.

[piamancini]

If all of those other services demand more than 30% for such service, why wouldn’t it be justified for us? What am I missing?

The advertising model is expected to charge what they charge, they all do. We are a crowdfunding platform so we'll be compared to Patreon, Kickstarter, GoFundMe and the likes. It's a different space.

If (or when) we decide to build other services for the open source community (curating registry of dependencies with information like bus factor, latest update, health of their community etc; interfacing between companies and collectives for hiring talent; managing support contracts with the community) then I think we should get higher fees. This proposal is not that. It's a way for companies to automatically give out to their dependencies. We are not curating or assessing those dependencies.

I see this as a way to a) increase sustainability of our community, b) increase our recurring based revenue and c) as a base on which to create services around the dependency tree in the future.

I'd like to pilot it as is at the moment and use it as a conversation starter for companies to see what services we could provide around this.

[BenJam]

/me leans in

Wow, there's a lot here! Picking out some of the bits from above:

Motivations

The company spends $1,000 and expects $1,250 in return.

++ to this kind of thinking. Companies need a bottom-line value that is positive in their favour.

Advertising is a perfect example of this.

With respect I am not sure I agree with this. Advertising used to sell something can be this, but many accept that advertising is a bit of a dark art and that it's often difficult to attribute a specific new customer, user etc. to a particular investment in advertising.

I believe there are other quantifiable gains (recruitment, brand awareness, loyalty)

I agree, but I would add that these are indirect benefits. And that there are masses of direct benefits that are easier to quantify still: Developer support, LTS versions, back-porting fixes, direct involvement in development as a committed user etc.

I think we need to increase fees in spaces where we add something different

I think OC (as a whole) should increase fees where they enable users (collectives or sponsors) to increase the value of what they receive. Also I am happy to say that 5% fees for a platform that enables me to accept payments, communicate with sponsors and manage project spending as a community is cheap :)

Getting hosts to pay platform fees (paying 5% platform fees).

that this is a problem is a bit weird. Why would hosts not pay platform fees to use the platform?

I find it hard to justify an increase in fees in a donation system

Yup. But as I say, there are lots of quantifiable, direct benefits available to you too :)

I think we would do a disservice to the community if we don’t think enough about our own self sustainability.

++ we all want OC to exist as it does today: a responsible, transparent and thoughtful company that works in the best interests of (and ties itself to the success of) its community.

Implementation

How do we split among the different dependencies? Not all are equal

I don't have an answer here but I suspect a successful approach would grant proportionally more of a given subscription to level n dependencies than it would n+1th level. I also suspect that there will need to be a damping factor in there that pushes donations up and down the tree depending on current level of support for a dependency.

I do know that there are some conditions that we should all strive for:

• I should not be able to change my take by vendoring my dependencies.
• I should not be able to change my take by splitting my package into many packages.
• I should not receive a disproportionate take by implementing simple interfaces into complex projects (i.e. maintain proportionality between value and take)

Ultimately I think there will be many variations and we should try them, be open about them and codify the one that emerges as being the best approach, which is why I would support:

If they want to change the weight and give more to different dependencies, they could add a backyourstack.json

With the proviso that this is a nice to have really.

how do we manage when (1) new dependencies appear in the company repo

Grab them from the repo, shake them out with https://github.com/librariesio/bibliothecary

(2) when existing dependencies that weren't on open collective

The inwardness of subscriptions only going to projects that have an existing collective is, to me, limiting OC's reach and removing incentives for projects to join the platform. Pledges are the way to do this.

I'm not a fan of giving an amount per dependency because companies need visibility for their budget.

This. Though I would say that companies need control of their budgets. Linking the accountants to developer's ability to choose OS packages would have pretty tragic consequences! Subscriptions need to be fixed amount with multiple options.

Conclusion

What would be the best way to test our assumptions here?

This is my whole working process in one statement :)

For me the mechanisms here are good. Sponsors should not have to care about who they're supporting, projects should not have to care about who is supporting them. Lowering metaphorical transaction costs until they are near zero, enables communities to find and support one another. The no. 1 thing that projects told you in your survey: help with outreach. Making the above a reality not only addresses that, it makes it a non-issue going forward. Your project is used? You're in a position to succeed.

The issue I have is with the value that is being delivered back to sponsors. IMO the value being delivered back is indirect in that it's not something that you would underline in engineering as part of a company's accounts. Recruitment, brand awareness and customer loyalty aren't engineering's departments.

For me creating quantifiable benefit within the engineering department (which is often seen as the most important in the company) is the ticket to creating a symbiosis between open source maintainers and commercial users of open source software. Is that right? If so what are they? Let's go find out.

[piamancini]

I agree, but I would add that these are indirect benefits. And that there are masses of direct benefits that are easier to quantify still: Developer support, LTS versions, back-porting fixes, direct involvement in development as a committed user etc.

Yup. But as I say, there are lots of quantifiable, direct benefits available to you too :)

I agree, but the proposal for the increase was to increase on the collective's side. We take the fee from the collectives' not the companies. My point is that if we can structure those direct benefits then we should charge the companies a fee for them.

Maybe a good first step would be, charging the company for the subscription of $100 + a fee on top that we charge them not that we take from the collective's available budget.

@coderberry what do you think about this?

[xdamman]

@BenJam Thanks for your thoughts! I wish I could +1 different paragraphs there!

@piamancini

the proposal for the increase was to increase on the collective's side

No. At least that wasn't my view.
It's really a question of how you frame the conversation, whether you say give $1000 to give $700 in an automated and smart way to your dependencies or whether you say give $1000 to collectives and we will charge them 30% for that service. I'd definitely go for the former because we would take the 30% at the source, when the money comes in, not after it's spread out. It's also much more justifiable to collective. We won't take your money, we just go find money out there (that's work!), we take our cut and then we give the balance (the majority!) down to the dependency tree.

[BenJam]

@piamancini honestly: I wasn't thinking about the devision of incomes to OC or OSC, just about the problem itself.

As a project: I'm not fussed where the fees come from, only that I understand what I'm getting. We currently 'pay' 25% to GH which feels like a lot but when I can side-step procurement at companies who want me to do x, y and z before paying us $100/month it feels incredibly cheap!

[xdamman]

Exactly, that's why I'm sure that collectives won't complain if there is a 30% fee.
They will look at what they are getting. They have to do literally nothing and they will get new money. And somebody else is worrying about reaching to companies, dealing with procurement, invoicing, etc. etc.

So it's basically the same fee than on the AppStore except you don't even have to "market your app". It's an amazing service / deal for the community (in fact, I still think that asking 50% like a classic ad agency business or like Spotify would still make sense, but a 30% seems more "fair" in our spirit of being transparent and sustainable for everyone)

[BenJam]

I think the difficulty here is that projects currently pay 5% to OC for the service, and that flat pricing structures are easier to grok. I can see @piamancini's concern that increasing the %age across the board by a factor of 5 would raise a few eyebrows in the community.

Personally I think that a project opt-in scheme to 'subscriptions' could be a solution to this problem, but it's increasing the complexity of the pricing (now I need to understand the split between payment processor, platform, host and 'programme').

Maybe there's a place for 'the Open Cooperative': a space for subscribers to support their ecosystem as a whole and for projects to subscribe (if they choose) for income in addition to what they might raise themselves within open collective. The Open Cooperative could agree, as a group, to offer group-wide benefits to subscribers and yet maintain the freedom to offer their own benefits to subscribers of their specific collective.

Kinda just thinking out loud (typing out loud!?) at which point I apologise to everyone for this thread getting incredibly off-track 😅

[xdamman]

I like that. Ideally and to avoid confusion, it’s something that the community should take on its own. In the same way that @coderberry took the initiative to create codefund, it would be great if someone could take the initiative to create the BackYourStack Coop on the same model than resonate.is. The main purpose would be to sell backyourstack subscriptions to companies and redistribute the funds. Since the coop would belong to the community, I see no issue that it takes 30% for that service. It’s one or more full time jobs. If there is too much money in the coop (I doubt in the first few years), the coop can always decide to reduce the 30% fee.

[piamancini]

Exactly, that's why I'm sure that collectives won't complain if there is a 30% fee.

I only believe in god, everyone else bring data ;) (well I don't even believe in god, but point stands, there's no data here) Happy to look at it if there is. From the survey we did, maintainers said the 10% fee was high compared to other platforms. Plus we've had quite a few collectives expressing that themselves. Examples in social media abound.

That said, we only see the complaints and never the 'we think this is cheap' so I agree we need some more research.

I can see @piamancini's concern that increasing the %age across the board by a factor of 5 would raise a few eyebrows in the community.

Indeed. Specially without a thought out justification.

Maybe there's a place for 'the Open Cooperative': a space for subscribers to support their ecosystem as a whole and for projects to subscribe (if they choose) for income in addition to what they might raise themselves within open collective

What would the income addition look like?

Final thoughts: we are moving forward with this as an MVP as is spec'd out by @znarf here. But I think we need to keep this conversation going, there is something here.

[BenJam]

Keeping the tangent rolling lol:

What would the income addition look like?

Perhaps you would become a member of a collective that shares its subscriber revenue. Within that collective you would offer benefit tiers (decided as a community) that are applicable to all the projects that are members of that collective (and enforceable by the community itself). This would not preclude you from having your own collective on open collective for your own project so provided additional income for the project(s).

I think there's room for OC to offer this.

[xdamman]

From the survey we did, maintainers said the 10% fee was high compared to other platforms

Of course. If you do the work of finding a sponsor, they agree to give you $1,000 and then there is a 10% commission for the platform, that’s not fun.

But it’s a very different story if every month, without doing anything, you receive proceeds from an entity that has been selling a bundle that you are part of. It’s normal that that entity should first takes its cut to make sure it can sustain itself to continue to sell in the future the bundle to more companies.

That’s why people don’t complain to CodeFund for taking 50%. Because they know that they don’t have the time to go reach out themselves to advertisers. So better take 50% than nothing.

@BenJam This could be the BackYourStack Collective. And then collectives that want to be part of the bundles that will be sold as subscription to companies could become members of the collective. What about we start that way and all the money goes to the BackYourStack Collective in full transparency and then we decide together how we split the money among all the members? Based on the amount of work required, the amount of money raised, and other data points, we would be able to take a much better informed decision.