Balancing IRC and email, the secret of success for open collaboration

Are seasoned contributors to OpenStack giving too much importance to IRC, and is that creating bad side effects in other areas of the community?

Since I started contributing more to working groups outside of the OpenStack upstream contributor community, I noticed that email is used in a limited way, with a couple of lists having either very low traffic or low signal/noise ratio. The email lists are often used to share calendar notifications for meetings and their agendas with often little to no discussions. Have we insisted so much in holding weekly meetings “like developers do” that now people think that email discussions are less important?

This weekend a couple of posts on Planet OpenStack talk about IRC: one very good source of information on how to use IRC better from Chris Aedo who suggests to stay more on IRC. He argues:

If you are interested in becoming an OpenStack contributor, having a persistent IRC presence might be one of the most important secrets to success. Anyone who spends time in one of the more active project channels will immediately see the value of synchronous communication here where problems are sometimes solved in minutes.

On the other hand of the spectrum Chris Dent who highlights the chaotic nature of IRC. He mentions that too  much IRC leads to:

no opportunity to be truly away, frequent interruptions, an inflated sense of urgency, and a powerful sense of “oh noes, I’m missing what’s happening on IRC!!!!”—but the killer is the way in which it allows, encourages and even enforces the creation and expression of project knowledge within IRC, leaving out people who want or need to participate but are not synchronous with the discussion.

This last point is crucial: not everybody can be online all the time, some of us have to sleep or go see a movie at times. IRC is often mentioned as a blocker to new community members. I advocate using a bouncer only to get personal messages, not to read the backlogs.

While synchronous communication is crucial for distributed collaboration, a sane habit of using email is as important. The OpenStack community has put so much emphasis on using IRC to hold weekly meeting and to resolve the most controversial conversations in real-time that some new comers now think that synchronous communication is more important than async email.

A sane balance of sync-async communication is more crucial to success of open source collaboration, mixing email and IRC (which is what most of OpenStack upstream developers do, by the way.)

All in all, I think there is also a need to teach people how to hold conversations via email, with proper quoting, no top posting and other nice things to do… but also email sorting and filtering client-side, what not to say (hint: “me too” messages are generally considered noise)… a lost art, as much as using IRC.

A new push for OpenStack public clouds?

Monty “mordred” Taylor just announced that he’s leaving HP and going to work at IBM. Usually something like this wouldn’t deserve more fanfare than the twittersphere explosion already in act. In this case, I think the announcement is more important than just an OpenStack board member and technical leader changing employer.

Monty says on his blog that he is leaving HP because he wants to build public clouds, implying that he can’t do that at HP. At IBM instead he’ll be focusing on a strong OpenStack-based public cloud, to compete head-to-head with Amazon (and surpass it).

His words confirm the impression I had when analyzing the competitive landscape of public clouds for DreamHost. HP clearly is targeting the enterprise market, with their public cloud used mainly as a supporting mechanism for the private clouds.

I think OpenStack will benefit from more focus on public clouds: I have the feeling those are taken for granted, since there are working groups for pretty much anything but for public clouds. And all operators running large clusters have nightmare stories instead. Hopefully lots of positive changes aimed at public cloud users will keep going upstream (and we can avoid creating yet another working group in openstack-land).

Improving the content of OpenStack wiki

The pages on wiki.openstack.org have been growing at a fast pace and it’s  time to give the wiki more shape: new contributors, end users and operators are having a hard time finding documentation since over time it spreads across many places. The wiki can have a role at directing readers where most appropriate. Luckily we have a team ready to help give the ~350 pages a more solid navigation and fixing content while at it:

  • Katherine Cranford (a trained taxonomist) volunteered to get through the wiki pages and propose a taxonomy for the wiki.
  • Shari Mahrdt, a recent hire by the Foundation, has volunteered a few hours per week to implement the taxonomy in the wiki pages, setup templates and write documentation to maintain the wiki.
  • I am overseeing the implementation and looking more carefully at content for contributors.

We are keeping track of things to do on the etherpad: Action_Items_OpenStack_Wiki. Shari and I started implementing Katherine’s proposed taxonomy: it’s visible as a navigable tree on https://wiki.openstack.org/wiki/Category:Home.

