Hi David, On Sun, May 3, 2009 at 6:54 PM, David Pollak <[email protected]> wrote: > ...My expectation is that the ASF has experience building open source > projects... not just the code, but all the pieces that go into making the > project a living and thriving thing....
Looking at the list of ESME mentors: yes, those guys all have experience with the various aspects of an ASF project, not just code. However, IMHO, there's no "The ASF" here. The ASF as a whole is not going to help build ESME - that's the responsibility of the ESME community. What the ASF does (via the reports that you seem to snicker at in your blog post) is to keep an oversight on all of its projects, to make sure they are run according to the ASF principles of meritocracy, legal oversight, etc. The technical and community aspects of an ASF project are the project's responsibility, and the board of directors avoids interfering with projects unless it is absolutely inevitable. For a podling like ESME, the Incubator PMC is the entity that keeps oversight, and acts in the same non-interfering way. Here is the original mission statement of the foundation, as it stood on our original home page: The Apache Software Foundation exists to provide organizational, legal, and financial support for the Apache open-source software projects. Formerly known as the Apache Group, the Foundation has been incorporated as a membership-based, not-for-profit corporation in order to ensure that the Apache projects continue to exist beyond the participation of individual volunteers, to enable contributions of intellectual property and funds on a sound basis, and to provide a vehicle for limiting legal exposure while participating in open-source software projects. Nothing says "the ASF will create new projects" or "the ASF will build communities". The ASF exists to "provide organizational, legal, and financial support", that's it. Now, the incubation mentors are usually happy to help with the community building aspects of podlings, but as Gianugo quite rightly says mentors are usually not proactive in this. It's like coaching a band that's about to start playing live: it's the band members who are going to be on stage once the show begins, not the mentors. Unless the band members actually start playing something (even if that's initially out of tune and out of style), mentors will just sit here and wait. The role of ASF incubation mentors is described at http://incubator.apache.org/guides/mentor.html, if you have a look there's nothing about code or community building in there, the (minimal, I agree) role of mentors is just to allow the ASF to "provide organizational, legal, and financial support" for the podling once it graduates. > ...So, let me enumerate what I would have expected you or other people in the > ASF to do/not do in order to incubate ESME: > > - Do an analysis of the overall needs to the project to succeed in terms > of user adoption and increased contribution. No, I'm not expecting a > full-on market research project, but identifying (or at least asking the > questions to help identify) what it would take to move the project to the > next one or two levels of user and developer adoption... Mentors won't do this, unless ESME can grab out attention based on our personal itches. And ESME could as well grab the attention of any other experienced ASF members who could help with that, mentors do not play a special role with respect to those project needs. Yet, we had a good discussion on this in the "state of ESME" thread beginning of March (http://markmail.org/message/yryr4ld7mm7friq2) where me and Robert Burrell Donkin (not a mentor - an ASF member who became interested in the project, scratching his own itch), among others, gave advice as to how ESME can progress. People have been listening, and things have been happening, but just real slow, for some reason that the mentors can't control and don't really care about - the speed of progress entirely depends on the people who are actively involved in the ESME community. > - Do an analysis of the existing team and the existing project leaders > and figure out where the strengths are and where the weaknesses are and work > to help the team leverage the strengths and find folks to augment the > weaknesses. The ASF is driven by meritocracy, not by analyzing teams. What people contribute to the project will show their strengths are weaknesses. Someone might be a strong coder in one project, take an evangelist role in another, and just be a time waster in yet another project that they're not following closely enough. > - Understand the projects existing interaction patterns and work to meld > the interaction patterns with the ASF's best practices. I've been doing this at the beginning of the project, trying to (gently) steer interactions so that everything happens on the mailing list, code is committed to the ESME subversion repository, etc. In the last few weeks I got the feeling that not much was happening in ESME, so didn't do much. Again, mentors are not proactive, and I'd prefer the project to fail early if it's not viable, so I switched to wait-and-see mode. > - Set milestones for retrospectives with the project's leadership to see > where things are and how they can be improved, as well as criteria for > cutting the project loose. Did I hear you say "monthly incubation reports" ;-) Podlings report to the Incubator PMC monthly in the first three months, then every three months. From the podling's point of view, the (hopefully collaborative) creation of the report is an excellent point in time to ask the above questions. And that's one thing where mentors are expected to help, so feel free to grab us. > ...So, an aside. I think that together, Anne and Dick have a tremendous > amount > of potential. Anne is amazingly charismatic, has a ton of people she knows > and has a bunch of really good vision about the power of social networking. > Dick is one of the best process people I've worked with. He has a good > understanding of technology, but an amazingly deep understanding of process > and the benefits of applying process to technical projects. He's got > a phenomenal touch with respect to herding cats along the process path > (although my experience is that his touch manifests itself better verbally > than in writing.) Anne and Dick have a great working relationship and > communicate well with each other. Together, Anne and Dick are a great > combination and have the potential to deliver a ton of value to ESME and to > the ASF more broadly. But, it's going to take work on someone's part to > help guide Anne and Dick through the differences between their world and the > open source world. It's going to take some investment to unlock the great > value that Anne and Dick have to deliver.... Teaching those differences to Anne and Dick will happen as the project progresses - if you guys can get a few coders interested enough so that something actually starts happening in a collaborative fashion in ESME, the project will have to do releases, make technical decisions, bikeshed on names, argue over the project's vision, etc. That's where the learning happens, but again mentors have no obligation to teach individuals how open source work - mentors are here to help the project as a whole. About Anne and Dick's potential - seen from the project's point of view, it's all about meritocracy *inside the project*. You'll find many CTOs, entrepreneurs, CIOs, and geniuses active in the ASF, but within their projects they are just normal contributors and community members - until the value that they bring *to the project* makes their peer recognize them as someone special *for the project*. That's how it works here - I'm not trying to downplay Anne and Dick's role or qualities in any way, just using that example to try and explain how things work here. > > So, with that set-up, let me outline what I expect from you and/or the ASF: > > - Understand that Anne and Dick are the leaders and drivers for ESME. That's not the mentor's role, we want a self-sustaining and self-organizing community. > - Learn more about the strengths that Anne and Dick have as well as their > weaknesses (e.g., not a lot of open source experience) Not the mentor's role either, though personally I'm not *that* thick, so yes I gathered that from our exchanges within ESME. No problem with that in general, but how can you want them to be leaders while saying they have no experience? > - Understand (as Erik pointed out on my blog) that Anne and Dick are not > coders and working on what help they need based on that fact. All the ASF projects that I know of are mostly (95%) about code. There's space for non-coders to play important roles in projects, but only if some coding is happening. > - Understand that ESME is an end-user application and that differentiates > it from most of the ASF's offerings and work with the ESME team as well as > the ASF's leadership to figure out what, if anything, needs to be changed in > ASF process to accommodate this difference. I'd say the ASF's way of working is more suited for infrastructure projects than end-user applications. This could be the most important realization of this thread, that some parts of ESME might be better off outside of the ASF. Food for thought only though, at this point. > - Identify that the momentum slow-down ESME has been suffering since > joining the ASF as a serious problem and help the project leaders deal with > it. Can't help if no questions are asked, and in the abstract there are no "project leaders" in ASF projects, all committers are equal and decisions are made by consensus and voting. In practice, every committer can be a leader for some part of the project, that's the cool thing. > - Once there's reasonable momentum back in the project, figure out how to > retain the momentum and enhance it. "The ASF" will not help for that, ESME has to build a self-sustaining community if it ever wants to graduate. Mentors can probably help steer it, but we don't have that magic community wand. >... I expect real analysis and work on the part of the ASF. This is the kind >of > value that the ESME project needs. Are my expectations way out of line?... As the above shows, yes, I think they are mostly out of line. The analysis work can either happen by someone sponsoring analysts to work on ESME, or by the ESME team getting ASF folks (not necessarily the mentors) interested, which needs some initial momentum to happen. Hope this helps. -Bertrand
