s/Neary Consulting/Red Hat/g

As of May 2nd 2012, I have been working at Red Hat in the Open Source and Standards group. As such, this site is now an archive of past activity, rather than an active promotional resource.

Thank you to all of my clients for their support over the years!

Community Software Development training course

For the past few months, I have been offering a new service – a training course tailored to helping a team be effective working with community projects – whether that is engaging an existing community, or growing a community around new code. Details of the topics I cover are up on the site now, along with a link to a brochure (PDF) for you to download.

Developing software in community is as much a social activity as it is a technical activity – and engaging an existing community, like moving into a new neighbourhood or starting at a new school, can be very daunting indeed. This course covers not just the technical issues of community development, but also the social, management and strategic issues involved. Some of the questions that I help answer are:

  • What are the tools and communication norms?
  • How can I get answers to my questions?
  • Is there a trick to writing patches that get reviewed quickly?
  • How do I figure out who’s in charge?
  • How much will it cost me to open source some code/to work with an existing project?
  • How does managing volunteers work?
  • Is there anything I can do to help my developers be more vocal upstream?
  • What legal issues should my developers be aware of?

All of these things, in my experience, are challenges that organisations have to overcome when they start engaging with community projects like Apache, GNOME or the Linux kernel.

If you’re having trouble with these issues, or some subset of them, and are interested in a training seminar, contact me, and we’ll talk.

Getting people together

Reposted from gnome.org

One of the most important things you can do in a free software project, besides writing code, is to get your key contributors together as often as possible.

I’ve been fortunate to be able to organise a number of events in the past 10 years, and also to observe others and learn from them over that time. Here are some of the lessons I’ve learned over the years from that experience.

Venue

The starting point for most meetings or conferences is the venue. If you’re getting a small group (under 10 people) together, then it is usually OK just to pick a city, and ask a friend who runs a business or is a college professor to book a room for you. Or use a co-working space. Or hang out in someone’s house, and camp in the garden. Once you get bigger, you may need to go through a more formal process.

If you’re not careful, the venue will be a huge expense, and you’ll have to find that money somewhere. But if you are smart, you can manage a free venue quite easily.

Continue reading

Drawing up a roadmap

Reposted from gnome.org

One of the most important documents a project can have is some kind of elaboration of what the maintainers want to see happen in the future. This is the concrete expression of the project vision – it allows people to adhere to the vision, and gives them the opportunity to contribute to its realisation. This is the document I’ll be calling a roadmap.

Sometimes the word “roadmap” is used to talk about other things, like branching strategies and release schedules. To me, a release schedule and a roadmap are related, but different documents. Releasing is about ensuring users get to use what you make. The roadmap is your guiding light, the beacon at the end of the road that lets you know what you’re making, and why.

Too many projects fall into the trap of having occasional roadmap planning processes, and then posting a mighty document which stays, unchanged, until the next time the planning process gets done. Roadmaps like these end up being historical documents – a shining example of how aspirations get lost along the way of product development.

Other projects are under-ambitious. Either there is no roadmap at all, in which case the business as usual of making software takes over – developers are interrupt-driven, fixing bugs, taking care of user requests, and never taking a step back to look at the bigger picture. Or your roadmap is something you use to track tasks which are already underway, a list of the features which developers are working on right now. It’s like walking in a forest at night with a head-light – you are always looking at your feet avoiding tree-roots, yet you have no idea where you’re going.

When we drew up the roadmap for the GIMP for versions 2.0 and 2.2 in 2003, we committed some of these mistakes. By observing some projects like Inkscape (which has a history of excellent roadmapping) and learning from our mistakes, I came up with a different method which we applied to the WengoPhone from OpenWengo in 2006, and which served us well (until the project became QuteCom, at least). Here are some of the techniques I learned, which I hope will be useful to others.

Continue reading

Effective mentoring programs

Reposted from gnome.org

I’ve been thinking a lot recently about mentoring programs, what works, what doesn’t, and what the minimum amount of effort needed to bootstrap a program might be.