As an example of how the taxonomy works, let’s look at the tree of OpenStack Programs. One can think of Programs as teams of people using tools (code repository, bug tracker, etc) and coordinated processes to deliver one or more project to achieve a clearly stated objective. For  example, the Telemetry Program has a team of core reviewers responsible to drive development in code repositories for the Ceilometer project and the Ceilometer client, and each has pages for blueprints and specs, meeting notes and more. Programs contain projects, so the tree of categories under Programs will look like:
  • Programs
    • Telemetry
      • Ceilometer
        • Client
        • Blueprint
    • Block Storage
      • Cinder
        • Client
        • Blueprints
    • Compute
      • Nova
        • Client
        • Blueprints

You can see this live on the wiki on https://wiki.openstack.org/wiki/Category:Programs. Fairly straightforward except that over the years some of the pages have started with describing a project and have now been repurposed to illustrate a Program. Look at Nova page for example: the name of the page is “Nova” but the title is OpenStack Compute. We’ll definitely have to shuffle content around.  For example, the Category:Programs page can be considered a duplicate of the wiki https://wiki.openstack.org/wiki/Programs page: since everything on mediawiki is a page, the Category pages can be edited and can be redirected to/from like all other pages. In this case, it would make sense to make high level content like Programs more of a dynamic page, like Category:Programs. The cool thing of this approach is that we can probably create new category page for new programs automatically when modifications to the programs.yaml are approved via jenkins.

Adding a taxonomy and templates (more on this later) will help newcomers discover relevant content and find information more easily. While we implement the changes to the wiki we’ll also be reviewing the content on the pages, delete or mark as obsolete the old stuff and make things more readable for all. You can keep up with the progress by looking at RecentChanges.

If you’d like to help us out or find out more please feel free to contact stefano@openstack.org and shari@openstack.org

How is your OpenStack team organized?

I’ve been collecting a lot of good insights talking to directors and managers about how their companies are organized to contribute to OpenStack. For geographic reasons I have mostly gathered comments from people between San Francisco and Silicon Valley and I’d like to expand the research.

I’m especially interested in learning about internal processes, system of incentives, things that impact performance evaluation for engineers contributing to OpenStack.

To expand the research I’m asking the OpenStack community to fill in this brief survey or contact me directly (stefano openstack.org) for a quick interview.

Only developers should file specifications and blueprints

If you try to solve a problem with the wrong tool you’re likely going to have a frustrating experience. OpenStack developers have been using the same workflow to plan and manage development of OpenStack software over time, they chose a set of tools appropriate for the project’s software development. Developers use blueprints define the roadmap for the various projects, the specifications attached to a blueprint are used to discuss the implementation details before code is submitted for review.

These are the tools for the developers and this doesn’t mean that blueprints and specifications are the only way to interact with developers. Operators and users in general don’t need to dive in the details of how OpenStack developers organize their work and definitely should never be asked to use tools designed for and by developers. When I read ‘s post the place of a non-developer in the openstack community I immediately felt her pain: she was asked to use the wrong tool to solve a problem. I think this case is a major misunderstanding but the comments on the post signal that this is not an isolated case.

The most common way for a non-developer to highlight a flaw in OpenStack is to file a new bug report. Bugs can be defects that need to be fixed  or they can be requests for enhancement. In this case, Dafna filed a bug report and interacting with the triager, they agreed that the reported bug was not a defect per se but more of a request for enhancement, a wishlist.

In order to fix a defect or implement a wishlist item, developers need to file a blueprint (and a specification) before they can start writing code. If the person who filed the original bug report is also a developer then s/he can go ahead and continue carrying on the process, file a blueprint to solve a bug # and write specifications (when needed) to describe the details of the implementation. Users interested in the bug can chime in adding comments to the bug and to the specs, provide input to developers.

The process above works in similar way when the person filing the bug is not a developer, like in Dafna’s case. The proper flow of bug #1323578 would have not required Dafna to file a blueprint and specs, but to have a developer do that. Users are required to interact closely with the developers to discuss the implementation details, and that’s where the new specifications process helps. Gerrit may not have the best UI but it’s definitely better than holding discussions on a mailing list. Adding comments and holding conversations with the developer assigned to resolve the issue, on the bug report itself is also a valid option.

While I think that as a community we have plenty of ways to improve how we include users and operators in our conversations, in this particular case, I think frustration came from being pulled in the wrong place from the beginning.

