Doghouse – Continuity

In a conversation with a chief technical officer (CTO) of a web-hosting company the other day, he mentioned that a large piece of FOSS that his company depended on was being removed from the Linux kernel, because there was no one to develop and support it. While he did not really come out and make the accusation, I inferred from his remark that he felt parts of the Linux kernel were not receiving proper attention, given their importance to the FOSS world.

This does happen, and it has been noted in the past. Typically at the last minute, the FOSS community will belly up to the bar, and a few more developers will be found. Or some company will fund the primary developers, so they can spend full time supporting the software that they had been supporting and developing in their spare time.

Yes, the FOSS community has a coverage problem from time to time. Yes, sometimes software that we depend on goes stagnant, with the developers either leaving the project or sometimes (unfortunately) dying. This is why software projects need to spend as much time "building community" around their projects as they do writing code. The project leaders have to attract new talent, both building enthusiasm for the project, as well as building expertise in those who will become the new architects and leaders of tomorrow.

The fact that closed source software has the same problem did not occur to my CTO until I mentioned it, and the look on his face was priceless. I pointed out that not only do whole companies (sometimes very large ones) disappear and their products become useless, but companies drop product lines or features when they are deemed "not profitable" (or not profitable enough).

The difference between "open" and "closed" projects is that typically "open" projects give warning signs that are visible for those who know how to look for the signs. The rate of code submissions, the last date of code release, the number of developers, activity on the mailing list – all can be indications of a project's strength. Of course, to ask "Mom&Pop" to do this analysis is typically beyond their capabilities, but the CTO could certainly have done that task.

Also in the case of the CTO, if his business depended on the functionality that was being dropped from the kernel, he could have volunteered resources to keep that functionality alive or switched to a long-term kernel that had the functionality in it while he devised a plan to recover. The functionality being dropped from future kernels did not mean it would suddenly disappear from existing kernels.

Still, the issue of "coverage" is an important one and touches more than just the software and hardware itself.

In the "good old days," a mainframe computer typically had only a few applications on it at one time. The mainframe might be dedicated to a specific task or tasks, and the number of layers and dependencies in "the stack" were small. In the modern world of servers and the cloud, the number of dependencies seems to grow without bound, and a "dependency nightmare" pushes us toward containers, which allow the nightmare to grow even faster. To try and keep up with all of the different pieces of code that your business depends on is a difficult, if not impossible, task.

Part of this issue is the graying of the FOSS development world. When I started with the Linux project, I was "only" 43 years old. Linus was 24 when I met him. Next year, I will be 69 (itself an interesting number), and Linus will be 50. There were discussions a long time ago about what would happen to Linux if something happened to Linus, and he put the issue to rest, pointing out that many of his lieutenants would be perfectly capable of taking over from him. Nevertheless, the conferences and meetings that used to have sandal-wearing twenty-somethings now have graybeards attending. These graybeards need to work extra hard in "passing the baton."

It is not the Linux kernel that worries me, but the hundreds of thousands of FOSS projects on which we all depend. Each project leader should develop an exit strategy with regards to their project. Who takes over if something happens to the project leader? Who controls the domain name and other intellectual property of the project? Does anyone know all the passwords necessary to keep developing the project? Is someone identified (even tentatively) who would be able (and willing) to take over the project? Does this person have what they need to take over? Waiting until the project absolutely needs this information is often too late.

Go out and find those Padawans and work hard to develop them into the next generation of Jedi Knights.