With the advent of Google Summer of Code and Google Code-In, more and more projects are formalising mentoring and thinking about what newcomers to the project might be able to do to learn the ropes and integrate themselves into the community. These programs led to other organised programs like GNOME’s Women Summer Outreach Program. Of course, these initiatives weren’t the first to encourage good mentoring, but they have helped make the idea of mentors taking new developers under their wing much more widespread.

In addition to these scheduled and time-constrained programs, many projects have more informal “always-on” mentoring programs – Drupal Dojo and GNOME Love come to mind. Others save smaller easier tasks for newcomers to cut their teeth on, like the “easy hacks” in LibreOffice. Esther Schindler wrote a fantastic article a few years ago documenting best and worst practices in mentoring among different projects.

Most mentoring programs I have seen and participated in don’t have a very good success rate, though. In this article, I look at why that is the case, and what can be put in place to increase the success rate when recruiting new developers.

Continue reading

The Lifecycle of a Patch (or: Working Upstream)

Yesterday I looked into what it means to be a maintainer of a package. Today, I’m going to examine how to effect change in a distribution like MeeGo, and what it means to work upstream. To do so, we’re going to look at how code gets from a developer’s brain into the hands of a user.

So – how can you make a change in a Linux-based distribution? Here’s what happens when everything works as it should:

  1. You open a bug report for the feature against your distribution
  2. You identify the module or modules you need to change to implement the new feature
  3. You open bug reports for each of the modules concerned, detailing the feature and the changes needed in that module for the feature
  4. You write a patch to implement the feature, and propose it (appropriately cut up for ease of review) to the maintainers of those modules
  5. Once the code has gone through the appropriate review process, it will be committed to the source control of the module(s)
  6. Some time later, the maintainer of each module will include that code in a stable release of the module
  7. Some time after that, the new stable versions will be packaged and uploaded to MeeGo
  8. Your code will be included in the next release of the distribution following the upload.

When people talk about “working upstream” in MeeGo or Linaro, this is what they mean.

To simplify matters for our analysis, let’s consider that the feature we want to implement is self-contained in one module (or related modules which release together). There are two different scenarios we’ll consider:

  1. The module is maintained by people not associated with your distribution (for example, a GNU or GNOME project)
  2. The module is maintained by people closely related to your distribution (for example, Unity in Ubuntu, or oFono in MeeGo)

We will also look at a third situation, where you find and fix a bug in the software you are using – that is, a released version of a distribution (the proverbial “scratching an itch”).

For each case, I will try to pick a representative feature/patch and follow it from developer through to distribution to Real Users.

Continue reading

What’s involved in maintaining a package?

An interesting question was asked on a MeeGo mailing list recently: What does it mean to be a maintainer of something? How much time does it take to maintain software? It resulted in a short discussion which went down a few back alleys, and I think has some useful general information for people working with projects like MeeGo, which are part software development, part distribution.

Are you maintaining software, or a package?

The first question is whether you are asking about maintaining something in the Debian sense, or the GNOME sense?

A Debian package maintainer:

  • Tracks upstream development, and ensures new releases of software are packaged and uploaded in a timely manner
  • Work with distribution users and other maintainers to identify bugs and integration issues
  • Ensure bugs and feature requests against upstream software are reported upstream, and bugs fixed upstream are propagated to the distribution packages
  • Fix any packaging related issues, and maintain any distribution-specific patches which have not (yet) been accepted or released upstream

A GNOME project maintainer:

  • Makes regular releases of the software they maintain (typically a .tar.gz with “./configure; make; make install” to build)
  • Are the primary guardians of the roadmap for the module, and sets the priorities for the project
  • Works with packagers, documenters, translators and other contributors to the software to ensure clear communication of release schedules and  priorities
  • Acts as a central point of contact for release planning, bug reports and patch review and integration
  • A typical maintainer is also the primary developer of the software in question, but this is not necessarily the case