PS: To be super-clear, in this post I’m using the terms developer and operator to describe a role, not a person. One person can be at the same time a developer and an operator, and act at times as a developer writing blueprints, submitting code and as an operator filing bug, giving comments to specifications.

 

Sustainability of Open Source software communities beyond a fork: How and why has the LibreOffice project evolved?

Sustainability of Open Source software communities beyond a fork: How and why has the LibreOffice project evolved?

via Sustainability of Open Source software communities beyond a fork: How and why has the LibreOffice project evolved?.

Tracking gender diversity in the OpenStack developer community

The OpenStack Foundation has always tried to increase genders diversity in our community: we joined the Outreach Program for Women, established clear policies for our summits and in general we’ve been actively promoting good behavior across the board. A few weeks ago I realized that we were lacking of a decent way to track our progress in gender diversity in the OpenStack developer community and decided to improve the situation.

When Anne asked me for the number of women or non-male developers in OpenStack, I realized that we don’t have that number. When people register to become OpenStack developers they need to become members of OpenStack Foundation and have an account on Launchpad. Neither of them track gender information. The best number I had to offer was the t-shirt kind requested at our Summits. If you don’t measure it you can’t improve it, the saying goes. So we thought we need to offer the option for Foundation’s members to tell us their gender, if they want to. How do we ask for gender without being disrepectful to non-binary genders?

We did some research, discussed them on the bug and adapted the best practices to our case. We wanted to keep the choice short and not to offend anybody by leaving out options. An open entry form leads to hard to use data (people have very creative ways to spell just about anything), using pronouns would have made translations a nightmare. We need a way to restrict options so we can easily count them in the database so the binary options male/female were set first and ‘Prefer not to say’ was soon added as another option, since it’s really not mandatory to disclose that information. For non-binary genders using “Non-binary” sounded too geeky to me; using ‘other’ sounds weird, borderline offensive. We came to a consensus on my suggestion to have an open entry prefixed by “Let me tell you”. I liked this phrase because I feel like “Let me tell you” empowers the member to own their own gender definition. The new form is now live so you can now register or edit your OpenStack Member profile and add your gender (if you want to).

Why people contribute to OpenStack

A few days ago, I asked 55 OpenStack developers why they decided to submit one patch to OpenStack and what prevented them from contributing more. The sample polled people who contributed only once in the past 12 months, looking for anecdotal evidence for what we can do to improve the life of the occasional contributor. To me, occasional contributors are as important as the core contributors to sustain the growth of OpenStack in the medium/long term. Since it’s possible that the community has already already hired the best candidates among Python developers and system operators, to sustain the growth of OpenStack we need to tap into the wider Python community and experts of large distributed systems coming from other languages (Java, for starters). Knowing what hurdles new contributors face when they first join OpenStack is a first step to make onboarding easier and multiple contributions more frequent.

People who replied are for the most parts users of OpenStack, that is developers and dev-ops people working on deployments of OpenStack for internal usage and system integrators who develop and deploy OpenStack for their customers. A third group of occasional contributors are developers of projects that use or are used by OpenStack, like Docker or Ceph.

The top reasons to submit a patch went from the practical convenience of having patches maintained upstream, to fixing bugs (discovered during a proof of concept or in more advanced phases of a deployment) or to add/fix funcionalities to better integrate OpenStack with other projects. Finally, people contribute patches for personal growth and to enrich resumes.

Why don’t they submit more? There are three main stumbling blocks. Legal hurdles delayed contributions, and even prevented (at least) one. The reasons for the delays range from NDAs with customers to incompatibility with corporate policies to release software under open source license and sign a Corporate Contributor License Agreement. Another group of reasons for the delay is the long time it takes for contributions to travel the review queue. The time it takes for patches to get in OpenStack repositories was mentioned more than once. Finally, the lack of simple issues to fix in the spare time: apparently the community fixes simple bugs too rapidly.

The results cannot be considered representative but they seem to confirm that legal hurdles and speed of the reviews are preventing more casual contributions. While there are already many discussions on how to improve reviewing times, changing the way we handle contributions legally requires a massive endeavour to change OpenStack Foundation’s bylaws. The fact that simple issues to fix are hard to find is new to me: it may indicate that there are lots of people joining the community fixing these ‘low hanging fruits’ or something else. I think more analysis is needed in this area.

