Write bylaws

[chadwhitacre]

Draft Document

https://docs.google.com/document/d/1WgYvY9wEwUV8r3pj0er9vVMgbwzOXqEUM_dtwDRUsdU/edit?usp=sharing

Background

Over in https://github.com/getsentry/fsl.software/issues/2 we went down a 🐰 🕳️ trying to find a brand name to normalize software sharing practices between closed-source and Open Source. "Software Commons" emerged on that thread, and while we are not directly using it for the original intent (we're moving that forward with howtoshare.software instead), Software Commons is turning out to be a really strong brand under which to attempt to address the sustainability crisis in Open Source.

Task

The Open Source commons refers to maintainer attention as a common-pool resource, non-excludable but rivalrous. Software Commons is intended to be an institution with a purpose of bringing together producers and consumers of this attention resource to ensure its sustainability according to this definition:

Open Source sustainability is when any smart, motivated person can produce widely adopted Open Source software and get paid fairly without jumping through hoops.

tl;dr Companies pay maintainers.

At a sketch, Software Commons should have rules similar to these:

• Companies and maintainers negotiate "fair share" compensation, something like $N,000 per year per developer on staff at a company.
• Companies report on what their fair share is and how they have paid it.
• Software foundations report on how fair share payments have been distributed to individual maintainers.
• Platforms aid companies and foundations in their reporting.
• Software Commons audits both company and foundation reporting and provides accountability.

Let's write bylaws for Software Commons to encode rules along these lines.

[chadwhitacre]

Bringing this over from @mattisg at https://github.com/getsentry/fsl.software/issues/2#issuecomment-1982328368:

References:

• OpenFuture's Paradox of Open (summary) • Joint Statement on the Creation of a European Initiative for Digital Commons • Next Generation Internet: Forum 2023 and Commons call • Open Knowledge Foundation’s Tensions in Commons • PublicSpaces statement and Building Digital Commons conference

[chadwhitacre]

Picking up from https://github.com/getsentry/fsl.software/issues/2#issuecomment-1981529753:

A Commons approach can bring producers and consumers of software together as peers. It enables a consumer of software to participate in the production and maintenance of commonly-held information goods, and to share in prosperity when enjoying those goods for their productive uses.

@mswilson It seems like you're not taking on board the distinction between software as a public information good, and maintainer attention as a common-pool resource. This is more fully developed in Working in Public, where Nadia concludes: “Open Source is consumed like a public good, [but] produced like a commons” (p. 212). "Producers" and "consumers" in this context are producers and consumers of maintainer attention. Attention is time, and time is money, hence the focus for Software Commons on companies (consumers, or "appropriators" in Ostrom's terminology) paying money to maintainers (producers).

[mswilson]

First, I'm not super excited about engaging with this under the "softwarecommons" GitHub org. It feels like you're moving forward with very problematic branding / messaging.

That aside, I'm familiar with the separation of information goods (which are naturally non-rivalrous and bountiful) and the effort required to produce those information goods (which is naturally a scarce resource). I do not agree that maintainer attention is a common-pool resource in many cases, even when information goods that are available to the public are produced. I will borrow the definition that C. Titus Brown (@ctb) proposed for the sake of argument: "communities of effort".

In order for "effort" to be a CPR, it needs to be allocated according to the needs of the Commoners that are participating in a given Commons (i.e., are engaged in collective action in managing the common resources at their disposal). When the resources that can be applied toward continued production of a given piece of software are coordinated through the use of a Firm (e.g., a VC-backed company that is engaged in the business of producing and monetizing a particular software package), rather than through community consensus, it is hard to see how "CPR" applies.

[chadwhitacre]

the definition that C. Titus Brown proposed

I had not seen this, thanks. Please never stop bringing the references. I love how widely read you are. :-)

(Also hi @ctb! 👋 😁 )

coordinated through the use of a Firm

Now it seems like you're not taking on board the distinction between a Firm as a participant in a CPR, and a Firm as the governor of a particular software project. It is the former that is relevant here.

When the resources that can be applied toward continued production of a given piece of software are coordinated through the use of a Firm [...], rather than through community consensus, it is hard to see how "CPR" applies.

Modulo that "consensus" is not the only way communities make decisions, I quite agree. 😌 Sentry and Codecov are not CPRs, but Functional Software, Inc. is a participant in various CPRs.

Maybe an analogy will help.

Comparing Maintainer Attention to an Aquifer

Picture an aquifer under a city. The households and businesses in the city draw water from this aquifer. As their demands for water increase, they must collectively develop a system of boundaries, rules, monitoring, and enforcement to prevent the depletion of the aquifer. If unsuccessful, the rate of withdrawal outpaces the rate of replenishment and the aquifer dries up.