Obviously, these two jobs are very different. One places a high priority on coding & communication, another on integration, testing, and communication.

So how much time does maintaining software take?

Well, how long is a piece of string?

To give opposite extremes as examples: Donald Knuth probably spends a median time of 0 hours per week maintaining TeX and Metafont. On the other hand, Linux Torvalds has worked full time maintaining the Linux kernel for at least the past 15 years, and has been increasingly delegating large chunks of maintenance to lieutenants. The maintenance of the Linux kernel is a full time job for perhaps dozens of people.

On a typical piece of GNOME software (let’s take Brasero as an example) much of the work is simplified by following the GNOME release schedule – the schedule codifies string freezes and interface freezes to simplify the co-ordination of translation and documentation. In addition, outside of translation commits, Brasero has had contributions from its maintainer, Philippe Rouquier, and 6 other developers in the last 3 months. Most of these changes are related to the upcoming GTK+ 3 API changes, and involve members of the GTK+ 3 team helping projects migrate.

In total since the 2.32.0 release, there have been 55 commits relating to translations, 50 commits from Philippe, 9 from Luis Medina, co-maintainer of the module, and there were 4 commits by other developers. Of Philippe’s 50 commits, 14 were related to release management or packaging (“Update NEWS file”), 5 were committing patches by other developers that had gone through a review process, and the remainder were features, bug fixes or related to the move to the new GTK+. Of Luis’s commits, 2 were packaging related, and 2 were committing patches by other developers.

This is a lot of detail, but the point I am making is that the “maintenance” part of the work is relatively small, and that the bigger part of maintenance is actually sending out the announcements, paying attention to bug reports and performing timely patch review. I would be interested to know how much time Philippe has spent working on Brasero over the past release cycle. I would guess that he has spent a few hours (somewhere between 5 and 10) a week.

On the other hand, the Debian maintainer for the Brasero package has a different job. There are 6 bugs currently forwarded upstream from the Debian bug tracker, and another 35 or so awaiting some final determination. A number of these look like packaging bugs (“you need version X of dependency Y installed”). The last release packaged and uploaded was 2.30.3-2, dating from November, and there have been 4 releases packaged in the past 8 months, none by the maintainer.

A typical Debian maintainer is a “Debian developer” for several packages. Pedro Fragoso, the Debian maintainer of Brasero, maintains 5 packages. I think it is fair to say that the amount of time a package maintainer spends maintaining an individual package is quite low, unless it is extremely popular. Perhaps a few hours a month. But the package maintainer has little or no say (beyond interacting with the project maintainer and forwarding on bug reports & feature requests) in what happens upstream, or which features have a high priority.

What’s in a word?

It’s clear that a package maintainer is not the same thing as a project maintainer. So when Sivan asked on the MeeGo developer list how he could become a maintainer, he clarified later to say that what he was really asking was “How can I affect change in MeeGo?” To do that, you need to write some code that changes a module, or a number of modules, and then you need to get that code into MeeGo.

How that happens, in all its gory details, is the next instalment in this series of at least 2 articles: The Lifecycle of a Patch (or: Working Upstream).

Lexicon:

  • Upstream: The place where the thing you package comes from. For example, Ubuntu’s upstream for gedit is gnome.org
  • Downstream: Any distributors who take what you release and re-package it before redistributing
  • Distribution: A collection of software packages that are organised into a product, with integration testing

Follow-up to “Shy Developer Syndrome”

My article on “Shy Developer Syndrome” a few weeks ago garnered quite a bit of interest, and useful feedback. Since a lot of it adds valuable perspectives to the problem, I thought I should share some of my favourite responses.

On gnome.org, Rodney Dawes argued that developers tend to stay away from mailing lists because the more public lists are very noisy:

For me, mailing lists are a huge risk vs. low return problem. They can become a time sink easily, and it’s quite often that pointless arguments get started on them, as offshoots of the original intent of the thread. Web Forums also have this problem. And, to really get much of anything out of a list, you must subscribe to it, as not everyone who replies, is going to put you specifically in the recipients headers. That means, you’re now suddenly going to get a lot more mail than you normally would for any highly active project. And for anyone trying to get involved in an open source community, 99% of the mail on that list is probably going to be totally irrelevant to them. It will just make tracking the conversation they are trying to have, much harder.

I agree with Rodney that dealing with a new level of volume of email is one of the trickiest things for new contributors. I still remember when I signed up to lkml for an afternoon in college, only to find 200 new emails 3 hours later. I panicked, unsubscribed, and gave up that day on being a Linux kernel hacker.

Since then, however, I have learned some email habits which are shared by other free software hackers I know. Everyone I know has their own tricks for working with medium or high volume mailing lists, and some combination of them may make things livable for you, allowing you to hear the signal without being drowned out by the noise. LifeHacker is a good source of tips.

Rob Staudinger says something similar, pointing the finger at bikeshed discussions as a big problem with many community lists:

Will the zealots go and suggest postgresql’s process model was poor, or samba’s memory allocator sucks? Unlikely, but they will tell you your GUI was bad or that you’re using a package format they don’t like, just because it’s so easy to engage on that superficial level.

Over at LWN, meanwhile, Ciaran O’Riordan makes a good point. Many developers working on free software want to separate their work and personal lives.

When I leave the office at 6pm, my work should have no more relevance until the following morning. Same when I quit a company. I might choose to tell people where I work/worked, but it should be a choice, and I should be able to choose how much I tell people about my work. Having mailing list posts and maybe even cvs commits might be too detailed. Maybe waaay too detailed.

Finally, here at neary-consulting.com, MJ Ray suggested that asking individuals to respond to a request can backfire:

Publicly referring to individuals on a mailing list is a double-edged sword. It might bolster the confidence of the named individual, but it also reduces the confidence of other people who might have answered the question. In general, I feel it’s best not to personalise comments on-list. Some e-democracy groups require all messages to be addressed to a (fictional or powerless) chair or editor, similar to the letters pages of The Times.

While I agree with MJ in situations where the answer is accessible to the wider community, but often only developers working for you, the manager, are in a position to reply – at that point, you have a choice: get the information off your developer and answer yourself, or ask him to answer the question. and I’ve found that asking on the list has the positive side-effects I mentioned.

Curing “Shy Developer Syndrome”

One of the most common issues I have seen with experienced professional software developers who start to work on community software is a reluctance to engage with public communication channels like mailing lists. Understanding the reasons why, and helping your developers overcome their timidity, is key to creating a successful and fruitful relationship with the community you are working with.

In my experience, common reasons for this timidity are a lack of confidence in written English skills, or technical skills, nervousness related to public peer review, and seeing community interaction as “communication” or “marketing” (which are not part of their job), rather than just “getting stuff done” (which, of course, is part of their job).

Lack of confidence

Shy Kittens
Shy (Credits: maong@flickr, CC BY-SA)

For non-English speakers, this phenomenon is more prevalent, but in general, professional software developers have not developed writing skills during college, and often have not been required to learn them as part of their job. In addition, while most engineers appreciate good logic, they are never taught how to structure an argument. The end result is that when asked to write about their work, or to ask a question on a public forum, they hesitate.

One engineer I worked with would (eventually) write an email about a topic if I specifically asked him to, but would not react to responses or questions from community members. When I approached him, he would rationalise, say he hadn’t had time, or didn’t see the need to reply, or refer the questions to someone else. But as part of a pattern, I concluded that he was nervous about sending an email to a publicly archived mailing list. He was nervous about making a mistake, writing something he shouldn’t, overstepping some unwritten corporate policy, or felt uncomfortable expressing himself in writing. It doesn’t help that “bad netiquette” is often dealt with rather harshly, reinforcing the lack of confidence.

The only way to cure the problem is with baby steps.

A great first step is to get your engineers answering questions. One way I have found to help get this to happen is to publicly refer a question to an engineer on the mailing list, while affirming his expertise in the area. “Tommy knows the RLE algorithms inside out – Tommy, would you mind answering Franz’s question, please?”

