Slashdot Mirror
Five Fundamental Problems with Open Source?
meriksen asks: "I found a very interesting paper which I am sure will stir up a hornets nest.
Despite the growing success of the Open Source movement, most of the general public continues to feel that Open Source software is inaccessible to them. This paper discusses five fundamental problems with the current Open Source software development trend, explores why these issues are holding the movement back, and offers solutions that might help overcome these problems." What do you think of the issues given in this paper, and how do you think the Open Source community should address these issues?
"The lack of focus on user interface design causes users to prefer proprietary software's more intuitive interface. Open Source software tends to lack the complete and accessible documentation that retains users. Developers focus on features in their software, rather than ensuring that they have a solid core. Open Source programmers also tend to program with themselves as an intended audience, rather than the general public. Lastly, there is a widely known stubbornness by Open Source programmers in refusing to learn from what lessons proprietary software has to offer. If Open Source software wishes to become widely used and embraced by the general public, all five of these issues will have to be overcome."
The solution is to provide motivation to write for someone else. There are a lot of companies out there making a lot of money off open-source, selling hardware or services. If they want open-source programmers to write code differently, they need to provide some motivation for that change. One possibility would be an annual award program which could include - for example - a "best documentation" category. The combination of a cash prize (it needn't be large) plus the bragging rights for having won could provide the necessary nudge to improving open-source code.
===== Murphy's Law is recursive. =====
Open-source software does lack documentation geared towards the "common user". The documentation that is out there always seems to only understood by the geek.
The thing holding back more widespread adoption of Open Source is that it doesn't ship already-installed on new computers.
One serious problem is the lack of a standardized, easy-to-use (=click-and-point) installation program and the fragmentation of package management (rpm. deb. tar, whatever).
The owls are not what they seem
i have to say, that my own personal reason for not using an OS that is open.... is because i can't figure that shit out. i've been spoiled by microsoft. make it more friendly, and more ppl will use it
Are hardly exclusive to Open Source development. Plenty of closed sourced projects suffer from the exact same things, and plenty of open source pojects do not.
Part of the problem, I believe, must also be the inadequacy of software download websites. In general Open Source distributions are tricky to obtain and install. The sites are difficult to navigate and provide too many download options that reqiure understanding beyond what most users posess. i.e., should I download the "source" or "binary" version? "Stand-alone" or "self-installing?" All of these are terms outside the average user's vocabulary. Worse, many simply link to those SourceForge sites where users are presented with myriad different versions of the same product--some not even stable.
Religious blindness
.Net good, use .Net, write everything in C#, Java bad, GPL evil, etc.
Doesn't seem to me to be specifically open sourcey (sp?) to be religious about technical issues. I mean just look at Microsoft, they are a frikkin' technical monopoly:
John.
usability.
ESR's rant over CUPS is something we need more of.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
Well written article, and she even forgot to write about the other problem of FOSS:
PROPER TESTING.
When by proper testing, I mean test cases for each and every OSS app is getting released out there. Simply releasing an app as a "beta" and asking for input from random people who will use your app on the web, is NOT how proper QA should be happening. Unfortunately, distros are not any better on this, who are supposed to be "professionals".
I really agree with this. For example, there are a few software programs that I use and would like to recommend to people, but then I remember the long text based config file, or other small things that prevent the naive user from getting software working properly.
Little things like this make programming something about 10x easier (which is why most open source programmers do it, even I do it), but really do leave out the general public.
I mean look at the most popular open source programs (going by sourceforge). You have DC++, which has a beautiful interface, much better than its closed source counterpart (also more useful). You have Gaim, again designed with the interface and users in mind.
What is the common factor among the list? A pretty GUI. How many powerful console applications do you see up there? Very few.
The author definetly has a point.
Open Source seems to ignore this whenever it becomes inconvenient to pay attention to it. Yes, there are exceptions. But it is not infreqeunt to encounter somethign akin to, 'users of verions prior to X.yz must completely redo a whole lot of things because we changed underlying structures'
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
Developers focus on features in their software, rather than ensuring that they have a solid core.
This motivation is even more present for commercial apps; developers are asked to add every feature that somebody suggests in a focus group, etc. for better advertising - e.g, We have this feature and $COMPETITOR doesn't! Many of the Windows security scares have been due to poorly thought out features becoming bugs; for example, using ActiveX or VBScript to "spice up" web pages or Outlook's tendency to "enhance" emails by displaying HTML
--- You shall know the truth, and the truth shall make you mad- Neal (not Cowboy) Boortz
One thread I've noticed emerging in the comments here is that of "but non open source stuff has the same problems". Why should it matter if the non open source stuff has the same problems? If it's a problem at all, should it not be addressed?
After all, addressing a problem that other guys haven't is a good way to improve the chances of getting ahead.
If it works in theory, try something else in practice.
No, the thing holding back more widespread adoption of open source is that nearly no one currently would want it shipped already-installed on new computers.
Make it good enough that ordinary users demand it, and adoption will come automatically.
I think she missed the biggest reason of all here: Designing a good GUI is very hard. Wait -- let me further clarify that: it's very, very hard.
Designing a GUI from scratch requires a sense of aesthetics (balance, color, flow) and the ability to decide exactly what needs to be up front, and what needs to be hidden behind a menu, option button, or some such. Frequently the developer will have a fervent opinion about "this is the most important thing, it must be on top" whereas a good user interface designer can step back and see what will work for the users. A good UI designer will also run user acceptance labs to test their designs. Many open source projects end up with little more than "Hey Bill, would you check this out for me?" And Bill, being aware of the project from its inception, and having heard about it over the lunch table for the last five months, already posesses a deeper understanding of the task that prevents him from being able to adequately judge the design.
Apple, of course, has always been at the forefront of GUI design (at least as a commercial success, I'm fully aware of the contributions of Xerox Parc, et al.) I believe this comes from a strong, single, visionary designer, a rigid set of GUI design guidelines that must be absolutely followed, and a corporate mindset that the GUI is the most important aspect of an application. They undergo rigorous testing procedures, and countless user feedback labs. Microsoft hasn't ever caught up to Apple in that respect, although they do have a good set of GUI guidelines and some very strong products.
But nobody in the open source world wants to be "told what to do". Also, nobody in the open source world feels they have the authority to stand up and say "you must design your GUI in this fashion." Some projects, of course, will have beautiful, solid GUIs thanks to having a quality GUI designer on the project. But that currently doesn't pan out beyond the scope of the single good application. So the consistency isn't there, and it will never be there until someone puts together a GUI committee that has the authority to stamp "Tux Approved -- Good GUI Inside" on open source projects. It will require a single, strong voice. And that voice has to have a world of talent behind it. That's a mighty tall order for hundreds of grass-roots volunteer efforts to come up with.
John
The author of article specifically says that Firefox is an exception to the general trend. However, she doesn't name what project X is, and as far as I can tell, uses a lot of vague, unproven arguments, such as the one bashing gnome and kde.
"If I'd put the same person on KDE or Gnome, they probably would have spent half of their time fighting their own intuition, and the other half wondering why they were being forced to sit in front of such a clunky desktop when their Windows XP computer worked so much better."
Prove it. It might be true, but this is just a supposition. I haven't participated in an open source project and have minimal programming skills, and I can find my way around quite well.
You can lead a horse to water, but you can't make it dissolve.
Code can be split into parts and reused. A professional programmer benefits by having a large body of good open source code.
Documentation, on the other hand, is much more likely to be a one-shot thing. If a professional technical writer were to write, say, a terrific GIMP manual, and release it open source, it's not likely that they are going to get anything back that will help them on other documentation projects, at least to the extent a coder gets for releasing code.
Same for UI designers.
Basically, good open source documentation and UI design comes from people doing it as an act of charity, whereas there are good practical reasons for people to write open source code.
They are rather related to zero-cost voluntary software developement, no matter if OSS or not. It just happens that currently both are often the same.
I'm currently develpoing OSS and getting paid to do it. Overall consitency goes way over 'cream-code'.
My partners don't care about dirty hacks as long as the result is usable and looks good. Thus I'm cutting corners in code-beauty. It's going to be GPLs OSS none the less.
We suffer more in our imagination than in reality. - Seneca
Open Source companies have tons of money. Look at all the kernel hackers they hire to work on stuff.
Red Hat spent $700,000,000 on buying out compiler companies and dot-coms, and then the reason their programmers give me for why their software has usability problems is "we can't afford an HCI department."
Linux companies like Red Hat (and Suse, bought out for $200,000,000) have tons of money. It's just that they don't consider usability to be very high on their list of priorities. To these folks, its only the technical stuff and server stuff that matters. Screw having a properly trained user interaction dept that makes their software easier to use.
Ergonomica Auctorita Illico!
You'd better belive I'm designing it for ME. Its not fun to design programs for other people. Thats a job. I wouldn't do that for free. If you would like to PAY me to make it work for you, I would be happy to. Of course it is open source, so if you don't like it you can change it yourself.
Well.. maybe. Or Maybe not. But Definitely not sort of.
At the very first lecture of the Software Tools and Systems Programming class that I took, we were carefully instructed that the best software tools are small programs that do one thing well and interface cleanly with the other tools. This sounds like a philosophy which is perfectly suited for the Open Source movement: if you have many contributers and they all create one (or several) small programs that do one thing well and interface cleanly with the other programs, a very clean and powerful system can come out of it. And I believe that this has been proven by the durability and longevity of the Unix operating system.
i fully agree that this is a problem. projects like FVWM have it right. with many different programs (taskmanager and so on) on top of their core. All modules have their own manpage and are configured in the core or separate.
Where's the documentation? It came with a flimsy document showing trivial stuff. When I do Start->Help I get tons of documentation but it's all 'fake' in the sense that it tells me stuff that's obvious. Eg. to Share a folder I need to right click on the file and select 'Sharing' et.c. Doh! Where are the docs telling me how to write a device driver? Where are the docs telling me how to manipulate junction points? This OS shipped with Internet Explorer which supports a bunch of programming languages like Javascript and VBS. Where are the docs about these? Where are the docs for the APIs in all of the DLLs all over the place? Oh yeah...I have to buy a separate product to access those. When my PC fails to boot what do I do? Where are the docs telling me about the different stages during the boot process? Are there any logs? What is the precise format of NTFS on the disk? Endless questions to which I can find no answers in the documentation that came with my OS.
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
> suspect that there isn't one single reason for
> the poor quality of user interfaces, but here
> are some explanations I've heard roaming the
> Open Source circles: geeks value integrity over
> beauty; the gender gap in Open Source
> communities; it's intuitive to the programmers
> so why would they fix it? (see Programming for
> the Self), the belief that a pretty user
> interface can always be designed later once
> they're done the real work, the belief that user
> interface design isn't real work, and several
> others.
I think the two main reasons:
1) Open source developers just don't think about usability - they think about functionality. It's kinda of like a blind spot that naturally develops when you spend all day coding.
2) Good user interface design is very hard. It is a skill that most developers don't have.
When you see a slick application like the Apple i-Apps or pro graphics and video programs, the reason they're nice is that they were designed by usability specialists, who are following interface guidelines and testing the interfaces on actual users.
There are just not enough of these people in the the open source community.
Why don't these people *get* it? We write open source software because it's fun. If other people want to play, that's fine too. But you're going to have to play by our rules, because it's our game. Got it? Good.
That said, if the author of the article doesn't like the state of the documentation for the software she is using, perhaps she should consider improving it.
Don't whine. Do it.
So let me get this straight:
You say that OSX is a great example of interface design, because real live people have told you so... and KDE or Gnome are poor examples of interface design, because of an imaginary scenario?!?!?!
For the record, I've put people (such as my mother) in front of a KDE desktop, and they've had no problems with it (in fact my mother said how much she liked it.)
Note that neither this, nor the author's experience actually has any bearing on whether KDE or Gnome are usable or not.
Using the exact same methodology in this article, I could prove that MS has no money, that the moon is made of green cheese, and that Iraq has weapons of mass destruction. (Hmm, come to think of it, maybe this guy works for the White House.)
Remember kids, if you can imagine it, it must be true!
*sigh*
Fundamental issues with open source software development
From the article :
This paper discusses five fundamental problems with the current Open Source software development trend
And later :
First of all, there will always be exceptions to every rule. For example, I believe that relatively few complaints listed here apply to the Open Source browser Firefox [2] which continues to surpass my expectations. I'm discussing general trends that I've noticed, not specific cases. Secondly, I don't think that these are unresolvable problems. The purpose of this document is to raise awareness -- not to mindlessly complain -- in hopes that the Open Source community may begin to change their mind-set about some of these issues and work towards improving them.
I'd argue that the last paragraph I quoted indicates that these are not fundamental problems with Open Source Development, but merely common problems with Open Source Development. The author seemed to overuse the word fundamental throughout the article. Sorry to be nitpicky, but the title suggested a very different article than what I found. I was expecting something more along the lines of, "Open source software will never be useful, because the open source development model is fundamentally flawed in such and such a way."
Of course that would have merited a very different response, such as, "You're clearly being payed by (Insert evil proprietary software company here)".
Other than the lousy title and the gratuitous use of the word "fundamental", this article seemed very mild, obvious, and full of information that gets regurgitated on Slashdot every two days or so.
Yup, open source has a few rough edges. Of course this may be due in part to the fact that many that use it are tolerant of a bit of DIY action. This is as noted simply due to the fact that tech savvy wrote it for the tech savvy. But in the last few years linux and its packages have improved by leaps and bounds. In time it will be more accessable to the less tech savvy. This growth is clearly happening and will continue as the open source movement matures and gets better at filling a market niche.
All the problems he has noted really are the hallmarks of a "Immature" package but as time goes by the worthy packages get better and "grow up". Take KDE or GNOME in point. A few years ago it was VERY clunky (still better than win 95 tho). In just a few short years with NO PAY these guys made something quite usefull, nay may be even intuitive. It has problems and as time goes I am sure they will be addressed. It is all in the process of maturation that the project shed the bugs and effects of bad project design to become a intuitive finished project. This is true for all softwear and maturation is not free nor instant, it takes allot of effort to do this.
When a software company devotes massive $$ to make a intuitive ap that nobody needs/wants then they go bankrupt and stop. In opensource it is different. Someone has an idea. A basic implementation is made. If it is good and the demand is high it will be polished by the many that flock to use and develop it. Then it will mature and become a product that is less cumbersome, those packages that are less need/popular stay basic implementations, "infants".
*I wonder what linux wants to be when it grows up?
One of the biggest problems the average user has with most open source software is that he can't figure out how to install or configure it. The open source java app I have been working on for 2 years has gone through a few different installers, none of which were very good. Even the ones that required licence fees that we tried out were crappy. Many open source projects require the user to compile and link the source code, sometimes even making users edit source code for configuration changes. This is either laziness or lack of resources on the developer's part, neither of which looks good from a user's perspective. Software that is distributed a binaries with install/run scripts are better, as long as you can provide scripts for each platform.
As developers, generally the first thing we do after downloading some new open source software is read the README file. Then maybe the GOTCHAS.. Most users won't or can't pay attention long enough to read the instructions in a wizard based installer, much less a 50+ README. Programmers tend to be fast readers in my experience, many other people are not. So, if you can, include a one click installer and make the program configurable at runtime through a nice, easy to understand GUI.
TallGreen CMS hosting
A better operating system doesn't necessarily mean a windows clone. It means a better operating system.
Software with crappy or lacking documentation isn't good software, no matter what interface it uses.
Btw: one of the tenets of user interfaces is: if the user requires a manual, then the interface has failed in its task.
------- "From bored to fanboy in 3.8 asian girls" ----------
Can't the adults have a conversation with the Just A Kernel Kids interrupting?
Also, to out-anal your tiny mind: "Linux" is a trademark of Linus Torvolds which has been licensed for branding use by several similar operating systems. So you are wrong.
There are plenty of applications which exhibit all the flaws mentioned by the paper -- I don't disagree with any of the summary points.
Most of those applications are in-house proprietary business applications, not open source. The author is complaining about a general problem with the politics and pride of software development, not open source methodology or products.
If someone chooses to develop a tool or product that meets their personal needs, and offers it up for others to use or extend, they aren't typically getting paid for it.
If you don't like it, extend it, fix it, or hire someone to do so. Don't dump your personal application requirements on community members who are just trying to share what they have.
You want professional UI designs? Hire some developers to fix your favourite open source project, or fund the existing project development team. My idea of a professional UI is basic, plain, and functional -- no skinning, no beeps, no video, no candy.
Nothing pisses me off more than someone who demands the world for free, then bitches and whines because they can't have it without putting in an effort.
I do not fail; I succeed at finding out what does not work.
Problems with Open Source Software. It can't be. Not true. *Plugs ears* La, La, La, La, La, La, La. I can't hear you!!!
(Coming back to reality) OSS does have problems. In my experiences the problems are not techical but are with the interface. I started using Linux in 1998 and over the past six years the UI has improved. Linux is a mature OS and can no longer be considered a hobby OS but with that being said the interface, (KDE, Gnome, ect.) is still not as clean as Windows.
I do agree to an extent with the writer. The main focus of open source is often from a programmers point of view, so most programmers or computer savy people are more confortable with it. KDE and GNOME have vastly improved, but still have a few weak areas.
In the case of a mac, my roommmate can go to the Mac store and buy a printer, camera, video camer, software, install it and use and not have to think about how to get it running. You can't do that with Linux, there are few if any stores that sell Linux software, linux cameras, linux video cameras, etc, ( except for online stores ). Buy a quickcam 4000 and try to get it running. You must download special software and then 'compile...' I'm sorry but once you start haveing to require a person to compile anything they loose interest if all they want to do is use the computer. Most people think of the computer as a tool to do a task and don't want to f*** with the OS to get stuff done. Redhat and SuSE and several other vendors and programmers have made installing it and using it somewhat easier, yes, but my experience has been Mac is easeier to use, and I use Linux as my primary desktop. Windows is even easier to use.
The difference is that both Windows and Mac have UI designers, that work at the whole look and feel and making things easier for the end user. Most open source projects dont have that and need it desperately.
I think the point that you may have missed in the article is that the design of most open source is by a programmer and used by other programmers who understand all this stuff. End Users dont. I do, but I'm a programmer.
To many of the HOWTOS out there are missing a few things here and there and require a little debugging. They usually cover the majority of cases, but people don't want to read a how to they want to turn on a computer and it just works. The reason cell phones have gained such a huge acceptance today is because you just turn it on and it works. That is what made Palm so liked, was the fact that it was a simple UI. This is what Mac is famous for. The simple to use UI. of course if someone tells an open source programmer that their UI is lacking, they take offense. Hey why shouldn't they! They did it for free.
Bottom line is you get what you pay for!
Only 'flamers' flame!
Does slashdot hate my posts?
Ignoring the problem as it relates to a medium to large vendor of Free Software for a second:
If I write an application to suit my needs, I will use alpha and beta versions myself, and address any problems that come up. There's no way I'm going to write test-cases and go through a formal testing procedure, because I'm not motivated to produce a mature and complete application...just to do the bare minimum to satisfy my needs.
As for "asking for input from random people who will use your app on the web", who better to do it? People who are using the software are on many disparate platforms, which may not all be available to a developer. Those same people have just as much interest in seeing problems fixed quickly as the developers..possibly more so. Why do proprietary software vendors release beta versions of their software for interested parties to evaluate? How are *they* any different? Because those betas are released under NDA and not to anyone who wants to use them?
Good question. The answer is that I am doing it for myself, but it can be useful to others. Before the age of the public internet I actually rewrote a couple utlitlities which are now free. I would have like to have just used one that soemone else had written or taken what they had done and change it to fit my purposes. Thats usually what I do with free software, so to be fair I release back what I've done with it. Usually people probley ignore my contributions, but some of it can be useful.The point is that we as a soceity advance faster if knowledge is free.
Well.. maybe. Or Maybe not. But Definitely not sort of.
"So, it's not going to "fix" itself and there is not much we can do to alter the situation. "
Most people think that if they whine and complain enough somebody else will fix the problem for them. Until that perception is changed we will be subjected to endless articles about how much open source sucks from the perspective of the user.
It should be pointed out that users in general are never happy. They never read the documentation, they haphazardly push buttons, they never read the dialog box that pops up in their face and they constanly complain about how much computers suck. We should resign ourselves to users now bitching about linux as much as they bitch about windows.
There is an answer to all the so-called problems of the open source and that's to get off your ass do something. If you can't then give some money to somebody to do it on your behalf.
We need to make a push to make the users understand that they are not buying a product. They are joining a worldwide effort and they help is needed. Just as some shmuck gave up endless staturday nights to code that nice GUI, you need to give up something to help the process along.
evil is as evil does
How about insulting market speak passed off as documentation? For games, docs that are not included so they can be sold separately in hint books? Docs for motherboards? The worst documentation I've seen recently was for some blade servers from IBM. Among other things, IBM didn't make it clear the servers, intended for the US market, required 220 volts. Also don't care for the patronizing tone that tax program interfaces adopt.
Just ask Microsoft what Office is:
Microsoft Office XP Professional puts the features needed within easy reach at all times. Working alone, experience a smarter way to work. Working with others, collaborate more effectively. And increased reliability means never looking back - which is perfect, because your best results lie in front of you.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
Get a clue.
Violent puppy rape is not consensual sex between adults. Using the former term to refer to the latter act is incorrect and makes no sense.
Free Software IS Open Source software. It says so right on the label. Some, but not all, Open Source software is free software. In other words, Free software is a perfect subset of Open Source software. Using Open Source to refer to both is technically correct and should be perfectly acceptable. Using Free software to refer to both would be incorrect.
"The legitimate powers of government extend only to such acts as are injurious to others." Thomas Jefferson.
So what is rpm (redhat and redhat-like0/apt-get (debian and its flavours)/emerge (gentoo)/XXXXBSD's ports/package manager etc?
I personally find it a LOT easier AND less irritation to type "emerge mynewpackage" and 10 minutes later I have my new package ready to be used(and it's the most recent stable version, fully patched etc etc, no need to now go to an "update" site to make sure I haven't opened a huge hole into my system etc etc) as opposed to those stupid click click click click YESFFS I ACCEPT THE EULA click click click packages that you get with windoze.
And there's the added bonus that anything I install in linux using for eg gentoo's portage installs only what I need and no more. Those nice installation packages u get with windoze these days often install not just the app but those delightful spyware bits and bobs.
I think that the only issue with Open Source boils down to this: The things that nobody wants to do, but somebody has to. Nobody wants to think about documentation.
.m3u file to the .lst file that xcdroast wanted. If I'm wrong, and someone out there wants my script, reply here and I'll send it to you :-)
I will second that opinion, and run with it a little. But first let me say that this is a self-perpetuating situation: geek1 is using OSS and needs a program to do xyz->geek1 looks on freshmeat->geek finds program for xyy written by geek2 using OSS->geek1 mods xyy program to be xyz program and reposts to freshmeat, playing geek2 to someone else's geek1, writing minimal docs that only a geek can understand. The only way to break this cycle of unintelligible geek-oriented documentation is to have some large company ( *cough* Novell *cough* ) start paying people to write OSS docs with pretty screenshots and small words aimed at Mary Lou and Jimmy Wal-Mart Shopper-- otherwise, it will never get done.
I don't write new code becuase of the bragging rights, or becuase of the potential for 3. PROFIT!!! the reason I modify software is that I have a problem that I can't solve with the software that is currently available.
I write new code because I can't make the stuff I found on freshmeat or sourceforge do what I want it to do: it doesn't play nice with my db format, or it messes up the layout on my web pages, or it won't take my track list from xmms as a template for the order of tracks on the cd (*) So I write a little code, or tinker with what's already there, to meet my specific need. And if I come up with a solution that I think is elegant, maybe I'll submit my changes to the guy who is listed as the main contact at the place I got it from.
But your job is to provide the "service layer",
No, my job is something else entirely, and my job deals with software only tangentially. I use OSS at home because it's more secure, more flexible and more stable than Microsoft. I made the jump from windows98 because I needed a NAT box, and I didn't have any money to buy a standalone router, but I did need internet access through one DSL line for 3 computers at the same time. I solved that problem with OSS, but I didn't take the time to write documentation for it-- I HAVE OTHER THINGS I'D RATHER BE DOING. I don't get paid to write software, or write docs for someone else's software. Once my specific problem is solved, I don't care if anyone else uses the code I write... I just get on with my life.
And I argue that this is where the problem with documentation lies- if I write software that is good enough to solve my problem, then I use it, no docs required. Since I know what problem it's supposed to solve, and how it solves the problem, I don't need documentation. And since I don't care if anyone else uses my mods, I'm not going to go out of my way to write docs that no one will ever read, so that this hypothetical imaginary someone else who wants to use my software to take xmms playlists and use them to order tracks to burn cd's can do so without parsing the raw code for themselves. I think that in general people write docs for OSS only when the user base for a given program is large enough that it takes less time to write a howto than it would take to respond to questions individually. Before that threshold, it's just not worth the effort to write good docs! After all, my problem is solved, remember?
(*) the program I had these issues with was x-cd-roast, an excellent GUI frontend for cdrecord maintained by Thomas Niederreiter. I know, I know, I could just use **insert program name here** instead, but I tried 3 or 4 other guis, and was using fvwm2 instead of KDE, and... it ended up being easier to just write a script to translate the
Humpty Dumpty was pushed.
This is exactly the kind of misunderstanding that causes UI design to be swept under the rug by most open source projects. UI design is not a matter of pretty icons - its about avoiding creating software that actively discourages people from using it.
"It's Dot Com!"
1) User interface design
I also think the author of the article doesn't understand how open source projects get started and evolve. My impression is that most start from the individual "scratch an itch" program and then grow and evolve from there. This is, I need a program to do X so I write a command-line program to do X. I know where (newsgroup, whatever) other people are who might be interested in X hang out so I post about my program there. If enough people are interested, it becomes a real open source project and someone says, "Gee, it would be nice if it had a GUI."
The prevalence of command line programs is not some deep dark conspiracy to retain the command line but, if you just need something for yourself, who is going to engineer a complete GUI? That only comes after you figure out how to do X (unless you also want to learn about crafting a GUI). The main difference is that in the commercial world someone says, "We need a *product* that does X," so the ease of use and human engineering are part of the *product* development because they know they have to make it easy to use in order to *sell* the program. You will note that this misunderstanding of motivation also comes through in the original article's problems 3 and 4.
2) Documentation
Most general purpose software documentation sucks regardless of whether its from a FOSS project or a commercial vendor. The last hardcopy documentation I saw for Microsoft Office was simply the on-line help printed and bound. You don't see anything like the quality documentation that used to come with some of the old DOS programs (e.g., WordPerfect, Lotus 1-2-3, dBase, etc.). Part of this was that the people writing that documentaion had to assume that the user didn't have the faintest idea of what a computer was or what their program did.
3) Feature-centric development
I don't see this as being restricted to FOSS projects. About the only difference is that with commercial software, the feature-centric development just means the features come from marketing instead of the developers/users. I actually see *less* of this in FOSS than I do in commercially developed software. Commercial software producers have a huge monetary incentive to keep their customers on the upgrade treadmill to maintain their cash-flow. I see more of a recognition in FOSS that a program can be relatively complete.
4) Programming for the self
This one I have to agree with although I see hope in companies like IBM and Novell getting involved in FOSS. I see them as having the resources and incentive to do real human interface engineering.
5) Religious blindness
I don't see this as a problem either. I think this is one place where the author needed to provide some specific examples instead of just making general accusations. I do see a very valid position taken by the FOSS development community to respect open standards and rejection of proprietary protocols and formats. If this is the "religious blindness" she's talking about then so be it.
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
text based config vs gui/app based config
/usr/local so perhaps that shouldn't be the default, or worse ONLY place the installer looks if the app in question is a plugin or some such.
Why is this is a debate or an issue? Why do most projects still get this wrong? Having configuration stored in a text file is absolutely the way to go, this has tons of benefits, probably the biggest and least mentioned is that the configuration can be passed around or backed up. So although you spend 3hrs configuring server x and services, you then backup the conf files to a floppy and pop them back in place the next time.
Text config is also the most flexible way to go, you always have the most power and control (or potential for it anyway) with text config. That's great, it covers half the battle.
What does that have to do with the absolutely neccesity to have a configuration program? At the cli I should have two options, the text file direct or ncurses configuration app which offers 99% of the functionality available to me by editing the file directly and does so in an intuitive manner. At the gui I also have two options, the gui based configuration app which works like the ncurses one and editing the file directly. Alot of projects come close (although usually they offer one or the other) but they make said app a one time shot, rather than say, letting me configure, and then *gasp* later modify rather than completely start over my existing config or manual modifications.... and this is produced by the same people who already wrote code to parse the config file and read in the values!
The other issue here is conformity, despite configuring dozens of apps via text file every day about once a week I encounter a new style/format of config file. We need to come up with a standard for this. We also need to work on defaults, I've yet to encounter a project with even vaguely reasonable defaults... defining reasonable as the most commonly used values. As an example, neither postfix nor sendmail actually come "out of the box" configured for the most common mail setup, to use the already set host value, and relay for the most commonly used private subnets (namely 192.168.1.0 and 192.168.0.0) and use mbox files. Other configurations are exceptions rather than the rule and 90% of those exceptions would require no more than a change to who to relay for so why don't these programs come with this default config out of the box?
Installer, binary, source, wizard...
I don't see a real question here either, the answer is all of the above again. The source code of course should be available but is hardly the format of consumption for end users. The binary should be available (at least an rpm that doesn't have dependencies or has them packaged with it) and an installer wizard which helps you arrive at your initial configuration, put things where they should go and install any dependencies which the program needs with just a few clicks or key punches (after all there should be an ncurses version of the installer as well). Nvidia has a good concept with downloading the source if the binary doesn't match the system which the app is being installed on.
Someday someone will figure out that there really aren't many distro's that make use of
Documentation
There should be some! Most I've seen doesn't cover the whole spectrum, either it's for idiots, or it's for programmers or the worst, it's outdated and inaccurate and/or wasn't even vaguely accurate when it was current. For an example, look to grub documentation on installing the bootloader from the native command prompt, you'll find two different general sets of commands to use, the most common method found on a google does not work on any version of grub I've EVER encountered but is faithfully repeated, the commands listed outright wrong.
Generally a basic, and advanced USER guide which don't reference source code or compiling at all. And then a seperate set of programmers documentation kept as curre
She's referring to Open Source as a development model and not as a particular piece of software.
And I didn't say she wasn't referring to Free Software. She's referring to both. To go back to the puppy analogy above, referring to puppies necessarily refers to poodles. Not all dogs are poodles, but all poodles are certainly dogs. One needn't refer to "puppies and poodles." The term "puppies" necessarily includes poodles.
In a discussion of the relative merits of poodles, it might be appropriate to specify poodles in some places. In a general discussion of puppies, saying "puppies and poodles" is redundant. Similarly, there are some conversations where it makes sense to differentiate between Free Software and software that is Open Source but not Free. This isn't one of those discussions, since the issue is the develpment process and not the philosophy behind the movements.
Vender written software that is released as Open Source probably does not fall under the article because it likely wasn't developed using the Open Source development method.
"The legitimate powers of government extend only to such acts as are injurious to others." Thomas Jefferson.
I agree with everything said in the paper. In fact, I have been arguing those exact same 5 points for several years now.
Admittedly, in the last few years there have been real strides made for free/open-source software -- the GNOME project is the most vivid example, keeping true to its philosophy of simple, usable programs. I am particularly fond of applications like Epiphany, SoundJuicer, and Totem, all of which take a simple, user-oriented approach toward the tasks they perform.
As for advice, I would say that more projects simply need to take the advice the author of this article gives. Spending more time trying to avoid the five pitfalls outlined in this article is really all they need to do -- the real problem is that they're usually just not aware of these issues, or if they are, they don't care. If they want to make their software usable by others, they need to fix the problems.
The one thing I disagree on is the lack of documentation. I don't disagree that documentation for most free/open-source projects is poor, but were the program intuitively designed, it would be unnecessary. How many people read the documentation for a Mac or Windows system? Not many. I'd rather the developers spend time making the program usable than documenting something that is not.
Ack...yes, yes...v. bad analogy, but it was only intended to be humourful. Apologies to PETA/RSPCA etc.
Maybe a better one is...the difference between sex between consenting adults trying for a baby and sex between consenting adults who just want to spread some love in the world.
A pre-requisite of a program being Free Software is that the source is open, this is pre-supposed by the 2nd and 4th freedoms. The reason for the source of Free Software being open is ideological.
The reason for "Open Source"(N.B. capitals) software having open source is one of practicality/necessity/development methodology.
She clouds the issue, well aware of the "political" implications of doing so, why? Why not just drop the capitals from Open Source? Or better still, use the respective terms as befits the situation.Instead she relegates Free Software to a footnote and expounds on the "sociology"(hah!) of Open Source software.
Ya know...is all...
"We need to make a push to make the users understand that they are not buying a product. They are joining a worldwide effort and they help is needed."
Uh, I'm sorry, but you must have Open Source confused with Free Software.
I frankly don't give a damn about your "worldwide effort," and if that's the official position of OSS, then I don't want any part of it. I want the most cost effective software that does what I want. If OSS can provide that, so be it. If I have the urge to contribute to something that lacks features, I will do so. But I certainly do not feel compelled to design a UI for someone's pet project.
But you say I'm not allowed to complain unless I fix it myself. I have always disagreed with this idea. Let analyze it:
Situation 1: you're a developer creating a public good work as a pet project. You're not particular devoted to some "worldwide effort." I complain. If you're interested in making your project appealing to others, you will fix it. If not, no problem. I might switch to another product, but you don't really care.
Situation 2: you're a developer creating a public work as part of the "worldwide effort." I complain, despite cries that I should not. Now, if you really believe in the worldwide effort, you (or someone in the effort) will fix it because you're trying to get more people on board. But if you really just want to be self-important, you'll insist that I fix your bugs because to be in your little worldwide effort, I have to take part. You're no longer really creating public works. Instead, you've got your Eric Raymond "gift economy," in which, if you had it your way, a non-contributor would not even be allowed to use the Free Software.
Situation 2 is why the average user will hate Linux.
(That being said, I do contribute to projects from time to time. But not because I'm obligated to.)
The author gives some arguments why Open Source Software cannot be used by the common people. Is she implying our goal is to achief world domination?
Well, I like OSS, I use it all the time, but I see no reason why non-geeks should do so too. The only really bad thing about proprietary software is that most of it is owned by one company. And that causes problems when it comes to defining standards. But if it wasn't for the proprietary Word, Excell and Windows Media documents: why would we care that 95% of all computer users are using proprietary software? Does it hurt us? Most open source programmers have no advantage by the number of users. TV stations are being payed according to the number of viewers, OSS isn't. When a programmer uses OSS, and he adds code to the project, then we have win-win situation. But if 100 milion simple users use OSS, we're not getting payed, we're not getting any new code, but only millions of mails with questions that are already answered in the READMEs, FAQs or documentation. So to me it's not important that everbody uses OSS, the only important thing is that companies and OSS developers can agree on some standards, so that it's possible, and will keep being possible in the future, for users of different software to communicate with each other.
This is one lame signature, please read the message above instead.
You know, much like twofidyKidd above, I don't want to "toot my own horn" too much, but I'm one of those weird people that does a fair job of writing documentation. Knowing this about myself, and knowing that there are a lot of OSS projects out there that could use such talent at whatever level, I've gone in search of a project to help out.
:-\
Here's the rub: If I want to find an existing project to write documentation for, I have to either a) read all the existing documentation, figure out what the product does, then figure out what documentation is needed and write it, or b) find that there's no documentation at all, read the code, figure out what the product does, then write documentation from that.
In no way should I be allowed to approach a project's web site, introduce myself on the forum saying that I'm a documentation writer, and have people offer their expertise as developers in telling me what the product does so I can write documentation for it. God forbid that I should ask questions that are clearly evident if I would just read every post to the forum boards for the last year and corrolate that with code snippets that were submitted to CVS.
So, based on that, I spend my time fooling around with bad software and figuring out how to use it on my own. Once I do, I'll be pretty good at it, and I can be an elitist (l33t???) that tells people how I could lower myself to telling them the answer to their question, but I don't really have the time because I'm too busy posting to Slashdot.
The Spoon
Updated 6/28/2011
I agree with all points in the original article. I also agree with your indications of where the solution lies to (1)-(4). However I can't agree that there isn't a significant problem of religious blindness.
As just one example, take the issue of the MDI interface. Mentioning the lack of MDI as an issue on /. is likely to result in your karma being wacked with a chainsaw. But the reality is, some people with experience with all four ways of doing this find MDI easier and more convenient. Yet open source projects consistently refuse to add MDI as an option.
The four ways are, of course:
I for one have experience with all these approaches, yet I still find the lack of MDI on Linux annoying in the extreme, and the alternatives less than convenient. Especially in the Gimp. The lack of MDI there really shits me.
Why am I calling it flamebait? Because of the 5 problems he describes, not a single one was unique to open source software development.
User interface design. I've seen some truly horrendous user interfaces coming out of non-OSS companies. He points to MacOS X as a shining beacon of "UI done right" and I have to agree. But that's Apple. They're very good at it. Not all companies are as good as Apple. Not even all MacOS application developers are that good!
Documentation. He slams OSS as providing a mixed bag of documentation. Non-OSS is exactly the same! I've worked on non-OSS which is poorly documented, and I've worked on non-OSS which is brilliantly documented. In fact the OSS UNIX-like docos blows away the majority of non-OSS UNIX competition. That's one reason why almost all the non-OSS UNIX companies are kaput; their offerings were considerably worse than Linux!
Feature-centric development. Has he forgotten that the bloated-does-everything application was the hallmark of non-OSS development for years? He rightly accuses some OSS developers of repeating the same mistake, but this is a bad design habit being carried over from the largely non-OSS PC OS and PC apps market. It has nothing to do with OSS specifically.
Programming for the self. This one really takes the cake for nonsense. Has this guy ever worked with Cadence? Or Oracle? Or Paradigm? Those apps are extremely difficult to ramp up with so they have the exact same issues that he describes for OSS. What does this specifically have to do with OSS? Once again, absolutely nothing.
Religious blindness. Lest we forget, the term "zealot" was first used to describe Mac users and later Amiga users. I realise I've just invoked Godwin's corollary (the person who first says "zealot" loses the argument) but the shoe fits. All platforms have their religious nutcases. Once again, not OSS specific.
It was a flamebait article designed to invoke angry responses. The 5 problems he listed were not fundamental problems with OSS. If they were, then all OSS projects would exhibit those 5 problems. The fact that some OSS projects don't have those 5 problems is proof that they're not fundamental to OSS development. The fact that some non-OSS projects do have those 5 problems is proof that they're issues with all software development, not just OSS.
What he has described are 5 pitfalls that all projects, OSS and non-OSS, sometimes fall into. If he had rewritten the paper as "A number of pitfalls that OSS projects would do well to avoid" then he would have had a winner. If had even written it as "some OSS projects have these undesirable qualities" then that would be OK. However written in the sweeping over-generalised sense, that those 5 problems are fundamental to OSS and therefore inescapable, it's inciteful nonsense.
A few folks have touched on this, but it seems nobody really wants to say it.
... it was a mess! Since that time the average ability of users has gone DOWN, and Open Source and free software have fragmented much like the VB3 apps.
Whenever you take a collection of small applications and try to turn them into wide-spread, useful tools, you need to change the small applications so they conform to standards and can be used by the masses.
Everything needs to look the same, everything needs to act the same, and everything needs to be done graphically. Yes, the elite know you can hop out to a prompt and do certain things with certain apps, but the regular users don't, and assume the program doesn't do it if there's nothing graphical (and obvious).
Does anyone remember what VB apps looked like with VB3? Everyone was doing their own thing: some programmers used certain tools, others used only basic tools, some programmers used the Form_Load event as their Sub_Main (and basically turned it into a non-graphical program)
Don't get me wrong - standards are boring. They take all the fun out of everything (unless you consider standardization fun). But they're a necessary boring.
Winners tell stories while losers yell deal.
When I fixed my code last week, I half assed it. I only put bounds checking on one pointer, figuring that management didn't care what network neighbors would exploit.
Seriously, motivation in commercial software is a huge problem too. As a business, Microsoft only pursues security to the extent it increases profit. The mass market has demonstrated that it will mostly tolerate insecure code and so M$ keeps churning out--you guessed it--insecure code.
With their resources, Microsoft could have every buffer overflow fixed inside of a month. But currently, the competition (open source or otherwise) isn't enough of a threat to justify that expense.
If you want Windows fixed, get your friends to install Linux.
From the article:
The systemic, fundamental flaw with her analysis is that there is no united "open source" goal from which to be held back!
The assumption that all free and open source developers share the principal goal of supplanting or competing directly with more traditional software is just wrong.
For some projects, it may be true, but clearly not for others. Do the authors of ghostview want to supplant acrobat reader? I don't think so. Do the authors of the Gimp want to compete directly with photoshop? Perhaps.
Do Star Office and Open Office developers want to erode Microsoft's share of the office-suite world? You bet.
Do the mingw people want to compete with visual C++ (or whatever Microsoft's latest c++ compiler is called)? I don't think so.
In general, do you think GNU people want to compete with anybody? I don't. I think they just want to be free to create the kind of software they like.
It seems to me that there are a huge variety of goals out there, and in many cases, competing with commercial software is not one of them. In other cases it is. But in my opinion only newbies and idealists believe that free software should try to or will eventually take over the world and put closed software out of business.
What free sofware does is put pressure on commercial software. For example, I'm sure one of the reasons that Microsoft fixed the TCP/IP stack in its newer OS's is because the Linux and BSD stacks are so good. (In fact, I've heard people say that Microsoft just lifted the stack from some BSD variant. I don't know if that is true.) Microsoft also took a lot of heat for stability, once again due to the stability of various Unix-like OS's running on the same hardware. This has forced Microsoft to improve. Finally, now, Microsoft is taking tons of heat on security. We'll see how they react. (In my opinion, this already makes Linux and the BSD's a complete success. They forced Microsoft to compete!)
And of course, Linux is sort of like the blob. Microsoft tries to fight it off on some narrow front, but it just expands around that area and pushes in somewhere else. Whether it's servers, PDA's, the embedded market, or 64-bit systems, or gaming consoles, Linux is there, making life difficult for Microsoft, not out of malice, but just because it is what it is.
Anyway, just my $0.02.
MM
--
By including this sig, the copyright holders of this work or collection unreservedly place it in the public domain.
The author of this article fell into the very temping trap of least effort: not actually giving any examples whatsoever to back up her points. The only example (Firefox) is basically an admission that her points are not universal.
What's more, it is easy to argue (with examples) that all of the points in the article except for "programming for the self" are far, far more prominent in the proprietary software world than in the open-source software world. As for "programming for the self," there isn't an example and it's only true in a small subset of open-source projects.
So what can you expect? With no examples, no programs even mentioned in passing, and basing the entire article on a seemily-fictional piece of software called Project X... there's simply no content.
I'm not sure how this relates to the ease-of-use issue. I can see how having multiple small well-designed programs can solve a problem better than one large monolithic program. But that doesn't really scale to the GUI world.
For example, I'd rather run Thunderbird to read my mail, news, and RSS feeds (through an extension) all in one place than run a mail reader, a news reader, and an RSS reader seperately.
Similarly, I'd rather run Gaim than Yahoo! Messenger, AIM, ICQ, and MSN seperately. I get a consistent interface, and I use fewer system resources.
How do these things apply to the whole "small tool that does one thing and does it well" paradigm?
WeRelate.org - wiki-based genealogy