I think we need to overhaul the way open source software is maintained, or rather, how the authority to update modules is allocated.
Currently, if you wrote and publish a module, you get a name, and can update that name to point to a new thing. There are bunch of cultural expectations around that, such as not changing it to a completely different thing, etc etc. Also, that you'll fix problems or at least respond etc.
I don't think I need to go into any detail about the problems with this... but I will.
This system makes a module (name) into "property" - and maintaining it as your "job"... but it lacks most of the benefits of property. Such as the ability to dispose of it as you wish, transfer, sell, etc. Imagine if buying a car meant that everyone in the village got to drive it. Suddenly if you didn't keep it fully maintained that impacts everyone not just you... I have been burnt by this and just writing this is stressful.
A more experienced open source user understands this as a problem and may be more respectful of the holder of authority over a module but these expectations are also a necessary adaptation to life in such a system.
If everyone uses it and only you can fix it... now everyone's problem is your problem.
Some people respond to this by backing away from the idea of modules, they check in code, or copy and paste open source into their repo... I think this is a huge step backwards. The ability to use open source is great, and the ability to install it as modules is fantastic.
But what we need is a way to model these shared resources created at one point by an individual, then gifted to the community.... as shared gifts
Features I think a system should have
- immutability. released code just is. you can't update a hash.
- publish should not imply a later update.
- no pull requests (that is, to an authority)
- publish instead of pull request.
- anyone can merge. merge just combines multiple gifts and regifts again.
Just distributing code via content addressed blobs would give you all that already. There is nothing technically challenging here.
But this wouldn't be very useful as is. Just being able to install any git commit is too many possibilities to deal with. You need a way to constrain and bring the better hashes to the surface... you need a way to install updates.
Computers are the most modern of technology... but why are we, working with computers, continually wrestling with the past? Everything is legacy and often resembles fudalism. It's often argued that the printing press led to democracy. It makes sense, you need to to print voting forms, and also newspapers so that that people have some idea who they are voting for... shouldn't it follow that a far more efficient communication technology could produce some sort of super democracy? yet the tech world seems to have gone the other way. Instead it's been used to move in the other direction into a command and control system driven by surveillance. I think this is all wrong and we should actually try and build a democratic system and also that software development tools is the right place to start. Firstly, there is a dire need to make decisions that affect many people. Secondly, there is no current effective system that needs displacing. And Third, as life becomes increasingly computerized, politics will just become software development - so we can head them off at the pass.
So what should updates be like?
Well, I think that any situation where someone expresses an opinion should some sort of update. For example, when someone posts "+1" on a pull request thread, that can be them actually merging, and switching to the update stream including that PR. Or a one-off bump ahead, that will be overwritten when someone you have subscribed to updates their position (prehaps to merge that change themselves)
+1 is often construed as a "vote" but a vote in a democracy as traditionally conceptualized means you have a some set of candidates, and then some set of voters, and a single, most popular candidate is selected, and considered to represent all voters. Not everyone has voting rights. Often, only some classes of people are entitled to vote (such as land-owning males), but usually it's citizens or at least residents. There are many cases where many people are affected by a vote, but not entitled to participate in it. For example, US presidential elections effect the whole world, but only US citizens can vote.
The other problem with this conception of democracy is that there is a single winner. Voters who wanted someone else do not get properly represented. In some systems, the single most popular candidate may win, but if there are more than two options, the majority may have wanted anything but that.
In any case, it would be not practical to allocate voting rights like this for decision making in open source because it's not easy define the people who should be entitled to vote, and if enable anyone to vote, it's easy to manipulate. However, in this case, it's not necessary to have a single winner. Code is not like a physical object that can be possessed by one person or another. You can just have multiple different versions of a project with different leadership. There are clear advantages to having everyone using the same thing (economy of scale) but forcing everyone to use the same would be mean an unrepresented minority.
So, I think "votes" are bad and "subscriptions" are much better. You still get the benefit of representation, but without creating a disaffected minority, and it completely sidesteps the problem of allocating voting rights.
Anyone can vote, but their decision is not forced on anyone. This also means that the election cannot be stolen by creating phoney voters, it may look like you have a large crowd of supporters but it does not affect other people who have subscribed following their own preferences.
All that I need to figure out is how it works exactly. I think the basic premise is that there is a subject to decided - which is a sequence of shapshot hashes. Then you can give pick a hash your self or delegate weighted votes to any number of proxies, and also pick a quorum threshold.
From my experience as an open source developer I know that sometimes you want to be extremely conservative, because you value security or stability (only make decisions after multiple highly trusted parties agree) but other times when you want more people to be free to make changes, because you value the benefit of rapid improvements (so maybe delegate to multiple people, but allow any one of them to make a new decision)
With just weighted votes, it's easy to calculate a transitive delegation, but threasholds make it a bit more complicated.
The other puzzle is how to identify "subjects" the classic ssb way would be to have a root message that refers to the subject, then "replies" to that, but a project may evolve towards being run my multiple completely distinct groups of delegates... so I feel that this isn't fluid enough.
An alternative is to refer to the snapshots themselves, and to say "this supercedes that"... call this "commits over branches"
this was originally intended as an essay not a design so I'll stop here, hope you get the idea