This serves a triple purpose: an individual can easily ignore a question if it is addressed to a group, but it is a rare person who doesn’t answer when you ask them a question directly – it’s human nature; affirming your engineer’s skills makes him feel good about himself, and gives him more confidence; by identifying an individual engineer with a specific skillset inside your team, you are giving people outside your company a glimpse inside the walls – you are making your team human, a collection of individuals with different strengths and weaknesses, rather than an amorphous group – “the Acme Co developers”.

Another good step is to give a series of creative writing workshops to your developers. It is not enough to stand over people with a whip and ask them all to have a blog. First you need to get them in the habit of writing regularly. Since terse language, often in bullet form, is the norm for mailing lists, the goal is not to turn them all into novelists, writing perfectly crafted works of art. The goal is to get your team in the habit of writing.

Finally, you should train your engineers in basic netiquette and writing good email – there are lots of good resources out there, including Producing Open Source Software by Karl Fogel, The Open Source Way, the Linux Kernel Contributors Guide from the Linux Foundation, and ESR’s “How to ask questions the smart way“. Michael Meeks suggested to me that developers should treat writing email in a similar way to patches – when you generate a patch, typically the last thing you do before you send it is you check over it, to make sure nothing silly is included. Michael suggests that the same habit applied to email will identify any places where phrasing is awkward and ambiguous, resulting in better email.

Nervousness related to peer review

Tough crowd
Tough crowd (Credits: seedingchaos@flickr, CC by-sa)

It is one thing to have engineers answer questions when they have the knowledge to do so. It is another thing to have them submit their plans and patches to a community forum and have them exposed under the harsh light of peer review.

On more than one occasion, I have heard a hiring manager say that he didn’t have time to have a developer go through peer review of specs or patches – after all, he was hired because he was competent to do the job, and what are we paying him for if he’s going to be second-guessed by “the community”? After a first job or internship, peer review is more an exception than the rule for professional software developers (regrettably, I might add).

In community projects, peer review is expected – in fact, it is a best practice, one of the things that separates successful community projects from the crowd. Developers expect to hear about features before they are developed, and have an opportunity to suggest better ways the feature can be implemented. They expect new contributors to submit patches that they can review – it is the way a new contributor builds trust before getting the keys to the house. It is such a recommended practice that the only treatment I can suggest is that you should help your developers to get over their nervousness & embrace peer review, by making it the norm in your team.

The best way I know to get people used to peer review is to have a company policy against the “day one commit bit” – the practice of getting commit access to the project repository on the day you start in the company. For corporate-sponsored projects, new developers should go through the same review process for their work that contributors outside your company have to go through.

For corporate contributions to community projects, that means discouraging internal branches and a “gatekeeper” project structure, where one or two developers commit the work of others in the team. Developers should submit their work upstream at the same time it is being submitted internally. For those changes which only apply to your internal branch, you should create a probation period when patches are submitted via an internal mailing list, and subjected to the same peer review you would expect outside the company. This is a hard change for many organisations, but one which is necessary to transition your team
to successful community contributors.

Having new developers go through this review period is important for a number of reasons – the most important is that you are demonstrating that employees have the same burden to prove themselves in the project as non-employee contributors, and it ensures that new employees have a period where they familiarise themselves with project coding & communication conventions & norms, and when they also introduce themselves to the community at large.

Communication & marketing are not my job

Under the bed
Hiding (Credits: stuartpilbrow@flickr, CC BY-SA)

The developer I mentioned before shied away from the mailing list because he set a very high bar for himself on any public communications. In his mind, posting project plans to the mailing list was an announcement, and needed substantial preparation. In reality, most communities have a very high tolerance for things like spelling errors, incomplete plans (as long as they are marked as such) and other things which would be unacceptable in a press release or an official announcement. This is very definitely a case where Voltaire was correct: the perfect is the enemy of the good.

