On Fri, Sep 4, 2015 at 1:53 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
On Fri, Sep 4, 2015 at 2:33 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Wed, Sep 2, 2015 at 5:41 PM, Chris Barker <chris.barker@noaa.gov> wrote:
1) I very much agree that governance can make or break a project. However, the actual governance approach often ends up making less difference than the people involved.
2) While the FreeBSD and XFree examples do point to some real problems with the "core" model it seems that there are many other projects that are using it quite successfully.
I was just rereading the complaints about the 'core' structure from high-level NetBSD project leaders:
"[the "core" and "board of directors"] teams are dysfunctional because they do not provide leadership: all they do is act reactively to requests from users and/or to resolve internal disputes. In other words: there is no initiative nor vision emerging from these teams (and, for that matter, from anybody)." [1]
"There is no high-level direction; if you ask "what about the problems with threads" or "will there be a flash-friendly file system", the best you'll get is "we'd love to have both" -- but no work is done to recruit people to code these things, or encourage existing developers to work on them." [2]
I imagine we will have to reconcile ourselves to similar problems, if we adopt the same structures.
I guess I just don't see how you think we can legislate ourselves into having a vision. Like... we'll elect a volunteer to produce a roadmap, and then if they don't we'll fire them (accountability!), leaving us with no volunteer and no roadmap? How will that help? The Jupyter/IPython project probably has one of the the most developed roadmaps in all of open-source, since their grant-funded development model requires them to actually commit to plans ahead of time. And AFAIK the way they accomplish this has nothing to do with Fernando sitting down and having visions; it involves dragging the "core" team in front of a whiteboard 2x a year for a week, and seeing what they can come up with. And I guess we have some tentative evidence from the other thread that this strategy may work for us too... I'm not sure how useful this focus on NetBSD is, given the elephant in the room: the fundamental challenge for NetBSD is that NetBSD has no compelling reason to exist; even its old distinctive feature of being the most portable free OS (which is already an intrinsically niche appeal) has been taken over by Linux. (And Linux, notably, has always explicitly refused to have a roadmap [1][2]... it seems to be doing okay.) Nonetheless, looking at the Hannum [3] post in particular, I'm struck by how much it *doesn't* apply to us. In particular, his main two prescriptions aside from "have leadership" are #6 and #7. #6 is that the legal Foundation part of the project should restrict itself to administrative activities and get out of technical decision making; the draft governance document says "[The NumFOCUS] Subcommittee shall NOT make decisions about the direction, scope or technical direction of the Project.". #7 is: The "core" group must be replaced with people who are actually competent and dedicated enough to review proposals, accept feedback, and make good decisions. More to the point, though, the "core" group must only act when *needed* -- most technical decisions should be left to the community to hash out; it must not preempt the community from developing better solutions. (This is how the "core" group worked during most of the project's growth period.) So he has nothing at all against the idea of a "core group", he just thinks it should be competent and... basically follow the rules that we attempted to codify in the draft governance document....? -n [1] http://www.cnn.com/TECH/computing/9906/21/linus.idg/ [2] https://en.wikipedia.org/wiki/Linux_kernel#Development [3] http://mail-index.netbsd.org/netbsd-users/2006/08/30/0016.html -- Nathaniel J. Smith -- http://vorpus.org