Forms of interaction

Direct contracts

The most obvious and increasingly common[150] way to bridge a FOSS project and the enterprise is for maintainers to operate their own legal entities, selling “consulting or master services”, “service levels”, et c. sign standard contracts, take on legal liabilities, issue invoices, provide a legible KYC and AML story, et c.

In a sufficiently privileged position, a “professional maintainer” might take a finer control over their non-disclosure and non-competition agreements than feasible in employment, hedge their commitments over multiple consumers, and secure a wider margin they can use for independent work and research.

Later in the document, comparing to the alternatives, we’ll argue that this regime is the most likely to maximize the volume of money moved from “the industry” and into “the community”, i.e. converted from “legible” into “useful”.

The function of such an entity is to offer legible terms in the form of a “statement of work” or a “deliverable”, and justify the margin, which finally can be used for the real, illegible, work.

The establishing and maintenance of a legal entity is a cost for a maintainer, but only in the early “subsistence regime” stages: once a margin is first established, the administrative overhead is easily offloaded.

By employment

Companies aiming for scale may quickly become a liability and a threat to the project. Unless managed directly by maintainers and without debt, they reproduce the bureaucracies that keep money frozen in the “legible” state. Employed maintainers are further locked into subsistence and scarcity. They may not afford to keep contributing once their employer has withdrawn from the project. Employment, as any financial dependency, may further bias the maintainer to accepting temporary and suboptimal solutions.

A consulting firm operating on a flat fee rather than value-based or the profit-sharing basis is particularly prone to taking on a larger number of projects with smaller margins. This damages all maintainers within and without the company, by lowering the “market” prices for their services, and by creating additional workload for volunteer reviewers.

By proxy

Maintainers doing maintenance for a living, employed or independent, are competitors and bring conflict into the project. Even with demand far exceeding the supply, it takes clear and frank communication between the two maintainers offering the same service to avoid confrontation.

Competing maintainers could manage conflict by selling their service as a single co-owned entity. Its function might range from that of a simple “Fiscal Host”, hosting a shared pool of money, to that of a “cooperative” or a “Guild”. One might already make out some of these familiar shapes in projects such as Numtide.

The NixOS Foundation is one hypothetical candidate to serve as such a proxy. It comes with the promise of a recognizable “brand”, the potential for a greater negotiating power. It is a non-profit organization, which should hopefully incentivize it to channel the money into actual maintainers’ hands in a timely manner. A shared fund unattached to any specific obligations might be our second-best chance to enable the maintainers’ “real” work, which is: the research, the “gardening”, the community-building, the onboarding of new contributors, all in contrast to the fulfillment of the paying corporations’ terms.

Second-best after Direct Contracts, but second by a large margin, the Foundation would be a very inflexible host, put into a position where it “represents” and “decides” for maintainers, its non-owners, and disbursing money that hasn’t been yet “cleared” of obligations to the Investors.

Owned by a third party, in a conflict between the maintainer and the sponsor, the Foundation is better incentivized to salvage the relationship with the large paying customer (“the good of the many”), than the one comparatively replaceable contributor. Not invested in any particular project, the Foundation risks becoming an extra layer of a viscous and fallible bureaucracy, a source of logistics errors. Where the Investor used to have to maintain a relationship with the contributor, it is now the contributor’s job to maintain a relationship with the third party. In short, the Foundation becomes a point of failure and a threat to the maintainer.

What is a risk to the maintainer, is sometimes seen as a benefit to the investor. Initially scared away by the Foundation’s publicity and its non-profit status, a Corporation might find it a vehicle to organize a buyers’ market and exert a tighter control over the Project’s technical direction.

Rather than a “Guild”, owned by maintainers and promoting their interests, the Foundation might grow into a “Trust”: conspiring for lowered prices, holding Investors’ shared assets and “human resources”, deduplicating their procurement and taxes, and imposing Enterprise-favouring conditions on recipients of the funding.

Defining Success

Comparing to SEC numbers right away might make it seem discouraging

Comparing to SEC numbers "is clarifying! It's right, it works. It cuts through, and captures the essence of the evolutionary spirit!"

Charging for the same work, twice? That sounds unethical!

Prices depend on the will of Allah: it is he who raises and lowers them.

Per Graeber D, attributed to Prophet Mohammed[140]

The profit of each partner must be in proportion to the share of each in the adventure

