Hi! Thanks for continuously working on and improving OSC. I administer collectives here since 2016 and it's a vital part of my income.

I'm concerned about these new eligibility criteria! I'll share why, but first: what was the motivation to change it? Do you have too many collectives and are trying to reduce the number of extra work?

My main concern is that this is a negative for small projects. Almost by definition, a young project with 100 stars on GitHub will *not* have several contributors, it will be a one-person effort. I understand you want to increase collaboration, but young projects are so tiny and they are usually born out of one person alone. I've seen this happen countless of times and it's a strong pattern (also known as the Pareto distribution, or the 90%-9%-1% in internet communities). Even the medium sized projects have a difficulty finding and keeping a second maintainer (they are usually exceptional people who also have their own ideas and go on to build their own hobby projects!). So my concern is that OpenCollective would only be useful for the medium-or-large projects, and it would hurt the development of new and exciting projects which may *need* all the help they can get, including from OpenCollective.

I understand that building an active open source community is a noble goal, but in my experience (as an open source maintainer), open source is not built by communities. It is 80% built by exceptional individuals, and 20% tweaked by other people who pass by. It is even difficult to label those people as community, because the vast majority of them have a shallow and temporary engagement with the open source project. They may create a great PR and never come back. They may actively engage for 1 year, and then suddenly disappear and never come back. I have real life stories of people who fit those stories. The maintainer of curl said similar things.

In my experience, the nature of open source does not distribute responsibility, and it is not built as a community effort. It's an incidental masterpiece. Someone somewhere has exceptional drive to create something, they happen to have enough free time, and they're willing to work for free or for little money just to keep the project alive. Please don't take away the little that these people get, you'll leave them just working for free because they'll not be able to start an OpenCollective. Or, they will artificially invite some friend to be a co-admin and the same dynamics will continue.

What was your motivation? To filter out some projects and have less work, or are you trying to prescribe a certain way how open source *should* look like? So far OSC has done a great job at just supporting open source projects, no matter what they look like. I wouldn't like to see you folks getting into the game of changing what open source should look like.

BR,

I completely agree with Andre's comment above.

imo requiring two administrators is unrealistic, and penalizes the majority of the ecosystem, which is comprised of single-maintainer projects.

Nobody is a solo maintainer by choice - all this will do is incentivize folks to create a sock puppet account to be the second admin, which doesn't help build community, and is strictly worse than having a single admin.

Thanks for your comments, responsiveness, and care, Andre and Jordan. 

We are implementing this change for a few reasons, at least one of them mentioned by Benjam: we need to continue to provide an efficient service to our member projects. This isn't always easy. The number of applications has ballooned, and we've spent a considerable amount of time vetting new members over the past year.

