Tag: unity

Removing the minimize button? Not giving a preference to turn off the display and not suspend when you close your laptop? Moving the window controls to the other side of the window? Making the tabs square instead of round? Not allowing the editbox to be manually resized? Hiding the RSS icon? Moving the link preview to the URL bar? Removing the status bar?

And those are just the ones I can recall at the moment.

The computer is so central to peoples’ activities, that there is a certain fear that someone will break it for them. That’s one of the major motivations behind Free Software in the first place: if I can build it myself, then you can’t force me to use the broken one. If I can’t, then MicrosoftAppleSonyPaypalMastercard can up and decide to force their will upon me, and my recourse is simply to stop using them. No stabbing big corporations with a fork.

Canonical Limited (the main driver for Ubuntu Linux) and the GNOME project couldn’t work together so they are each moving forward with their own, reinvented desktop interfaces. GNOME is going for gnome-shell and Canonical/Ubuntu will get Unity.

I don’t think this is a bad thing, excepting the bickering. The larger community of desktop Linux users will get to see two different approaches in the wild for at least a year, which will inform the next iteration of the Linux desktop landscape. There’s also an open-ended possibility for reunion later.

The dispute is territorial, which is not uncommon in open source. The uncommon part of this is simply that it’s between two big players rather than between one big player and the users. Though, the latter has occurred for both reinventions as well (see a few of the questions posed in the first paragraph).

Project governance is hard. Cooperation is hard. Finding the best way is hard.

If it weren’t for the bickering, nothing would be wrong. There’s too much distrust and fear, because that’s what we’ve been taught by the proprietary realm. When we used proprietary software, we could be stuck with a bug indefinitely. Or things could change with no warning.

So we’re edgy. But when the source is open, we shouldn’t be. And if we weren’t, it would make project governance easier, it would make progress easier. We should be willing to give the code an honest run.

At the end of the day any shift in any system will require a new equilibrium to be reached. In open source that means some users will switch, forks might be created, etc. But it also means that most users will find a slightly better workflow, will be a little (or a lot) happier and more productive.

I just wish that the developers weren’t so quick to assign blame, because they’re both building the foundation for the future, and they should be proud of their efforts even if they fail.