Who Decides?

Mitch posted another installment on his weblog, in which he said:

http://blogs.osafoundation.org/mitch/000033.html

"[H]ow to keep moving along with the product definition while still
benefiting maximally from community involvement? On the one hand, the
more high-quality input and debate about the product the better. To
paraphrase Bill Joy, most smart people don't work in your own
organization. On the other hand, decisions must be made, and voting,
even if it is non-binding, isn't the way to go. Some successful open
source projects have solved this by having a Benevolent Dictator for
Life (Linus Torvalds for the Linux kernel, Guido Rossum for Python), who
is respected, sets general directions, and makes final calls. I'm
honored that I've been proposed for this on the design mailing list, and
I accept. So now my head is really on the chopping block. Respect has to
be maintained and earned through action. I hope I'm up to it."

Ok, now that the siren-call of democratic development has been put
behind us, and Mitch has accepted the role of BDFL (Aside: maybe we
should come up with a new title? How about 'Grand Poobah of the Loyal
Order of Water Buffalos' (GPLOWB)?), we can discuss what the OSAF needs
to do to help the community help them.

A big problem (as noted by Warner Onstine
http://lists.osafoundation.org/pipermail/process/2002-November/000006.html) for many open-source projects sponsored by corporations is a sense that the corporation is a black box, the inner workings of which are impossible to divine.

Now, as a non-profit corporation, the OSAF could certainly 'open the
books' and publish everything, from board meeting minutes to finacials,
but that's not what I'm talking about here.

I'm talking about the org-chart.

A number of people are listed on the OSAF website, along with titles and
job descriptions, but there is little sense as to who reports to whom,
or what parts of the platform and application are being worked on by
which people.

Now, obviously the community is (and wil likely remain) very
unstructured and fluid. But we're a 'smart swarm', that will apply
itself to the points where it can do the most good.

Right now, the folks from the OSAF who have interacted with the
community on these mailing lists are (I think) the most senior people
there (Mitch, John, and Andy). While this is great, we're going to need
to talk to the folks who are (and will be) writing Chandler's code. Are
they not allowed to come out to play? Something I've noticed in a few
other corporation-sponsored projects is that interacting with the
community was something the developers were supposed to do on their own
time, not during work hours.

There are a dozen decisions made every day by someone writing code. I am
not suggesting that every decision needs to be run by the community for
feedback, as that would slow development to a crawl, but besides a
record of the decisions made (in CVS), we also need to get to know the
people making the decisions. And not just the big decisions, but the
little decisions too.

So, who decides?

Cheers,

Michael Bernstein.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Process" mailing list
http://lists.osafoundation.org/mailman/listinfo/process