We also spend a lot of time dealing with bad actors on the platform - and almost all of these actors are from single-person projects that suck up a lot of our bandwidth (and Open Collective's bandwidth). Fraud sucks. Having a second admin is one way to ensure that this is easier for us to catch and deal with. 

I see your concerns about smaller projects and solo maintainers. Yes, the majority of projects are started by a single person; yes, the majority of projects are also maintained by a single person. Contributors to a project rarely end up being maintainers of that project. Project contributor size grows and ebbs during the lifecycle of a project, as well, and the roles held by community members may change. 

Open Source Collective is here to help collectives - groups of people working on projects together. We're also interested in sustainability for open source - we don't want to invest time in energy in projects that are short-lived. A single-maintainer project is less sustainable in the long term than a project with multiple maintainers. A project that has enough of a drive to get two or more people on board (if only for fiscal matters) it is better off than just one. What we're looking to help are projects that have made that crucial step in governance - from 1 to 2.

We've hosted workshops, written guides, and continue to create resources to make it easier for people to learn how to find and grow other maintainers to help them out. I'm personally super interested in that problem - how do we make it easier for open source projects to develop their governance strategies away from BDFL, if they want that?

I hear your comment on OSC not changing what open source should look like - adamantly, I agree, heterogeneity is better and I'm on board with not being prescriptive. OSC is just trying to limit ourselves to supporting those projects that have a community, so that we can do that better.

I actively want to help projects, which don't know how to build a community, build one too. I also want to help projects talk to each other better, to share their needs and wants, because OSC can't provide everything, either.

The goal of this isn't to incentivize people to set up dummy accounts, of course. To be very clear: we don’t want you to resort to having to create a dummy account, or to invite a friend to set up an account just to pass our criteria. We will work with you to make this easier. Instead, we are trying to encourage more involvement, more shared responsibility and decision making going forward for our member collectives.

Our strategy outlined what we're interested in - strength in community; people more important than code; one size does not fit all; and solving problems together. Some of our strategy is aspirational for the ecosystem as a whole (for instance, sustainability, or reducing the Gini index in OSS) - I think that's OK. Let me know if you disagree.

I didn't expect limiting admins to two people to come as a major shock to our collectives, and I am more than happy to work with you to talk about it, either here, on a call, or on Slack. 

Thanks for giving more context, Richard, specifically this part:

> We also spend a lot of time dealing with bad actors on the platform - and almost all of these actors are from single-person projects that suck up a lot of our bandwidth (and Open Collective's bandwidth). Fraud sucks. Having a second admin is one way to ensure that this is easier for us to catch and deal with. 

Answers my question, and it's something that wasn't obvious from the original announcement. I understand if you folks are dealing with a ton of illegitimate applications. Any financial system will end up with these things. 

The scalability/efficiency in dealing with applications seems to me like the primary goal for this change, and the reducing Gini index seems like a secondary goal. The secondary goal is noble, but given that OSC has operated for 6+ years allowing single-maintainer small projects, it seems like a brutal change of direction. But I'm here to talk about the primary goal. If you're mainly concerned in reducing noise and increasing signal, perhaps consider different ways of solving the problem that doesn't hurt (some types of) signal? I know you want to focus on communities, but: you have served individual maintainers for years, and this type of project is a very common type, you'll be effectively inviting people to use GitHub Sponsors or Liberapay instead. Can you just focus on reducing noise while preserving all types of signal?

While your concerns are understandable, let me add my 2ct for the "longevity" of projects. Sure the bus factor often is a criterion. But I've also seen multi-person-projects splitting up or "going down the drain". I always wondered if as a single-person project I'd even be eligible to use OC (I have an account here as I'm also a co-maintainer of a larger project). Thanks to Andre's comments I now know I would have been – but thanks to the change might be no longer.

I might be an exception here. My 3 main project (which consume quite a lot of my resources) are in existence for many years: I run one of the largest German eBook servers (12k free books under free licenses available via web browser or OPDS catalog functionality inside eBook readers) for about 12 years now, the largest 3rd party F-Droid repo for about 7 years, and my website with app listings plus articles for at least 8 years.

Now back to the issue on hand: If I'd apply, would you (still) take me? Would I need an "identical twin" to satisfy the new rules, or would there be exceptions – and if so, which? Answering the latter with a suggestion:couldn't single-person projects be accepted at least if an existing (approved) project "vouches" for them (in my case e.g. the one I already co-maintain)? Or bring other "reputation" (references) into play?

We're talking about this in the Drupal community where there's been progress on adopting/integrating Open Collective into drupal.org (where thousands of large and small open source projects reside).

Similar discussions have been taking place in WordPress (which also has thousands of projects and pretty huge economy). Because these projects have huge communities, economies, and have solid, existing tools for discovery, search, and connecting with resources (contributors, partners, funds, etc) the requirements should be less of an issue.

Most open source projects aren't so lucky. Even ones with hundreds of Github stars and their own Slack or Discord community have an extremely difficult time finding maintainers, let alone sustainers (which is a whole different skillset and mindset).

OSC has been making great strides by publishing its strategy, building capacity, and providing some workshops and resources. 

Problem is most open source projects don't have capacity to do anything beyond maintaining. They need funds and contributors - and currently OSC (the platform and community) doesn't really provide clear ways to connect to either. 

That said, we should be able to solve most of these problems if the OSC embraced it's open sourceness and enabled the large, diverse community to contribute to platform improvements, documentation, building community, to training newcomers how to help OSC screen/approve collectives or managing, maintaining, and sustaining collectives themselves. 

Basically all the things the OSC working group was setting up to do... before it kinda stalled out due to lack of funds and time the initial team members were able to commit to helping get up and running. 

Considering there could be a large uptick in applications coming from Drupal and WordPress alone, a relatively small amount of OSC investment (time and funds) should enable a wide range of long term returns. 

Hey folks, thanks for the feedback. I want to show a similar level of thoughtfulness and consideration in my response, but for those who might not have the time let me say up-front, we'll remove the hard requirement for two administrators.  With that said, I'd like to tell you why we've reconsidered the requirement.

When we started Open Source Collective there were very few options for maintainers to gather financial support for their projects and, at that time, we had a responsibility to support as many as we could. Today we work happily alongside other solutions that work particularly well for individuals, which allows us to focus on what we do that is unique.

What we do is, of course, transparency and collective action, and we will continue to focus on this. What we missed was the part we can play in the story of individual maintainers. 

It is clear now the role we have is to support individual maintainers on a journey toward sustainability. That their registering with us is a signal that they care about transparency and collaboration, values that we share and believe are positive for the future sustainability of their projects.

Make no mistake, the terms of our hosting agreement have not changed; they always have, and continue to center on the project, not the individual. But we are here to support you to grow in every way we can, and we apologise for this brief misstep.

Thanks

Ben
—
Executive Director 

Thank you!