Slashdot Mirror
Shirky: Given Enough Eyeballs, Are Features Shallow?
cshirky writes "A persistent criticism of open source is that it is more about copying features than creating new ones. While this criticism is overblown, the literature of open source is richer on the subject of debugging than design. I've written an article about Ben Hammersley's LazyWeb.org, wondering whether open source methods plus RSS distribution can do for feature requests what open source already does for bug fixes, namely parallelize the problem in ways not available to closed source development methods."
the problems with Free Software is that its followed by politicians and not innovators; naturally, in open source (that is, not the so-call Free software) this is less of a problem.
Innovators innovate need money, and open source don't provide.
Personally I use the BSD, because it helps innovation with license that provides freedom, but that does not mean that the BSD's them selves do innovate, just that we provide a good system to base innovations on.
but if the closed source software is already good enough then why do you need the code if theres nothing to add?
sounds like a copout of major proportions.
Open Source development, as practiced by many Linux programmers, is not about pleasing the masses; it is about scratching an individual itch. As the ratio of users (ie. non-developers) to developers grows, there are bound to be more itches left unscratched.
The reward of scratching your *own* itch is obvious. The reward of scratching other peoples' itches, especially when they are not likely to even send you a "thank you", are more dubious.
I do not mean this as a criticism, simply as an observation of how it really works. Open Source works because of individual need. You cannot expect it to do the same kind of thing as paid development (which also tends to include nasty, unpleasant bits).
We can help a little bit by giving non-developers the ability to participate in a meaningful way. Think translations, documentation, icons, loading screens, project supports, web support, whatever. A lot of this is in place today of course, but it may not be obvious to many. We may need to work on that - both making these things more obvious and 'sharing the fame' with the non-developers who help out in a meaningful way.
The criticism that Open Source is always copying is highly unfair. It is unfair because Open Source is in many ways still catching up to closed source. Many of the tools are growing stronger, but are still lagging a little bit behind. Once that gap is filled I expect the Open Source community will boldly go on to create new and innovative features. Until then... Well, there are only so many hours in a day.
We should always watch out for complacency. Something is not 'good enough' just because it works. We should instead take pride in making OUR source the very best possible. Paraphrasing Apple for a moment, we really *do* need to 'think different'. A copy of Windows is not likely to be 'best'. A copy of UNIX is not likely to be 'best' either.
If we want to evolve further, a point will come where we need to help other people onto our platform. These other people are not users perse, but rather creators of content like us. Unlike us, they create music, pictures, video, etc. We need to provide them with tools to do what *they* do best, and we need to educate them towards our mindset (Open), and they in turn will reward us by sharing *their* work.
Although this is not scratching a personal itch, the job can still be rewarding because these are generally nice and interesting people to work with.
Right, off the soapbox I go...
We don't have new needs, except the need for source, the freedom Richard Stallman talks about.
Thats utter nonsense. There's always something new that people want. It's called progress. If everyone had said that back in the 70's, we still all be sitting in front of a terminal with tapes whirring around behind us.
Actually I see users trying to give feedback all the time.
The problem is no one is listening.
Usually they get flamed as "Yet Another Whiny Luser Who Can't Code".
There is a ton of feeback out there and armies of people willing to offer feedback, to bad usually developers are to busy flaming from their self important pedastal instead of listening.
Well then there are developers from the other side of the ego. They think any feature suggestion or request is an attack on their hard work and automatically go on the defense mode and flame the user saying how its perfect the way it is and if you want that feature code your own software and shut up etc.
There's been plenty of feedback, just no ones been listening.
Actually, I find that Open Source/Free Software packages are pretty feature-packed, and for any given feature I can think of, chances are _some_ package already implements it.
Finding those packages can be difficult though - we need enhanced feature discovery.
We ALSO need to maintain the Unix philosphy of SMALL TOOLS THAT DO ONE THING WELL that you can combine - and perhaps develop a GUI paradigm for that, not throw the kitchen sink into every package.
Ha-ha. Fat chance that the open source crowd would actually start using real software engineering methodology.
Most of that crowd is still in the 70s (like their programming language and OS) and believe that the documentation and proper design before coding is just a fad. "Real men start coding right away". If you try to say anything to the contrary, you are labelled a poser with a university grade or - gasp! - even a manager type.
Two random thoughts about features and open source: 1. Mozilla shows that Open Source *can* do innovative features (or at least, features not found in comparable commercial software like Intern Exploiter): e.g. type-ahead find. 2. The problem with letting users spec features is they will often make suggestions that are too vague, plain impossible or, if actually implemented, would make no sense. It's hard for most people to think about the impact a feature would have without actually trying it out. So maybe the way forward is to use systems which allow interfaces to be modified more easily (like XUL). Even if you can't implement an idea yourself, it makes it easier to find someone who can. The benefit of the feature is easier to understand if you can try out a prototype.
Excellently put. I agree completely.
On the other hand I also feel there are a few Open Source projects that, after years struggling meet the current state of the art in that particular type of application, have finally caught up with it and even surpassed it. A shining example of this would be Mozilla. For years it was a huge pile of bloat, barely useable. Now it is a stable and relatively fast browser, feature-complete by even the most rigid modern standards (at least on Windows, for linux there are still a few crucial plugins missing) and provides features that i sorely miss when, for one reason or the other, I end up using IE.
The point I'm trying to make is that much is dependent on maturity. Maturity of the code that makes up the application, but also of the team that develops it and of the community of users as a whole. And I have the distinct feeling that this maturity has been rapidly increasing that last few months.
Open Source development models do not prevent innovation. They merely provide unusual challenges. Only now are we starting to learn how to deal with those challenges effectively, especially in the arena of desktop/user software.
Pathman, Free (as in GPL) 3D Pac Man
What free software needs most is ardent maintainers.
Too many promising projects end up as working diligently, but then end up never maintained and never compliant with later libs, GUIs etc.
As a free software author myself, I feel qualified to talk on this matter. I'll drop a hint to everybody right now: if you have a feature that you want, or think would be really useful, REQUEST IT!
Send me an email, and ask. What's the worst I'll do? Say "no". I personally wouldn't do that (I'd probably explain why I thought so), but it wouldn't hurt! I'm guessing a huge number of free software developers are sitting out there, very lonely. I *know* I have quite a few users, since I get a steady trickle of downloads, averaging over 20 a day - some of them *have* to be trying it out!
Of course open source projects can do interface research, hold user trials, go through test cases, etc.
The problem is that no-one seems to want to. Most open source projects happen because someone (or a group of people) decide to write some code, and start. People don't want to spend months gathering requirements and having meetings to discuss and finalise features, they want to get on with "the real work".
I do agree with you though - I see nothing wrong in taking inspiration from those companies that do put that sort of effort into interface design. Isn't that what open source is supposed to be about? Learning from others, building on their work to produce something better?
That learning and reuse doesn't stop at code.
It's official. Most of you are morons.
I think the more pressing issue is making open source developers understand that end users are valuable. Mozilla for instance has pretty active forums (as well as newgroups on usenet), but frequently when someone posts a feature request the result is "nobody's working on that, code it yourself :)".
I definitely don't think that the user is always right, but I do think that if you're going to give the end user a voice you'd better take their opinions to heart.
pw:secret
That's odd. I started programming in the 70's and a lot of what we're working on now is exactly what we were dreaming of then. If anything, we'd have been pretty shocked and horrified to know that we'd still be working on them after <heavenly choir>the Year 2000<heavenly choir> (which once seemed as distant and hallowed, yet imminent and all-conquering as any Messiah or deity)
We cursed the limitations of our hardware and software then, but we worked with them because they were all we had. We'd spend weeks trying to trim a kilobyte or a few cycles out of a loop, not because we were virtuous (we weren't) but because we had to. Those whirring disks ran 24/7 to do crude payroll jobs that would run minutes on a desktop today.
It's been well documented, here and elsewhere, that most of our routine computing doesn't really save us much time, if any, but is simply chasing that elusive 0.1% "better output" (documents, biz data, presentations, etc.) A high school frosh today would be ashamed to hand in a report that looked like the most painstakingly prepared reports prepared for President Nixon. The addition of kerning hasn't vastly improved the content of a high school report.
Among the early computers I worked on was a triple CDC Cyber7600, which (in its initial configuration as a mere dual Cyber6600) exceeded the total computing capacity of the Soviet Union, but had a fraction of the CPU power, storage, etc. of my laptop so where's my accurate voice transcription, much less my intelligent editing and automated personal research assistant? Text recognition is just about usable for some major applications, but handwriting recognition is still barely usable
Yes, many are happy with their PDA hand-print inputs (or whatever) but it's a singing pig, we've learned not to expect Pavarotti; we're amazed it's workable at all. In ten years, we *may* achieve our 1975 dreams, and call the current state 'crap', not because of added features, but because 95% success (if one can even achieve it) *is* crap performance that we'd never accept in other daily technologies. Contrast this with, say word processing: load a PDA with 1979's AppleWriter ][ word processor, (a 190K package) and *truly competent* speech- , text- or handwriting recognition (pick one) and you'll have something that'll fly off the shelf at a kilobuck a pop, and make the cover of Time.
I don't know your age, but I assume you recall the 70's. If so, you'll recognize that these functions that we expected "any year now" back then (and are still waiting for) are just a handfull of hundreds of basic functions that are clunking along today. Our standards have dropped. We haven't even implemented the feature set we were promised then
With the Web (hypertext), wireless networking, huge storage, and a thousand other technologies, we're finally getting close to the Dynabook, which in 1974, we were promised "by 1984 at the latest". In 1994, a dynabook would still have been a total world-changing breakthrough. in 2004, it may finally be here. Added features are nothing compared to competent basic functionality. We've had programs that claim to do all this stuff for 25 years, but we're still waiting for solid human-free performance (which is largely the point of having a computer do the job) on our 1975 dreams
Before you say creeping featurism pulled us out of the Dark Ages, just give me reliable, competent worry-free versions of the stuff that was outlined in the magazines in the 70's -- software that was being written on mainframes, knowing the PC and laptop were coming, someday, and is still only in what we'd have call "commercially released beta" form 30 years later
While some open source developers work on a project for personal reasons, others don't. Everybody has their own reason for contribution.
I, myself, am working on the Autopackage project because I want to make third-party software installation on Linux easier (and get rid of all the flame on Slashdot and other places about Linux software being hard to install) to make this world a better place, and partially because I want a packaging system that doesn't rely on a database.
Everybody has their own reasons. Some do it for themselves, some do it for others, some do it for fun, and some do it for other reasons. There is no one single answer to why this and that happens.
Example: "open source produces bad GUIs and have no usability experts". Huh? Have you guys never heard of all those usability studies Sun contributed to GNOME? Or the GNOME/KDE Usability Project? Or the GNOME Human User Interface Guide? I mean, they've been here for months, yet people still talk as if they don't exist.
I can only conclude one thing: the world is heavily underinformed or are biased. Go read some websites!
Again: there is no one single answer to why this and that happens. People saying that open source can't do x because of their ego or whatever have a single-minded view on open source.
The most obvious example is Perl. It was made to generate reports, but grew so far and in so many different directions that few Perl programmers have ever used it to generate printed-page reports.
But open-source isn't just about features. It's about rock-solid reliability *and* portability; few commercial products run on as wide a range of platforms as, say, GNU fileutils. And I can still cause most commercial 'pwd' implementations to dump core, but have never done so with GNU pwd :-)
To set the record straight, during 2000 and 2001, I worked at an incubator called The Accelerator Group, where my job was to assess new businesses' technologies. I certainly wan't the one writing the checks, and I certainly do think Python (and perl and Ruby) are innovative.
As for successes, and failures, I detect another pattern in your list. Open Source does better the deeper in the stack it is. Deep in the stack == programmers as users. Tools high in the stack, on the other hand, have a strong split between the people writing the software and the average user. I am wondering if LazyWeb can bring about useful communication across that gap, at least among users capable of describing what they want clearly and developers looking for outside inspiration.
See Von Hippel's papers here.
Enjoy,
Frank Ruscica
This is ridicolous. It's the other way around. Open source / free software has always (long before it had those names) had much more productive innovation.
And of course it has. Open source is all about mimicking the open science research community around all the universities in the world. This scheme has been perfected for centuries with the explicit goal of more innovation.
With open source you don't have to reinvent the wheel. Have a new idea for an operating system feature? Implement on Linux and you can be ready in no time and (which is important) you have plenty of people to show it for, get feedback, and if it turns out good, plenty of users. Creating a new language? Just write a new frontend to gcc and you have modern state-of-the-art code generation and register allocation tools which would cost you millions to develop from scratch.
Five years ago, we already had a complete operating system for us, GNU/Linux, all created within the open community using open tools. Using only some of the thousands of available tools, you could chat with users around the globe using IRC, setting up ad-hoc document collaboration with CVS and LaTeX, develop software etc.
Then we had the whining. Corporate users saw there was money to save by using free software, *if only* there was a free word processor. Word processor! You had emacs, CVS and LaTeX and you wanted a *word processor*! Why? Because the better software wasn't "familiar enough". Familiar. Ok. After several years, both communitites realised that it is only good for us both if we cooperate (it almost always is) so now we have, what, 5 good free wordprocessors?
We had mutt, procmail, GNUS, and some wonderglue called Perl. Corporate wanted Outlook Express. Now we have an insane amount of Outlook clones. Repeat ad infinitum.
Now we find ourselves in the peculiar situation where new users are introduced to lookalikeware such as GNOME, Evolution and Openoffice -- and they complain they are just pale clones. Well of course they are! That's why they were created!
Want a 3D GUI? Available. Unified messaging? Available (at least with some Perl glue). Ad-hoc collaboration systems? Right there.
If you want to understand the innovation taking place in the free software community, start with understanding our basic tools. Understand CVS, LaTeX, Perl and such. Look at the reiser4 filsystem, the XML-UI in Mozilla, Parrot and Perl 6.
Then come back and give us a little bit more well informed complaints about innovations in free software.
The whole "Open Source Developers are not Creative" line is crap. Sure we copy a lot of features if we think they're useful, but we've been on the leading edge in places where big companies would like to re-write history to take credit for various inventions of ours.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Adding features is easy. But I think often less is more. As an example, I compare Apple's iTunes software with MusicMatch Jukebox. I have both and I much prefer Apple's offering.
When you compare what's under the menus, MusicMatch looks like a mess. In comparison, iTunes seems clean and well designed. I think the ratio of useful features to features follows the 80-20 rule.
It's probably also the reason that I have stuck with Palm handhelds (actually a Handera) when the PocketPC's seemingly have much more to offer.
It is very difficult to make something simpler without losing any essential functionality. And of course what is essential is very subjective. But in the case of iTunes, I think Apple has done a very good job.
Replying to my own post...
For end users it is obviously important to make things easy. Although it is true that many web sites for Open Source projects have forums or email lists for feedback, I don't think that's easy enough. Many end users don't really know or care what software they are using.
What I suggest is a new dropdown item from the menu bar. Just as it is standard practice to add Help->About to an application, so it should perhaps become standard practice in the OSS world to add a Help->Feedback item. This send feedback info. from all OSS applications to a single database, which could then be browsed by OSS geeks to find out where problems are occurring.
I've always wondered why MS never did something like this. I think it would innovation - and a willingness to listen to endusers - on behalf of the OSS community if they did something like this.
You, and very few other people. It's incredibly annoying (from a user's POV) to have to learn a new UI for every application I use. A programmer that insists on wasting my time because I've got to 'learn to ride the camel backwards' to get his weirdass program to work, gets the boot from me. I'll find an alternative that's better designed.
The program's design is an integral part of the production process. Badly-designed software simply isn't of release-quality. Stable or not, if your UI is badly designed, your application is a beta.
It isn't a question of either/or (usability vs stability). You need both. Actually, you need a few more things. Documentation, for instance. Good documentation, not just manpages.
I completely agree. There are (at least) two reasons for this. The first is that someone will find an app that they like, which doesn't exist for Linux and decide to write an OSS version. The second reason is that the software could have a cost that only few could afford, i.e., Office, Photoshop, etc. So they model the clone after the original program, hence not needing interface studies.
However for most OSS work, the developers are most likely located all over the world. With such sites as sourceforge and with tools like CVS, development can be accomplished smoothly. Spending time with test cases, requirements gathering, and with general research, unless done by a small group is probably difficult with developers spread all over the globe.
There is also the notion that writing code is the fun part and gathering information is not something that people want to do in their spare time!
...but it is well documented that the requirements and design effort swamp the coding effort in the process of delivering software. I've worked at two companies so far in my carreer where the product was commercial software. Unless you are building an application that programmers will use, one really needs to enlist domain experts to determine what features will be effective. As an example, I developed a number of commercial applications that are used by electron microscopists in performing quality control on prototype integrated circuits. It succeeded not because my manager was a software developer with a Princeton education but because our resident microscopists told me exactly what the tool needed to do based on years of experience in the field.
Now, this tool can be purchased and it's features can be copied...but certainly I never could have built this thing myself from scratch as my background is in computer science and software engineering.
IMO there is absolutely nothing wrong with copying features. In fact, if I were looking for an OSS tool like the one I described above - I think the most important thing I could say about it is that it is just like "X", except it's free (as in beer/speech/or whatever.)
Lastly, it seems to me that since requirements and design consume so much effort/time/expense that one reasonable lifecycle for an application is..
1. Domain experts recognise the opportunity to automate some aspect of their work based upon years of experience in the field
2. They invest the effort/time/expense in developing the requirements/features and create a proprietary application which the sell for $$$ for as long as they can
3. Eventually, other commercial proprietary apps are available with added improvements to compete...so less $$$ available
4. Over time, the set of requirements for this type of tool become known by all.
5. Once the requirements/feature are common knowlege, OSS replicates the tool and the world is a better place.
Clearly, OSS has produced original work that never went through a commercial cycle. But there is no shame in copying features. As Isaac Newton said, "If I have seen farther than others, it is because I was standing on the shoulders of giants."
I want to be alone with the sandwich
Can not a person be both a politician and an innovator? Caring about the world around you certainly doesn't keep you from having good ideas.
:)
I'd have to argue with the idea that innovation has anything to do with money. My most productive times are when I'm unemployed with lots of time on my hands and no money to pay someone else to write software I could write myself. If someone else has already invented the wheel I play it smart and look at what they have first, then I innovate the rest. If it's something entirely new I innovate it all but given my lack of a marketing department and the fact that nobody is looking for what I'm offering very little noise is made about it's existence.
As a developer I will never use a BSD license because it lets people rip me off without giving me anything back. If I release code under the GPL and they want to distribute changes they've made they have to make their changes available to me and others. If they don't want to do this they have to contact me and work out some other license for which they will pay me the original developer.
All the BSD license does is make it so you innovate and other people can run off with your code, make just enough changes to break compatibility, and make money off of it.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
Good Software is not about more features! Good Software is about doing it safely, reliably and securely. Good software is about doing it well, not doing more.
Adding more features will only make the software worse. More bloat, less easy to understand and use, needs more hardware, and the documentation usually lags behind as well.
Writing software is an art form. It is an exercise in restraint and thinking before you do it, not in gluttony or adding more crap to already crappy software. The world is full of bad software with hundreds of little understood and under-documented features. I'd rather have small, well-documented and reliable software, thank you very much.
Wake up! Many of todays users don't even use their cell phone. I mean it - they ask you how to add someone's number or something similar after a year using it. You tell them and they ask again after two weeks. Everyone is not a developer becouse not everyone wants to.
Many people ignore any technics as far as they can (and are afraid of) not matter how trivial it could be.
How many web servers were around before Apache? The NCSA server, which was OS I believe.
How many web browsers were around before Mosaic?
How many email servers were around before Sendmail?
How many web servers had dynamic content before CGI/Perl or CGI/C?
Even if I'm wrong about how innovative these ideas were, there certainly were catalysts for the creation of closed-source and/or commercial products rather than OS just copying featues.
"For a successful technology, honesty must take precedence over public relations for nature cannot be fooled." -Feynman
Funny how perception can differ.
I consider GNOME and KDE big failures of open source. They could have epitomized great design, they could have demonstrated how to write reliable, fast software. Instead, they are bug ridden bloat monsters. I'm ready to puke when I see my notebook start to swap when I open konqueror.
And I don't follow your directory service rant. Obviously you have never even looked at the commercial directory services, because they suck even worse than openldap (and we both know that is a feat not easily achieved).
By the way, you invalidate your whole rant by counting as success only software that has been mentioned favourably in the (spectacularly uninformed) mass media, not software that is actually well done. Nautilus, for example, is the slowest piece of file managing software I have ever seen. I always thought it is a parody rather than a file manager, how can anyone use anything this slow in his day to day life? Sure it looks good, if you have the time to wait half an hour for it to draw your home directory.
And about that office stuff: we are using TeX in our office. We write our letters in it and then we put them in CVS so we can work on them collaboratively. Then we can do full-text searches in them. We once trained a secretary to use TeX who only knew Windows before. It took her less than one week to work productively with TeX.
There are lots of great successes in the free software world. Most people are just too badly informed to know them.
"Just as it is standard practice to add Help->About to an application, so it should perhaps become standard practice in the OSS world to add a Help->Feedback item. This send feedback info."
I don't think that will work. Why? Because most people simply don't care. If they think the app suck, then they'll delete it. The last thing most people think is "Let me send feedback to the authors". I mean, a lot of people I know don't even know what version of Internet Explorer they have (they don't even know they have to look in Help->About!!!!)
There are of course always some people who do send feedback. However, a lot of them are very stupid (no offense intended, but it's true). Things like "it doesnt work plz fix it tnx" or "yo dude do me a favor would ya fix this bug, LaTeRZz!" or "It doesn't work." are not uncommon. How do I know what to do if all I get is "it doesn't work" or "it crashes"? Also, for smaller projects, the authors do not always have time (school/work/social life/whatever).
I think it's much better to teach the users how to give good feedback. Or better: encourage them to contribute. The problem is: are people willing to learn or to help?
You know, one thing I've noticed is that many people tend to have a erroneous perception of the complexity of their jobs. I mean, after working (or studying) in a given field for a couple of years, you start forgetting how much you know and understand it. Many tasks seem utterly moronic to you even though a very bright specialist in another field would be completely helpless in front of them.
/. are proficient in CS/CE. Many threads on /. are totally obscure to me. Sometimes, I don't even know what is the subject. Yet, I'm often appalled by the complete lack of understanding of financial basics of the /. crowd. One example? The RIAA/P2P "debate". How many times have I read "reasonable" arguments like "A CD costs $1 to burn and the majors charge 20 bucks. They are overpricing!!!"? Yet a quick look on yahoo! finance will provide you with most majors' annual reports and you'll see that their operational profit (whoops, I do it myself, do you know what operational profit is?) represent around 5% of their sales. Does this mean that a CD costs $19 to be brought to the store? No, of course. First, the 20 bucks is not the major's revenue it's the retailer's revenue, and he keeps a margin. Then, there's sales tax in most states. Then there are fixed costs, investments that are not proportionnal to the number of CDs you sell. Then there's price elasticity: volume increases if prices decrease. Then there's competition etc... Sounds complex? It's not. For me, it's like 6th grade common sense. Yet, many educated and clever people (though unfamiliar with accounting/finance) suck at that.
The reasons are many. Language: read any doc in any field and you'll see countless acronyms, names, references that an outsider has no chance to understand. Mindset/methodology: in each field, there's a "best practice" way to present problems and solve them; and you get (grok) it only through experience. Information: every field (not only IT) is evolving quickly and most people don't know where to look for useful info; in many cases, they don't even realize that information is available.
This holds true in every field, not only scientific or technical fields. It's true in finance, sales, marketing, journalism, politics, you name it. That's the reason why it's so hard to make different kind of people to work together (like R&D and marketing). Very few people are able to reduce the level of previous expertise needed to (really) understand what they are talking about.
One illustration: My field is finance, i guess most people on
It's the same with programming. I want to code something, what should I do? Wow, lots of questions come to my mind. Which langage, which platform, which IDE, which compiler, which database? How do I use any of these things? What do these words really mean in the first place? What is their syntax? Should I write the whole thing or use an existing GUI? Which one? Does this question even make sense? I'm confident that I could do it eventually if I commit enough time. It's not worth it!!! It's far more efficient if I outsource that task to a tech-savvy person.
To conclude: No, everybody is not a developer. And even in the future, most people won't ever do something that you would call developping. The problem goes far beyond GUIs and user-friendliness. You just grossly under-estimate the amount of investment needed to develop even the simplest piece of code.
It would be nice to be sure of anything the way some people are of everything.
The original UNIX developers limited their feature sets because that was their philosophy. Open source projects limit their feature sets because they rationally decide that the time and effort it takes to implement and maintain the feature are not warranted by its utility.
Microsoft, however, has the resources to implement every nifty feature they can think of. It doesn't make their systems better, it turns them into Rube Goldberg systems. The NT kernel really is "the most modern kernel in the world" in terms of having lots of features that CS researchers ever dreamed up, and that is not an asset. Microsoft developers get paid to add features, not because they need them or because it makes sense to do so, but because they can and because it looks good on glossies. Many people go to work for Microsoft because they can finally get their ideas into a shipping system without such pesky details as having to convince customers that they actually need it enough to pay for it--all they need at Microsoft is buy-in from a few managers.
Or, to continue the dermatological paradigm, if you keep scratching itches you only imagine you have, you are going to get scratch dermatitis. Too much scratching is bad for you, as is too much fiddling around with software.
Linux should keep things simple. Some of the attention from big companies and the resources they contribute (IBM, Sun, etc.) threaten to cause Linux to make the same mistakes Microsoft is making. Fortunately, Linux is still much more modular, so all that stuff can be left out. But it will be the end of Linux when the kernel and desktop will ship with all the "commercial grade" stuff lots of vendors have contributed.
I think that the parent was a beautifully worded post and deserves every one of its +5 mod points...
...but...
We have tens of millions of people working in the IT sector now. And it isn't as though no work is being done. Sure, we haven't developed what we thought we would develop back in the 70s... but we've made huge strides in other directions that we didn't even dream of then...
Cellular phones, wireless networks, wireless everything, the web, MP3, DVDs, digital photography, the human genome project, DNA fingerprinting, ebooks, ATMs, laptops...
Some of the problems we thought we could solve turn out to be really tricky things that our current ways of computing have trouble tackling. Other things -- like the very short grocery list above (which I would LOVE to see others reply and expand upon!) -- are everywhere today and were near unimaginable in the 70s.
Computers aren't magic. They won't solve every problem. They are very well suited for solving specific kinds of problems. We are just discovering together what those kinds of problems are...
I would have to say that explosives are the most abused technology in all of history.
I think the problem with thin features is not a bug, but a feature.
.WAV file editor, Sound Forge, so that Sound Forge launches with that wave file if I double-click it.
A lot of the people who buy into the OSS concept also buy into the small tools philosophy -- where it is more powerful to have a lot of small tools that each do one little thing well than to have a handful of large tools that duplicate each other's functionalities to varying degrees.
Take digital audio editing, for example. I use SONAR for writing music now, which has some high-end features to make editing digital audio for music simple, along with support for plugins. I can also attach it to my favorite
But neither Sound Forge nor SONAR have the ability to do some of the audio processing things that CoolEdit can do. And of course, CoolEdit lacks features the other two have. So for me to use all of these features, I have to repeatedly open and reopen the wave file between the various editors until the file sounds the way I want it to.
The idea behind small tools would be to make each audio effect its own self-contained unit. Then you'd have another unit, the GUI for finding and merging all of these together. The music software (the SONAR equivalent) would then use the GUI for editing individual digital audio tracks, and then there's a whole separate batch of programs for dealing with MIDI, SMPTE, and other functions.
There can be several GUIs that all use these different functions. There can be several music software packages. And they all essentially work together.
This is how UNIX basically works. It's part of why getting anything done in Linux is a research project, and part of why we generally love Linux so.
Take CVS for a good example of the small-tools approach. It does one thing well: Merging multiple versions of files that many developers are working on around the world. That's really its only feature. But you can then use script files that it calls to enhance its functionality so that it sends you mail, updates a web page, works with BugZilla. You can integrate CVS into your IDE, and there are dozens of graphical front ends for it that can give you better views of changes. You can switch out what programs CVS calls, you can switch out the front ends, you can integrate it into your Emacs or your ProjectBuilder.
CVS thus becomes a version control software that can do everything even though it is a small tool that really just does one thing plus respecting the small tools approach -- although it needs a bit of configuration to work the way you want it to at first.
Linux itself is such a beast as well: It has invaded many markets simply because it is so configurable that it can be a server OS, a palmtop OS, a desktop OS, or even part of a mainframe system.
So I don't think feature-thinness is a problem; I think it is a philosophy that when applied correctly (as CVS and Linux do) that results in software that can do more than the most feature-rich bloated closed-source software out there.
"This document basically tells people of OTHER TECHNICAL THINGS (like making icons for programmers and writing documentation for programmers and reporting bugs to programmers) that they can do."
Since when is creating icons technical things? What about writing USER documentation?
"This is irrelevant to the issue of design and usability"
That is irrelevant. You're saying only programmers work on OSS projects. That is not true.
"Provides a series of slides that explains things like "what usability is." A nice start, but that hardly means that the end product will be designed with usability in mind."
That's what the entire project is about! To convince app developers to think about usability! That so far, they're succeeding. More and more application developers are fixing their GUIs to be HIG-compliant. Also take a look at the traffic of the Usability mailing list.
"Let us not forget that the usability thing is being spearheaded by Sun, who sure as hell isnt doing it for altruistic reasons."
Aha. Let's see...
Slashdotter A: "Open source apps have bad usability because the developers write it for themselves. Commercial software have good usability because their customers demand that."
Slashdotter B: "Sun is not doing it for altruistic reasons."
Hm? Contradicting claims?
Sun's customers demand a good, usable, intuitive GUI. Sun is using GNOME as their GUI in Solaris. What's wrong with Sun helping to make GNOME more usable?
"Documentation + Translation != Usability != Design"
That's why the documentation, translation and usability projects are seperate projects!
"Oh stop it, you're making me laugh. Mozilla fails even the most rudimentary usability tests because of its speed (or lack thereof)."
Since when? On any modern system (my Athlon 1.4 Ghz with 128 MB RAM for example), Mozilla runs just as fast and snappy as any other application. Stop using Mozilla on that Pentium 166. Even on that AMD K6-400 with 128 MB RAM that my friend has, Mozilla runs just fine.
And of course I'm talking about post-1.0 Mozillas here.
"If you knew a damn thing about usability rather than playing the old linux game of equating "fancy gui" with usability, you'd recognize this. Usability is a user-centric-ness that needs to be considered in many ways, and Mozilla fails by a mile."
Oh you mean those thousands of happy non-geek Mozilla/Netscape 7 users are all fake?
And what about Netscape? They're a company. Their customers demand a good product. Isn't it common Slashdot knowledge that companies create good and usable GUIs?
"There's a world of difference between getting an answer to a technical question by supplication and driving the development of a new product."
What's that got anything to do with this?
"OSS is developer, not market driven. Where it is more market driven, it's basically being used by for-profit companies to serve some auxillary goal (like Sun's support of Gnome)."
Then what are you complaining about? Are you saying NOBODY (not open source, not companies) creates usable GUIs?
"This is best done in person. OSS suffers because of this, in general, as well."
I don't get you. You say OSS suffers from bad usability design. Yet you also complain about that companies only do it for the money. What's your point?
"Commercial open source software, that sideline game through which companies position themselves in a to take advantage of the work of free labor while bundling this with their own proprietary extensions as a 'value add' does care about usability."
*Ahem*. Mozilla is sponsored by Netscape...
"RedHat does everything in its power to keep the usable bits proprietary"
What bits are proprietary? The installer is GPL'ed. The configuration tools are GPL'ed. What exactly in RedHat is proprietary?
"Big picture: at the end of the day, you STILL can't reliably cut and paste complex objects between apps that dont explicitly know about each others file types in linux systems."
What complex objects?
"You STILL dont have so much as a simple, fast, usable web browser that comes close to IE."
What's wrong with Konqueror?
Personally, I find Galeon and Mozilla far and far more usable than IE. The little details like middle clicking on links, tabs and popup blocking make my browsing experience far more pleasant than IE ever gave me. I'm not the only one with this opinion, there are many, many more people out there.