Now take it that the time and attention of Victor, Serhiy, Erlend, Alex, and the other individuals producing Python is the aquifer. Households and businesses drawing water is analogous to users of Python requesting new features and bug fixes from the producers.

Here's where the cases diverge:

• In the water case, the aquifer's rate of replenishment is not changeable by the participants. They must resort to restrictions on use to prevent overuse. The analogy would be if the Python maintainers started restricting who could open a ticket; Nadia does consider this scenario (in general terms) on p. 186.
• In the Python case, though, the supply of time and attention is changeable (WiP, p. 181 ff.). The straightforward way to increase the rate of replenishment of the aquifer of Python maintainer attention is to pay maintainers. Companies do this by directing their employees to work on Python, and this is important. But it is also important to have a strong proportion of independent maintainers, to avoid enclosure of attention. Moreover, while available attention will always be outstripped by available work (this is true universally), the prevalence of maintainer burnout suggests that many Open Source projects are heavily under-provisioned in terms of available attention.

Specific Open Source CPR Examples

The PHP Foundation runs the best program I've seen for funding maintainers to work on the project. In fact, it is their "primary task." The foundation "contracts 10 part-time developers who work on maintenance and new features for PHP" (ref), and their finances are transparent on Open Collective. I love the PHP Foundation for this. 😊 🥰

The Django Software Foundation runs a fellowship program that employs one person full-time and one part-time. Django co-founder Jacob Kaplan-Moss in a recent post suggests:

“Sustainability” would mean that something like a dozen people were being paid to work full-time on Django – and being paid something approaching the industry median. It would mean several dozen people working full-time on Python. Heck, just PyPI by itself ought to have a team of 10-15, minimum, given its scope, scale, and importance.

(The Python Software Foundation does have grant and fellowship programs, but they are structured differently and do not go towards employing core maintainers.)

When Functional Software, Inc. gives money to PHP and DSF, we are (to mix the metaphor) increasing the amount of independent maintainer attention that is available in the PHP and Django aquifers.

[ctb]

the definition that C. Titus Brown proposed

I had not seen this, thanks. Please never stop bringing the references. I love how widely read you are. :-)

(Also hi @ctb! 👋 😁 )

hi!

[MattiSG]

Functional Software, Inc. is a participant in various CPRs.

As @mswilson said, and rephrasing: a common-pool resource has its finite resources allocated through common (democratically-decided) rules. In the example of the PHP foundation that you gave, who decides on what the Foundation-sponsored devs work on? If Functional Software, Inc. staffs developers to add some specific feature they need to some FOSS, they are not participating to a CPR: they are contributing to an asset, but not pooling resources.

Qualifying maintainer attention as a CPR makes at least the following assumptions:

1. The number of maintainers is limited and cannot be increased easily.
2. There are rules in place that enable any community member to participate in the decisions on allocating maintainers' attention.

The counter-example to (1) is contributive commons: Wikipedia, OpenStreetMap, OpenFoodFacts all have a massive number of contributors and have rules that enable election of “maintainers” (also called “admins”, people with extended rights). The counter-example to (2) is most FOSS, where maintainers (usually founders or people with high social capital in the community) decide on their own what is worth their attention.

---

Anyway, back to the OP: “Companies pay maintainers” is good. I believe the goal of funding maintainers based on adoption is great (because we might think that adoption in the free market of open-source is a good proxy for quality, so we don't need to assess practices beyond adoption: if maintainers have high adoptions, they are doing something right, so let's just pay them because people use their production; counter-example: stuff made by large companies like Meta have huge exposure beyond quality merits, leading to disproportionately high adoption).

Digital Commons, however, are called this way solely because of their democratic (common) governance. They are first and foremost political objects. As long as you use “Software Commons” as a brand name, you'll conflict with this definition and the goals of all actors who work towards establishing and supporting Digital Commons.

[anehzat]

When Functional Software, Inc. gives money to PHP and DSF, we are (to mix the metaphor) increasing the amount of independent maintainer attention that is available in the PHP and Django aquifers.

The byproduct of this contribution is also nice when a maintainers works on a dormant package only to be recognised & rewarded for their effort.

[chadwhitacre]

Reporting back on an introductory call @MattiSG and I had last Friday:

1. Matti introduced me to the work he has been doing for the past 2+ years to establish policies around Digital Commons in Europe and elsewhere.
2. We agreed that a particular concept of governance is essential to the general definition of commons, which precludes (in our specific case) software projects controlled by companies.
3. We agreed that Software Commons will not be about companies sharing software in ways that don't include commons governance (I've moved the howtoshare.software repo out of the Software Commons GitHub org to reflect this).
4. We agreed in principle that a strong potential direction to explore is for Software Commons to become a US-inflected complement to the EU's approach with Digital Commons.

There's a lot of open threads, still, but I'm hopeful we'll be able ultimately to reinforce each other's work.