Leadership in open source projects

Projects

It is common to say refer to open source as projects. While it is true that open source/free software is a project with limited resources it doesn’t have a fixed end date. I don’t think they fit the criteria of the PMBOK.

Software “projects” run from the usefulness for the maintainer and the feedback received. If a maintainer does no longer use a piece of software and doesn’t receive any feedback they might choose to not update the public version. The software is still up there but the valuable resource (maintenance) is no longer there.

This explains why it is so common to look up for activity on a “project”. If a developer/maintainer hasn’t committed or reacted in a long time the “project” is no longer active. The code might still be used, it might have more users, but it is no longer a project.

Another characteristics of projects is that there is a leadership. It might be a team or an individual like a benevolent dictator for life as explained by POSS. This leadership most important role is communication. It is not enough to have commit access or a foundation but to communicate and steward the community towards a direction or following some guidelines.

This communication is usually done by NEWS and changelog, in bug reports feedback on mailing list (and by the lack of communication too).

These leaders are those who can steward with contributor growth, support, ease of participation and technical improvements. Particularly POSS mentions the distinction between commit access and maintainer; also considering maintainers those that organize conferences, set up infrastructure and participate even if not committing code.

All the activities of the maintainers (and others) help with the project status and growth.

Growth?

There seems to be in the MMOSS book a tendency to only mention growth, which is very hard to measure. Just fo give an example focusing on users: Is LAPACK user base growing or not? I would say it is, because R uses it and more people is using R. But there isn’t, to my knowledge, a growth on users claiming to be experts on LAPACK, although there are several LAPACK optimizations.

MMOSS mentions that the (long term) contributors tend to lurk and just chime in when they can propose something of value or given the room. This is echoed by POSS, which even says that one of the roles of maintainers is to encourage other contributors to become maintainers.

Casual contributors post when they have an issue/bug while using it but they are not interested on the long term health of the software. Presumably on the classification on table 1 of the previous post refers to both. However, as acknowledge by the author it is hard to measure users and contributors.

The books always focus on the very positive outcome growth, not stagnation or reduction of users/contributors. I think it is important to acknowledge this happens too and find the causes to avoid them.

On python the support of python 2.7 had to be extended multiple times due to slow uptake of python 3.x. It might have similar effects than the upgrade from perl4 to perl5, which (besides many other reasons) left perl outside the curriculum of the universities, so without many new users.

Probably the best indicator is the relationship between users, contributors and maintainers. If these are three different groups of people, there are more users than contributors and less maintainers while the dynamics are good and the software is in good healthy status.

End

I haven’t touch much the status of code but this is also important it can be status as in quality of code and status of the software and community. The first is easier to measure and compare while the second one is much harder, more subjective and thus less general.

Whatever the status of a software is don’t forget to be nice to users, contributors and help them become more familiar with the code in a friendly manner.