Communication and Coordination for release management in software ecosystems

Recently, I had an opportunity to work with German, Leif, and Daniel on a very interesting study of the Gnome FOSS Ecosystem. We were interested to understand how release managers coordinate a shared release of a set of interrelated projects within the Gnome Ecosystem. In particular, we investigated:

  • Communication channels used…
  • How developers communicate and coordinate…
  • The key actors, the key tasks, and the most pressing challenges…

With respect to release management in the Gnome FOSS Ecosystem.

What I personally found most interesting are implications for coordinating activities across an ecosystem. In our case, release managers did not exhibit concrete power over developers. They could not just make people do things. This reminds me of some systems and systems as well as ecosystems that I see emerging in industry, where again it is not always clear who has the main responsibility.

In such a situation, our lessons learnt relate to soft factors more than technology. Specifically, we derive the following recommendations from our case study:

  1. Ensure that the release team follows the main communication channels used by developers. The release team needs to be in touch with the developers. IRC channels and face-to-face meetings in developer conferences were highlighted in our case study.
  2. Provide a common place for coordination for an ecosystem. In a globally distributed and multi-cultural environment, we found an asynchronous, global mailing list ideal, when complemented with individual, direct communication (face-to-face or IRC) with developers.
  3. Consider including both good technical and social skills in a release team. In short, technical skills are necessary to earn the respect of developers and to communicate with them, social skills are crucial to convince them to perform necessary actions.
  4. Aim for a diverse release team. Successful release managers can be seen as representatives of the different parts of the ecosystem. A good release team should mirror the diversity of its ecosystem.
  5. Based on lack of power, lobbying and consensus based management must be followed. A release team is well advised to keep close to key influencers in the ecosystem.


The Journal of Internet Services and Applications has accepted this work and published it open access.

author Germán Poo-Caamaño and Eric Knauss and Leif Singer and Daniel M. German
title Herding cats in a FOSS ecosystem: a tale of communication and coordination for release management
journal Internet Services and Application, 2017, 8(12), 1-24
abstract Release management in large-scale software development projects requires significant communication and coordination. It is particularly challenging in Free and Open Source Software (FOSS) ecosystems, in which hundreds of loosely connected developers and their projects are coordinated to release software to a schedule. To better understand this process and its challenges, we analyzed over two and half years of communication in the GNOME ecosystem and studied developers’ interactions. Through a case study, we cataloged communication channels, determined the main channel from which we categorized high level communication and coordination activities spanning five releases, and triangulated our results by interviewing ten key developers. We found that a release schedule, influence (instead of direct control), and diversity are the main factors that positively impact the release process in the GNOME ecosystem. We report a set of lessons learned that encapsulates our understanding of how the Release Management process function in a FOSS ecosystem, we learned that: (1) ensure that the release team follows the main communication channels used by developers, (2) provide a common place for coordination for an ecosystem, (3) consider including both good technical and social skills in a release team, (4) aim for a diverse release team, (5) based on lack of power, lobbying and consensus based management must be followed, (6) help the release team in the coordination process with a well defined schedule, and (7) release team work is different from regular software work. Our results can help organizations build better large-scale teams and show that research focused on individual projects might miss important parts of the picture.
doi 10.1186/s13174-017-0063-2
keywords release management, software ecosystems, empirical study

Questionnaires with Likert Scales Using SoSciSurvey and GNU R

In a recent post, I discussed different online questionnaire tools. My personal preference is still SoSci Survey, because it’s support for complex Likert scale questions, the good options for data export, and the support for reuse. In this post, I focus on visualizing results from the System Usability Scale (SUS) question block that is available in SoSci Survey. For this, I am using GNU R and the likert package.

Continue reading

Online Questionnaires

Questionnaires are a funny thing. Obviously, they are a great tool for researchers. They seem to be so simple. But it is really difficult to create a good one. Two years ago I tried an online questionnaire tool for the first time and I was impressed on how helpful it was.

First, the assistants and editors such tools provide allow to quickly create a questionnaire with a good layout of questions. Then, you get the results in a format that allow analysis even with little experience. You do not have to bother with setting up a webpage.

