<div dir="ltr"><div><div>Developers are user too, you know. :)<br><br></div><div>Your argument seems to imply that the developers 1) don't use their own creations and 2) have no good or original ideas of their own, and are eagerly awaiting the input of sales and users to guide their decisions. Developers aren't children in need of adult guidance.<br><br>Why would a developer make something --- in his spare time, for no compensation --- that he himself would never use? Illumos is a volunteer effort, and developers have a clear idea of what they want the system to do. The majority of Illumos developers are heavily invested in the technology, and aren't in it just for the paycheck (if they're even getting a paycheck for Illumos work). Many of them use and depend on Illumos every day. Naturally feedback from users is welcome, but you don't need full-blown governance for that, just these mailing lists and the bug trackers.<br><br></div><div>Given the choices between democracy, bureaucracy, autocracy, and adhocracy, I'd say that empirically adhocracy (Illumos) and autocracy (Linux, Node.js, SmartOS) have worked out best in open source projects. Democracy results in community schisms (Gentoo, the BSDs, all of which got forked permanently and never merged back --- even Debian got forked into Ubuntu, IIRC), and bureaucracy is too rule and process-oriented (we're making software, not mass producing pharmaceutical products). While there are some interesting sociological questions here to be answered, it nevertheless holds that we know what has and hasn't worked well so far, and we should do what has worked well.<br><br></div><div>Having said all of that I encourage everyone who is interested in Illumos or in software in general to learn to code. This 1) makes one a better human being, 2) gives one more credibility, 3) give one the ability to solve one's most pressing problems, when the other developers are unavailable due to a crisis in the data center (or in life generally) --- or due their lack of interest in one's specific problem.<br></div></div><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 11, 2014 at 11:32 PM, Nikola M. <span dir="ltr"><<a href="mailto:minikola@gmail.com" target="_blank">minikola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 09/ 7/14 06:23 PM, Nick Zivkovic wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The issue of governance has been talked about before, so I'll just summarize the decisions the Illumos community reached.<br>
<br>
Governance causes way more problems than it solves.<br>
</blockquote>
And yet, without governance, you end up having no product. And supported product is what users need.<br>
And yet, illumos does not have Any stable release yet, to form stable distros around it. (binary compatibility, anyone?)<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
happened because the founder of Gentoo, left the project and left a governing-board in his place. The Illumos community believes --- and please correct me if I'm wrong --- that those who write the code have the power to decide, to disagree, and so on. Those who are merely consumers of the code don't get much say in development decisions. Hence, there is no need for governance. Code rules.<br>
</blockquote>
This is really bit shortsighted and not accurate. Users rules.<br>
Real consumers of the code are users and sysadmins and if you don't listen what people need, 'coders' could end up coding what no one will actually want to use. (Or coding something stupid that is not designed well)<br>
<br>
It i true that coders have in reality more power to technologically decide means of achieving goals, bu to let only to coders to decide strategies and setting goals , without involving Sales, user feedback and some strategic planning, would lead to situation like you described.<br>
<br>
So 'power to the people' could also be described as:<br>
If you have maintainers of an distro and some process around it, people involved would have better chance to contribute more, by all means.<br>
As opposed to opposing organized effort.<br>
Things don't solve for themselves, but with organizing,<br>
exactly to avoid personal shortcuts in code for small goals, without bigger picture i mind.<br>
<br>
<br>
______________________________<u></u>_________________<br>
oi-dev mailing list<br>
<a href="mailto:oi-dev@openindiana.org" target="_blank">oi-dev@openindiana.org</a><br>
<a href="http://openindiana.org/mailman/listinfo/oi-dev" target="_blank">http://openindiana.org/<u></u>mailman/listinfo/oi-dev</a><br>
</blockquote></div><br></div>