Exploring why people contribute to OpenStack

No doubt that OpenStack is one of the largest open source development efforts existing at the moment, with Linux, Debian and few others.  What can be improved to make the OpenStack community grow faster? How can we help new contributors become productive more rapidly?

Whatever dimension you look at, the growth of the OpenStack developers community is astonishing. I’ve looked at the reasons for this growth and I’ve identified four main causes summarized in my presentation at Linux Conf North America and Open World Forum in Paris last year:

  • One clear mission to solve a hard problem
  • One initial core team with strong motivation to solve that problem
  • One team dedicated to recruiting new team members
  • One clear path to onboard new members in the team

The first two points are pretty clear already and don’t seem to need much tweaking: those ain’t broken, so no need to fix’em. The other two are not broken either but they’re the kind of stuff you want to stay on top of because once you notice they’re broken, the cost to fix them will be higher. Recently I started to ask myself what margins of improvements there are in recruiting and onboarding new members in our communities.

I quickly realized that while we know a lot about the top contributors to OpenStack, we don’t know much about the ‘long tail’ of contributors. It’s fairly easy to understand why the people responsible for 80% of OpenStack code and documentation work on the project. But who are the occasional contributors and what are their motivations to join the community? I embarked on a quest to get to know this long tail in an effort to understand how we can improve recruiting and onboarding new developers.

After a conversation with Asheesh Laroia, of OpenHatch fame, I selected 55 random developers from the list of those who submitted a single change to the integrated OpenStack programs during the past 12 months. These people went through quite a huge chunk of trouble only to submit one single patch: besides learning enough of the quite complex OpenStack code, they had to sign the Individual CLA (maybe the Corporate CLA, too), learn about git review and the other tools, go through the code review process. I would expect that whoever goes through that process, does it with the intention to stick around. So I asked the sample two simple questions:

  • What made you decide to submit a patch to OpenStack?
  • What prevented you to submit more patches?

I’ll wait a few days for their answers and share more details. Feel free to answer the questions leaving a comment here, too.

Wrap-up post OpenStack Summit in Hong Kong

Back from busy days in one of the most exciting cities I’ve ever visited, I needed some time to put thougths back in order, recover from jet lag and deal with my irremediably broken WordPress installation (will probably blog about this later, too). Hong Kong was a blast in many aspects. The Summit itself started with lions dancing at the sound of drums in front of over 3,000 people:

And then we saw that Bejing is the first city by total number of contributors to OpenStack in the whole world:

There has been an incredible growth inside and around OpenStack, the project is growing fast. Growth is good, it’s what we wanted so we have plenty of reasons to celebrate. The second edition of the User Survey brought us more insights about usage of OpenStack around the world. We announced our first OpenStack Ambassadors, people who will help the OpenStack Community team get closer to many communities around the world. It was great to meet personally more women from the Outreach Program for Women of OpenStack. we’ve been doing this for over a year now, it’s a thing.

IMG_20131111_204451Growth also brings challenges and some of them were evident in some of the conversations had at the Summit, around it and after. A few signals I caught during and around the Design Summit sessions highlighted that we may need to start taking new steps to reinforce the culture of collaboration inside the project. The challenges highlighted go from lack of reviewers (not core reviewers, just developers who pay attention and help others), PTLs getting overloaded, the high traffic on the Development mailing list (which leads to loss of information), the increasing number of questions on Ask OpenStack with no interactions (no up/down votes, comments, etc) and little engagement in its Chinese version, the challenges inside the Internationalization Team with processes and tools. We’ve also heard of a very few Design sessions where it was too hard to have a productive discussion because of one or two uncollaborative people.

Since we’re getting so many new developers in the project we’re probably getting to the point where we can’t assume they are accustomed to contributing upstream first. The founders and first members of OpenStack all had a brilliant pedigree of open source contributions and collaboration. New members of the OpenStack Foundation may need some help to succeed. I enjoyed the session Getting Your Blueprint Accepted Quicker: the VPNaaS Use Case so much that I’m proposing the Upstream University training as an official program at the OpenStack Foundation to help new members. I’ll write more about this in the future.

The next six months will continue to be super exciting and full of things to do. If you have missed Hong Kong go watch the recordings of the sessions  keep watching this space for more news.