The developer was framing “sending an email to a mailing list” as “making an announcement”, something which fit in the “marketing” box in his head. One other developer I worked with once told me that he didn’t have time to send email to the mailing list because he had real work to do – “dealing with the community” was my job as community manager, as far as he was concerned.

Part of this issue comes from a general discomfort with written communications. But another part of it comes from the culture which is pervasive in most companies – only a small number of people get to talk for the company, and everyone else should just keep quiet. The authors of “The Cluetrain Manifesto” claimed that in the modern connected world, there is no such thing as a marketing department, that every interaction between an employee of your company and someone outside your company is an opportunity to win or lose reputation.

In free software development teams, this is even more true. There is no marketing department for project communications, and nor should there be. To be productive you need to talk to your peers, so the institutional barrier to external communications *must* disappear for people dealing in community projects.

It is all fine & well to say that this should be the case, but even if the organisation is clear about giving engineers a free hand to talk about their work, the engineers may impose limits on themselves, requiring proposals to be perfect before sending them on (which, of course, they never are). In fact, waiting until a proposal is finished is usually a lost opportunity, since by the time it is finished, there may be so much emotional investment in the proposal that making changes to it can be difficult. It is better to release a rough early draft, giving the author an opportunity to integrate early feedback.

The best way to prove to your team the benefits of “release early, release often” is to do so by example. As a team lead or manager, you can lead by publishing team plans publicly and early, and pointing out the benefits which result to your team. Breaking down this barrier will take time, but by making it clear that perfection is not expected, and by rewarding early release of information and encouraging feedback, your team will soon learn that participants outside your company are peers, not an audience.

Another useful technique is to ask your engineers to break tasks into smaller parts, so that even if they do hold off until the first part is up to a high standard, information is still getting out there more quickly, allowing feedback to inform later stages of the process.

However, another phenomenon is fighting against this desire for openness.

It is not uncommon for companies to want to keep their plans secret, so as to have a Big Reveal announcement effect at a major trade show. This can lead companies to ask their engineers to work internally on significant features for fear that the big surprise will be ruined otherwise. The alternative seems to be to announce a project when you start, rather than when you have something to show – but this can result in a long wait before products get to market, and impatience and bad press from the mainstream press.

I would argue that having engineers talk about design decisions & implementation details of significant features in a mailing list will not result in significant attention outside of your community – and when the press release and announcement comes, the community who knew it was coming will feel better about having been in on the secret from the beginning, rather than feeling worse because they have to deal with a big code drop which no one person can review.

Bashing bashfulness

The key lesson here is that you want your developers to feel a connection to people working outside the company. That requires people outside your company to feel a connection with them, too. By drawing the curtain on your team, its members and their skills & priorities, you are creating the circumstances for people to come to appreciate each other as peers, and to feel comfortable discussing features & patches on their merits. When you get to that point, you have already won – it’s impossible to be shy when you’re among friends.

Hi Dawn,

I plan to put this live tomorrow, and I'd really appreciate getting any
thoughts & feedback you might have. It's still missing a re-read or two
& some links and maybe a photo or two but I think the content isn't bad.

Thanks!
Dave.

One of the most common issues I have seen with experienced professional
software developers who start to work on community software is a
reluctance to engage with public communication fora like mailing lists.
Understanding the reasons why, and helping your developers overcome
their timidity, is key to creating a successful and fruitful
relationship with the community you are working with.

In my experience, common reasons for this timidity are a lack of
confidence in written English skills, or technical skills, nervousness
related to public peer review, and seeing community interaction as
"communication" or "marketing" (which are not part of their job), rather
than just "getting stuff done" (which, of course, is part of their job).
Lack of confidence

For non-English speakers, this phenomenon is more prevalent, but in
general, professional software developers have not developed writing
skills during college, and often have not been required to learn them as
part of their job. In addition, the art of rhetoric, structuring an
argument or thought to make it convincing, is not taught to engineers.
The end result is that when asked to write about their work, or to ask a
question on a public forum, they hesitate.