As a drawback, you have to find the right tool or service provider. And this proves to be difficult. There is all kinds of advertisements going on, service providers try to lure you with features you don’t need (in my case: Facebook integration) and make it almost impossible to discover that they do not offer features you do need as part of their basic plan, before you have created and posted your first questionnaire (in my case: export of the data as CSV or similar). Here are some of my experiences. Please let me know if there is more.

Further reading: How to questionnaire?

Wai-Ching Leung: How to design a questionnaire. These three pages are a great read. Leung provides a checklist with do’s and don’ts that quickly help to create and improve a first draft. It also includes some inspiration for longer thinking but might be to brief for real experts.

Idealware: A few good questionnaire tools. A good starting point for choosing a tool. I especially liked the discussion.

Where to do it

Google Docs: This is pretty straight forward. Just create a Google Form as a front-end to your Google spreadsheet. The questionnaire can be directly integrated into the email, it looks great and might be the best solution for a quick poll. From Google spreadsheets, you can do all the analysis you want to do and export the data in all possible formats. Maximum freedom, but limited support for more advanced types of questions.

Surveymokey: Google search gave me this tool as first result. It looks great. I love the question editor. I was able to create a nice questionnaire pretty quickly. What I do not like: I cannot export the data in the free plan and the restrictions (amount of responses, amount of questions) might actually be hurtful. I have to check if they offer free upgrades for education and not-for-profit research.

SurveyMoz: Extremely good price and lots of important things in the extreme plan. However, the data only exports to Microsoft Word in the free plan, which would be a no go. There is a free upgrade for educational and non-profit organizations, which mitigates this problem. Did not try to create a questionnaire yet, because apparently one cannot sign up with a Mac (Exception: Validation of viewstate MAC failed.)

SoGoSurvey: The new star among the questionnaire tools. It has a very reasonable free package and low prizes. My opinion: Has all the functionality I need, even in the free plan, but the editor is more complicated and not as straight forward as SurveyMonkey, without direct support for a set of questions with the same Likert-scale.

SoSciSurvey: This is the provider I made my good experience two years ago. Although this seems to be a German project, you can switch the language and create surveys in English, too. If I look on the page today, it looks a bit old-fashioned, but it is a solid tool, especially focused on the needs of university research. It has all the question types I need, excellent data export (e.g. to R), great examples. For example, you can integrate standard usability questions with one click. This is the tool I am currently recommending when asked by students.

Please let me know about your experiences!

Amazing adventure: Rowing across the Atlantic Ocean

Since a few month now, we are constantly observing the progress of an amazing project: Four adventurers of OAR Northwest are rowing(!) across the Atlantic Ocean from Dakar to Miami. The project aims at educating (young?) people towards a sustainable and healthy lifestyle. It also supports a high number of research projects.

The team allows us to take part in their adventure via social media and the partly dramatic accounts show that this project is not only a “metaphor for important life lessons” (Adam Kreek), but that it is literally an example for reasonable management of very limited resources.

It is also a great example of excellent team spirit, keeping a positive attitude, and stay motivated, despite overwhelming challenges and a seemingly endless task. And there is one particular picture, that shows this more than any words:

Oar Northwest's heartThat is right, the crew spend almost two days on painting a heart with their trajectory, after being caused to leave their course for some reason. Despite the fact that there potentially is a longer and more profane story behind this, this picture has become a symbol for caring about beauty in your actions to me.

Learn more about this exciting project and lessons you can draw from it on And if you wonder, how this relates to Software Engineering, you can find a more specific answer here.

Panel on Empirical Requirements Engineering, EmpiRE@RE’12

Yesterday, I participated in the workshop on empirical requirements engineering. My notes on the talks will follow shortly, but I want to highlight the excellent panel that concluded the workshop. The panelists where Nan Niu, Jörg Dörr and Neil Maiden. Note, that the panelists were required to be provocative in their statements. Also note that I will add more links and references to this article later. Continue reading