Nice article from a Word for Mac developer echoing my stock reply to most Metacity feature requests. Question: will I get more flames or less flames if I start quoting Microsoft in bugzilla? ;-) (Of course the guy is wrong that open source won't do the root cause thinking, since he describes pretty much exactly the GNOME party line over the last few years. For that matter the first question out of almost any decent developer's mouth on hearing a request is "what are you really trying to do?")
This article says:
To sum it all up: OSS developers should learn to live with the fact that their software is no longer exclusively used by geeks and enthusiasts-- and if they cannot cope with this, then clearly state that your software is a hobby project-- this will save a lot of hassle and takes away the ground under the feet of ordinary users complaining and whining over features.
The funny thing is that smart developers use interaction design methods (such as ethnographic observation) and customer feedback in order to set the roadmap based on user needs.
A "hobby project" would use all the random stuff geeks and enthusiasts say on mailing lists to set the roadmap, because hobby projects confuse mailing list posters with users, and Internet noise with data.
I offer the following definition of geek/enthusiast: you read Slashdot, OSNews, eXpert Zone, Planet GNOME, this blog, or anything else of that nature. Yes, this means you. No, you aren't "an ordinary user." Sorry. Neither am I.
Does anyone else see the hypocrisy in posting to a mailing list with the single canonical list of features that are absolutely necessary to succeed on the desktop (if I had a nickel for every one of those...); and then getting pissed when an "arrogant" developer has their own opinion about the top priorities. How can developers who have been working on the desktop for years, understand the resource and technical tradeoffs, have access to direct customer feedback, and so forth; possibly know more than J. Random Slashdot Reader; J. Random, after all, is an ordinary user.
One reason Red Hat split Fedora from RHEL is that geeks/enthusiasts do indeed have different priorities than the general population of paying customers. This is even more true for desktop than it was for server. In fact it's kind of a defining feature of geeks/enthusiasts that they aren't paying customers, because they want to do it themselves. People who pay are people who want a company to make it work for them. So we split the OS to do two different things for two different audiences.
I don't think developers are always right or even usually right. But they are more likely to be right than a mailing list thread or web poll.
Your average Linux distribution has at least 50% of its effort and even code size aimed at geeks and enthusiasts. If I were making a strict desktop distribution, you'd see sendmail gone, the terminal gone, Emacs gone, compiler gone, I bet I could even get rid of /bin/bash eventually. And the product would be better for desktop users because of the resulting focus and technical flexibility.
The thing I like about Pages is the handling of "semantic styles" and their relationship to "text formatting" - while OO.org has a "styles" feature it's pretty clunky and the details are all wrong. Pages has a good model for how styles relate to the text formatting - to see it you have to enable the styles drawer and look at the features in there and how the styles work. The way they have done it also allows templates to be applied/changed after document creation (i.e. is a template just sort of a blank starting document, or is it a style sheet). Also I think making styles the default/encouraged way to write documents was the right decision.
They have the advantages of something like DocBook, without losing WYSIWYG or introducing weird markup. Making new styles is simple enough for users to do, and if you want to skip styles and just change formatting by hand that works also.
Basically what happened here is that the interaction design was done with styles and templates as the focus, rather than bolting them on as a bullet-point feature afterward. Keynote has the same basic idea at its core (you can make an outline, then change its template).
Marc, desktop-backgrounds-extra sounds plausible to me, if I remember that's the one with outer space photos. The only problem I can think of there is if it's the same SRPM as fedora-backgrounds (the add/remove suggestions have to be according to SRPM, not RPM). If so then there's some work to split it apart or maybe just delete it. Probably nobody thought about removing this package because they were looking at an SRPM list and so just saw "desktop-backgrounds."
Of course, if we make that space then why re-add AbiWord rather than Gnumeric? You see the reality. Somebody is always going to get pissed off.
I'm assuming that the exact disk space isn't known until the last minute (for example, right now we're rebuilding with gcc 4, which probably changes the size of everything). I don't know if this means that the "dropped from FC3" list will grow or shrink prior to the final release.
Regarding updates of AbiWord, ultimately Core vs. Extras should not matter there. We want to enable external maintainers of Core packages, and we want most of the same rules to apply to Core and Extras. I think the version of AbiWord in FC3 is probably just what was available around the FC3 package freeze date.
Personally I think you're focusing on the wrong thing. To me there is a path to making AbiWord + Gnumeric + a presentation app into the new default office suite, and if it were me, becoming the single default would be my goal. I don't think Core vs. Extras makes any difference whatsoever in achieving this goal, honestly.
I think there's some misunderstanding here. Several points:
All this is explained in the huuuuuuuuuuuuuuge mailing list thread about what to remove; but I can't really blame anyone if they didn't read the whole thing. Anyone is welcome to read it and suggest something else to remove instead of the current list, but I think anyone reading it will realize that the problem is intractable, and requires the long-term plan of either a) re-expanding Core or b) shrinking Core to be some relatively objective set like "the default install."
On the overall office suite question, the Red Hat engineering team is very supportive of a native (and just plain better) office suite. I am personally as well, and was recently re-convinced of the value of this when I tried out Pages and Keynote. But given that we have to remove something, it just makes sense to remove duplicate functionality first, instead of for example removing all office suites in order to keep a choice of ten text editors.