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