No. Open source should be more like Darwinism. If you want to make a change, you fork the code. If the creator(s) likes your changes, they incorporate it. If a code base is good, it survives, if it isn't it dies.
The key point is freedom - your freedom to do whatever you like with the code, and the creators freedom to do what they like.
Or the freedom to come to the conclusion that someone else's vision is worth supporting, and choosing to devote time and effort to helping them realise it.
"Seek freedom and become captive of your desires. Seek discipline and find your liberty." ― Frank Herbert, Chapterhouse: Dune
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.
You ignore the cost savings in terms of project build and testing that you lose by going your own.
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.
Except the initial selection is done by an individual, which leads to a high chance of negative outcomes, since good ideas could be denied and bad ones accepted. Due to the pile-on nature of open source, good code could be killed early on and the contributor not survive long enough for it to included into later editions.
The problem is that only tech-savy users have this freedom. Sure, non technical users should not decide on core technical decisions but they should still be able to steer the evolution of the project (e.g. deciding what features to implement next)
I think democracy is almost the worst way to take decisions when it comes to scientific/engineering things. In an open source project, a single expert should be able to overrule the mass of users/contributors if his point is technically more correct. This is very difficult to consistently achieve in a democracy.
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.
To quote that article:
"""
This version of the theorem is correct, given its assumptions, but its assumptions are unrealistic in practice. Some objections that are commonly raised:
...
* 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. :-)
> 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)
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.
> This is definitely incorrect. Decision procedures have a massive impact on how long things take to decide.
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.
So the contributors appoint a project leader according to relevant expertise, and that leader has final authority in decision-making. But prior to making any decision, the leader solicits independent input from each contributor.
I am not sure I understand how do you think this is going to improve the probability of making correct decision.
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.
The leader is not producing consensus. The leader is choosing the best of all suggested solutions--including the leader's own solution--without regard to the popularity of any given solution.
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.
Consider the case where everyone can generally agree that the leader is qualified to make good decisions, but they cannot agree that everyone is so qualified.
OK. If the 2nd proposition holds, why do you think the agreement in the 1st proposition is correct? If they do think they are not qualified to decide as a group, why do they think they are qualified to correctly select the leader?
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.
In principle, one tends to agree with the sentence about experts overruling the mass but in fact we don't accept this behaviour in economy or any other aspect of our lives. So, maybe it's the right to do it but I'd love to have more data (and confidence) on that. Also, it's not only about technical decisions but also regarding who decides what feature should be implemented next
> in fact we don't accept this behaviour in economy or any other aspect of our lives
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.
What do you mean "we don't accept this behaviour in economy"? I believe we very much let experts handle the economy. Or are you talking about the fact that it is a widely criticize state of affair?
The Fed Chief is put there by elected officials. Same for Treasury. Same for most of the regulatory agencies. The economy is very much handled by fiscal, monetary, and regulatory policy, which is handled by individuals that are handled by elected officials.
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.
It's not like de Raadt or Torvalds got arbitrarily dropped into their positions. People effectively chose them by investing usership and development effort into their projects.
Note that I do not think non-experts should be ignored. I think everyone should be able to voice their opinion, expert or non-expert. But there should be a final authority where the buck stops, and their word should be final, no matter how many people wanted something else.
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.
You realize your first sentence is practically the definition for a democratic republic?
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 other options between unconstrained direct democracy and monarchy by someone who does not listen to colleagues. For example, a model wherein one person makes the final decision but is socially pressured to earnestly listen to the opinions of other members of the community often works well.
Exactly. Democracy does not imply that all members of the project (including non-technical users) have to vote every single decision.
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),...
Yeah, like GitHub. Can you believe how socialist their intro statement is:
"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."
While the language Github uses to describe themselves has become increasingly "social", and "sharing" and basically political, their success is backed by solid tech and innovation. All the sharing and social aspect of the website is a byproduct of the innovation and technical superiority (owed in part to git).
In fact, the one that says how decisions are taken follows a Benevolent Dictator for life model. Cleary, not something we would accept in any other community aspect of our society.
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.
Imagine a building whose design and construction was governed by democracy. The architecture would be a horrible mish-mash of whatever happened to be popular, and likely architecturally unsound and unsafe. The actual construction would be a nightmare too, since someone would have the "brilliant" idea of painting drywall before laying it so people don't have to use unsafe ladders, ect.
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!
> Imagine a building whose design and construction was governed by democracy
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.
It is precisely because of resource constraints that the open source model would work better. Take education for example. What if anyone could start a school with any standard for curriculum? It would instantly solve the arguments that happen over the democracy of curriculum we have today. It would also allow experimentation into redefining how education is done. We could easily see what works and what doesn't without having to change education for an entire state or the country. How many resources have we wasted following fads? How many good ideas have been skipped because they were too risky to implement universally?
There are obvious downsides as well, but history seems to show that the benefits outweigh the downsides for this type of model.
"Imagine a building whose design and construction was governed by democracy. The architecture would be a horrible mish-mash of whatever happened to be popular, and likely architecturally unsound and unsafe."
No need to imagine it; it exists: the new span of the (San Francisco) Bay Bridge
We're researchers trying to get funding to study how existing knowledge in political science, social science and economy can be adapted to improve open source software development. We need the input of OSS developers !
It sounds vaguely interesting what existing knowledge there is on people working for free for a common cause out of their own volition, and where democracy comes into play.
"Democracy is two wolves and a lamb voting on what to have for lunch"
Of course you can. Democracy is just the ruling of a majority of a specific group. It doesn't have any inherent "higher ideals", human rights, or whatever.
I disagree. The above condition is unorthodox, I admit, but is needed to make the definition logically consistent.
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.
I do like your idealism.
But what means "to give everybody the same voice"?
Is this about having your voice heard? Or about actually participating in a decision?
Either way, only the pure direct democracy guarantees both.
In the end you still have the rule of the majority.
What you might be looking for is some sort of equal representation of "minority groups"? We're somewhat doing this in Switzerland on the executive level and this only partially works because the executive is explicitly chosen to be very "consensus friendly" in other words no extreme (left/right) positions.
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.
It is about actually equally participating in the decision. I agree with you on direct democracy, I am big fan of it (since about 2000).
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.
What I meant is, who do you give a vote, and what do they get to vote on?
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.
Reversible here has meaning that the same group of people can come to a different conclusion later. If you exclude (or include) someone as a result of voting, then it's not reversible.
You can make them however you want, for instance by voting, they just won't be democratic.
I find myself harumphing at much of the proposal. It's not the topic itself; democracy can work in open source, and I think Debian is well served by that model. There are interesting things to be researched about open source project management, but the approach doesn't seem to face them head on, and is full of assumptions that could be detrimental to the usefulness or quality of findings.
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.
No, it doesn't mean that monarchy is better. But if you want to argue for democracy in open source projects, the lack of positive examples does merit some consideration.
The key point is freedom - your freedom to do whatever you like with the code, and the creators freedom to do what they like.