Open Advice/Prepare for the Future - Evolution of Teams in FLOSS

Prepare for the Future: Evolution of Teams in FLOSS

by Felipe Ortega

in: Open Advice

This text is available under the CC-BY-SA license. (see also: Open Advice/Info)

Contents 1 Generational relay 2 The knowledge gap 3 It feels like home 4 I wish I had known you were coming (before I quit) 5 about the author 6 notes

In his well-known essay The Cathedral and the Bazaar, Eric S. Raymond remarks one of the first important lessons that every programmer must learn:

“Every good work of software starts by scratching a developer’s personal itch”.

You never realize how certain is this statement unless you experience that situation by yourself. In fact, the majority of FLOSS programmers (if not all) certainly underwent this process as they got their hands dirty in a brand new project, or they join an existing one, eager to help making it better. However, many developers and other participants in FLOSS communities (documentation writers, translators, etc.) usually overlook another important lesson stressed by Raymond a bit later in his essay:

“When you lose interest in a program, your last duty to it is to hand it off to a competent successor”.

This is the central topic I want to cover here. You should think about the future of your project, and the newcomers that one day will take over your work and continue to improve it.

Generational relay

At some point in their lifetime, many FLOSS projects must face a generational relay. Former developers in charge of code maintenance and improvement eventually leave the project and its community, for a wide variety of reasons. These include personal issues, a new job that does not leave them enough free time, starting a new project, switching to a different project that seems more appealing, ... The list can be pretty long.

The study of generational relay (or developer turnover) in FLOSS projects is still an emerging area of study that needs further research to improve our understanding of these situations. In spite of this, some researchers have already collected objective evidence that sheds some light on these processes. In OSS 2006, my colleagues Jesus G. Barahona and Gregorio Robles presented a work entitled “Contributor Turnover in Libre Software Projects”. In this work, they show a methodology to identify the most active developers (usually known as core contributors) in different time intervals, over the whole history of a given project. Then, they apply this method to study 21 large projects, in particular GIMP, Mozilla (former instance of the well-known browser) and Evolution. In a nutshell, what they found is that we can identify three types of projects according to their rate of developer turnover:

• ˆ Code gods projects: These projects heavily rely on the work of their founders, and there is very little generational relay, or none at all. GIMP falls into this category.
• ˆ Projects with multiple generations: Projects like Mozilla show a clear pattern of developer turnover, with new groups of active developers taking over the lead of code development and maintenance from the hands of the previous core contributors.
• ˆ Composite projects: Evolution belongs to a third category of projects, showing some rate of turnover but not as evident as in the previous case, mitigated by retention of some core contributors over the project history.

This classification leads us to an obvious question: so, what is the most common pattern found in real FLOSS projects out there? Well, results for the whole set of 21 projects analyzed in this work render a clear conclusion, which is that multiple generations and composite projects are the most common cases found in the FLOSS ecosystem. Only Gnumeric and Mono showed a distinctive pattern of strong retention of former developers, indicating that people contributing to these projects may have more appealing reasons to continue their work for a long time.

Nevertheless, this is not the normal picture. On the contrary, this study gives support for the advice we are considering here, that we should prepare to transfer, at some point in the future, our role and knowledge in the project to the future contributors joining our community.

The knowledge gap

Any person experiencing a significant change in her life must deal with adaption to new conditions. For example, when you quit your job to get another one you prepare yourself for a certain period in which you have to fit in a new place, and integrate yourself in a different working group. Hopefully, after a while you have finally settled down in your new job. But, sometimes, you keep good friends from your old job, and you can meet them again after the move. Maybe then, talking with your former workmates, you can learn what happened with the person recruited to fill your previous position. This seldom occurs in FLOSS projects.

The downside of generational relay in FLOSS projects may come in a very concrete form, namely a knowledge gap. When a former developer leaves the project, and especially if she had an extensive experience in that community, she leaves behind both her tangible and abstract knowledge that may or may not be passed on to subsequent newcomers.

A clear example is source code. Like any product of fine intellectual work (well, at least one should expect that, right?) developers leave a personal imprint whenever they produce new code. Sometimes, you feel eternally in debt to that awesome programmer who wrote neat, elegant code that virtually speaks by itself and is easily maintainable. Other times, the situation is the opposite and you struggle to understand very obscure, unclear code without any comments or hints that can help you.

This is what we tried to measure in 2009, in a research work presented at HICSS 2009. The title is “Using Software Archeology to Measure Knowledge Loss in Software Projects Due to Developer Turnover”. In case you were wondering, it has nothing to do with a whip, treasures, temples or thrilling adventures, though it was really entertaining. What we measured (among other things) was the percentage of orphaned code left behind by developers who quit FLOSS projects, and not taken by any of the current developers, yet. In this case, we choose four projects (Evolution, GIMP, Evince and Nautilus) to test our research method. And we found quite interesting results.

