The initial title for this article was "Why the Apache model sucks". It would have been a catchier title but would taint my arguments with triviality. But it was the first title that came to my mind and you should be aware of that.
I have written about Apache in the past past and the present post is a rehash with a slightly different emphasis. Before laying further criticism at the altar of the "Apache Way", it must be mentioned that Apache is one of the most open and transparent organizations I know of. Transparency comes at a price. If one is allowed or even encouraged to voice criticism, the voices of the critics may drown the successes of the organization so that the state of affairs may seem bleaker than it is really is.
On the other hand, an organization can be wildly successful even if some of its governing rules prove to be counter-productive on the long run. As a very extreme example, in the Ottoman-empire, one of the most successful and relatively recent empires in history, whenever a new sultan acceded to power he would proceed to kill all his brothers. Not only fratricide was authorized, in the absence of clear succession rules other than the survival of the fittest, the people actually expected the new ruler to kill all his brothers so that the strongest ruler could emerge. The rulers who chose to spare the lives of their brethren were accused of not getting the Ottoman-way. Suleiman the Magnificent went as far as killing his own son Mustafa after bogusly charging him of treason.
One of the the core tenets of Apache is meritocracy. If Apache is a meritocracy, it is a lousy one and this has consequences. If some developer, say David, shows interest in some Apache project, say Prokayotae, and contributes by submitting patches, or by responding to users on the mailing list for a period of time, usually three months or more, then he will be awarded committership. As Prokayotae committer, David can veto decisions of the project – yes, that is veto with a 'v'. After a few years of good behavior, David could even be co-opted to become a member of the Apache Software Foundation. Being a member is a nice honorary title but does not carry further entitlements at the project level. As a member David can indeed vote for the Apache Board during elections but that is mostly inconsequential at the project level.
Coming back to Prokayotae, the newly elected committer David wields the same voting power as Carol, who has been actively contributing to Prokayotae over several years. In most cases David will be a reasonable individual who play nice and will naturally defer to Carol's and other committers' opinions by virtue of common decency and their past involvement in Prokayotae. However, while most new developers are reasonable individuals and make every effort to play nice, some people are less reasonable. Even a modestly successful project will have over a dozen committers elected over its lifetime. Thus, the probability of electing an "unreasonable" individual increases over time, and I'd venture to say, approaches certainty.
Let Ursula be such an unreasonable person elected as a Prokayotae committer. Ursula maybe otherwise a nice person overall and a valuable member of the community she lives in. But, as a fervent believer in Thor, one night Ursula has a dream where Thor ordains her to oppose the pernicious influence of Carol over the Prokayotae project. Of course, the motivations for Ursula's opposition to Carol may have origins other than Thor appearing to her in a dream. The potential reasons are innumerable. It may be as simple as a design principle lambda that Ursula reveres but which Carol reveres less.
Invested with this new mission in life, Ursula begins to challenge Carol by vetoing her commits or merely intimating that she will veto them based on the lofty lambda design principle. Were Ursula's objections patently silly, she will be revealed as a fool. For example, invoking Thor's appearing in her dreams as a justification for her opposition will expose her to ridicule. However, any reason which is based on some apparently reasonable pretext, often adherence to a lofty principle, provides sufficient cover for long-term disruption. Every developer knows that the IT industry can claim more than its fair share of high and often contradictory principles. Ursula will make convoluted arguments, misrepresent facts and argue endlessly. Given that each new commit takes ages in endless arguments, further development in Prokayotae will be severely disrupted and may even cease.
Carol who has invested heavily in Prokayotae and got along well with the other developers may be shocked and ill-prepared to deal with Ursula's disruptive interventions. Carol may be further shocked to see other committers sitting on the fence with respect to Ursala's arguments cloaked under an important design principle such as lambda. At this stage, Carol must tread with utmost care because she formally has the same voting rights as any other committer, including Ursula. If Carol dares to claim that her arguments should carry more weight in light of the volume of her past contributions, she will immediately lose her credibility.
The Apache culture aggressively enforces its egalitarian model. Carol, even if she effectively led the project for several years, is not allowed the title of project leader or project manager. Author tags in source code are also frowned upon with the Apache board having formulated a statement discouraging their use. Hints at unequal merit are met with condescension and/or alarm.
As a result, if Carol tries to explain the injustices of the Apache way she will be branded as clueless and subsequently ignored. Being ignored is Apache's equivalent to being ostracized in the pre-Internet age.
As most people who face injustice and have a choice, Carol will leave Prokayotae as I have left log4j to start the SLF4J and logback projects. Leaving log4j was one of the most traumatic experiences of my life. Trustin Lee, of Netty and Mina fame, had an analogous experience. He apparently could not bear to see his work being vetoed over a triviality.
Those favoring the current voting system, while recognizing its lopsidedness, argue that letting everyone having an equal voice fosters communication between developers. Admittedly, the current set up is conducive to collaboration as progress can only be achieved after reaching consensus. As a corollary to this line of reasoning, letting all arguments be heard and all objections raised at every step of the development process must surely lead to best possible software.
Unfortunately, in the absence of a fair conflict resolution mechanism, having lots of ideas floating around emanating from different people does not lead to the emergence of the best software design insofar as it promotes bickering and political paralysis. In such a system where development can be easily disrupted, it is not the best ideas that win but the ideas advocated by those possessing the most stamina.
Instead of trying to learn from past failures which open discussion is supposed to encourage, Apache forges on in the path of egalitarianism. As time passes, I see attempts at institutionalizing egalitarianism instead of recognizing its inherent injustice. For the sake of a bogus ideal, the Apache-way expects selflessness on the part of the developer in the same way that the catholic church expects celibacy from its priests. If egalitarianism is really at the core of the Apache way as an absolute value, then the Apache way sucks. Yay!
While the one person one vote principle applies to a democracy in order to run a country for the benefit of all, the one committer one veto principle is ill-suited in a purported meritocracy such as Apache. If it must be "one committer one veto", then the word meritocracy cannot be honestly ascribed to Apache. It it would be most appropriate for the ASF to stop misrepresenting itself as a meritocracy, at least not without clearly defining the meaning of merit.
The Apache culture fails to recognize that project participants may have drastically different investments in a project. Allowing a person with near-zero involvement in a project to hold the same weight as a person with 10'000 hours of investment is to date an essential part of the Apache-way. According to the prevailing Apache culture, if you don't completely agree with this premise, body and soul, then you just don't get it.
I hope that this blog entry will incite OSS organizations, including the ASF, to adopt fairer decision making procedures. If that does not happen, before joining such an organization, developers should at least be aware of the inconveniences associated with lack of fair and orderly decision making mechanisms at the project level. If knowing these inconveniences, a developer decides to join anyway, then it will be the result of an informed decision.
31 comments:
I love the way you tell that story, even though it's a sad one at its core.
I think the number of active committers makes a big difference, on a large enough project you will always find enough folks to see beyond Ursula's smoke screen and speak up.
Smaller projects have a harder time, the edge case might be Carol, Ursula and Boris who's a friend of both, but maybe not deep enough in the code to see the fallacies of Ursula's position.
All in all, I tend to agree with you that egalitarianism can be a problem in smaller projects. But measuring the merit of someone in a finer way that "committer or not committer" in a fair way would be quite hard.
I agree with Bertrand's point.
Also, it is necessary to be careful not to ascribe too much power to the votes themselves - they are only a tool for gauging consensus, which is the main objective. I've seen groups that are both too afraid to (lovingly) use a valid technical veto to prevent code that wasn't good enough, and those that get bogged down using it on minutiae.
I would say equal control is important, but that individuality, expertise and leadership are important to maintain. The group has to be built on trust and respect, not equality of vote - it is when that breaks down that it falls apart. It becomes a problem when people want to put control above reaching agreement (whether they are Carol or Ursula, and whether they are doing it for the right reasons or not), and this is possibly what is mistaken as requiring "equality". In an environment where the model is working well, committers will understand each other's strengths and weaknesses and base their individual "equal" decisions on that knowledge.
That said, more projects have likely imploded because of individuals or a core group that monopolise a project than the other way around (where in most cases, they can be more easily weeded out early). It is understandable that the Apache model pushes against that strongly. The trick is not pushing that too far.
Yes, given enough time, patience and continued engagement with the community, any fallacious argument can be overcome -- which is actually quite a valuable piece of advice.
As for merit, it could be measured in a finer way than 0 and 1 (committer yes/no) by taking into account the number of commits made by a given committer. A person who has made 1000 commits should have more of a say than a person who has just made 2 commits. The playing field could be leveled by pondering the number of commits by some asymptotic function having a large value, say 100 for 0, and asymptotically approaching 1 at infinity. This would have the effect of favoring committers with a small number of commits so that they still retain substantial voting power.
I reckon all governance models suck in some way, trick is to find the one that sucks least.
I think merit is being used in two ways here. One is a person has earned merit - and, thus, committership. The other is an argument's merit. Whether an argument has merit or not is independent of the person presenting the argument (and how many commits they have) and is up to the community to decide... eventually. For example, in my first month hanging out on apache lists, I effectively voted down two release candidates. I hadn't personally earned merit, in an Apache sense, but I presented an argument against two release candidates which had merit. Talking about votes as "power" instead of, as Brett says, a way of gauging consensus is a fair warning sign.
Bret, can you please expand on "more projects have likely imploded because of individuals or a core group that monopolize a project".
First, you omit to tell that a committer veto does not stand, unless he is member of the PMC. Being a PMC member requires that the other PMCs members vote the candidate in.
This will protect a project from ungrounded vetos.
Second, vetos are rare. But when one is issued, may be it's time to stop and think. May be it's a string signal that the process has derailed, and that either the one who vetoed is wrong, or the one being vetoed is wrong. It's up to the PMC to discuss this point.
Don't get me wrong : as soon as a veto is issued, a lot of pain is inflicted to the one who has been vetoed (at least, ego is wounded). We have to move on and try to understand what's going on, get out of this as fast as possible.I see vetos more as signal that something is wrong and should be discussed.
Last, no least, of course you have pathological behaviors, but with more than 70 projects, 2700 committers, 300 members, and tons of over developed egos, it's pretty normal to have tome frictions.
We are just men, not gods ... (sigh ...)
As a geek I've been per force side-tracked by #SocialPathology. (I.e. in SigInt I went from interdicting Soviet assets to, "'scuze me, but that's a democratically elected government we're over-throwing."
So it was ... comforting, to find your narrative here.
As with such as LiveJournal "Disuss" (where folk don't!) so with dev communities.
Aspects of bonding (affection, manifestations or rank, various sorts of loyalty) can quickly draw strong lines. Threatening or even questioning those lines quite normally becomes evidence of disruptive attitude along with a whole constellation of personality problems.
The social dynamics that give rise to our present economic and political situation (macro) also determine other instances (micro). Software creation isn't different. Though it might provide a platform / venue for looking at how we are who we are (on the odd chance that some might care).
thanks for this
@bentrem
Your "being ignore ~~ ostracism" reminded me of what I tweeted coupla weeks ago re: "blocking is forever".
Agreed that the downside of an egalitarian meritocracy is showing to be the triumph of égalité over merit. An interesting counter point to the downside of the benevolent dictator being the turn to the dark side (see recent Xoops history).
Sadly number of commits won't work; you can get just as frustrated at a -1 from someone who fixes hundreds of javadoc and import statements, than from the occasional committer. You also have to define how long respect lasts - an active coder coming back after a few years and finding they no longer get to drive the project.
So no solutions, but agreed on the problem. The committer notion does not map to the need to retain merit.
Finding a very good solution may take some time, this does not mean shouldn't improve on the existing approaches to voting in OSS projects. As I tried to show, the current 1 or 0 approach while it promotes consensus building is otherwise grossly unjust.
The ideal merit based system should be based on merit. But merit is not so easy to define in software. So I'd be willing to settle for a weaker concept of "engagement". For example, the first commit on a day earns the committer 1 point, subsequent commits earn the committer no additional points. Zero commits on a given day earn the committer zero points.
So committers C0, C1, ..., Cn are attributed to c0, c1, ..., cn commit points per their "engagement". In order to favor consensus building, the voting system could be titled in favor of committers with fewer commit points. However, for committers Ci and Cj with ci and respectively cj commit points, if ci > cj then Ci's vote carries more weight.
Here is a possible formula: Vi = (C/ci)+1)*ci
where Vi is the voting points awarded to Ci on a particular vote. C could be some arbitrary constant. However, varying C with the number of voters and the total number of commit points seems to give very interesting results. Thus,
C = Sum_over_all_committers(ci)/Number_of_committers
Another possibility is:
C = Sum_over_all_committers_voting(ci)/Number_of_voters
I should now mention a key optimization in the voting process. If for a given subject everyone agrees then there is no need to count voting points. If there is opposition, it may still be possible to seek consensus by further discussion. It is only after it appears that no consensus can be reached that the weight-adjusted voting system is employed.
It would be fairly easy to build a tool that calculates the voting power of each individual by looking at the source repository. Once the ci are known, a spreadsheet could be used to compute/verify the voting results.
Ceki,
as good as your proposal sounds, it's doomed to be a failure.
Look, you are trying to fix a marginal social issue (ie, having a sociopath with over rated ego in the team) by using math.
It's like because you see a pimple on the skin of a beautiful girl then this beautiful girl is not worth the time unless she goes through plastic surgery...
Just face it !
I mentioend the vote weighing formula only to show that it is possible to come up with a better solution than a 1/0 switch. I am not particularly keen on the math.
The quesiton of voting powers and its relation to meritocracy is essential, not marginal. As the number of committers increases over the lifetime of a project, it is not just probable but almost certain that a person with a disruptive personality will be elected as a committer. Having a disruptive personality does not necessarily mean having a unbalanced personality let alone being a sociopath. It may be as benign as not getting along with another committer.
Instead of pretending that personality clashes never arise or that disagreements can always be solved in a timely fashion, Apache should recognize that its voting system is seriously lopsided. By valuing all contributors equally with total disregard to the extent of the contributions, it devalues all contributions and ultimately the contributors as well.
I don't mean disrespect but your reaction is reminiscent of cult-like abandonment of the self to the ideals of the group. Think about it.
Ceki,
what I mean is that you can tweak the voting system as much as you can, you will still have disruptive personalities (sociopaths or not, that does not matter).
The ultimate question is : can we continue further without being blocked by a veto, if the veto is with no ground ? The answer is yes, absolutely.
First, if the veto is not shared by the team, it should not stand. The board is like our supreme court here.
Second, if the veto is backed by a few people, say more or less than half of the PMC, then there is a serious problem that need to be discussed. But we are not dealing with a disruptive personality here. This is more or less "democracy in action". Again, at the end of the day, if there is a need of a decision, the board could help.
Last, if no decision can be make, then a fork is possible. This is obviously the worst case.
Don't get me wrong : it happens, it's not funny, and it often ends with someone quitting the project. I don't know anything about your own experience, but it's devastating for the ASF and for the leaving person. Now, I just wonder if more diplomacy, and less ego put in the process could help here ? I really don't know...
Nut I still consider that this is a very rare situation, and such a situation can be mitigated without having to set a new voting rule. I would rather ask for an intermediate group of "wise" people, being able to decide if the veto really stand, and on which base.
ATM, I consider that such a dispute can be discussed at the board level. Don't you think so ?
The board is usually too far away from the problem domain to intervene with the required finesse. On the other hand, if the issue is of a more general nature, then their interventions can be more constructive.
As you know, software development frequently involves making technical compromises. It follows that there are countless opportunities for contention. In the current system, those most prone to contention can be those least exposed to the consequences. The current system is so grossly lopsided that any change that takes into account the effort of contributors would be an improvement.
So we are converging to something less dramatic...
Yes, compromises are necessary, and yes, every time you make a compromise you may lose something. But also consider every time someone came with a better idea than the one you had in mind, and this better idea saved the project from a bad decision...
It's not a perfect system though. Having admitted this, and I think we both do, you are proposing a solution based on a system that ponder each one 'weight' on their own merit.
Question : how do you evaluate this merit ? Number of contributions? It won't work. For instance, we have a committer on my projects who is dedicated on the build system and code cleaning. His number of commit is very high, but does it make him have a better insight on what's going on in the guts of the project ? Good question ... (note that, yes, I consider his option as valuable)
So whatever system you will set up, it won't fit perfectly. I prefer having a control on who is entering into the PMC after having controlled not only that the committer really has some merit, but also that he his able to smoothly collaborate with others. It's all soft skills we are talking about, with a lot of interactions, team building etc.
At the end, sometime ego is too strong, and it does not work, and we have to make some move that save the project.
Not easy...
Yes, measuring merit is not exactly easy. This does not mean it can't be measured at all or that imperfect measures are useless. One simple measure is the number of commits. To avoid micro-commits, the count could be limited to one commit per day per committer. Such as a count would measure the degree of consistent involvement in a project, but not necessarily the quality of that involvement. In order to measure quality of the contributions, the commit count could be supplemented by a human-based voting system as currently operational at stackoverflow. Another possibility is to let code analyzers to judge the complexity of the contribution grant points accordingly.
In my opinion the commit count with one point per day limitation would already be a huge improvement over the all-contributors-are-equal-regardless-of-merit approach.
A poisonous person is always bad for a project. A poisonous person has a malicious agenda which isn't in line with the well being of the project.
But that doesn't mean you dealt with a poisonous person. He/she maybe simply didn't want things to change.
In the log4j case, the success and merit of slf4j clearly shows that you were very correct to change things.
Although I agree, that in a perfect world, you, as a creator and very active committer, should have a bigger vote, I don't think the system can be improved by some mathematical formula. Any decision system should be clear and simple. The apache model has the weak spot of a poisonous person. The benevolent dictator model has the weak spot that the dictator can become mostly inactive (but doesn't want to give up control).
But there is a much more important issue: Because of the political mess, most people (especially managers) don't know that slf4j = log4j 2. They don't know that is is the natural evolution. By losing the "apache" brand, and by losing the "log4j" project name (and maybe by not having the apache license), the slf4j project is being limited in its growth.
Can we change that? Can/should we convince apache to accept slf4J as log4j 2?
IMHO The first words on the slf4j homepage should be "slf4j is a logging framework and the natural successor of log4J". The words "natural successor" should be a link to a page explaining that you created log4j and were it's most active committer and that log4J is dead since 2006.
Keep the message simple: "slf4j is log4J 2". The logo alone doesn't show that message enough.
PS: keep up the good work on slf4J :) Thanks for not giving up after the log4j ending.
It's simple: If the community cannot resolve a (usually very rare) veto - it's broken. Dealing with people means finding compromises - no matter how much investment you have in a project. In an healthy community investments and contributions are valued and respected by the community members. Problem like you are describing are very unlikely to happen then. So I am not sure this really is a general problem with approach itself. A good leader leads without power or title.
But I agree with the other comments. The size of community also comes into play here.
I think the previous comment made by "anonymous" nicely summarizes the current line of thinking prevalent at Apache. It assumes total surrender of autonomy by the community members to the community. As I tried to argue above, lengthy conflicts are quite likely to arise over the lifetime of any project. Putting people's feelings aside, compromises do not necessarily result in the creation of better software, on the contrary. The developers who are at peace with their surrender of autonomy may cope with conflicts without much suffering in the same way that some members of the catholic clergy can nicely cope with abstinence. Adopting a fairer voting system taking into account the number of commits made by each developer (limited to one point per day) could potentially allow the ASF to run more smoothly and to scale better. Otherwise, it would be more appropriate for the ASF to stop misrepresenting itself as a meritocracy.
It is so sad that you've missed the most important lesson that the Apache Way can teach you ... you, or me, or anyone else, is not always right.
Consensus building is hard ... it's a skill somewhat different than being really good at software ... but in the real world it is actually more valuable to the world. It is my hope that up and coming open source developers will remember that building *anything* larger than a small one-man project is more about team buy-in than it is about technical brilliance.
If you win *solely* because your vote counts more than others, you've already lost.
Yes, over a variety of topics, no one is consistently right nor consistently wrong -- that includes individuals, organizations and even nations. Getting things right happens over long periods, sometimes spread over several generations.
Yes, consensus building is hard and that having a consensus buildier may be globally more valuable than someone who is just good at writing software. But software writing and consensus building skills come in gradations. Every committer should seek to build consensus but if for whatever reason consensus is not reachable, there should be a decision making mechanism other than let us argue until someone drops.
You are right to observe that imposing a decision on the basis of voting power will have chilling effects but so does imposing decisions based on stamina.
I am not a specialist but it looks like the problem is coming from the veto power, no? No one should be able to veto.
Being a voting member through meritocracy is one thing but from this point on, the process should be democratic.
If one wants to challenge a commit they should only be able to call for a vote.
Let's state it again : ASF Veto is pretty clearly explained on http://www.apache.org/foundation/voting.html.
Typically, the *only* veto that stands is the code change veto.
And even then, the following sentence limits its power :
"To prevent vetos from being used *capriciously*, they *must* be accompanied by a technical justification showing why the change is *bad* (opens a security exposure, negatively affects performance, etc.). A veto without a justification is invalid and has no weight."
So in any case, I don't see how at The ASF someone can spoil the project up to a point it's unmanageable.
All in all, it's about managing egos. Not that simple ...
PS : I'm *not* saying that Ceki is responsible for this situation. Sometime, it's better for your 'mental health' to quit instead of fighting ghosts. Life is too short :)
It all comes down to the concept ownership...
Is it "your code" or is it "our code". This ASF strives for the latter, simply because for long term sustainability, that one "lead developer" could go away at any time, and the codebase and project could die. By encouraging the concept of "our code", the project survives the ebb and flow of individual contributors.
I assume that by "our code", you mean code developed by a community of developers in a collaborative fashion. Fairer rules for decision making do not preclude collaboration, on the contrary.
Just to jostle your conscience, GitHub/SourceForge/GoogleCode/CodeHaus ask a lot less of software developers in terms of compliance with procedures than does the ASF. If you discount the personal relationships a software developer may or may not have within the ASF, then developing software within the ASF may actually not be worth the trouble. Besides its responsive infrastructure, the only perceptible attraction of the ASF is its overvalued brand. Overvalued because good software is just as likely to be successful outside the ASF. The ASF's essential promise is that of a community but now that the tribe has grown substantially, there is a larger distance between those who make the rules and those who have to live by them. So you darn better make good rules.
By the way, for those who don't know, Jim Jagielski is the current chairman of the ASF.
Jim, I virtually tip my nonexistent hat to salute for your efforts running the ASF and putting up with our collective crap. Wouldn't it be nice if there was a tiny bit less of it?
Less crap? Yes! Please!
BTW: Believe it or not, the "word verification" for this post was "pooman"
I kid you not!
You should take it as a divine sign corroborating the thesis advocated in this blog entry.
I have not seen a veto stand based only on a design principle. Design principles, by their very nature, are trade-offs and therefore decided by majority opinion (no veto allowed). If it seems that a design principle you don't agree with, particularly an obscure one, is being imposed as a veto justification, then make the group vote on adherence to the principle itself (again, a majority vote).
The fact of the matter is that newbies do not have equivalent veto power over a project as the primary developers. Anyone who has been downstream of one of my vetoes can tell you that. The more merit you have within a project, the more people will listen to your arguments even if they are not backed up by a specific vote. For the same reason, more people will follow you (if you let them) if a valid veto cannot be resolved and you choose instead to fork the project within Apache. And, in any case, a truly poisonous person can be removed from the team the same way that they were given access.
Ultimately, there is a cost associated with any agreement to share power. You benefit if the tasks you don't want to do are taken care of by others, and also by learning from the viewpoints and experience of others. They benefit by being exposed to your work, experience, and critiques. If you can't get more benefit out of that one-to-many relationship than you are giving up by not being a dictator, then you probably shouldn't be doing the work at the ASF anyway.
The world has plenty of open source hosting sites. Apache is a lot more than that, and has a good reputation in industry because of its community-induced reliability and longevity.
Oh, and just to be clear, the specific veto cited in the Mino project was invalid and later rescinded. It is unfortunate that the social issues had already escalated to the point of no return before a more experienced Apache person could get involved.
It is not the principle itself which is in doubt but its applicability in a given context, especially in presence of conflicting considerations. As such, reducing the argument to the principle itself would not help to resolve the argument.
Since you mentioned others' reactions to your vetos, consider that when you intervene you typically do so rather late in the debate when the other participants are already pretty exhausted. They might be tempted to seize whatever coherent or event half-coherent argument they can get hold of, especially if stated with some authority.
Coming back to the main point, newbies formally have the same veto power as the other developers. And as you know, there is no such thing as a "primary" developer according to the Apache culture. If reasonable decisions can still be reached, in my view, it is not on account of Apache's decision making processes but in spite of them.
As for sharing power, pondering veto rights in some proportion to each committer's investment in a project does not prevent sharing of power but fosters a more just way of sharing it.
As for Apache being more than project hosting sites, keep in mind that Apache imposes more on its projects. If the rules being imposed are unjust, isn't it the obligation of the foundation to seek to improve the rules?
I believe the only way around this human factor is automation.
How would you measure a developer's contribution automatically using a version control system? Lets assume 10 developers committed their code to the same branch and you need to give them voting rights proportionally to their contribution but you don’t want to bother with code review. How just by looking at the changes they made you can calculate their contribution versus other’s?
I believe the only way to bring some justice to voting power is to automate the contribution merit calculation.
Lets assume 10 developers committed their code to the same branch and you need to calculate their voting power proportionally to their contribution but you don’t want to bother with code review. How just by looking at the changes they made you can calculate their contribution versus other’s?
Post a Comment