Many open source maintainers feel overloaded: The new Tidelift State of the Open Source Maintainer report takes a look at the stresses maintainers are under today. In particular, lack of remuneration is putting pressure on project supervisors and 60 percent of them do not see any money for their commitment. Some give up. We talk to Volker Leendeke, who has been with us for many years samba team membersAbout their experiences with it.
Advertisement
Do you see increasing pressure due to increasing requirements, for example security, as well as a decrease in support from the community?
To be honest – no. There is always a lot of pressure on us when it comes to security. We certainly had our fair share of the usual security vulnerabilities, but Samba works in a Windows protocol environment. These protocols alone reveal the full range of attack points we are dealing with. That’s why we did it years ago Defines our security proceduresIn this respect, and this may be an overestimation of our own abilities, we actually see ourselves in a very good position in Samba.
Do you know of those neighboring projects that are groaning under the increasing pressure and perhaps not even able to handle it anymore?
One security-related project that has been publicly seeking financial support for a long time is gnupg. GnuPG specifically shows that free software is made by people. And wherever people meet, different ways of doing things come together. Samba is also not untouched by this. In the past, the Samba team has always managed to pull itself together and pull itself together. With OpenPGP, gnupg or librepgp you can also see the big advantage of free software: if your ideas go too far and you don’t need to start from scratch, you can fork.
A neighboring project, which, in my opinion, is not going well, is the SMB subsystem in the Linux kernel (fs/smb/*). Refactoring is practically impossible in the Linux kernel; You can’t just clean up code and make it better. Many places end up being ugly and so incomprehensible that you don’t even get a chance to check these places from a safety perspective.
However, there is a reason for this fundamental refusal to refactor: the Linux kernel must be patch-compatible with versions from several years ago, because backporting has been promised for a very long time. If one now allows refactoring in the main branch to make the code more understandable, it will make the job of backporters much more difficult. And this should be avoided at all costs, even at the expense of completely incomprehensible code.
I can figure it’s in the fs/smb subdirectory of the kernel, but I’ve heard from friends that it’s no different in other areas of the kernel. Besides, I don’t really have enough information about the projects to be able to make a decision.
Have you personally ever thought about giving up?
No 🙂
Volker, thanks very much for the answer!
In the “Three Questions and Answers” series, iX wants to get to the core of today’s IT challenges – whether it’s the user’s perspective in front of the PC, the manager’s perspective or the administrator’s everyday life. Do you have any tips from your daily practice or from your users? Whose suggestions on which topic would you like to read briefly and point by point? So feel free to write to us or leave a comment in the forum.
(Who)
