A Programmer Union Can Save Open Source

1 Like

This was super interesting.

If I can walk up the abstraction ladder for a moment. For some time now, FOSS has been characterized by the dichotomy between open source on the one hand, and free software on the other. But I think neither of these models work anymore.

Free software is increasingly not how software is written (see the rise of clang for one example). The free software people perceive themselves as a political movement which insulates them from recognizing the problem but there are plenty of political aspects of it (RMS controversy, AGPL controversy, v2/v3 split, etc etc)

Open source in some sense won the popularity contest but it also isn’t how software is written, if by “written” we mean things like “actively maintained and reasonably handles security issues.” It is mostly a cog in a larger corporate wheel rather than a reliable way for an independent developer to accomplish a project.

Personally I think there is a ton of space in the middle, or somewhere else, or that otherwise engages with the modern situation at literally any point. The thread connecting SSPL, Prosperity, Ethical, this union proposal, etc., is first of all a bunch of “we wrote a document in the 80s” objections like Freedom 0 or OSI 4 or whatever.

But the “documents in the 80s” were once upon a time a real solution to some contemporary problem, and our movements were in fact problem-solving traditions. It is increasingly difficult to solve problems now.

The interesting thing about this proposal is it strikes a compromise between a free-software political project and the reality that companies are the ones who write open source, and proposes some mechanism by which we can bridge those realities. I suppose that means everybody must come to hate it. But to me that is a reflection on the problems of our two-party system, which seems to prefer continuing to erode both movements rather than capture the spirit of innovation they had back when.

1 Like

What I like about it is the idea of union-exclusive software.
Not because I personally care about using licensing to push companies towards unionizing, but because I think the key to our success may lie in exclusivity.

Basically, protect the commons by making it:

  1. Valuable.
  2. Exclusive.

If there is an incentive for companies to help support the commons because they get access to valuable software that gives them an edge over competitors who don’t have access, that can be what enables a sustainable commons.

The biggest obstacle to that, as far as I can see, is the undermining caused by “scabs” who choose to continue with the open-source approach, and the ideologues who persuade people to continue to subsidize companies with open-source.

But even in the presence of those folks I think we can win, if the value of the “fortified commons” is greater than the value of the improperly funded, and improperly maintained free commons.

Perhaps we could even sell our message like this:
Big tech companies love to give away open-source stuff for free and they’re willing & capable of subsidizing it.
Let them. Do not oppose their efforts.
But if you’re a small guy (like the vast majority of FOSS contributors are), we have a better deal for you. You can have the financial support necessary to make great software for the commons.

Let the big guys subsidize, and let the small guys get supported.

That’s my grand vision for the future: the fortified commons.
Transcending the tragedy of the commons to become the victory of the commons.

But as I said, my vision is predicated on having a higher value proposition than the free stuff nowadays, coupled with exclusive use to those who financially support the commons.

I’m trying my best to look through many of the distracting specifics in this post to the heart of it. Hopefully this would be a fair TL;DR:

Summary

Workers at companies vote to join an organization, at which point everyone working there has to join. The org’s job is to collect 1% of everybody’s earnings, to fund matching-donations and grant making programs to software projects. The software projects in turn release code that’s free to use only by members of the organization, or organizations of the type.

Two big problems.

First, the idea of a union that does not bargain for its members collectively makes no sense. That’s not a union. True, some unions also do other things, like political activism or collective insurance. But collective bargaining defines a union. It is what they do.

Second, the law is not going to let 66% (or any percentage) of workers at a shop force everyone else to hand over 1% of their income for this kind of scheme. The exception to forced association like that, under US law, is unions that bargain on their behalf, collectively, because taking pay and benefits under the union contract without paying union dues is free riding. And this only applies in states that allow it. Many are “right to work” states, and do not.

One point I think this post makes well is that investing in shared software is wise. It tends to increase productivity, which tends to increase coder comp. But if that’s a good investment, what’s the use of an organization that compels them to invest? Where’s the collective action problem that a compulsory association of coders is supposed to solve?

Early on in my 1099 coder days, I remember saving up what seemed like a huge amount of money to buy a MacBook Pro and Textmate. Partly, no doubt, because folks like DHH glamorized those tools, and even cast doubt on coders not willing to “invest in the best”. Partly because I was working with and for a bunch of designers, who all used Macs.

The logic of paying Apple, Inc. and Allan Odgaard extends to donating to free projects we rely on, too. It’s feeding resources back to the people that feed us that drives the logic, not the particulars of what form that contribution takes, or whether it’s called “license price” or “donation” or “consulting fee”. Those are just implementation details.

