Having the right people in the right places pursuing the right goals is key to Gentoo’s success. Keeping in mind the Pareto principle (20% of the effort produces 80% of the results), I’ve come up with some ideas. The core of these ideas is creating a development community composed only of top-notch contributors and putting the entire Gentoo project into a cycle of continuous improvement, from the bottom up.
Each team and project should have goals. A good goal is SMART (Specific, Measurable, Attainable, Relevant, and Time-bound). That means “Maintain foo packages” is a poor goal, because you cannot answer it in a quantitative way and it has no time limit. One example of a good goal is “6 months from now, 90% of new bugs will be closed within 2 weeks of their report.” Another example is “3 months from now, 100% of our packages will be bumped within 1 week of release, or a bug will exist describing why not.” Progress toward goals should be checked once a month by the team lead and reported to the project lead (or to the council, if no project lead exists).
Each team member should have goals. The performance of that contributor in the context of that team should be measured. People who aren’t up to the team’s high standards (measured by failure to meet goals) should receive coaching from the team lead. There should be a concrete plan for improvement, committed to by both sides, for how these people will reach the high standards they aren’t hitting yet. After a plan exists, failure to improve within 3 months will result in their departure from the team. At the team lead’s judgment, people may be removed without going through coaching if they are considered a lost cause. Progress toward goals should be checked once a month by the team lead.
To minimize the chance that an underperforming developer was simply not in the right place, each developer gets 3 chances to find the right place in Gentoo. Upon removal from the first 2 teams, the team lead will report what happened to the project lead (or to the council, if no project lead exists) and to developer relations. On the 3rd strike, you’re out.
Council members and project leads should take responsibility for mentoring the next generation of leaders. Just as team leads are helping to improve individual developers, so the next tier of leadership should be developing team leads into strong project leads and council members. Nobody sticks around forever, and we need to be ready for when even our most critical developers move on. It’s far better to have too many strong potential leaders than to have a vacuum that’s filled by a poor leader.
Finally, all of our goals should flow downward in a logical manner from the Gentoo mission & vision through projects to teams and individual developers. Gentoo’s perennial problem is a lack of focus. Any work that is inconsistent with our goals should be stopped, and we should rededicate our time to things that tie in with where we want to be next year and 5 years from now. To ensure this, goals at each level should be reviewed by whoever’s at the next level up to make sure things make sense at a global level all the way down, like a waterfall.
Now is a good time to re-read the Gentoo philosophy. I find it extremely powerful and compelling, and I hope you feel the same. We should live this philosophy every day in our work with Gentoo, and every aspect of our work should grow from it:
Every user has work they need to do. The goal of Gentoo is to design tools and systems that allow a user to do that work as pleasantly and efficiently as possible, as they see fit. Our tools should be a joy to use, and should help the user to appreciate the richness of the Linux and free software community, and the flexibility of free software. This is only possible when the tool is designed to reflect and transmit the will of the user, and leave the possibilities open as to the final form of the raw materials (the source code.) If the tool forces the user to do things a particular way, then the tool is working against, rather than for, the user. We have all experienced situations where tools seem to be imposing their respective wills on us. This is backwards, and contrary to the Gentoo philosophy.
Put another way, the Gentoo philosophy is to create better tools. When a tool is doing its job perfectly, you might not even be very aware of its presence, because it does not interfere and make its presence known, nor does it force you to interact with it when you don’t want it to. The tool serves the user rather than the user serving the tool.
The goal of Gentoo is to strive to create near-ideal tools. Tools that can accommodate the needs of many different users all with divergent goals. Don’t you love it when you find a tool that does exactly what you want to do? Doesn’t it feel great? Our mission is to give that sensation to as many people as possible.
I’ve run out of time for tonight. Most of what I’ve written is about forward progress rather than improving individual developers, so I’ll try to write more about that another time. I think we need know how we’re doing if we ever want to improve, so this investment into goals and thinking about performance is worthwhile. What do you think?
Striving for greatness 
Gentoo development lives from a lot of volunteers – I’m not sure whether such rough management methods are accepted widely within the dev community.
Furthermore within an open source environment you should use other methods – have a look at the linux kernel development. Everybody can post patches (eg to the lkml) but nobody is under pressure to accept/respond to such mails.
The quality derives from the maintainer princip and the BDFL princip.
This method seems to be applicable to commercial organizations with employees. Each such organization that contributes to Gentoo may apply this method to its employees to help achieve its goals with regard to Gentoo.
Each of the Gentoo contributors, volunteers as well as commercial, is motivated by and works towards its particular goals. Those goals overlap partially and are compatible, which is the reason that the contributors can work together in the Gentoo project. This form of collaboration makes the Gentoo project achieve the goals of many contributors, with much less effort than it would take each of them to create his own project to achieve just his own goals. But of course it does not mean that contributors can apply the kind of control that you describe on each other. A salary is needed for an individual to accept responsibility to do things within a deadline, or deal with the kind of coaching and rededication that you describe.
On the general side, look at Work breakdown structure in Wikipedia?
On the specific sides:
– “6 months from now, 90% of new bugs will be closed within 2 weeks of their report.”
= How will achieve this? Can we get all developers to make more active use of NEEDINFO to explicitly state to users that they need to get back to us?
– “3 months from now, 100% of our packages will be bumped within 1 week of release, or a bug will exist describing why not.”
= This one I really like. Minor change to: ‘within 1 week of release notification’, because sometimes unless we actually got looking for the releases, they aren’t reported by users. We just need to get Meatoo up and running again, add daily/weekly email reports into it or create bugs directly.
As another suggestion of my own:
End goal: No open bug will be more than 1 month away from a comment by a developer. If no developer has caused a change on the bug in a month, something is potentially wrong (changing CC or adding a dupe does not count).
Exception: bugs with explicit due/delay dates on them or dependency chains.
As the bugzilla admin, I’ve periodically gone through looking for the oldest open bugs, and tried to bump or action them myself. Given that it’s the new year, probably time to do this again.
What are your personal goals going to be?
As a prominent Gentoo developer I’m assuming you want to leverage your leadership skills and provide a rolemodel showing how Gentoo developers can excel in their areas.
Setting some ambitious goals and following through on the promises inherent in those goals are important in my opinion if you want the rest of the developers to follow this model.
Managementese aside, it sounds to me like you’re trying to force the loosely knit group of people that form an open source project into a model for a tightly controlled corporate environment. It might be what all your expensive management books tell you is right, but have you ever stopped to think exactly what makes open source projects (or more generally any project based on volunteers and free [as in beer] work) different from businesses? I think you will find that quite a few people resent the ideas you present here, mostly because they don’t like being told how to act, think and work. Having goals to present to your manager (if you prefer to call them group leads, because it sounds less enterprisey, then be my guest), goals you must follow, goals that sets stupid and arbitrary limits is not what gives people the will and inclination to spend their free time working on a project. Striving to create an environment where they feel they are appreciated and where they can scratch their particular itch does.
I think most of the technically minded people get fed up with this crap at work. Having to waste their spare time on it as well is not exactly what motivates them to work on Gentoo.
Treat people as sheep and all you will get is ‘baaah’. Treat them as humans and trust that they know what they’re doing better than you do and you will most likely be rewarded with skillful people doing skilled work. Should someone lag behind at a given point, gently nudge them and ask how they’re feeling – don’t hit them with a sledgehammer that says ‘goals! you didn’t meet them!’
“To minimize the chance that an underperforming developer was simply not in the right place, each developer gets 3 chances to find the right place in Gentoo. [….] On the 3rd strike, you’re out.”
Wow. That’s …. harsh. Gentoo is a volunteer project, isn’t it? Are new developers that easy to attract to the gentoo project?
What if the first and second strike happened 5 years ago?
This is an excellent idea. It would definatly improve Gentoo a lot if more forward planning was made and more common inter-team goals were set.
Wow. Remind me not to become a Gentoo dev. I get enough of that crap at work – at least I get paid there.
This sounds great, but I have a similar opinion to those above – it’s pretty enforceful. The biggest downfall I’ve noticed as a user is the huge gap between stable and ~arch. A few years back, gentoo was great for quick paced development; now, I have to unmask *alot* of packages just for them to work properly (xorg comes to mind). Of course, I know what stable means, but it really seems that the audience to which gentoo is geared towards has changed over the years.
Hmmm
All gentoo needs a good competitor in source base field, this will fix most of the issues in time.
Its all sound commercial business management where the paying customers pay for the admin overhead such ideas impose. I have reservations about it working within Gentoo as most software developers hate admin, so it will be difficult to sell to project leads.
Lets run a pilot project on a well defined, well publicised small team and see how they do. Start with the council. I suggest the council roll out a five year plan together with the stratergy to attain it and quarterly milestones to measure its success/failure.
I suspect it can only fail as a volunteer organisation has no compulsion to contribute at any time and when real life needs more time, contributions go down.
I have to do this goals crap at work..There is one difference there though. I get paid. Show me my check from Gentoo and I will show you goals. (And probably move on to another distro that doesn’t have such nonsense.)
Bryan,
I entirely agree with you. I intend to create and publish my own goals, and later, my progress toward them.
I think I failed to sufficiently justify my reasoning for the suggestions in this post. I’m going to write another post entirely about why I think this is important in terms that make sense to our developers, which will address the concerns of most of the other comments.
Dag:
To clarify, I’m not saying devs cannot leave 3 teams. I’m saying they cannot be *kicked out* of 3 teams. That’s indicative to me of a pattern of failure.
Mudrii,
I agree that competition will push us to improve. Looking only to source-based distributions is too narrow of a frame. We should compare ourselves with *all* distributions, which I don’t think we’re doing enough of.
Roy,
Showing instead of telling the benefits of setting and striving for goals at various levels of Gentoo can only help. I don’t think we need any kind of formal pilot project, but I hope starting with both the council at a “big picture” level and me at an “individual developer” level will illustrate the process and its usefulness.
Great post Donnie. With goals, deadlines, etc., there are many other benefits. I know I have helped several devs over the years track down and squash bugs. I’ve had a couple invites to become a dev, just don’t have the time or feel like I could stick with the commitment.
That said, I do think that being asked to help here and there do some bug squashing for a few days within herds I have involvement would be a good place to start. Some developers are already doing this. Encouraging bug submitters to submit and follow upstream bugs. I’ve been trying to go back and comment on ones that get fixed upstream so they can be closed.
I certainly have time to test and follow upstream bugs more than I do currently. Dev work takes quite a bit of time. There shouldn’t be such an aversion to spreading the work load around a bit more.
I think that it’s not planning and bureaucracy that improves volunteer based projects. It’s motivation that binds us to Gentoo (Both devs, dev to be’s). And I should say that this post will demotivate many people (yeah includes me as well) reading it, and shouldn’t have been posted before internal discussion.
Hi Serkan,
This is the most informal place I can post things, because it’s a place for me to put my personal thoughts. Internal discussion doesn’t fit the spirit of Gentoo.
It’s clear to me that we don’t share the same perspective on goals. I don’t see them as added bureaucracy but as a requirement for improvement at the large scale.
@Serkan
It’s the whole concept of only discussing issues “internally” that has really irritates me about Gentoo sometimes. Discussions should be out in the open. Voicing thoughts in public is a good thing, IMO. The secret backroom meeting strategy really needs to end.
I truly agree with Donnie that structure is a good thing. Especially when dealing with bugs. Creating more thoughtful, logical ways of dealing with bugs is what separates successful projects from ones that fail. Encouraging developers to perform is a good thing. And if I understood correctly, giving developers the tools to improve is the most important goal of all.
I agree with Donnie with the goal,vision,sla on project and long term target, that is really what gentoo need to make clear and keep in mind, that will help gentoo grow better. but I am scared that words on ‘strike’, I am here to work for fun and credit, nothing else. if we kick off all freshman, make more crap things than make great pleasure, I don’t think that will help gentoo grow.
It really sounds like you just learned some new management tool and want to apply it everywhere without thinking if it’s applicable or not, and this is exactly the job of a good manager (to use the right tool at the right moment in the right context).
As many says before, this is not going to be applicable as is in the context of volunteering job like is Gentoo.
The first point you missed about volunteers is that they contribute to the project with a specific goal which are definetely not SMART.
If you try to enforce such goals on volunters, you will just turn them away from the project, and it will be both good and bad devs. So you will be stuck with the 80/20 ratio and lost some human power.
From my real life experience, managing volunteers has nothing to do with managing employees.
You managed the later by somes methods like you showed, plus a tons of other. Yes, such tool by itself is a big mistake, with it you have many other tools to put in the field, like stress management, carreer plans, training, compensation, … Things which cannot be applied to a volunteer in a worldwide project like Gentoo.
To properly manage a volunteer, you have to first find its motivation and his own goals. Then you have to integrate those goals with the goals of the others people in the team. And with such a team you can then find the team goals and eventualy push it a little higher.
The fact is that you can manage employees by a top-down method (goals goes from top leader to employees) like the own you mentioned but you have to manage volunteers by a down-top method (volunteers have their goals which becomes teams goals).
If you failed to make a volunteer reaching his own goals, he just leave the project and move on something else which he think may help him to reach his goals.
You have to keep this in mind when trying to transfer business management to a volunteering organization.
In my opinion, a gentoo-wide roadmap would be better than individual goals for the devs. Always having a “team leader” (or whatever you call it) behind your bag doesn’t match the idea of open-source-communitys.
Take the goals as a team!
Apart from that, i agree with Andrew.
The degree of fuzzy thinking in many of these replies boggles the mind. Lack of self-discipline (both personal and organizational), leadership (both personal and organizational) and goals (both personal and organizational) are not an automatic consequence of volunteerism. Those of you who chafe at these things might consider that they are likely to be the reason you continue to get paid at that job you seem to hate so much. These ideas aren’t “corporate”, you just hear about them at work because these things are essential in an environment where competition is tough and long-term survival is difficult. The reason “open source communities” can get away with ignoring sound life principles is because often nothing of great importance is at stake (apparently). The number of projects at places like Sourceforge which go nowhere (if they even start) is a testament to this fact. The missing ingredients are the kinds of things Donnie is talking about (and the list isn’t even complete). If what you really want is complete freedom to only do what you want, stay at home. That kind of attitude has no place in any effort with a participant count greater than one. Or as Harry Nilsson once wrote, having a point in every direction is the same as having no point at all.
apart from what is already said, I wuould like to emphasize that this discussion is great example of how well new additions to Gentoo’s site works.
Great job Donnie and all others! to keep essential I’m with Roy to start with a pilot; in our situation no hurry and radical twists are needed.
I think this depends on your aims and goals for Gentoo. If you want it to become “enterprise-quality” and to take a significant step up in terms of stability, something like this could probably make it happen.
Personally, I work on Gentoo in the moments when I have time because I find myself enjoying it often – specifically, the technical problem solving aspect. However, I’m personally not interested in the kind of “paperwork” that this would entail: setting/measuring/monitoring goals, or evaluating fellow developers. I’d rather keep my time to the technical stuff. My contributions will continue to peak and fall irregularly in a way which would not be suitable in a strictly goal-driven environment.
lol Anders, thatsclassic.
I don’t baaahh!
Wow Donnie, what a tough crowd. Obviously a lot of these people have never worked for “real life” volunteer outfit. Just because you’re volunteering doesn’t mean you get to do what you want, when you want. When other people depend on you and your work, you have to own up to a certain amount of responsible, period.
Daniel Robbins made some interesting points in a recent interview. He said one of his goals for the Funtoo project was to blur the lines between developers and users, so that it’s dead simple for users to duplicate and decentralize the whole project. This seems similar to the road Exherbo is taking, elevation the roll of overlays to the point where some are on par with the main tree.
For current devs that don’t have very much time or motivation to work with others toward set goals, why not just run your own overlay? You can run your own team, have commit access to your own tree, and control your own pace. Are you so stuck on the term “developer” that you’d let the project continue it’s perennial slip? Where are your better ideas?
Please allow me to “cross-post” this comment (originally posted at Scherbaum’s blog @ http://blog.scherbaum.info/2009/02/17/deja-vu-kind-of/#96444):
I think that Gentoo has reached the state of those huge companies that struggle to grow at those same two-digit percentages they used to when they were young.
Gentoo already provides much of what you can possibly wish for — it’s the closest I can think of to a metadistribution. I don’t see any need for major restructuring anywhere or fancy new features — and I must say I’m definitely not the easily satisfied kind of person, especially with operating systems.
Gentoo is already very mature. Of course it can improve — any mastodontic-scale enterprise can –, but it won’t probably be very different from regular-paced organic growth. The Gentoo project is very broad both content- and goal-wise. If users and devs miss the attention their favorite metadistribution gets nowadays, I really believe marketing is the way to go — do we have a community manager already? Any new tutorials, business cases, success stories and stuff like this would be a great way to tell everyone outside the Gentoo community that the project is alive and well, and also VERY mature.
Back to the project, this very organic growth is a challenge: keeping the Portage tree up to date requires lots of users bumping packages and commited devs commiting those bumps. Apart from that, I believe that any specific action by any individual herd or project within Gentoo should be free to act as its members wish, and at the pace they wish. After all, devs really do it for fun.
As A feed up up windows users I spent about a years looking at Linux distro.Gentoo was to be my new os,stability, security, flexibility, portability were my reasons.Now I find out that it’s a ship without a Rutter and destination unknown.
Thank-you in advance for the learning curve,and know that your OS regardless of how you got there could have gone head to toe with other market OS.
Nogoogle
This post makes me feel a little bit nervous. I want to enjoy my contribution and not being anxious about it. Everybody ( and me as well ) has enough “real life” obligations. What I do ( and i think most devs do ) is to put personal goals such as:
1) I need to close that bug asap
2) I need to bump this package asap
but I dont want to be forced to do that. It is good to stick on schedule but you cant always succeed it. Personal goals ( to feel ok with yourself ) is the most important thing imho 🙂
To make Gentoo compare itself to all other distros is going to destroy all that is precious about it! Please keep Gentoo within its limits — source-based distros certainly have their own universe and goals. Why should they care about the rest?
What are the benefits of being source-based that you cannot get from a binary distribution?
Well, perhaps it is only me not being aware of them, but how many binary “meta-distributions” are there? Correct me if I am wrong but the power of portage lies exactly in the fact that it uses source for everything. Portage is the most powerful and diverse package management system — it contains so much software because it is source based; it contains optimizations because it is source based; but above all, its flexibility is allowed because it is source based. As I said, I am not aware of any binary distro that offers so much flexibility in terms of what you have installed on your system. There is no versions in Gentoo for a reason (I do not consider the LiveCDs seriously, and the minimal CD is not assigned any versions besides date it was assembled). I repeat my question — why does Gentoo have to compare itself with binary distros when by default it has different capabilities? I urge people not to assign goals to Gentoo — the primary purpose of this Linux distro is that it allows the user to set his own goals, and that should remain so. Take a look at Funtoo and what it is aiming to do, for example. Lack of direction? Great, more for me to direct!