One engineer I worked with would (eventually) write an email about a
topic if I specifically asked him to, but would not react to responses
or questions from community members. When I approached him, he would
rationalise, say he hadn't had time, or didn't see the need to reply, or
refer the questions to someone else. But as part of a pattern, I
concluded that he was nervous about sending an email to a publicly
archived mailing list. He was nervous about making a mistake, writing
something he shouldn't, overstepping some unwritten corporate policy, or
felt uncomfortable expressing himself in writing. It doesn't help that
"bad nettiquette" is often dealt with rather harshly, reinforcing the
lack of confidence.

The only way to cure the problem is with baby steps.

A great first step is to get your engineers answering questions. One way
I have found to help get this to happen is to publicly refer a question
to an engineer on the mailing list, while affirming his expertise in the
area. "Tommy knows the RLE algorithms inside out - Tommy, would you mind
answering Franz's question, please?"

This serves a triple purpose: an individual can easily ignore a question
if it is addressed to a group, but it is a rare person who doesn't
answer when you ask them a question directly; affirming your engineer's
skills makes him feel good about himself, and gives him more confidence;
by identifying an individual engineer with a specific skillset inside
your team, you are giving people outside your company a glimpse inside
the walls - you are making your team human, a collection of individuals
with different strengths and weaknesses, rather than an amorphous group
- "the Acme Co developers".

Another good step is to give a series of creative writing workshops to
your developers. It is not enough to stand over people with a whip and
ask them all to have a blog. First you need to get them in the habit of
writing regularly.

Finally,you should train your engineers in basic netiquette - there are
lots of good resources out there, including Producing Open Source
Software by Karl Fogel, The Open Source Way, the Linux Kernel
Contributors Guide from the Linux Foundation, and ESR's "Asking Smart
Questions".
Nervousness related to peer review

It is one thing to have engineers answer questions when they have the
knowledge to do so. It is another thing to have them submit their plans
and patches to a community forum and have them exposed under the harsh
light of peer review.

On more than one occasion, I have heard a hiring manager say that he
didn't have time to have a developer go through peer review of specs or
patches - after all, he was hired because he was competent to do the
job, and what are we paying him for if he's going to be second-guessed
by "the community"? After a first job or internship, peer review is more
an exception than the rule for professional software developers
(regrettably, I might add).

In community projects, peer review is expected - in fact, it is a best
practice, one of the things that separates successful community projects
from the crowd. Developers expect to hear about features before they are
developed, and have an opportunity to suggest better ways the feature
can be implemented. They expect new contributors to submit patches that
they can review - it is the way a new contributor builds trust before
getting the keys to the house. It is such a recommended practice that
the only treatment I can suggest is that you should help your developers
to get over their nervousness & embrace peer review, by making it the
norm in your team.

The best way I know to get people used to peer review is to have a
company policy against the "day one commit bit" - the practice of
getting commit access to the project repository on the day you start in
the company. For corporate-sponsored projects, new developers should go
through the same review process for their work that contributors outside
your company have to go through.

For corporate contributions to community projects, that means
discouraging internal branches and a "gatekeeper" project structure,
where one or two developers commit the work of others in the team.
Developers should submit their work upstream at the same time it is
being submitted internally. For those changes which only apply to your
internal branch, you should create a probation period when patches are
submitted via an internal mailing list, and subjected to the same peer
review you would expect outside the company. This is a hard change for
many organisations, but one which is necessary to transition your team
to successful community contributors.

Having new developers go through this review period is important for a
number of reasons - the most important is that you are demonstrating
that employees have the same burden to prove themselves in the project
as non-employee contributors, and it ensures that new employees have a
period where they familiarise themselves with project coding &
communication conventions & norms, and when they also introduce
themselves to the community at large.
Communication & marketing is not my job

