Don't Lick the Cookie!

The phrase "cookie licking" has become popular in recent years to define a pattern which can be problematic in communities. Its meaning comes from a story: Mom makes a plate of cookies, and sets them on the table for the family. After everyone has had their cookies, there is one left on the plate. The cheeky child of the family wants to have the last cookie later, but has no confidence it will still be there when she comes back, so she grabs the cookie, licks it, and puts it back on the plate, secure in the knowledge that no-one else will want to eat it.

Cookie-licking can take many forms in community projects. The most common symptom is what the Apache community calls "volunteeritis." An individual, with the best of intentions, offers to take on an important task. Being the kind of person who underestimates the effort involved, and overestimates the time they have available, however, they over-commit, and end up unable to complete the task in question. As time goes by, they feel increasingly guilty. The task is an important one, and they really feel like they are well placed to do it, but it is not getting done. After a while, they are in the unpleasant situation of needing to admit failure and renounce doing the task, or crunching it in, and potentially not doing as good a job, because they have insufficient time to do it justice.

There are other forms of cookie-licking, more insidious, and harder to identify and fix. There are a number of subtle signals that you can send out to signal ownership over things, and as a result dissuade others from doing anything which might be perceived as trespassing on someone else's territory. One of these is to include ownership information in source code. In "Producing Open Source Software," Karl Fogel describes why ownership signals can be damaging to a community in the long term:

"When people sense a "no trespassing" sign, they stay away. This results in reduced review in that area, and greater fragility, because the lone developer becomes a single point of failure. Worse, it fractures the cooperative, egalitarian spirit of the project. The theory should always be that any developer is welcome to help out on any task at any time."

Karl recommends a number of ways to avoid ownership tags in code, while maintaining a record of provenance. Another subtle signal to community members that they might be invading someone's turf is through assignment tags or other data in the project bug tracker. My colleagues Brian Proffitt and Rich Bowen both described the frustrations that part-time contributors can feel when working with full-time developers. Many of these frustrations come from a feeling that you are getting in the way. There is a busy team bustling around you, and you are getting in the way.

This does not come from bad intentions. If you are a member of a team of full-time software developers, and your team is collectively responsible for the majority of the work in a project, it can become easy to fall into a pattern of using the project bug-tracker to organize your team's work. After all, isn't working upstream best practice for open source projects?

Where this becomes problematic, however, is when you create a perception that the project bug tracker is serving your team's needs first, and the community second. There are any number of ways you can signal this--labeling issues as being in the responsibility of a team, scheduling them for a specific sprint or release, or even assigning issues to team members. None of these things prevent someone from working on an issue, but they do send a signal that it is someone else's job, and that if you start working on it, you may find someone else has finished before you are ready to submit your work.

Resolving this tension has more to do with process and communication than it does with tooling. Perhaps you should coordinate your team's work in a separate place than the project issue tracker. Perhaps you can open up release planning to give people outside your organization the opportunity to commit to tasks which your team might otherwise have done. Rather than labeling issues as the responsibility of a team, use a label for the component of the project affected. Perhaps as a team leader, you can discuss openly short-term commitments of your team members, or have them assign issues to themselves only when they begin working on the issue, rather than when they commit to doing it as part of a sprint.

None of these things will have a significant short-term effect, so it is tempting to consider that they do not accomplish anything, and that any such changes are superficial paper-pushing. Long term, you are sending a strong signal that while there is a team working on the project, you see contributors outside the company walls as important stakeholders and co-developers of the project. In conjunction with building great software that people want to use, this is a winning approach to growing a developer community over time.