Log in

No account? Create an account
Mentoring and Incubation at the Apache Software Foundation - Nick [entries|archive|friends|userinfo]

[ website | gagravarr.org ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Mentoring and Incubation at the Apache Software Foundation [May. 25th, 2010|03:54 pm]
I'd like to give my personal view on the Apache Incubator, and how I see my role as a mentor of an incubating project with that. This post explains my views, and while it ought to chime nicely with official policy, there might be the odd error, and so this isn't official foundation policy. But first, a bit of history on how I ended up mentoring a project.

I've been using Apache software for a very long time now, and I'd guess I first played with the webserver back in something like 1996 or 1997, which seems a very long time ago.... I'd say I first properly got involved in Apache with POI when I started with Torchbox. A check of the archives shows I first started contributing patches back in 2003. I stayed around on the POI list after that, contributing more patches and helping out with user questions, and then in 2005 everyone had got fed up of committing my patches without changes, and I was granted committership.

In 2006, I attended my first ApacheCon, and had a great time whilst learning lots. In late 2006, I was elected to the Jakarta PMC, and discovered a whole new world as I learnt about PMCs, the board, how the ASF works and so on. This didn't put me off, and in May 2007 I helped POI leave the Jakarta umbrella, becoming PMC chair. At the 2007 ApacheCon, I'd gone to lots of foundation related talks, and began to learn in detail about "The Apache Way", which is partly how I ended up as the new POI chair. Roll forward to 2009 and I found myself giving talks on "The Apache Way", having in the mean time made member. Late last year I also joined the new Apache Community Development project, helping out with mentoring, outreach and so on.

It's been quite a long journey, from my first involements in apache, through my first commits and on to today. It has taken me a long time to learn about "The Apache Way", to really understand what it means, and get to a position where I'm able to try to help others to learn about it. It's really great to be able to stand up in front of an audience, and talk to them about open source, open development, and apache-style open development, and see that moment when someone gets it, understands part of why it's so powerful. Well, I say stand in front, but quite often it could just be sat in a pub, or even on the grass in a circle, enjoying the Irish sunshine!

Since starting at Alfresco, I've also become involved in the Apache Incubator, and I'm currently a mentor of the Apache Chemistry incubating project. Having explained how I got here, I'd like to look at what I think this role of mentor involves, and using Chemistry as an example.

Firstly, what isn't it? Well, I'd say a mentor isn't a committer. Sure, a mentor can also be a committer, and it's great when that's the case. However, I'd see those as two distinct roles, and you may sometimes need to switch hats. It's great if mentors can commit code, since it helps ensure that if there is any pain from the incubation process, one of the mentors quickly feels it too, but I don't think it's in any way required.

What is in the role of mentor then? I'd say the most important, and over-arching role is to teach the podling (incubating project) about The Apache Way. You can't do this in one go though (see above - it took me at least 4 years to get to the point that I was happy enough with my understanding that I could pass it on!), but you need to be trying to pass it on as and when you can. Partly this means watching the mailing lists, and offering insight and advice when things happen. Or don't happen. Possibly especially when the don't happen...

Within the incubator, various things need to happen whilst the project is there, and others before graduation can occur. As a mentor, you need to help everyone understand why they need to do something, as well as helping them do it. For example, the requirement that as much as possible of the project's communications should be on-list, and off-list things should be relayed back. It's no good just saying "no", you need to explain why, explain what gets missed if you don't, explain the benefits of doing it The Apache Way. With Chemistry, the big test for this was with in-person meetup in Munich back in March. Many of the committers were there, but certainly not all. I explained on-list beforehand why it was important to keep the list updated, then spoke again about it at the meeting. During and after the meeting, everyone who couldn't make it seemed very happy with how it had worked out, and how their views had been included. We also now have a record of those discussions to check back on if an architecture question surfaces again in future. Overall, it seemed to work well!

Three things that often cause issues within the incubator are IP clearance, releases and new committers. With all of these, the podling needs to do some work, and then the incubator PMC needs to sign off on this. Firstly in this then, the role of the mentor is to help the podling do the thing right, pointing that at documentation as needed, advising them on their process, and reviewing what they've done. When everything is fine, you then need to put on your IPMC hat, and approve it. Next, you need to prod your friends within the IPMC to ensure that a quorum approves the action, so the podling isn't stuck waiting. Finally, you need to ensure that the podling understands why and how to do it, because after graduation they'll need to do the same thing again, but without the oversight, so they need to be able to get it right themselves :)

Where does that leave us for defining the role of the mentor? Overall, you're there to help the project learn the apache way, both in what to do and why they should be doing that. You should be helping them when problems come up, and trying to spot problems and head them off before they develop. You should be helping the project to do the steps needed to run and graduate (clearance, releases etc), giving them guidance, advice and voting. You should be there to answer questions. If it all works, then the closer graduation gets, the less you'll need to do, as the closer the project will be to running itself happily in The Apache Way!

One thing I should probably point out at this juncture is about in-person vs remote mentoring. You sign up to mentor the whole podling project (while ComDev do have a formal 1:1 mentoring program, the incubator is about mentoring the project), so much of that mentoring needs to be remote, using mailing lists. However, with Chemistry, I found it very helpful to also have a chance to meet and advice many of the project committers in person. Much as the ASF is a global organisation with proceedures and a way of working that handles everyone being disparate and remote, some parts of teaching the Apache Way work best in person. That's partly why I've helped set up the Local Mentors Program (aka take a new contributor out for a drink to help explain the whole thing to them). With that in mind, I'm tempted to recommend that where possible, at least one of the mentors meets at least some of the committers at least once, probably ideally at an Apache BarCamp or conference.

There are many different ways to run a project, be that an open source project or a closed one. I'm a big believer that open development is the right way for many projects, but I'm also fairly well aware of the cases where it may not be the best. This isn't a post about project management and methodologies, though buy me a beer and I'll happily talk at length on the subject! Instead, I want to finish off with my view on why the Apache Incubator exists.

Within the ASF, all projects should be running to The Apache Way. Now, the Apache Way doesn't cover everything, just certain key areas, so each project is free to make their own decisions on how to do many things. It's part of the beauty of the ASF that different projects do try out different things, and share what works well, even if sometimes this leads to a week of discussion on members@.... However, most projects outside of the ASF don't run to the Apache Way. So, for a project to join the ASF, we need to ensure that the licensing is correct, the IP is properly cleared, and that the project runs itself The Apache Way. That's where the Apache Incubator steps in.

So, my view of the incubator is that it's somewhere to do the IP clearance, it's somewhere to sort out licensing and dependencies, but mostly it's a place to learn the Apache Way. Projects come in, they learn, and then the choose to either tweak themselves to fit the Apache Way, or they say "no thanks, that's not for us" and leave to go on their own way. Seems simple enough, doesn't it? :)