“The Year of the Linux Desktop” is a fable I’ve been hearing for almost as long as I’ve used computers in anger. I think it may have first come to my attention sometime in the late nineties, no doubt on the cover of Australian Personal Computer, PC Powerplay, or one of the other magazines I’d pick up that contained a CD with a 30-day free trial of AOL (which would inevitably end up being used as a drink coaster). While I’ve considered myself “platform agnostic” since at least my days at university, my preference for a functional work machine for software development has been *nix-based since the first time I was given a locked-down Windows machine for Java development, and found myself unable to perform relatively simple tasks like a tail or grep.
My current machine is a Dell XPS 13, running Ubuntu 19.04 (‘Disco Dingo’) and it works very well for what I need. I’ve got all the normal terminal-based operations I’d expect from a unix-like environment, and the default applications and GNOME environment compare very favourably with their Windows equivalents, especially when you compare them to their clunky forebears of 10-15 years ago. But the greatest utility my work PC provides me is not the Operating System, nor any particular application installed on it - it’s the fact that I’m in full control of it.
I’ve worked at a number of workplaces now where your work machine is locked down to varying degrees. Often, there are very good reasons for doing so - security is usually chief among them, and then there are numerous benefits for tech support and vendor management teams to have a unified set if applications and licenses to support. All of these need to be considered carefully when deciding what the right amount of access is to give developers to their software and hardware. Unfortunately, what often does not seem to make it into the discussion is the needs of the developers themselves. I’ve had to head off rollouts of SOE images that would have forced developers to authenticate every time they launched their IDE; I’ve been asked to justify why I have installed an ‘unauthorised’ version of Eclipse (it was two years more modern than the standard install); and I’ve witnessed heated arguments between a QA engineer and their management because “QA don’t need developer tools on their machine”.
It seems to me that an organisation is at far more risk of their top or middle management layers having loose lips over Friday night beers on the terrace, or misplacing a USB drive or document, than they are their software engineering teams starting fires by using their editor of choice or a different operating system. By all means, audit software, perform virus scans, and harden ports or entire OSes if you need to - but at some point, trust has to come into play. If a developer is going to be made less productive, or someone is going to be denied a tool that will make them happier or better at their job, sooner or later an organisation is going to either lose talent or people will find ways to circumvent the system (remember the days of ‘Portable mode’ Firefox giving sweet relief from the default IE install?).
For their part, people who want to take up the added freedom and productivity a self-managed install provides also need to ensure they take responsibile steps to safeguard their system. Currently, while I have colleagues who have security and networking specialities, they’re not in charge of ensuring my laptop is secured. They can of course help and advise, but ultimately I’m the one responsible for making sure I have backups if I need them, only use reputable sources, and keep everything patched with the latest security updates. Now I understand that’s not for everyone - but we need to appreciate we can’t demand ultimate freedom but expect someone else to hold all the responsibility. It’s like code - if you write a bin fire, you need to support that bin fire in production to feel the pain and know to do better next time. Likewise, if you want to risk a dual-boot or an exotic linux distribution, that’s cool - but you need to understand you’ve got to take a greater role maintaining and supporting your machine than you otherwise would. The same goes for non-standard tooling you might install that other teammates don’t have; it’s not up to them to conform to your new settings, it’s up to you to ensure you can all work side-by-side.
Ultimately, my current setup has seen me more productive in the last 18 months than I have been for years previously; and when I’m productive, I feel good - and when we feel good, we do our best work. That if nothing else should give organisations pause to think about what is best for their employees - or their bottom line.