The trouble isn’t on the paying side. It’s on the benefits side. When we contribute to permissively licensed projects, as individuals or companies, we bear the costs of benefits that accrue to a lot of other individuals and companies. Some of those will watch us contribute, contribute nothing of their own, and free ride. Others may even take the code and use it to compete with us. This negatively affects incentives to contribute back in the first place.

One class of solutions to this kind of problem boils down to reintroducing economic excludability. Which the law supports, via licensing. It could happen at one or many levels of granularity:

  • Only individuals who contribute or pay can use the software.

  • Only companies that contribute or pay can use the software.

  • Only members of some new kind of organization—e.g. the post author’s mandatory tithing not-a-union—can use the software.

  • Only members of organizations that meet some criteria—co-ops, mandatory tithing not-a-unions—can use the software.

Why incur all the organizing, administrative, and legal costs of doing this kind of investment collectively? Why write an entirely new license, with an entirely new boundary defining who can and can’t use for free, to worry about? Just put software up for sale. Those who find it worthwhile to invest the price can use and benefit.


Final, tiny thing:

Programming is unlike nearly any job, because we can make tools that recursively improve our productivity.

I can’t help pointing out that this is just not true. Machinists make their own tools, dies, and fixtures. You can find hours of YouTube tutorials showing how carpenters make wooden planes, workbenches, gauges, components, measuring tools, and so on. Many scientists routinely invent their own apparatus. Artists make library music, B-roll, stock photos, and so on. Teachers write their own curricula, materials, and so on.

Even when producing tools and materials turns into its own, specialized job, we see collaborations between users and outfitters. Successful musicians often collaborate on signature-model instruments to their custom specs, for example.

2 Likes

“The commons” is one of those very slippery glittering generalities. But many would define it first and foremost in terms of non-exclusivity.

In fairness, “commons” does get used in writing outside software to mean practically or legally non-exclusive to a particular group. The grazing commons in a village in the north of England was not really “non-exclusive” to camel herders in Somaliland, for example. But Internet access and digital reproduction tend to collapse those practicalities.

Acknowledging the parallel here. This vocabulary works.

But for what it’s worth, I’ve personally found it more productive to see this in terms of competition. What do we do about “scabs”? In this century, mostly call them scabs, call social attention to them, and try to make them feel bad about themselves. Little more.

What do we do about competition? Pretty obvious.

The best evidence for a new model will be projects under that model outclassing offerings under the permissive-open and proprietary-closed models. Making it way too simple, that could look like someone brilliant choosing to market important new work under the new model, new-model producers out-collaborating old-model producers, or, more likely, combinations of both.

Permissive-open does a good job of maximizing collaboration among large numbers of producers. Proprietary-closed does a very good job of funding individuals and small groups of high-value producers. There will probably always be producers and projects best served by those extremes. What will the producers and projects best served by a middle way look like? Where do we find them and how do we help them?

1 Like

Permissive-open does a good job of maximizing collaboration among large numbers of producers. Proprietary-closed does a very good job of funding individuals and small groups of high-value producers.

My view is that things are not so clear cut as that.
For once, it seems to me that the idea that permissive FOSS is great for collaboration is a myth.

I think that there is a difference between what can happen in theory, versus what does happen in practice.
In practice, most people who benefit from FOSS don’t contribute, and most people who do contribute (outside of the maintainers of a project), contribute in very small and trivial ways.
The legendary bazaar is just that, a legend. A cute bedtime story for little FOSS boys and girls.
Perhaps it happens on occasion, but it doesn’t seem to be anywhere near the norm.

So, if FOSS is not really buying us greater collaboration, then perhaps it could also be true that a more closed approach wouldn’t necessarily deny us collaboration.

I like the idea of a model where costs are passed along to consumers.
So, if you write a library that depends on another library with a price-tag attached, you pay nothing.
But if somebody uses your library for their product/service, they’ve got to pay for the dependency, and potentially any price-tag you added to your own library.
I don’t think such a model would hinder collaboration, because there would be no friction between producers.

I agree that permissive licensing doesn’t draw in nearly as much collaboration as open source advertising leads many to expect. But assuming potential collaboration—other contributors ready, willing, and able to contribute—I do believe it tends to maximize output, by minimizing friction losses. Especially when contributors aren’t already affiliated in some other way that manages IP and sets process, such as a company or a foundation.

This is the model of the trade-offs that “open source” likes. It starts from a fatal assumption that we’re learning to see now: ready-willing-able isn’t cleanly separable from licensing and distribution. Licensing and distribution affect finance, among other things, that in turn affect ready-willing-able for the vast majority of could-be contributors. But I suspect the error is in extrapolating too far from a few success cases, not that it isn’t really successful for projects that work this way.

1 Like

Economic exclusion through licensing at a broad scale seems to be the most efficient way of minimizing the benefits-side problem.

I have come up with a new concept called ‘social domain’ which is an alternative to the proprietary and commons rights systems.

