Okay, so here's my take...
First of all I want to thank Aryeh for taking the time to write out the
original mail in the thread. You've obviously done quite a bit of
thinking. I realize there has been discontent and even concern with the
way things have been / are between Foundation tech staff / paid
contractors and "everyone else" on the volunteer dev side of this
Project upon which we all toil. Aryeh, your mail was a well articulated
instance of those feelings.
I'm not going to deconstruct your suggestions; I actually agree with
several of them (although I think you'd find the reality of flagship
open source projects somewhat different than the legend). Instead I'm
going to make a more general statement about why and how we're trying to
shape our future efforts...
As I came into WMF, the UX project was still in full swing and we
decided not to interrupt their momentum until the Stanton Grant was
finished. I focused my efforts instead on planning for the new Fiscal
Year's budget and hiring plans and on observing the work patterns of the
existing Tech staff, the expectations and needs of the Programs staff
and the community interaction dynamic. During most of this time I've
been close to silent on public lists because my opinions were still in
formation. I figured there was nothing worse than somebody rushing in
with a lot of uninformed blathering.
Gradually I decided these were the most serious problems (in order of
importance) to tackle with a new design WMF Tech:
1. Eliminate single points of failure / bottlenecks
2. Reconfigure into teams designed to encourage faster (shorter
duration) and more accurate projects / deployments
3. Develop programs to encourage / grow volunteers into paid
staff...recognizing that as a non-profit WMF needs to plan for more
frequent turnover in the Tech department to ensure that we can grow
expertise across the dev community rather than concentrating it in a few
core people.
4. Restore the balance between community-led and foundation-led efforts
so WMF feels again like a partnership rather than concentric circles of
permission / blame
Once I recognized these objectives, I started working out how to reach
them. Notice that they are in order of importance above...starting with
hiring / training / documenting and otherwise creating redundancies to
mitigate the SPOF problem (in Operations to keep the sites functioning
for instance) is a big focus of the hiring plan for this Fiscal Year.
Fully 1/3 of the Tech hires in this fiscal year are SPOF related.
Item 2 is necessary to again make us very productive (as at least one
respondent on the current thread believes we should be given there are
"more of us than ever before"). Experienced developers know that more
hands aren't necessarily better unless you can modularize work to form
small agile teams within the larger structure to get discreet bits of
work done. The Linux Kernel team does this, and Apache projects are
implicitly organized this way. Most of the expense of this re-org hits
in the next fiscal year (hiring engineering program managers to help
teams stay undistracted and productive and to maintain an overview so
discreet bits of work add up to the correct whole), so this year about
1/3 of the Tech hiring will serve this item.
But the crux of Aryeh's original email is not about the first two items
on my list...it really rests in items 3 and 4.
It is my belief that the Foundation can not and should not plan to fund
or achieve most development projects cathedral-style. To do so would
not be consistent with our founding principles (and in any case wouldn't
be possible given our resources). At the same time our Projects have
grown in both complexity and popularity to the point where we can't we
solely expect volunteerism to provide for all needs.
There has to be a partnership...not a detente. To that end it is clear
we need to improve transparency and afford more opportunities for
participation and cooperation between paid Tech staff and the volunteer
developer community. We need to undertake this shift with realistic
expectations. We are never going to be interested in every scrap of
volunteer engineering ever undertaken, but we are going to take steps to
make it easier for volunteer engineers wishing to contribute to figure
out what contributions are sought and how to gain increased
responsibility in our essentially meritocratic community (which is how
Mozilla finds their new paid staff as well). We're going to create more
entry points and to get volunteers more involved. In this fiscal year
1/3 of the new Tech hires are in service of items 3 and 4...
If you're still reading, then you must really care to know what I
think. Thank you for that. Mostly I wanted to share that re-balancing
the volunteer-to-paid staff dynamic is definitely a first-year priority
for me, although its not more urgent than establishing a new primary
Data Center and making sure we have staff to keep the site running...but
its coming. We're going to co-create (or re-create it). Like all work
of digital "intentional communities"[1], its going to take work on all
sides to get it right...and I hope you'll help.
Danese Cooper
CTO, Wikimedia Foundation
danese(a)wikimedia.org
[1]
http://en.wikipedia.org/wiki/Intentional_community