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.
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?
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 :-)