Democracy in Open Source: Yes or No? (+ Our Research Proposal)
modeling-languages.com
modeling-languages.com
The key point is freedom - your freedom to do whatever you like with the code, and the creators freedom to do what they like.
Authored a popular project and haven't felt like working on it for 6 months?
No worries, somebody will fork it and take over the development. Or create something better.
It baffles me how hurt some people get because they had an issue closed without a resolution or a PR rejected because it was out of scope of the project's roadmap.
In the bigger picture, projects that don't aggressively maintain high standards of quality AND continue to improve are as good as disposable.
Though, if more people adopted a fork and build your own, we'd probably have more people involved in open source.
Then again, Darwinism really has a group that progresses together, not lots of little forks of individual development. You need some form of merging things back together at some point, otherwise you end up with tons of incompatible derivations of the project.
I wasn't implying starting from scratch. Rather fork and continue where the upstream project left off as long as there are no hard license restrictions.
Sometimes, a merge never happens due to neglect or the unwillingness of the maintainer to cede control and grant push access.
One specific project I've used that follows this pattern is NodeFTPd. It's a ftp server written in node. I use it to run functional tests on my node-ftpsync project because mock ftp servers don't exist for JS.
It is now 4 layers of forks deep since I started using it. Each added considerable improvements on top of the previous fork. It's one of those dependencies where I'll make the extra effort to check the network graph before updating to see if any of the derivatives are approaching or have surpassing the fork I'm current using in popularity.
Apparently, a FTP server is an extremely valuable application despite many devs failed efforts to manage the project over the long-term.
The real issue is central repositories like NPM/Bower. I had one dev fork a project of mine to host on GitHub because it was on Google Code at the time. He then registered his copy on Bower before I had a chance to. So now, not only is it hosting an outdated copy but I physically don't have access to update it.
For all the dev's huffing and puffing about how he was going to take over the project in my absence He made approximately 3 minor commits (which I later merged) and disappeared from the face of the earth.
"Seek freedom and become captive of your desires. Seek discipline and find your liberty." ― Frank Herbert, Chapterhouse: Dune
Just issues with users who demand it...
I would love to see the results/conclusion of this research. We would finally get some data-backed insight into why/why not democracy is good for a software project.
Seriously, the amount of basic misunderstanding of all things not programming related here on HN is starting to get to me. I can't read these threads without being compelled to correct such obvious errors. If you don't know what you're talking about, at least phrase it in a way so that it comes across as an opinion, or better yet, research before you type. It's ruining the quality of these threads.
I think it's simply because this approach is more prone to abuse. A good dictator leaves democracy in the dust in terms of efficiency, but converesly a bad dictator can make everything go to shit at moment's notice. In economy/politics, it's a matter of life and death. In open-source software, the risks of dictatorship don't matter - someone can always fork the project off and do it better, but even if not, no one is starving or dying because of it.
Your thinking is underlined by assumption there is one correct solution to arrive at. But maybe that's actually rarely the case.
* The theorem doesn't directly apply to decisions between more than two outcomes. """
Additionally, it does not take into account the cost of making the decision, which, under direct democracy, rises quadratically with the number of people that must debate and agree to the decision.
I think you would find, if you have n options, one of them is the correct one, and there is slight bias towards the correct one among the decision-makers, a similar theorem still holds (from the central limit theorem).
Regarding the transaction costs, this is a different issue, but I would say that is an issue in any project regardless how things are decided. Nothing in the theorem itself requires the people to actually communicate, they can just become biased towards the correct solution on their own.
It should be also noted that, in the real world, people can decide not to take the vote if they don't feel qualified to decide, further improving the results of the theorem.
(I actually rediscovered the CJT myself when I was interested in how democracy works.)
I think it would be nice to try this on college students, give them some knowledge test (or perhaps two - one in their area of expertise and the other outside their area), and compare the best individual results with the interpretation of the results through voting. I haven't seen anybody trying that, but I think many people would be surprised how well it works. :-)
You are making too many simplifying assumptions. One of these is that the decision-making process involves a simple up-or-down vote. That is rarely the case in complex discussions. Instead, as the number of folks who can bring up additional points for debate or an n+1th option grows, the length of time spent debating grows quadratically unless there is some procedure (For example, a presiding officer who can cut off debate) to stop it.
> I would say that is an issue in any project regardless how things are decided.
This is definitely incorrect. Decision procedures have a massive impact on how long things take to decide. I have empirically observed this. Student organizations at my university had a word for it: wanking. It was incredibly common at student group meetings.
What I meant was that the quadratic transaction costs apply to any large scale project anyway, because no one can fully understand it. In other words, I see the longer debate as a sign of project complexity, not choice of decision making process.
I agree that bad procedures can lead to indecision, but it's not different from indecisive leader really.
In fact, I think it would be bad to select this "leader" according to his expertise; he should rather be selected according to his ability to produce good consensus by incorporating those different inputs. However, we already have procedures (such as voting) that do that and that we can understand; why then bother selecting a person to do it in a black-box fashion?
In short, if you can reliably decide who is an expert, you can also reliably decide the issue itself. If nothing else than by following the expert in his opinion.
Presumably, if the leader is an expert in the field, that person should be able to recognize a good idea, even when it comes from somewhere else.
I am sorry, that's what he effectively does. The more other person is an expert, more likely is he to agree with the leader if he made the correct choice. You seem to think that good solutions are somehow unpopular but that's contradictory (unless there is somebody acting in bad faith). The best solution actually has the highest probability of being the popular one (otherwise the probabilities of the experts are incorrect).
> Presumably, if the leader is an expert in the field, that person should be able to recognize a good idea
This is exactly what I said. You say "presumably", but it is an assumption.
The point is, you don't actually need him. Everybody can voice their opinion about the best solution, and then they can have a vote. If you think it through, this procedure encompasses your proposal too, because your proposal is just a special case where they all follow (in the voting phase) the opinion of the person they agreed on. And the restriction that they need to agree on the person doesn't help you any.
But that aside, as I already explained, this is pretty easy to do with voting. All that's needed is that everybody (including the leader) voices their opinion. The people who feel that they are not qualified to make the decision can just vote for what the leader would vote for.
Maybe what you mean is that there is a person A who thinks that person B should get no vote, because they are not qualified enough (or perhaps that some other person C should get more votes, it's a similar deal). But this is already reflected in the "objective" probability of B making the correct decision. So either A's opinion agrees with the probability (through his own probability to make good judgement), in which case it doesn't matter. Or, it disagrees with the probability, and then following A's opinion can only make the result worse.
We could have elections and let elected experts to act unsupervised for a period of time, use liquid democracy (where you delegate your vote when you're not involved in a certain decision),...
"GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Over 12.4 million people use GitHub to build amazing things together."
I mean, it doesn't use the word 'technical' once!
Also, I agree that experts are not always right, but they are right in overwhelmingly more cases. Which is practically "always". The small number of times an expert is outright wrong, is a risk I'm willing to take.
I wasn't taking issue with the proposed decision making mechanism. I was taking issue with the idea that there are purely "technical solutions". In math, the most intangible of disciplines, I was taught that when working solving an open problem, the most important question to answer will always be, "So what?" It's easy to come up with novel but trivial proofs all day long. If you can't explain why the new proof is important, then, so what? Go play with Legos.
If such an intangible discipline requires some justification part of its most foundational task, then surely there must be some broader justification in software development. And I'm being specific when I use the term 'software development'. It's not like we're talking about computer science or applied mathematics.
Software development builds things that are to be used by end users for a purpose. There is plenty of room in software development for non-technical perspectives, and non-technical discussions will never be black-or-white. Often a software development project with be built specifically for a non-expert. In that case, to say that the end-user "should not necessarily be ignored" is such a bad tenor to be set for the discussion.
Last, I'd like to mention the idea of a do-ocracy, which is what many OSS projects have organically turned into. In these cases, the technical expert and the novice alike can do whatever they want, because folks will either choose to work with them or not. But in a do-ocracy it's not likely that someone will be forced to do something they don't agree with or at least sign-on-to.
If you want a "buck stops here" set-up, then go to a company that has a hierarchy or pay people to do what you tell them to do. But otherwise, there is no Utopia where programmers can go write whatever software they want and that others will be required to use without getting to share in the decision making process.
There are a handful of counter examples floating through my head. The BDFL model can be described generically as willing collaboration among peers where one ultimately has the power to control the project. The strongest example that comes to mind is bands. A band can have a very similar model, they - like open source - can also have a project structure nothing like a BDFL.
Cleary, not something we would accept in any other community aspect of our society.
This is also kinda funny to me because if we make a theoretical BDFL more controlling than we expect from an average Open Source BDFL, we accept this model for collaboration _all the time_. It's called "management." What's not funny is that this is the premise is treated as axiomatic by the researcher.
Software can be millions of times more complicated than building blueprints. Why in the hell do you think democracy will work for software when it doesn't work for office buildings?
Contrast this with the way open source development generally proceeds. A single developer (or maybe a few) create a software project as the core team. They are the experts for that project. Other people can make suggestions and contribute, but it's up to the core team to decide if something meshes with the vision they have for the project.
What if someone disagrees? They can simply fork the project and try out their own vision. They are the expert of their own project.
This has some amazing consequences. First of all there can be multiple winners. Project A can be very popular, yet project B, which caters to a minority, can also exist and serve people with different needs and tastes. Second, it allows parallel experiments of multiple ideas, which encourages rapid innovation to take place. Finally, it helps minimize conflict between people, since you can join or start a project that meets your fancy without penalty.
Contrast this with democracy. In a democracy it's winner take all. Majority vote determines what everyone has to live with. This creates conflict and intense competition (including bribes and corruption) to get majority vote. It slows innovation because things can only be done one way at a time, whichever way was popular. There can be no single vision, everything becomes a huge contorted mess. It's hard enough to architect software with a single vision.
You should be doing research on how to make politics more like the (multi)governance of open source development, not the other way around!
I haven't seen that, so it's hard to imagine (and I would thus reserve my judgement on that). But I have seen comedy governed by democracy, and it's not as bad as you suggest: https://en.wikipedia.org/wiki/Monty_Python But I do agree it's a mish-mash. :-)
Anyway, I think it's hard to make the OSS model work in politics. In politics (and other fields), you are severely resource constrained. However, in OSS model, anybody can fork the code on their own system.
There are obvious downsides as well, but history seems to show that the benefits outweigh the downsides for this type of model.
No need to imagine it; it exists: the new span of the (San Francisco) Bay Bridge
"Democracy is two wolves and a lamb voting on what to have for lunch"
No, it isn't. You cannot put democracy itself to a "democratic" vote, that's a version of Russell's paradox.
In particular, deciding who gets to vote, even by voting, isn't democratic. The democratic decision must be potentially reversible.
So how should we make non-reversible decisions?
You can make them however you want, for instance by voting, they just won't be democratic.
The idea of democracy is to give everybody the same voice in decision making. There are different mechanisms to achieve that, direct voting is only one of them. Other mechanisms are consensus, random selection and representation. Each of the mechanisms has different strengths and weaknesses and should be used to decide different things. You can also combine them to an extent, for instance you can randomly select members of a jury who then decide by consensus.
But this won't really work with the legislature, because there we have all kind of incompatible ideologies. There is simply no consensus possible with the contemporary ideologies (socialism, liberalism, conservatism, etc.) by their very definition. If you insist on consensus, your decision making process will simply deadlock forever. How can you ever unlock it? By shifting to a almost-consensus aka direct democracy.
Consensus can work but only in a very small groups. That's why I explained that there are different methods to achieve democratic participation and have different trade-offs.
I don't think ideologies are big a problem for direct democracy. I think they are artifacts of representative system, where you have to choose a package of things, rather than when you can decide each issue in isolation. From what I heard, that actually happens in Switzerland - since everybody is sometimes in a minority in referendum, people don't take losing as a big deal.
If I were a developer, I wouldn't want to work on things that the vocal/voting people want to use. I want to work on the topics that I like. Even if the participants voted on something, it is not binding to anybody.
I'd have to really dig into the proposal but I don't even have time to fully absorb that blog post. I'll try to expand on this after work if I still give half a damn.