The developer I mentioned before shied away from the mailing list
because he set a very high bar for himself on any public communications.
In his mind, posting project plans to the mailing list was an
announcement, and needed substantial preparation. In reality, community
fora have a very high tolerance for things like spelling errors,
incomplete plans (as long as they are marked as such) and other things
which would be unacceptable in a press release or an official announcement.

The developer was framing "sending an email to a mailing list" as
"making an announcement", something which fit in the "marketing" box in
his head. One other developer I worked with once told me that he didn't
have time to send email to the mailing list because he had real work to
do - "dealing with the community" was my job as far as he was concerned.

Part of this issue comes from a general discomfort with written
communications. But another part of it comes from the culture which is
pervasive in most companies - only a small number of people get to talk
for the company, and everyone else should just keep quiet. The authors
of "The Cluetrain Manifesto" claimed that in the modern connected world,
there is no such thing as a marketing department, that every interaction
between an employee of your company and someone outside your company is
an opportunity to win or lose reputation.

In free software development teams, this is even more true. There is no
marketing department for project communications, and nor should there
be. To be productive you need to talk to your peers, so the
institutional barrier to external communications *must* disappear for
people dealing in community projects.

It is all fine & well to say that this should be the case, but even if
the organisation is clear about giving engineers a free hand to talk
about their work, the engineers may impose limits on themselves,
requiring proposals to be perfect before sending them on (which, of
course, they never are). In fact, waiting until a proposal is finished
is usually a lost opportunity, since by the time it is finished, there
may be so much emotional investment in the proposal that making changes
to it can be difficult. It is better to release a rough early draft,
giving the author an opportunity to integrate early feedback.

The best way to prove to your team the benefits of "release early,
release often" is to do so by example. As a team lead or manager, you
can lead by publishing team plans publicly and early, and pointing out
the benefits which result to your team. Breaking down this barrier will
take time, but by making it clear that perfection is not expected, and
by rewarding early release of information and encouraging feedback, your
team will soon learn that participants outside your company are peers,
not an audience.

It is not uncommon for companies to want to keep their plans secret, so
as to have a Big Show announcement effect. This can lead companies to
ask their engineers to work internally on significant features for fear
that the big surprise will be ruined otherwise. I would argue that
having engineers talk about design decisions & implementation details of
significant features in a mailing list will not result in significant
attention outside of your community - and when the press release and
announcement comes, the community who knew it was coming will feel
better about having been in on the secret from the beginning, rather
than feeling worse because they have to deal with a big code drop which
no one person can review.
Bashing bashfulness

The key lesson here is that you want your developers to feel a
connection to people working outside the company. That requires people
outside your company to feel a connection with them, too. By drawing the
curtain on your team, its members and their skills & priorities, you are
creating the circumstances for people to come to appreciate each other
as peers, and to feel comfortable discussing features & patches on their
merits. When you get to that point, you have already won - it's
impossible to be shy when you're among friends.

-- maemo.org docsmaster Email: dneary@maemo.org Jabber: bolsh@jabber.org

MeeGo report card

Dave Neary recently wrote a guest article for VisionMobile, charting the first months of the MeeGo project. From MeeGo Progress Report: A+ or D-?

The end of October saw the release of MeeGo 1.1, the second major milestone release of the platform since it burst onto the scenes in February 2010. The MeeGo project was born under the auspices of the Linux Foundation from a merging of Nokia’s Maemo platform, targeting smart phones, and Intel’s moblin platforms, aimed at netbooks.

[...]

This contrasts sharply with Android which is primarily developed behind closed doors by Google, and iOS which is a completely proprietary platform. If there is a key differentiator for MeeGo in the hand-held market, this is it. It remains to be seen whether the open development model will be a selling point which will tip the balance when manufacturers are choosing a platform for a device.

[...]

It does not feel fair at this point to compare MeeGo, a project which came into being 8 months ago, with iOS or Android, but this is the yardstick which will be used when the first MeeGo smartphone comes on the market. The project has come a long way since its inception, in particular in working towards an open and transparent development model. There is still some way to go but improvements have been happening daily.

Read more