Evolution exhibited a somewhat worrying pattern, in the sense that the percentage of orphaned code was growing over time. By 2006, nearly 80% of all source code lines had been abandoned by former developers and remained untouched by the rest of the team. On the contrary, GIMP showed a radically different pattern, with a clear and sustained effort of the development team to reduce the number of orphaned lines of code. By the way, remember that GIMP had already been characterized as a code gods project, and thus benefits from a much more stable development team to undertake this daunting task.

Does this mean that GIMP developers were having a much better experience than Evolution folks? To be honest, we do not know. Nevertheless, we can foresee a clear, predictable risk: the higher the percentage of orphaned code, the larger the effort to maintain the project. Whenever you need to fix a bug, develop a new feature or extend an existing one, you bump into code you had never seen before. Of course you may be a fantastic programmer, but no matter how wonderful you are, GIMP developers do have a clear advantage in this case, since they have someone in the team with precise knowledge about most of the code they need to maintain. In addition, they also work to further reduce the portion of unknown source code over time.

It feels like home

Interestingly, some projects manage to retain users for much longer periods than one could expect. Again, we can find empirical evidence supporting this claim. In OSS 2005, Michlmayr, Robles and González-Barahona presented some relevant results pertaining this a aspect.^[1] They studied the persistence of participation of software maintainers in Debian, calculating the so-called half-life ratio. This is the time needed for a certain population of maintainers to fall to half of its initial size. The result was that the estimated half-life of Debian maintainers was approximately 7.5 years. In other words, since the study was undertaken over a period of six and a half years (between July 1998 to December 2004), comprising from Debian 2.0 to Debian 3.1 (only stable releases), more than 50% of maintainers of Debian 2.0 were still contributing to Debian 3.1.

Debian has created quite a formal procedure to admit new software maintainers (also known as Debian developers) including the acceptance of the Debian Social Contract and showing good knowledge of Debian Policy. As a result, one would expect to have quite committed contributors. Actually this is the case, since these authors found that packages left behind by former maintainers were usually taken over by other developers staying in the community. Only in those case in which the package was not useful anymore it was simply abandoned. I think we can learn some useful conclusions from these research works:

1. Spend some time to develop the main guidelines of your project. It may start as a single, short document, simply featuring some recommendations and good practices. This should evolve as the project grows, to serve as a learning pill for newcomers to quickly grasp the core values of your team, as well as the main traits of your working style.

2. Force yourself to follow well-known coding standards, good practices and elegant style. Document your code. Include comments to describe sections that might be especially hard to understand. Do not feel that you are wasting your time. In practice, you are being very pragmatic, investing time in the future of your project.

3. If possible, when the time comes for you to quit the project try to make others aware of your decision some time in advance. Make sure they understand which critical parts will need a new maintainer. Ideally, if you are a community, prepare at least a very simple procedure to automate this process and make sure that you do not forget any important point before that person leaves the project (especially if she was a key developer).

4. Keep an eye on the size of orphaned code. If it rises too rapidly, or it reaches a significant proportion of your project, it is a clear indication that you will be running into trouble very soon, especially if the number of bug reports grows or you plan to revamp your code with a serious refactoring.

5. Always ensure that you leave enough tips and hints for a newcomer to take over your work in the future.

I wish I had known you were coming (before I quit)

I admit it is not very easy to think about your successors while you are programming. Many times, you just do not realize that your code may end up being taken over by another project, reused by other people or you might eventually be replaced by another person, willing to continue your work thereafter. However, the most remarkable asset of FLOSS is precisely that one: the code will be reused, adapted, integrated or extended by someone else. Maintainability is a critical feature of software engineering. But it becomes paramount in FLOSS. It is not only about source code. It is about people, social relationships and digital etiquette. It is something beyond mere good taste. Quod severis metes (“as you sow, so shall you reap”). Remember that, next time, you may be the newcomer filling the knowledge gap left by a former developer.

about the author

Felipe Ortega is a researcher and project manager at Libresoft, a research group at University Rey Juan Carlos (URJC), Spain. Felipe develops novel methodologies to analyze open collaborative communities (like free software projects, Wikipedia and social networks). He has done extensive research with the Wikipedia project and its community of authors. He actively participates in research, promotion and education/training on libre software, especially in the Master on Libre Software at URJC. He is a strong advocate of open educational resources, open access in scientific publishing and open data in science.

notes

1. ↑ Robles, G., Gonzalez-Barahona, J. M., Michlmayr, M. (2005). Evolution of Volunteer Participation in Libre Software Projects: Evidence from Debian. In: Proceedings of the First International Conference on Open Source Systems. 100–107. abstract pdf