LWN's 2020 vision

The Python community will continue to chart its post-Guido course. One relatively unnoticed development in the Python project's 2020 steering-council election was the quiet withdrawal of project founder Guido van Rossum's nomination. While he will still participate, he no longer wants a leadership role in the project. Increasingly, Python will have to find its way without the developer who has guided it since the beginning.

Similarly, the GNU Project will have to decide what it will be in the 2020s. This project's founder, Richard Stallman, retains his post as its leader, and it's possible that he will still be there at the end of the year. But there is ongoing restlessness in the project that brings a desire for new leadership and new directions. After all these years, it still sometimes seems like GNU is stuck trying to reproduce the Unix workstations of the 1980s, leaving much of the current computing environment to systems that are half-free at best. We need a GNU project for mobile devices, private clouds, home systems, embedded applications, and more. Stallman once famously said "I'm not really concerned with what's running inside my microwave oven." The time has long since come to be concerned about such things; wouldn't it be a great thing if a newly reinvigorated GNU project were to take on this challenge?

There is a common theme to those last two items that may not really arise in 2020, but will certainly come about in the 2020s: many of our leaders in the free-software community got their start in the 1980s and 1990s. In talking with those people, your editor increasingly gets the sense that many of them are thinking they have done this sort of work for just about long enough. Retirements will increase in the coming years, and we will lose much of the skill and experience that has gotten us this far. There are plenty of skilled and motivated younger developers who can certainly pick up where these folks leave off, but the transitions will go more smoothly if they are properly planned for.

The presence of highly experienced developers is perhaps felt most strongly in the kernel project. This is a good thing in a setting where mistakes can be catastrophic on a large scale, but it also partially explains why kernel developers have a distinctly old-school workflow. This is, remember, the project that only started using a source-code management system in 2002. Change is afoot, though, and the kernel workflow efforts will begin to bear fruit in 2020. We'll still be sending patches over email at the end of the year, but we'll have an improved understanding of what a better solution that can work at the kernel project's scale will look like. As part of this effort, the kernel's testing tools will also continue to improve at a rapid rate.

For all its faults, though, the kernel's workflow produces reliable results. Thus, it is relatively safe to predict that the next long-term stable kernel release will be 5.9, on November 1, 2020. Most kernel release cycles have taken ten weeks in recent times. Should the process run a little faster and produce some nine-week releases, then the LTS release will, instead, be 5.10 in late December.

Strife in the Debian community will continue despite the project's recent decision on init-system policy. Debian suffers from a combination of hostile outsiders and certain project members who actively work to create turmoil on its mailing lists. The Debian community is resilient, and it will get past these problems too. But its mailing lists may not be a lot of fun to read in the meantime. The Devuan project, despite having picked up a post-vote defector or two from Debian, will continue to struggle for developer time and relevance.

It is now 20 years since the year-2000 bug failed to destroy civilization. Some now see y2k as an irrational panic, but without a focused effort there would have indeed been serious problems. The year-2038 bug looks distant and harmless, but it, too, requires a determined effort to avert real problems. The good news is that the year-2038 fixes will be mostly completed in 2020, at least at the kernel level. Yes, your editor has predicted this before and taken some good-natured grief for it, but this time it's for real.

BPF API issues will not go away in 2020. The in-kernel BPF virtual machine makes a great deal of power available to user space, and that will only increase in the coming year. Software providers will realize that it is often far easier to ship a BPF program to customers than to get a needed feature into the kernel itself. Sooner or later, one of those programs will break as the result of internal kernel changes and those customers will complain, quite possibly causing needed work to be reverted. The fact that much BPF functionality is available to proprietary programs is likely to create troubles of its own. A quick check shows 142 BPF helper functions in the 5.5-rc4 kernel; only 34 of those are marked GPL-only. Some developers are sure to see the growing set of BPF functions available to proprietary code as an erosion of whatever GPL protection the kernel has left.

Expect perturbations in the employment market as various economic realities catch up with us. Both the dotcom crash and the 2008 crisis impacted the development community; the next downturn will do the same. As in the past, Linux and free software as a whole will not be significantly hurt when this happens, but the same cannot be said for individual developers, at least in the short term.

Finally, though this is perhaps more of a wishlist item than a prediction: the free-software community has to think more deeply about what it is creating and how that will affect the world. At many levels free software has won; the world's computing infrastructure is built on the code we have created. We have much more control over our computing environments than we would have believed all those years ago; it's a great success.

But we have also created — and continue to develop — the foundation for the most intensive surveillance machine the world has ever known. We have helped to build a world where sex toys report on their usage patterns, video doorbells cooperate with police, companies are attacked via fish-tank thermometers, cars can be disabled remotely, elections can be attacked by hostile countries, televisions report viewing habits, home devices phone home with audio recordings, and more. All of this machinery is used to sell us things, or to direct our behavior in even less benevolent ways. It is increasingly concentrated in the hands of a tiny number of huge companies; using it will inevitably prove to be a temptation that governments are unable to resist. We wanted a world where we controlled our computers, but we have created a world where our computers are used to control us. It is not enough to blame the companies involved; we have helped to build this world.

Back in 1983, the GNU project helped to focus attention on the need to create a free operating system for our desktop computers. Now we desperately need a project that can bring a similar level of attention to the need for free computing in every aspect of our lives. Free software was able to demonstrate enough advantages to convince companies to adopt it, even if it was less convenient in some ways at the time. The next generation of free software (along with freedom-respecting devices built on it) has to succeed in convincing people that there is a better way. If the free-software community can rally around this project, the outlook for the 2020s in general will be much improved.

On a more mundane level, LWN is about to celebrate its 22nd birthday. Thanks to the solid support from you, our readers, we are still going strong after all these years. We wish for a great 2020 for all of you and we look forward to write for the best set of readers any publication could hope for.