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

Yes to this. I also think there should be some kind of compensation and accountability built into this. If you compare this to a democracy then the people elected are fairly compensated for their time. And maintaining a commons, be that recreational areas a the city or a software project needs to have a track record in the community they serve for this to work.

Ah, the smell of a Dominic thread on sunny Wednesday morning. So much to smell here. Politics, property, code, freedom, hashes. I don't know in what order to comment, so I'll just go random order.

I've thought about this a lot too, and @Kira and I briefly tried to do something called gitverse before I realized hahaha wtf I don't have time for all this. But the basic idea in that project was that forks should have 100x more role in open source maintenance than they currently do. Like currently GitHub (and GitLab and many others) hide the forks of a project somewhere deep in weird tabs, instead of putting it front and center. (e.g. one way would be to replace the "recent commit" link with "recent commit on any fork", which could open up a panel showing all forks)

In practice, what I've done is publish forks of npm libraries without blinking. I've done that many times, e.g. for muxrpc, multiserver, ssb-ebt, non-private-ip, react-native-audio-toolkit, react-native-image-viewing, etc.

Another tool that has vastly helped open source "consumers" maintain their own shit without bitching in issues is patch-package, I highly recommend it.

But going back to your topic, I think property is the heart of the problem. A package name on npm is property. Not in the legal sense, because it's not enforced by law (is it?), but it's at least enforced by npm's auth system. So it's property. And people have some kind of natural tendency to prefer "official" things, so they prefer to install muxrpc instead of @staltz/muxrpc, even though both are just names (property), and that kind of property is not scarce.

The other core problem is cultural. We live in a world of deep fried consumerism. When people approach anything that has a name, and which is not a person, they assume it's a service of some kind. It doesn't matter if the product or thing is free, because they got used to services like Google which do legit have customer support and come from a company who tries to work to satisfy users.

As long as we live in that world, it doesn't really matter what kind of novel system we come up with, people will still have those kinds of consumerist expectations when engaging with open source. I mentioned above that GitHub doesn't put forks front and center, and that's because GitHub users don't have that expectation, so it's not GitHub's fault directly, it's just what the world/market wants.

Computers are the most modern of technology... but why are we, working with computers, continually wrestling with the past? Everything is legacy

Because a vast majority of people are moderate conservatives who don't want things to change. Even among the dev community, soooooo many people just want to cling to the familiar.

End of post without a cohesive conclusion

So, I think "votes" are bad and "subscriptions" are much better.

Ah, forgot to comment that this reminds of "free listening" and "pull" mantras we had some years ago on SSB. And I agree, subscriptions are awesome.

But complimentary to that, I think TrustNet by @cblgh is (or is going to be) a game changer, because it reduces how much input you need from each person. In a free listening world, you have to choose all your subscriptions, but most people don't put in all the work, and if they do, they often were influenced by other folks. TrustNet automates all of this.

We live in a world of deep fried consumerism.

Totally.

I think this comes back to setting expectations. The MIT license does this pretty well in that it's pretty hands off what people can do with it and doesn't set a lot of expectations. There is definitely the cultural expectations as you say and those can be hard to counter.

you should absolutely be able to override dependencies deep inside the module tree. it would save a bunch of headaches and avoid abominations like patch-package (sorry) also.

Also, package-managers should not be language specific. It's basically the same problem for anything, but with the variation that most things unfortunately use a single namespace so that multiple different module versions within the same application are not possible. npm vastly improves on this but is unfortunately maintained as an implementation and not a well specified protocol.

@arj I think you'd want compensation to flow along the subscription/delegation channels. That way if thousands of people really want you to maintain a specific thing, you have some positive extrinsic motivation, but it doesn't create lock in.

@andrestaltz

deep fried consumerism

Yes, but you don't need to sell this to everyone, you just need a motivated niche to get started. And also, consumerism isn't very satisfying, like, no body really self identifies as a consumer, because of alienated consumption