Per Graeber D, an Islamic legal precept[140]

The first litmus test which will determine if the project is being eroded or empowered by the collaboration with the industry is whether we're having our discussions in the framework of splitting "costs" between corporations, or in the framework of each corporation buying from us a "service" responsible for part of the "value" they generate.

Salesforce scales the subscription fee by the number of people in the chat. Your housing company and electricity provider price their packages based on your squared meters. Your insurer assesses your income, your credit history, your health, and your grocery’s loyalty program data. Such is the model of Oracle, RedHat, and Microsoft. How does one estimate the value generated by Nixpkgs? How does one price the “service” we provide?

In the former case, the volume of money moved into the community per company is roughly divided by the number N of consumers. In the latter, the total volume is roughly the same quantity multiplied by N. Thus we identify our first Failure Mode, which we'll colloquially dub as the "Not Enough" or the "No Margin" Problem.

We shall consider the collaboration successful when we can estimate the money volume, being moved from "the industry" into "the community" as "service fees", post expenses, or as "charitable donations", to be at least in the range of (0.1..1.0]% of known corporate consumers' turnover.

By “community” we shall mean any maintainers-owned legal entities: sole proprietorships, limited companies, and non-profits such as maker- and hacker-spaces, community laboratories and workshops, student organizations. By “service fees post expenses”, we mean the margin that is left after fulfilling the respective commercial contracts’ terms. Just like a “charitable donation”, such a margin for as to employ as we will, and to redirect into any other project without consulting the Investors.

Concentrating our assets directly in the hands of individuals and non-exclusionary territorial cells like maker-spaces is how we hedge our risks, and prevent the second Failure Mode, the “Singularity” problem.

"Singularity" here shall refer to a "degenerate distribution", and specifically any state of affairs where all (most) assets are concentrated in one (few) place(s), a "point mass". This "single point of failure", the gate-keeper, may manifest itself as a committee, a board, or a council, which requires memberships and approvals, mandates application and voting procedures. These rituals may be then made to precede any expenditure and any access of the project's resources, or really any "decision".

The reasoning behind, say, building fabs or compute clusters under “hackspaces” is not that they are intrinisically better governed, or more ethical than any other form of association. It is, instead, that they are multiple and set not too high a threshold for entry. Compare a “hackspace” to a University: in Academia, to obtain a compute quota or access a chemical lab, one must obtain a contract with a research institution; the first filter for any position at a University is normally a document, certifying that the applicant has been on a multi-year continuous track of formal studies. A “hacker-space”, while it may wallow in drama and feature a harsher bureaucracy, is generally open to people of any background. A hacker space is discoverable, it is associated with geography. It is usually not hard to get hold of a member at a local pub.

The Margin is crucial. When it comes to our autonomy and independence, there can never be any security for us other than The Margin we extract above the “payroll” and the hardware we ourselves posses. It is decidedly and fundamentally impossible to diversify our dependency over multiple “sponsors”, when these sponsors know of each other or engage in the same trade. The Margin shall protect us when by the very nature and purpose of our work (#build-up, #refactoring), we subvert the demand for our services. The Margin is how we enable our next project: from redesigning the linkage model of Nixpkgs, to inverse graphics research, to local PCB production, to end-user inspectable integrated circuits, to permacomputing.

One might be tempted to naively assume, that a gradual exposure of Nixpkgs to Finance would be less corrosive and damaging, or cause less unrest, than the more realistic value-based approach. In our opinion, this is a plainly wrong, counter-productive, harmful thinking. Having claimed the Margin, one may immediately start implementing the counter-measures and demonstrating an improvement in our autonomy and sustainability. A "gradual exposure" compromise means we get "all of the negatives and none of the positives": we do shock Nixpkgs by driving it directly into the vast enormousness of the Capital that, for its size, many might not have recognized bearing down on us; we simultaneously do set up the channels for the Enterprise to directly influence Nixpkgs' decision-making, compromising our independence, and thus shrinking the Project's "value"; we do set the precedent, that the first time Nixpkgs sold out, it sold low; we do not acquire anything in return, save for means to subsist another day. Taking on such a blow, without also taking the necessary means to handle it, is a recipe for disaster.

We must not compromise and taint the project as open to influence, unless each party commits to the effort of consciously and continuously overcoming these structural issues, securing The Margin.