Linux, politics, and other interesting things
It’s common to hear a complaint of the form “I get paid to keep computers running not hack an OS” coming from someone who uses an Open Source OS such as Linux, BSD, or Open Solaris.
It seems to me that part of the job of keeping computers running when using Open Source software IS to hack the source and fix bugs. This takes the place of praying, begging, and having your employer pay arbitrary extra amounts of money to the vendor when you have problems with proprietary software.
It’s well understood that a good system-administrator will anticipate problems and implement solutions to them in advance. You don’t wait for a system to run out of disk space and then fix it – you install cron jobs to compress and remove old log files and have a monitoring system to tell you if disk space really runs low.
It seems to me that the approach that many companies take towards fixing software bugs goes against this ideal. They wait for software to fail in production and then file a bug report and hope that someone else will fix it.
When allocating time for various tasks it’s not uncommon to have various amounts of staff time devoted to different servers, departments, or projects. I believe that having a fixed amount of time devoted to finding and fixing bugs in Open Source software (both current versions and pre-release versions) would save money for a company in the long term. If 10% of the time of the most skilled programmers was assigned to finding and fixing bugs in the OS then the overall quality would improve. If a company depends on Debian then it would make sense to have this 10% time include testing out the production programs on Debian/Unstable, it if depends on Red Hat Enterprise Linux then it would make sense to test them out on Rawhide. This would increase the ability of the future releases of Debian or RHEL to support the applications in question, and might also discover some application bugs.
Also it’s very important to submit patches with bug reports. It’s not uncommon for a bug report to be critically important to a user but not overly important to the rest of the world. Such bugs can stay in a bug tracking system for a long time without getting fixed. But if there is a patch submitted that includes necessary documentation patches and a description of the tests that it has passed then it will probably be easier to include it than to debate whether it’s really needed.
If a project is only running for a matter of weeks or months (EG a consulting company that comes in, deploys a “solution” and then leaves) then there is probably no benefit for doing this. But if a company is going to be running servers for many years which will periodically be upgraded then it would be a real benefit to have bugs fixed in future versions.