Hi, Yay, discussion is looking more useful ;-)
Here's an applicable article to much of what you're saying: http://www.gnomejournal.org/article/5/experimental-culture That article tries to imagine a path that's neither "a fun project by and for developers, but sucky for everyone else" nor "a kind of boring same-old project," in part by wondering if we can find a way to try lots of stuff without necessarily _shipping_ all of it. How to get there in practice, I don't know. On 12/13/05, Linus Torvalds <[EMAIL PROTECTED]> wrote: > I don't understand why you and Havoc seem to be of the opinion that > working well out of the box and having good defaults is in any way > something I argue against. For me, it's just that I don't think you're 100% right here: > So you can have your cake and eat it too. It's not an either-or thing. That just doesn't match my experience. I'm not saying it can't be done, but in terms of desktop stuff I've seen, it's always seemed to be a tradeoff, for a variety of reasons. Firefox is maybe the best example of escaping the tradeoff I can come up with. I don't have a lot of insights into how it came to be and what their process is. > But _indirectly_, the thing that open source really excels at, is the > flexibility it offers thanks to having lots of users, and lots of users > whose needs get _heard_. My view on this would be that in an open source project, absent some outside force (such as the maintainer or the project culture) the needs of technical users get heard, but the needs of most other kinds of users do not. You get a "GNOME 1.4" kind of product. Thus if the goal of a project is primarily about some subset of nontechnical users, you need to find a way to stay out of the "by and for developers" problem - there are probably several ways. > THAT is the core of open source. You've got > different kinds of people that get attached to a project. It's _not_ a > corporate mono-culture, because people from different backgrounds can get > together and work on it _without_ going through the corporate mind-wash. BTW I really don't think the design/usability stuff is corporate at all; it's counter to most of the corporate interests on this list and elsewhere, and many companies have "by and for developers" as a strong de facto reality, just like open source projects. "By and for developers" by the way is better than some popular alternatives in the proprietary world, like "by incompetent developers for nobody-knows-who" ;-) and this does give open source a certain baseline that's better than average. But it's not enough to compete with the best examples of consumer products, even though it's perfect for designing and implementing web servers and IDEs and that sort of thing. > And to me, gnome is killing itself as an open source project, because it > ends up dismissing exactly that thing. I don't think oscillating back to the previous extreme is going to be progress; to get anywhere, we need to find the "best of both worlds" kind of setup. > Having strict UI rules ("The HID > says so-and-so") that are really a religion that you're not allowed to > question. I sit in the same office as Bryan Clark (one of the HIG authors), and last week he was complaining about zealots quoting the HIG back at him without knowing he wrote it. The "G" is for Guidelines, and really, the HIG is just cosmetics anyhow. You could not use the HIG to design something like the print dialog, other than the uninteresting parts like how much spacing between labels. A HIG-type document addresses UI consistency, but it doesn't address the design questions for a particular new capability. What printing-related stuff is there, how does it work, what does it let people do; the HIG isn't going to cover that. It's not a design algorithm. > And I think that's important. It's important, because that developer > energy, in the end, is what get things done. And as a side effect, you > will automatically end up with a system that understands that defaults may > be good, but that different people have different needs and views. Because > you had a very diverse group of people that worked on it. Here I just don't agree. Programmers as a group are very possible to distinguish statistically from the general population: introverted, male, for starters. Open source programmers are even more skewed away from the general population than programmers as a whole. But while that could be arguable, programmers are *definitely* very different if you start measuring how and why they use computers. For example, they will almost all be shell users, and shell users have a lot of special expectations and mental models. So while sure you have some geographic diversity and other kinds among developers, I don't think you have diversity on some of the important dimensions. > This, btw, is also why a "enterprise desktop" should never be allowed to > drive development. It is, by definition, boring and same-old, same-old. Concur completely. Same-old same-old is the best case, it can get worse. I don't think the usability/design stuff in open source has been about enterprise; it's been in conflict with the enterprise-ish nature of Red Hat and Novell most of the time. > And if you don't see the parallels with "enterprise UNIX" and "Linux" > here, I think you're blind. The thing is, Linux (the kernel) got better > than just about any enterprise Unix kernel _not_ by trying to develop > itself for the enterprise, but by allowing and encouraging different kinds > of people to all scratch their own itch. The kernel on my (admittedly old) laptop is a good example of something that works for a developer like me, but isn't usable by a nondeveloper who can't scratch their own itch. The wireless card gets wedged if you do certain things "too fast" (I'm really not sure exactly), in any case it never happens if you just use the command line, but almost always happens if you use a GUI for wireless networking. The suspend used to require mucking with grub to disable ACPI, and now that Fedora seems to have yanked APM, you have to go in and manually configure hibernate rather than suspend, then avoid clicking on the "suspend" menu item since it crashes the system. In both cases it works fine for me, and indeed anyone capable of coding a patch could also use my workarounds, but it's entirely unusable for a lot of people. This is the kind of stuff I think needs fixing by developers, for someone who isn't a developer. Maybe that requires paid development, but if it does it does. > Yeah, the whole development process is a bit more chaotic, and maybe a bit > more "cluttered" and even scary, but the end result is BETTER. And yes, > Linux (the kernel) has a million drivers that the "serious guys" don't > care for. But that wild and crazy thing is exactly what made Linux a > success in the first place. I would say drivers are more analogous to firefox extensions or "third party" GNOME apps. The analogy to a typical GNOME feature would be a new feature in the kernel core or at least a major subsystem. By reputation you guys are relatively picky about those, but I don't know firsthand. > Thinking that developers should also have to be aware or care about the > crazy UI HID notion of the day is just stupid. It just alienates > developers. And don't tell me that Gnome as a project hasn't alienated a > lot of developers, because some of them have been emailing me privately as > a result of this flamewar. My point of view is that there _are_ developers who are interested in doing "by developers for someone else" and who appreciate design/usability, have bothered to learn something about it via books or conversation or whatever, and enjoy writing apps that measure up to what some of the canonical "good design" proprietary companies might write. There are really quite a few of these developers involved in GNOME. Alex Graveley who's been posting on this thread is an interesting designer as well as a developer, in my opinion. Absolutely, there are people who don't want to work on a project with that kind of focus, but then there are people who don't want to work on kernels, or don't want to work on whatever else. Normally you should choose a project you find interesting. I'm sure there are people who get alienated for bad reasons that are GNOME's fault, like someone flamed them or failed to review their patch (I've done both of those quite a few times sadly). But I think if you look into a project and find out that its goals aren't something you're interested in, and get turned off by that, it's not really a "bug" in the project, just kind of the way it is. If I don't like a neighborhood, the logical thing is that I don't decide to live there. Some people would probably start flaming the existing residents until they changed the neighborhood, but it's weird to do that, at least where I come from. I don't think all neighborhoods should be for all people. I guess that's full circle to one of the first things I had to say in this thread. The GNOME tent could probably be bigger, sure. That's what Seth's article tries to figure out how to do I guess. But again I think it's about finding the smart path with best of both worlds, not about oscillating back to past mistakes. Havoc _______________________________________________ Desktop_architects mailing list [EMAIL PROTECTED] https://lists.osdl.org/mailman/listinfo/desktop_architects