Slashdot Mirror
The Open Source Design Conundrum
Matt Asay writes "Walk the halls of any open-source conference and you'll see a large percentage of attendees with ironically non-open-source Apple laptops and iPhones. One reason for this seeming contradiction can be found in reading Matthew Thomas' classic 'Why free software usability tends to suck.' Open-source advocates like good design as much as anyone, but the open-source development process is often not the best way to achieve it. Open-source projects have tended to be great commoditizers, but not necessarily the best innovators. Hence, Red Hat CEO Jim Whitehurst recently stated that Red Hat is "focused on commoditizing important layers in the stack." This is fine, but for those that want open source to push the envelope on innovation, it may be unavoidable to introduce a bit more cathedral into the bazaar. Without an IBM, Red Hat, or Mozilla bringing cash and discipline to an open-source project, including paying people to do the 'dirt work' that no one would otherwise do, can open source hope to thrive?"
Thing is apple laptops are usually pretty good in design, so even OSS people will buy one and then put distro of choice on it, problem? not really. Good hardware is good hardware.
This is already being done. Many of the most successful FOSS projects have corporate contributors, so this "design conundrum" doesn't really exist. As for the popularity of Apple devices among FOSS developers, well, a lot of Apple software is based upon FOSS. In fact Apple, like it or not, is a pretty good example of how to monetize FOSS. Can't say I'm thrilled with the methods they employ to achieve that, but it's still a fact that they do achieve it.
Caveat Utilitor
That many developers feel it is beneath them and gets in the way of them developing. In the commercial space, developers rarely interact with customers in a support role or in UI design. Many would quit before performing this role, but developers in some cases are the only ones who can properly address this.
In one company I worked for, developers had to eat their own shit in that they were forced into part-time customer support of their code. When your interaction with code begins and ends with the source code control system, you have one view. When you actually are forced to see where the rubber meets the road in your customer, you think much more about the interfaces, the update processes, and the support code and scripts that get working code into working systems.
In the commercial space much effort and resources is applied in these critically important areas. With the journeyman programmers, this rarely if ever happens.
That said, the entire Internet was built by FOSS and FOSS-like processes. From ftp and telnet through WWW/mosaic, it was all someone who had an idea and wanted to see if others liked it too.
For hardware, Apple's can be of higher quality because it is higher priced. It can be higher priced because it is perceived good value -- mostly the interfaces are less botched than their competition.
I'm not insulting you, but not buying something you can't afford is not a boycott, even if their are other supposed reasons.
Commercial applications have long separated the appearance and behavior of the application from the implementation for good reason. The obligatory strained car analogy, I like cars that are quick and responsive, but I don't want one made by an engine designer. No matter how talented the engine designer is, s/he will most likely make a car suitable for engine designers.
Balancing the viewpoints of "real world users", experts, and various designers is required to do it properly. Are all these sets well represented in the FOSS contributors?
This isn't necessarily true. It's true that great design is typically the result of a unified vision but design focused companies solve this problem by having a lead designer establish guidelines and standards that are then used by the team to create all the bits and pieces. You don't need one person, but you need one person in charge. For an Ubuntu, RedHat or OpenOffice where you have a corporate structure behind you, this level of design quality is achievable and I think they have it now. For a project of volunteers or a team that's widely distributed this has to be much more difficult.
Without the ability to write code, designers depend on an organizational structure that recognizes and values good design and will work to make sure that the end result meets the design goals you initially set out. This can fail in a non-OSS project and could succeed in an OSS project but a hobbyist project will probably never have a structure that allows a designer to do great work.
Another issue that I think isn't addressed here is that OSS projects are typically (necessarily?) started by people who can code. Once you have something running it takes a huge amount of effort to redesign away some of those early design decisions. You'll also forever be in a mindset that views design as window-dressing that gets applied to APIs. I'm not familiar enough with the history of OSS projects but are there examples of projects that started with a design process?
In business, you invest. That means you have a strategic goal you want to achieve with the input. That's what is missing most of the time in open source projects: goals. Most of these so called developers are actually just maintainers with no vision whatsoever. The business side also requires to build vision (or perish), yet another thing 9 out of 10 open source projects lack completely.
There is something extremely toxic to innovation in open source. One could solve the Ubuntu's #1 bug in 3 years flat if the way people worked and thought could be made to change. It's really not about resources or technology, just the fact that the progress is not being LEAD.
It's even worse than that due to inconsistency. In mac/windows, in a program such as a mail client like outlook, the list of mail subjects will scroll when the mouse cursor is in that subwindow and the body of the mail will scroll when the mouse cursor is in that subwindow. So they have click-to-focus between windows and sloppy focus between subwindows. I had a difficult time explaining this to my grandfather.
:)
I'm also quite unclear on why mac has this reputation for good usability/interface because in the few times I have used it I have encountered interface inconsistencies even within the base applications such as network settings. (e.g. radio buttons for "on"/"off" in one interface(dhcp) and a drop down box for "enable"/"disable" for another(static)) And, of course, inconsistencies between applications, too. Mail settings have cancel/save/apply buttons, but to save network config changes you have to close the window(hit the red x) and then get presented with an option to apply changes. Hitting a red x to apply your changes is almost as silly as hitting the start button in windows to stop your pc.
The price?
One axis I've not seen discussed is that most developers are using textual languages. Most mathematics is essentially text based, not diagram based. One uses diagrams for intuition, but when the formal derivation or program must be done, it is done in text.
The problem then becomes that the concepts expressed in the software are most easily explained in terms of text, not diagrams. Guis are diagrams. Consider, just for a mental exercise, any of the unix shells and their languages. Most developers have no problems. Most users would rather gnaw off their right arm than go through learning a shell language and then relearn in it 6 months when they must use it again.
So, let's see what it takes to produce a gui for it. Apple used to have a system called MPW. You could hilite a command and call up its Commando interface. The commands themselves were rather textual and unixy, but the interface allowed you to click radio buttons, use pulldown menus, etc. to construct a command. The command constructed as text and shown in an editable window at the bottom of the dialog box for the Commando interface of the command. You could run the command right there or copy the text and run it in another window. That sounds about the right level.
Now we must think about piping. There was a language called Prograph, but now called Marten. It is an object orientied data flow language. It is a diagrammatic language and one draws lines to 'pipe' objects from one command to another, with some special lines for control ordering. There are mechanisms for recursion and the usual range of program construction artifacts.
One could combine the two, Marten and Command and successfully guitate unix shell languages (I'm sure there are other concepts that would need to gui equivalents for those languages). Now think about the amount of work necessary to do this. The point is that guis take an extraordinary amount of time and effort, and most of the skills are not the headless (non-gui) development most developers are familiar with and it is a paradigm directly at odds with their programming languages.
I see no entity within the FOSS community that could do such kinds of design and get it stick so that it becomes the faces of the OS or the applications for casual users who might wear an occasional python boot (think Frank Zappa). OpenOffice isn't an example, it is the usual retarded word processor editor that Microsoft pushes with the usual result that people would rather use Office since OpenOffice isn't buying them anything in which they are interested.
UI design isn't dirt work; it is actually very fun and rewarding. The thing is it is hard to wear both a "UI Design Hat" and a developer hat at the same time. Why? The UI guy in you wants a usable UI and the programmer wants a usable codebase--those two goals are often highly conflicting. Good UI design often requires code that often needs to deal with crazy edge cases, or code that has to turn fuzzy human illogic into clean, elegant programming. If you try to wear both hats, the developer in you will fight the UI guy in you because the UI guy wants you to create a feature that the programmer in you knows will be a messy pain in the ass.
Once an organization gets large enough, you can have different people wearing the hats. This works great in an environment where there is a communication process for the two to talk to eachother. In the open source world, such communication channels typically donâ(TM)t exist--there is no process that has really been established. You might get UI guys dropping golden nuggets on the project mailing list from time to time, but you donâ(TM)t have the UI guy meeting up with the developers on a daily basis.
If you want the UI guys to be in on the party, the culture of open source development will have to shift to make use UI guys are not only included in the entire development cycle, but more important--they are seen as equals in the process. If the UI guys says "this design sucks", the developers don't implement it. I dunno if that is part of the culture nor am I sure how or if such a thing could ever be pulled off. UI guys get the props they deserve in paid jobs simply because there is a financial incentive to listen to them. Without that financial incentive, the only incentive to spend your time working on open source is the joy of programming. When you are doing programming for the joy of it, you donâ(TM)t want some UI guy (even if it you) raining on your pretty looking, well designed code :-)
stable kernel ABI
Oh, this old, tired and debunked canard again. Now your blaming poor quality drivers on it? Are you trying to claim that Windows for instance has nothing but excellently written, high quality drivers? Pure OSS drivers have many advantages, such as working for ages, supporting all features of the hardware and so on. If yu purchase with care you will have no trouble under Linux. If you fail to do so you will have trouble on any system.
Proprietary progeams needing 15 versions
If the proprietary application comes with all the .so's it needs, or statically linked, then it will work on any distro. I have several proprietary applications and they all run just fine on Arch, with no effort. If you are not able to successfully ship such programs, then I suggest you employ someone who knows how to do it. See, for example Matlab, Skype, World of Goo and so on.
Package managers are bad
So, if package managers don't support proprietary code, then what are proprietary thing doing in the repositories of Ubuntu, SuSE, Arch and etc...? The Linux package managers are the best out there. Nothing even comes close in reliability and ease of use.
As for the arrogance, have you ever paid anyone to maintain packages for you? If not it seems somewhat arrogant to think they should care what you want.
DLLs
WTF? That's why DLLs are versioned on unix. If you're overwriting DLLs, then someone has fouled up.
The self protecting idea is nice, though. You can probably do it with chroot.
SJW n. One who posts facts.
Walk the halls of any open-source conference and you'll see a large percentage of attendees with ironically non-open-source Apple laptops and iPhones
There are many "open source" developers. It wouldn't surprise me if Java or PHP developers use a lot of Macs. But what does that actually show? Just because people use or develop open source in one niche doesn't mean that they need to use open source for everything. And their reasons are probably the usual ones: Microsoft compatibility, appeal of Mac hardware, what they are used to, ... It does not show that Macs are easier to use than modern Linux desktops.
Open-source projects have tended to be great commoditizers, but not necessarily the best innovators
Really? Many innovations have first become available in open source form before companies like Microsoft and Apple finally managed to ship them as part of their commercial software. And what actual innovations have Microsoft or Apple actually created? I mean, much of Apple's platform is based on open source software.
I think the real reason it seems like Apple and Microsoft innovate so much is... because they spend billions of dollars to create that illusion.
Ubuntu, Apple products and the Python programming language have all stood out with their exceptional usability because of their "benevolent dictators." When everything's decided by committee (even loose ones like in FOSS), every drastic but beneficial change will be pecked down by the naysayers. Something like Python 3's intentional backwards incompatibility, done for the sake of a vastly cleaner language syntax would never had made it without Guido's spearheading of the effort.
CompizConfiguration Settings Manager's interface isn't great, but you really shouldn't use the 'Advanced Search' as an example. The window you are showing is the final result of the actions. In the beginning it only has a few UI elements. As you search and select stuff, more tabs and boxes come into view. So while you're using it, it isn't as bad as that screenshot shows. Also, that is not the default search. There is already a simple search on the main page of that program and you have to choose Advanced Search to begin your journey to the screen you depict.
Really, there are more legitimate things to complain about. The fact that the means of activating different effects isn't consistent, for instance, really annoys me.
Example: You can set a Screen Edge/Corner, or a Mouse Button or a Keyboard button for most plugins in the plugin's own dialog. However, for Show Desktop, you have to go to the General section because the Show Desktop plugin only has other settings in its dialog.
Everything does just work, most of the time. When it doesn't, you can wind up screwed :) I agree with nearly everything in your post, but not painting OS X as a bulletproof, unfuckupable OS.
free software doesn't suck any worse than any other sort
Oh yes it does.
Package managers are dreadful.
They picked one of the most stupid idea to ever come out of Redmond, installers, and made it worse by having different types or versions for each and every distribution *and* completely centralizing the process.
I feel sorry every time I think about it. The first and last thing the bazaar guys did when it came to installing applications was to design the most cathedral process they could come up with, only recently beaten by Apple with the iPhone app store's vetting process :-((
I don't want to look up the application in the package manager UI, I'm on their website, that's how I know I want to install it, let me download from there! The UI is often cr*p anyway, the search function is a pain, always returning 15 results that are similar apps, localized versions, devel versions, obsolete versions, and god knows what. I don't care about stinking dependencies, just run the app with the libs it ships with.
And of course it took Apple to show how to do *that* right.
Yeah, so it's less efficient, you have to download the same libs several times, the OS would need to load it several time (although that's fixable). So it doesn't work with more obscure programs that need to fiddle with options here and there. So it runs applications from their own dirs, which is not "the unix way".
So what, I don't care, and neither do most of the users. They download, open the dmg (or , for linux, tgz, or whatever), double click the icon, the app starts. You can copy it somewhere else if you like it. Delete and it's gone. Magic.
Keep the package stuff for server apps, by all means (although I tend to compile from source myself), but forget it for desktop apps.
You're right. In fact, that's one reason I use Linux -- when things go wrong, I can fix them. When things go wrong with a Mac, I'm pretty much lost.
However, the fact that I still have to edit xorg.conf is pretty embarrassing.
Don't thank God, thank a doctor!
Package managers are a bug, not a feature. They are a byproduct of the way open source is developed--one where everything can be compiled from scratch. If open source somehow had everything shipped as binaries, you would never have a package manager.
In other words, I wouldn't brag about package managers if I would you. You should work your ass off to get rid of them and replace them with installers or how the Mac does it. They are nothing at all to be proud of. They are a (sometimes rather elegant) hack to work around the (sometimes rather useful) nature of open source.