Coops only, NC, only and ‘ethical’ licensing do not escape market logics AFAIK but because they exclude the kind of large scale economic exploitation under the auspices of Big Tech (tacitly) they are classed as ‘social domain’ licenses.

The ‘contributions only’ licenses are I think weak… copyleft is a technical contributions only regime and what happens is Big Tech just stick one of their own engineers on the project or hire the lead developer and take over those communities… the financial contributions only licenses - like - if you want more than one seat you have to pay… don’t go much further than a kind of guild mentality… so don’t seem very interesting unless you have a fondness for medieval business models?

I will be working up this concept thru 2022 to see how far it can be pushed. The idea is to intervene in the market failure of the free and open culture movement and commons resource protection problems of FOSS.

It will be interesting to see what problems (if any) I run into.

Yes, the dichotomy is false from a political POV. It’s a bit like a shoes salesman asking you if you want the shoe in brown or black, deliberately omitting the most obvious choice… which is whether you want the new shoes at all.

I mean to me, the answer is obvious, programmers imagine themselves to be above money. To a first approximation it’s even true; we are well-paid as a class. But the two groups we have share in common a hostility to money.

Free Software considers itself a political movement, they are at best ambivalent about money and to some extent hostile to it. Moreso if you read their documents critically

Open source is usually a strategy to promote some standard (that someone will benefit from in second-order effects). Again charging money is hostile to that objective.

The group whose preferred strategy is to charge money is indie developers. We’re out there but not in large numbers and not with good PR. Depending on how stubborn we are it may make sense to align with a larger group rather than do our favorite thing.

I suspect the ‘organizing, adminstrative, and legal’ costs of these convoluted strategies to be falling. “All you need” is some DAOs or whatever, those are organized for dumber reasons already and represents the kind of larger movement you want to hitch a wagon to. That headache is a huge problem for people who buy software on invoices. But it is zero problem if you don’t care about receiving income and you just think it’s funny to troll accountants at facebook. I suspect that’s a substantial untapped constituency.

2 Likes

This critique can be fleshed out a little further if needed. Programmers do imagine themselves to be above money, but this is not as straightforward as simple hostility to money comforts. This affective response is well documented in the literature on professionalization, (recommend: [1]M. S. Larson, The rise of professionalism: monopolies of competence and sheltered markets. New Brunswick: Transaction Publishers, 2013.). The exemplary case being the medical profession. The motivation is to create a class barrier to entry… a ‘sheltered market’ and is typical of the middle social layers (petite bourgeois) that have to convince moneyed upper classes and disadvantaged lower classes that they can be trusted in order to flourish. It’s a classic virtue signalling strategy based on the classic dichotomy between ‘gentlemen’ and ‘mercenaries’ from the Victorian era still being played out today and thus is very much an internecine battle for social advancement and the economic benefits that go with prestige.

I also believe that Free Software and Open Source both consider themselves political movements, in the sense that they are hostile to each other only from the perspective of the Free Software ‘gentlemen’ vs. the Open Source ‘mercenaries’. I say this because both are of course in thrall to free market fundamentals, the idea that the market will dictate what survives and what goes extinct.

I think the only difference between Free and Open is the orientation. Free tends to emphasize ethics (gentlemen) whereas Open tends to emphasize function (mercenary).

Charging money may inhibit early adoption and network effects to dictate industry convention, however money is generally the driver of those conventions using tricks like <choosealicense.com>, SPDX and other behavioural nudges available through DevOps platforms like GitHub.

Indie developers fall into the Open Source orientation economically, but also require the professionalization techniques of prestigious engineering fields, such as credentialling and so forth.

Escaping the middle layers involves either riding a Unicorn to accomplish extreme levels of wealth through venture capital, or else securing work for hire permanently and thus becoming a member of the worker aristocracy… well paid and well rewarded but dependent on work for hire until we retire, which in some cases can lead to radicalization around new ways of working such as coops and unionization rather than bourgeois professionalization strategies that are likely to triumph under the current direction of travel of the world economy.

It would take a critical rupture in consciousness of the mass of tech workers for any of this to change substantially IMO.

As always, everything boils down to dumb status games between people :frowning:

I’m not sure if they are really ‘dumb’ (as in, ‘insensitive’/‘maladaptive’/‘excessive’ and so forth). There are abundant examples of preening / competitive / territorial aggression having evolutionary advantages in biology - but from the perspective of straight political economy I agree, it’s a terrible set of conditions to have to overcome when it comes to efficiently distributing a physical resource like information - before we even get to the excessive and intense allostatic load and so forth all of this tiresome behaviour places on both the arbitrary ‘winners’ and ‘losers’ which has as much to do with historical privileges won through group conflict and violence rather than any individual merit or talent.