The desktop and the developer
May. 18th, 2014 10:53 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59I was at the OpenStack Summit this week. The overwhelming majority of OpenStack deployments are Linux-based, yet the most popular laptop vendor (by a long way) at the conference was Apple. People are writing code with the intention of deploying it on Linux, but they're doing so under an entirely different OS.
But what's really interesting is the tools they're using to do so. When I looked over people's shoulders, I saw terminals and a web browser. They're not using Macs because their development tools require them, they're using Macs because of what else they get - an aesthetically pleasing OS, iTunes and what's easily the best trackpad hardware/driver combination on the market. These are people who work on the same laptop that they use at home. They'll use it when they're commuting, either for playing videos or for getting a head start so they can leave early. They use an Apple because they don't want to use different hardware for work and pleasure.
The developers I was surrounded by aren't the same developers you'd find at a technical conference 10 years ago. They grew up in an era that's become increasingly focused on user experience, and the idea of migrating to Linux because it's more tweakable is no longer appealing. People who spend their working day making use of free software (and in many cases even contributing or maintaining free software) won't run a free software OS because doing so would require them to compromise on things that they care about. Linux would give them the same terminals and web browser, but Linux's poorer multitouch handling is enough on its own to disrupt their workflow. Moving to Linux would slow them down.
But even if we fixed all those things, why would somebody migrate? The best we'd be offering is a comparable experience with the added freedom to modify more of their software. We can probably assume that this isn't a hugely compelling advantage, because otherwise it'd probably be enough to overcome some of the functional disparity. Perhaps we need to be looking at this differently.
When we've been talking about developer experience we've tended to talk about the experience of people who are writing software targeted at our desktops, not people who are incidentally using Linux to do their development. These people don't need better API documentation. They don't need a nicer IDE. They need a desktop environment that gives them access to the services that they use on a daily basis. Right now if someone opens an issue against one of their bugs, they'll get an email. They'll have to click through that in order to get to a webpage that lets them indicate that they've accepted the bug. If they know that the bug's already fixed in another branch, they'll probably need to switch to github in order to find the commit that contains the bug number that fixed it, switch back to their issue tracker and then paste that in and mark it as a duplicate. It's tedious. It's annoying. It's distracting.
If the desktop had built-in awareness of the issue tracker then they could be presented with relevant information and options without having to click through two separate applications. If git commits were locally indexed, the developer could find the relevant commit without having to move back to a web browser or open a new terminal to find the local checkout. A simple task that currently involves multiple context switches could be made significantly faster.
That's a simple example. The problem goes deeper. The use of web services for managing various parts of the development process removes the need for companies to maintain their own infrastructure, but in the process it tends to force developers to bounce between multiple websites that have different UIs and no straightforward means of sharing information. Time is lost to this. It makes developers unhappy.
A combination of improved desktop polish and spending effort on optimising developer workflows would stand a real chance of luring these developers away from OS X with the promise that they'd spend less time fighting web browsers, leaving them more time to get on with development. It would also help differentiate Linux from proprietary alternatives - Apple and Microsoft may spend significant amounts of effort on improving developer tooling, but they're mostly doing so for developers who are targeting their platforms. A desktop environment that made it easier to perform generic development would be a unique selling point.
I spoke to various people about this during the Summit, and it was heartening to hear that there are people who are already thinking about this and hoping to improve things. I'm looking forward to that, but I also hope that there'll be wider interest in figuring out how we can make things easier for developers without compromising other users. It seems like an interesting challenge.
But what's really interesting is the tools they're using to do so. When I looked over people's shoulders, I saw terminals and a web browser. They're not using Macs because their development tools require them, they're using Macs because of what else they get - an aesthetically pleasing OS, iTunes and what's easily the best trackpad hardware/driver combination on the market. These are people who work on the same laptop that they use at home. They'll use it when they're commuting, either for playing videos or for getting a head start so they can leave early. They use an Apple because they don't want to use different hardware for work and pleasure.
The developers I was surrounded by aren't the same developers you'd find at a technical conference 10 years ago. They grew up in an era that's become increasingly focused on user experience, and the idea of migrating to Linux because it's more tweakable is no longer appealing. People who spend their working day making use of free software (and in many cases even contributing or maintaining free software) won't run a free software OS because doing so would require them to compromise on things that they care about. Linux would give them the same terminals and web browser, but Linux's poorer multitouch handling is enough on its own to disrupt their workflow. Moving to Linux would slow them down.
But even if we fixed all those things, why would somebody migrate? The best we'd be offering is a comparable experience with the added freedom to modify more of their software. We can probably assume that this isn't a hugely compelling advantage, because otherwise it'd probably be enough to overcome some of the functional disparity. Perhaps we need to be looking at this differently.
When we've been talking about developer experience we've tended to talk about the experience of people who are writing software targeted at our desktops, not people who are incidentally using Linux to do their development. These people don't need better API documentation. They don't need a nicer IDE. They need a desktop environment that gives them access to the services that they use on a daily basis. Right now if someone opens an issue against one of their bugs, they'll get an email. They'll have to click through that in order to get to a webpage that lets them indicate that they've accepted the bug. If they know that the bug's already fixed in another branch, they'll probably need to switch to github in order to find the commit that contains the bug number that fixed it, switch back to their issue tracker and then paste that in and mark it as a duplicate. It's tedious. It's annoying. It's distracting.
If the desktop had built-in awareness of the issue tracker then they could be presented with relevant information and options without having to click through two separate applications. If git commits were locally indexed, the developer could find the relevant commit without having to move back to a web browser or open a new terminal to find the local checkout. A simple task that currently involves multiple context switches could be made significantly faster.
That's a simple example. The problem goes deeper. The use of web services for managing various parts of the development process removes the need for companies to maintain their own infrastructure, but in the process it tends to force developers to bounce between multiple websites that have different UIs and no straightforward means of sharing information. Time is lost to this. It makes developers unhappy.
A combination of improved desktop polish and spending effort on optimising developer workflows would stand a real chance of luring these developers away from OS X with the promise that they'd spend less time fighting web browsers, leaving them more time to get on with development. It would also help differentiate Linux from proprietary alternatives - Apple and Microsoft may spend significant amounts of effort on improving developer tooling, but they're mostly doing so for developers who are targeting their platforms. A desktop environment that made it easier to perform generic development would be a unique selling point.
I spoke to various people about this during the Summit, and it was heartening to hear that there are people who are already thinking about this and hoping to improve things. I'm looking forward to that, but I also hope that there'll be wider interest in figuring out how we can make things easier for developers without compromising other users. It seems like an interesting challenge.
no subject
Date: 2014-05-19 06:50 am (UTC)Sadly, the pinnacle of desktop Linux was Ubuntu around 2009. Most of the people I know who switched to Linux made the switch around that time. You had excellent apps, a simple UI that let you get your work done, a technical basis that was tried and stable, and thanks to Ubuntu, easy installation and configuration. After that, it went downwards. Paradoxically, trying to modernize Linux (the distributions, not the Kernel), has driven people away instead of luring them.
But even if Linux were to return to its virtues of a simple GUI, compatibility, and solid underpinnings (now that Gnome 3 and Unity are more mature, once the dust settles on the systemd, wayland, ... migrations), it would still compete with OS X which does all that right now. So what's the USP of Linux over Mac? Even if people don't like to hear it, Linux Is About Choice. (Or, for nitpickers: "what makes cost-free unix distributions (mostly using the Linux Kernel and GNU stuff) great is that I can change my desktop theme".) No, seriously. Make it easier to run stuff from different desktops in parallel. Make it easier to swap components. Let me run Gnome Shell, with the Mint version of Nautilus, but with the titlebars of KDE, and the theme of Ubuntu. Give me ten great themes to pick from.
So, make Linux comfortable, compatible, and configurable, and I believe all the developers will come back :-)
no subject
Date: 2014-05-19 07:14 am (UTC)But at the end of the day you work using a text editor, IDE, word processor, web browser, ... not a configuration dialog.
no subject
Date: 2014-05-19 02:39 pm (UTC)Everyone's workflow is different enough that an OS can't make a good non-tweakable judgement call on some things like the above.
no subject
Date: 2014-05-19 08:34 pm (UTC)Mac isn't all wonderful either but they are things further down the road. For example it requires correct file extensions to show file contents while Linux examines the file contents directly only using the extension as a hint. All the open source (eg bash) is years old due to Apple's GPL3 hatred.
If you want a system where the little things all work first time, a Mac is the way to go. I cannot work without focus follows pointer. That is pretty much the tweak for me, and Linux is where you get it.
no subject
Date: 2014-05-21 09:42 pm (UTC)I've seen this comment several times in relation to this article.
First, this is simply not correct. OS X uses UTIs (and prior to that, and in Classic, used creator codes). OS X infers UTIs from extensions - and this is the most common source for UTIs for filenames - but they can also be set in other ways and are used by "filename-less" things like the clipboard. Think of a UTI like a tagged union of possible MIME types and filename extensions. https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/understanding_utis/understand_utis_conc/understand_utis_conc.html#//apple_ref/doc/uid/TP40001319-CH202-CHDHIJDE
And this is the right way to do it. Looking at the file contents without the extension simply doesn't work. If I name a file with .oga I want it to open in an audio player; .ogv, a video player. But these can have the same MIME type, and neither is trivially identifiable from the contents. Or any of the thousand formats that are just a zip file. You _need_ filename extensions to make the right choice; I don't want to extract cbz files and I don't want to open source archives in my comic reader, and _nothing_ about the contents of the file will tell you which it is.
"Using the extension as a hint" is meaningless. Either you're using the extension, and you should follow it even if the file doesn't "look right" because why should there be a tool that knows how to parse literally every kind of file to make sure it "looks right"? Or you're not and that's terrible because now someone tricked the user into running trojan.jpg as a script.
It's something of a shame that file extensions are part of the file name. But it's not a shame that there's a visible, default, user-editable, otherwise vapid tag on every file that determine what application it will open with.
This kind of user-hostile focus on shallow and actually totally arbitrary "technical correctness" is one of the things that actually makes the GNU/Linux desktop inhospitable. Glyf outlined other good ones.
hardware support
Date: 2014-05-22 12:05 am (UTC)Apple has full control over the hardware and software, so of course you don't have those issues. Talk to the manufacturers of those computers about why they don't provided useful information to the Linux kernel developers.
Re: hardware support
Date: 2014-05-22 10:13 am (UTC)Some of them, like the HDMI audio, is free software developers not paying attention to details.
And sometimes, your multimedia keys don't work because GNOME decided, in a minor release, to grab all multimedia keys in a way completely incompatible with all existing applications using them and in a way that required nontrivial integration with (at the time) unstable parts of the GNOME software stack and a new poorly-documented API, which changed again a few releases later.
Re: hardware support
Date: 2014-07-22 11:34 am (UTC)no subject
Date: 2014-05-20 11:42 am (UTC)Maybe I like Gnome, but frequently have to type things in a terminal while looking at something else. Gnome's terminal doesn't support transparency anymore. It's great that another fully featured terminal is just an apt-get away.
Maybe I work with a lot of windows, and for my workflow I like to roll-up windows (which is supported by KDE's kwin).
There are a lot of different use cases and workflows. The great thing about using a Linux distribution instead of OSX or Windows is that it can accommodate a lot of these out of the box, as the parts are interchangable. (Well, at least that used to be the case.)
And yes, people *do* also simply tweak. Customization and individualization is incredibly important to many people. If you weren't able to change the wallpaper, lots of people would reject an OS. It is a feature of "Linux" that you can change the theme, choose to use a dock, a taskbar, or the GNOME shell, and so on. Of course, it is not necessary, but to me and many people I know it is a huge draw, and one of the biggest reasons to choose Linux.
If a Linux distribution is no longer app-modular, tweakable, and stylable, well then it is just an inferior Unix to OSX (for the Desktop of course).
no subject
Date: 2014-05-20 03:16 pm (UTC)I thought that myself until I recently had to boot and sort something out on an older powerpc mac. Just how different an early OS X was to the current one was quite shocking to me. I think the reason we think that it is essentially unchanged is because they've pursued a slow, steady, measured set of carefully considered improvements. See this pic of OS X 10.0 to see what I mean
http://en.wikipedia.org/wiki/File:MacOSX10-0screenshot.png
no subject
Date: 2014-05-21 12:27 pm (UTC)And that turned out to be a blatant lie. You don't like systemd? Then you're out of luck. You want to keep cdrtools instead of its mediocre fork wodim? Have fun building it yourself and fighting it through against dpkg/rpm. You like OpenOffice more than LibreOffice? Well, your distributor knows better, what is good for you...
Or you go with Windows or OS X and just install whatever you want, right from the developer's website, ready to go. Funnily enough, side-loading recent open source application software is a lot easier on Windows and OS X than on Linux.