Five Fundamental Problems with Open Source? 814
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."
Features vs 'core' (Score:5, Interesting)
You are kidding right? This is probably so much more true of proprietary software (to bring up the obvious - there is no open source clippy). Except for that, it's hard to disagree with the interface and documentation arguments on the whole, however keep in mind the rapid development pace that some open source projects move at, if you look just at the 'stable' projects you will usually find much better interfaces and documentation.
Open Source low on income. (Score:4, Interesting)
One of the items this paper doesn't seem to mention is that with Open Source, you tend to have less R&D money, if any at all. This is what has kept the likes of Microsoft and Apple at the top. They can afford to spend the money on intuitive, user-friendly design. That, and it would help if open source items, such as Linux, were pre-installed on the PC when it was bought. I know it is out there, but not as strong as it would need to be to succeed.
The Issues with Open Source (Score:5, Interesting)
The things that nobody wants to do, but somebody has to.
Nobody wants to think about documentation. Or user interfaces. These things are hard, tedious, and a hell of a lot more boring than actually coming up with stuff to "make things work".
It's the reason why Windows is pretty easy to use. Personally, I think that OS X is the preferred model that many business should think about: having an open source "core" (BSD or Linux, whatever) with standard interfaces, then having the companies business be working on the upper levels: the stuff you have to see, since that's what you can pay somebody to work on.
Novell is taking such an approach, I believe, along with IBM. The issues with how to handle memory and the things that 99% of the people never see, let that get put out there so it becomes stronger. Faster. Better, and if nobody "owns" it, then everybody can use it to make their business better - fosters competition.
But your job is to provide the "service layer", such as with Novell/IBM admin tools to administrate those underlying pieces, or Apple giving you a nice "standardized" GUI where everything just works with the rock solid core.
These issues in the paper are not new - but they're the things that somebody, somewhere down the line, has to fork up for. And that's where I'm content to let a business pick up that slack and fill a product niche on top of Open Source software.
Granted, of course, they play by the rules, and let the rest of the community in on what they did so we can all benefit and get better.
Of course, that's just my opinion. I could be wrong.
documentation (Score:3, Interesting)
Good points, not just OS specific (Score:5, Interesting)
I actually think these are exellent points to bring up about *all* software, as most, regardless of development methodology, suffer from one or more of these issues.
Good at cloning (Score:3, Interesting)
Of course, this effect is amplified with UI/highly integrated applications. When text is the input and the output, it's easy to glue things together with grep/awk and automate with scripts. But the user interface with text is simple, clean and unchanged after several decades. A GUI app inherently begs for some kind of library because few can (or should!) code this stuff from scratch. Fine. Except how often are you happy with the baked-in stuff for all but the simplest apps?
So once you venture from text, you suddenly face the obstacles Microsoft has tried to fix with COM/DCOM/DDE/OLE/.NET/ATL/MFC and so on.
The disadvantage Open Source had vs. Corporate-ware (and I mean *had*) is that chaos erupts with no unifying thing to keep all the GUI and inter-app stuff in line. It seems that the distros are now becoming that unifying force. The downside is that it is getting hard to tell the difference between RedHat and Microsoft!
Re:Installers (Score:3, Interesting)
open source vs commercial development (Score:4, Interesting)
With proprietary solutions, there are full indepth analyses of market need, product placement, user targeting, etc etc, which as far as I can tell, open source projects lack. The mentioned problem of documentation is a good example of this: if the target user is successfully identified, it should be obvious that unless the user is, himself or herself a programmer familiar with open source "documentation", a user guide covering every feature, behavior, and interface should be created. One software engineering practice (to which I subscribe to) is to create the user manual *before* coding the program, and not changing it unless there's a damn good reason.
Re:Motivation. (Score:5, Interesting)
UI is a bit tricky to solve in that way, but if a push to make all OSS API-driven is popular, then other people can create UIs for OSS developed software (eg. PHP front ends, windows GUIS, Java GUIs, whatever).
Okay, that wasn't what I expected (Score:3, Interesting)
1. The big advantage of open soure - sharing and code reuse - just isn't happening. For example, I'm looking for a new OSS webmail program. I have certain criteria. There are something like 209 projects related to this on Freshmeat. Why? That is no more efficient than a couple hundred closed-source vendors doing separate implementations of competing products. What have we gained?
2. Choice really isn't, sometimes. When I am faced with two OSS projects that supposedly perform the same task, I often find that each lacks a function that the other has, and neither do everything they should. Why don't they team up and make a single, solid project?
I think the answer may have something to do with the inability of people with different skill levels to work together. Or that differing programming styles prevent two developers from ever agreeing with eachother. That's not comforting.
No Problems with Open Source (Score:2, Interesting)
I have to admit right up front, I didn't RTFA.
I did skim it, it's too long for the lame points it makes.
o Bad UI
o Insufficient Documentation
o Focus Features (Kitchen Sink Syndrome)
o Programmers programming what they want for themselves
o Religious blindness (oh Please)
Open Source folks freely give license for you or anyone else who cares to modify, use, change -thier work- for your use.
With only the restriction that they can keep the right to what they created.
Yup, shame on them for not considering the needs of the entire rest of the world.
Michelle Levesque isn't even open enough to share the name of the Open Source project being modified, I seriously doubt that Michelle Levesque will bother to share the fruits of the added value added by Michelle's team with the same Open Source world that the project originated from.
Golly gosh, Santa Clause brought me a shiny new electric train, but the one I asked for had a B&O Engine, a yellow caboose and 4 cars. The one I got has a CGW Engine, a red caboose and 16 cars.
This train set sucks, and Santa is a Fink.
I suggest caboose take a look at the huge number of Open Source projects that meet an exceed his lame list and quit looking at the free (as in freedom) glass of water as half empty.
Re:Motivation. (Score:3, Interesting)
Exactly. UI design requires either directing force or a seperate person taking an existing project and making it user-friendly.
The very cream of the crop open source software always has both, and is always funded somehow.
Who would aspire to write a clean user interface for joe blow's project that might be dead or obsolete before you get done with it?
Re:Features vs 'core' (Score:1, Interesting)
Free/open source projects, on the other hand, tend to religiously focus on core -- sometimes even so that one might argue that may be a problem.
My thoughts (Score:5, Interesting)
Good UI design is hard. A good UI designer might not even be able to code and hardcore coders generally don't make very good UI designers. It's simply not what they're interested in and so it gets only as much time and effort as is absolutely necessary. We, as a community have built some wonderful code, but not many in the community are actually UI designers. We need to find and motivate more of these people.
2) Documentation
Documentation is time consuming and not very rewarding for coders. As with UI designers, we need a large group of people who get kicks out of writing documentation and there are just too few of those special people. We need more of these people too. Trusting these tasks to the coders isn't enough.
3) Feature-centric development
Features are rewarding for developers and guess where they put their time.. Project managers are meant to drive the scope and direction of a project. Most of time, the project manager is the lead coder by default. Got to entice a few of these management types over too..
4) Programming for the self
This has an almost identical effect to #1 and the solution is the same. People who are good at usability issues must be found and enticed to contribute. Unfortuantely, we don't have much to offer in reward. Recognition? Nope... The coders/project managers get the credit for the released program. Money? Nope.. We're not talking about commercial software. Beer and Pizza? That's probably our best shot, but I'm not convinced.
5) Religious blindness
Blatently wrong, at least for a significant population of the community. Quite of few recent articles soundly debunk this.
So, it's not going to "fix" itself and there is not much we can do to alter the situation. People are doing this for fun. If it's fun to work on features rather than write documentation, that's what they'll do. Commercial software will always have an advantage in this respect because people are paid to do the work they don't enjoy.
Who cares about the general public? (Score:4, Interesting)
But this doesn't interest me. I don't like Windows, and I can't imagine liking a Linux based Windows clone that is just as easy to use as Windows any better.
The more Windows-like Linux becomes, the less I am interested in running it. I've mostly switched to FreeBSD (I used to be Redhat only).
I use the CLI, I edit with vi, I write lots of scripts, and so on. In my opinion, text based, scriptable interfaces have a flexibility and power that Windows lacks, and which I refuse to do without.
This is not to say that traditional Unix is perfect. I have spent a lot of time thinking about how to make the Unix user interface better and more powerful. I think there is a lot of interesting work that could be done on making Unix suck less. I just don't see building a Windows clone as movement in the right direction.
I understand that the general public doesn't want a better operating system. The general public wants Windows. So feel free to donate your time building an open source windows clone, but count me out.
Doug Moen
Re:documentation (Score:3, Interesting)
Code comments are for co-developers who want to work on your code. Code comments are NEVER FOR USERS. Sometimes, developers are the users, but this does not excuse the practice. As a developer who wants to use something, I never want to have to download the source package to get README about how something works, much less have to poke around looking for comments.
Re:The Issues with Open Source (Score:1, Interesting)
I have to disagree. While documentation definitely seems non-glamorous for many ("those who can, do; those who can't, document"), there are notable exceptions in OS community: many of well-respected community members actually have done more on documentation side than with actual development. True, they are in minority, but it's incorrect generalization to claim no one wants or will do that.
But more importantly, it's plain wrong to claim no one cares about user interfaces. Most developers care a great deal -- that's why UIs are sometimes so bizarre, because developer made it way (s)he wanted, to the tee. It may even be as close to perfect from that individual's perspective as it could ever get. But that may not be what would be compromise one would do when trying to sell the product: in those cases you don't care abut 100% perfection for any single user, but about best optimization, good enough for large enough part of customer base.
Now, I personally it really has more to do with specialization: few people are good at all tasks, from development of core components to UI to testing, documentation and training. And as such, what is needed is (surprise surprise!) to have enough experts from different functional areas. To have good (g)UI designers, usability experts, technical writers, participating in creating Free / Open Source thingies. There's little point in barking up the tree where developer is coding, demanding he spends more time on UI design and documentation -- you wouldn't accuse your technical writer for paying so little attention to optimizing inner loops in your fourier transform code, instead of writing documentation.
Re:Motivation. (Score:3, Interesting)
Mod me down if you will, but I felt it needed to be said.
Re:My thoughts (Score:5, Interesting)
With no intention of "tooting my own horn," UI design is something I excel at. In addition, I know how to code, I understand how to integrate the two and I know that those two things are often exclusive to each other. However, the few times I've been involved with Open Source projects, the "project managers" have expressed a disinterest in enhancing the UI for any of their software since they felt that the user base wasn't the kind that would benefit from it. Granted, that makes perfect sense, but in the long run, how many users will start to look for improved UIs as Linux moves to the desktop? I feel that poor UI design is PRECISELY the reason Linux isn't there yet, and I think for it to truly succeed on that level, they need to get some of design's heavy-hitters to bear their expertise on it. It isn't difficult to learn how to code, especially for designers since they already have an instinct for detail and "cleanliness" which carries over well into the coding world, but its exceptionally difficult for a hard-core coder to learn how to design well since its never been something they experience to the same degree as others, especially new users.
If Linux is to truly compete as an alternative to Windows, it needs an interface that provides the ease of use and flexibility that companies such as Apple and Microsoft use in their products.
It's not even that Microsoft's UI is particularly good, its that people know how to use it, and even then, most of those people use it poorly. Linux has the exceptional opportunity to set a new standard for usability.
Re:er ... (Score:3, Interesting)
Mind you, I can see some uses for PhotoShop, but for those places I prefer Deneba Canvas. (And I prefer version 8 to version 9.)
I do, however, wonder what the menuing system will be like for the next version of the Gimp, and when it will hit the fink. (I haven't yet told my wife to brace herself for a change.)
GUI vs Documentation (Score:1, Interesting)
Actually, the definition of "good" for a piece of software is that it does not require documentation.
notepad.exe is good, for example.
emacs* is a little worse...
Cheers...
~Ola
Re:My thoughts (Score:1, Interesting)
I think KDE has come a long way with the UI and usability, but now the problem is you have all these programs and hardly any good documentation on them (if any at all). But I think this problem will gradually start to solve itself. People who aren't good at coding are still able to contribute documentation - and getting these people involved, and input on the UI will all help. It's unfortunate that you couldn't help out with the UI for those projects, because even small bits of polish go a long way in making software better. The sooner the community puts more attention on the small details, the faster Linux will be accepted.
Bring users into the process. (Score:2, Interesting)
How many open source projects have non-developer, domain experts with significant roles in their projects? I know there are some efforts to solicit this kind of input, but it seems if you are writing a word processor or an inventory management program a project would do well to recruit end users that are true experts in their respective domains. Even to the point of having them on the project's top management committee. Sure they would probably have to be categorized as 'power users' to be effective and they should be fairly senior (as to understand the big picture, not just their own direct perspective.)
Also, how often do usability studies happen going into a release? It's one thing to get something programed, but another altogether to ensure the good intentions of the developers are really good in a more absolute sense.
Just some thoughts.
Re:My thoughts (Score:3, Interesting)
If I could verify that and I was able to hire people right now, you'd have an interview tomorrow. It's easy to delude yourself into thinking you're good at both, but if it's actually true, you'll be in high demand.
Also, remember that we are talking about UI design, not UI coding or graphics design. Those are completely separate skills.
the "project managers" have expressed a disinterest in enhancing the UI for any of their software since they felt that the user base wasn't the kind that would benefit from it
Ack!! Even advanced users benefit from well designed UIs. I can understand it as a time vs. benefit argument, but all I can say is wow. Sorry you didn't run into some better "project managers."
for it to truly succeed on that level, they need to get some of design's heavy-hitters to bear their expertise on it
Yes, yes, yes. We need a very large GUI designer candy bar to offer as incentive.
It's not even that Microsoft's UI is particularly good, its that people know how to use it
Agreed again. Once the power users get used to the poorly designed interfaces present in many open source programs, it's generally not noticable because they know how to use the program. Creating a UI that is intrinsically intuitive is the real goal.
Clippy -- not just for Microsoft anymore? (Score:3, Interesting)
And maybe that's the problem.
I'm one of those guys who can't wait to take a hammer to the options and smash sh!t like that Clippy into the flaming embers of hell itself. Don't hide stuff from me, show me fully qualified paths, give me dangerous options, don't tell me what to do, don't hold my hand, I don't want your useless tip of the day, that kind of stuff. And I hang around with people of a like mind -- my friends are all techies, and they, of course, feel the same way I do about Clippy (I think.) It's an evil blight upon computerdom, foisted off upon us by Darth Gates.
So you might say I was more than a little surprised when I was setting up Office for my wife and I was going in to turn off the "dog" agent (one of the Clippy variants) when she said "Oh, don't turn it off. I like it."
Stunned silence. She liked it. You could have knocked me over with a feather.
Here I was, having spent the last thirty-one years of my life learning how to use and program computers, bursting at the seams with pride of my "|\/|4D s|<i11z", secretly laughing at those people who don't know enough about computers to even turn Clippy off, only to find that my wife of twenty years uses Clippy. And she likes it.
Fortunately, I was too stunned to open my mouth and say something that might have been hurtful to her. It gave me time to think about what she said. She liked it. She found it useful. And I consider her to be a very intelligent woman.
So, now I at least understand that there is a place for Clippy, at least among the vast majority of "users" out there. And Microsoft apparently understands that, too. Open source developers? We're still mocking Clippy. But we should be learning from him.
What "problems" were those again? (Score:3, Interesting)
From the abstract, emphasis mine:
Seems they are only "fundamental problems", if everybody accepts the premise that the highest goal is to become the premier choice of "the general public." I personally don't agree with this agenda at all. In no particular order: Innovation? Quality? Free-as-in-possible-to-use/distribute/complete-acc ess-to-understand/modify/contribute-back-to-the-co mmunity? Etc.
In any case, briefly looking at the list of these "fundamental problems":
1. The lack of focus on user interface design causes users to prefer proprietary software's more intuitive interface.
Do you agree? Is there consensus on this? Is that really a fundamental problem? I'm on fluxbox [sourceforge.net] when I can choose, but are KDE/GNOME/et al. so divergent and/or different from Windows or OSX?
2. Open Source software tends to lack the complete and accessible documentation that retains users.
Huh? As opposed to what, having the same amount of documentation of e.g. the Windows APIs as Microsoft's own coders (who are the competition - Office apps, media players, browsers, etc.)? Oh, wait - it's talking about user docs. Ok, but isn't that always a problem, everywhere? The article offers "Documentation should always cater to the lowest common denominator." The best doc you read was a dumbed-down so anyone could understand it? I'm unconvinced.
3. Developers focus on features in their software, rather than ensuring that they have a solid core.
Feature-creep is hardly more prevalent in open source?!? "Shipping the prototype" is such a standard practice in the closed-source corporate world it's not even funny. Additionally, the article writes about the small 'core' tools doing few things well - I thought that was a fundamental design principle in *n*x.. and subsequently GNU/Linux, BSD, etc.? E.g. mplayer doesn't contain any of the bloat found in MediaPlayer or RealPlayer (been a while since I saw them though, they might've become better..?).
4. Open Source programmers also tend to program with themselves as an intended audience, rather than the general public.
I don't understand this at all, what is the problem? When did Joe User become more important than making the software do what you want? And making it free, Joe User can use it to his heart's content - within the terms of the licence under which you release it. Why is creating software to solve your problem a flaw? If your motto is "General public acceptance or death", it seems to become one..
5. Lastly, there is a widely known stubbornness by Open Source programmers in refusing to learn from what lessons proprietary software has to offer. ;)? But seriously, is it so? Stubborness in hating/flaming Microsoft, etc., perhaps, but surely not using ideas from them (the GUI, Mono, and so on)? If anything, I'd like to see even more divergence from "industry standard 'best practices'".
One problem might be lack of source
Sounds more like (Score:3, Interesting)
With very few exceptions any software publicly available for free is likely to suffer from the exact same problems, Open Source or not. I don't think this is an issue specific to Free Software, but rather software as a hobby. It just happens that there's a lot of Free Software being released as a hobbyist effort.
marketing and I disagree (Score:2, Interesting)
Re:I don't agree (Score:4, Interesting)
The whole article is right on the money. It seems like the author does not hold any bias but approached open source with an open mind.
Considering the author is speaking about general trends, I'd say these concepts have one common basis: separation between the end user and the developer. Each of these problems can occur (in any project, "open" or "closed") when this separation exists. This feedback loop must exist for a project to be successful, and the article presents five clear reasons why.
1) User Interface Design
Feedback regarding the ease-of-use and intuitiveness of the interface must be communicated to the developer responsible for the UI. Otherwise, users are presented with an interface for which they had no input and therefore could not alter to better fit their needs.
2) Documentation
The developer responsible for documentation must make sure tasks performed by the end-user are fully explained and the information organized in a simple manner. In order to do this, the developer must interact with the end-user to ascertain how the software is actually used as well as the level of knowledge of the typical end user.
3) Feature-centric development
Users focus on how the software enables them to do what they need. When developers know exactly what users need, they can in turn focus their development on what is important to the end user. If they don't know what is important to the end user, then features which are important only to the developer have the opportunity to "creep" in.
4) Programming for the self
An open source project survives (by definition) because people use it. If developers program for themselves, then the usefulness of the application to end users can suffer (where developers are not the end user).
5) Religious blindness
End users are essential in this because they don't necessarily have the same viewpoints as the developer. They just want something that works. By telling the developers what works and what doesn't, the developers can balance their beliefs with the needs of the end user.
Usability and UI (Score:1, Interesting)
The further problem is the usability is a function of research; it usually costs money. At the very least it needs a number of users giving adequate feedback.
I've tried but to date my experience has been a negative one. Even in the paying software community usability and UI design are relatively low status activities. Engineers and the often resist the fact you are basically making more work for them. In OSS, without the influence of an insightful management, status is very much all. As such its not a social structure that promotes usability very well.
Not Clippy..."Links" the Cat... (Score:4, Interesting)
Now if only I could set it up in a "Neko" mode where it can play "chase the mouse" with the mouse pointer...that would be cool.
Note that what I am talking about has nothing to do with the help system. I suspect that the majority of the people who actually "like" the Office Assistants are probably fond of them for toy value, not as a way of searching for help. I seem to remember that the "Dogz" and "Catz" system toy programs were somewhat popular a few years back. Those programs still seem to exist... http://petz.ubi.com/ [ubi.com].
Re:GUI design (Score:5, Interesting)
Okay, I want to take exception to that. Writting a good GUI interface, isn't that hard. I'll admit that what I do isn't directly applicable to the disucssion, but it has a grain of facts that everyone ignores about OS GUI design.
I work developing internal applications for a company. Essentially everything is a web application that ends up being for the most part, a data entry job. There are plenty of other aspects of it, but that's a lot of what we do.
In the end, I personally have made the user interface probably 3-5 times faster for the user to use. We are a far more efficient company, because of the tweaks we've done.
Simple stuff, like changing the order of items on an interface. Easy stuff, like taking the web page to a my sister to have her pick nice colors, and a good font. To more complex things, like realizing that we read numbers that are essentially the same over, and over on the phone. The phone people had to figure out where the change in the number happened, and then say "starting at ....". Now, we use a color coding system to notate where the differences are. We moved elements around to take better advantage of the Wheel mouse. We changed the ordering and names of specific items in drop down buttons so that a single letter could choose them. We used Java script so that in 99% of the time when you fooled with interface control X, control Y should be set/reset that was done automatically. We duplicated controls and keep them in sync with JavaScript. So that sometimes it's handiest to scan down a page on the left, but the most spends all of it's time on the right hand side. So we duplicated the controls, so when reviewing that everything was done properly involved scrolling thru identical controls, but the actual clicking was done in a cluttered area of the screen because that is where other important controls were.
All of this could easily be done by me (the programmer), because I used to watch people use the software. I used to see people spend a bunch of time, using their fingers trying to find changes in numbers. I realized how much time they wasted with their mouse. I realized how often they had to cut and paste numbers into lookup forms, of flip screens to get simple information they need. So we made direct links for the lookup forms. We have customized each screen so the common information you need from other screens is duplicated at the top of the one you are working on. We have done specific testing to ensure that certain pages opened a new window automatically, so the user doesn't lose the page they are on (used to happen all the time).
Now, the reason I'm talking about all the little changes, is that, they were only done because I watched users. I saw what they spent time doing. I saw what frustrated them. I paid attention to what they griped about over the lunch hour.
Because I was in the same room with them, and I could interact with them. I had a specific advantage that most OS people never have. I can watch my users use my software, to see what they find clunky. In a lot of ways, OS people would be better off to develop an X Windows recording application so they could ask users to record their software usage for later review. So you could see what the user does. How they spend their time. What they think the quickest way to do something is.
A lot of OS people, precisely because it is a large distributed population, can't see how much people struggle with interface. They can't see how many problems it creates for people. How much time was wasted fiddling with idiotic layouts. Now my specific task was simple, because I had a fixed task, that a person kept doing nearly identically. Of the them got trained to use the software identically, and they shared information about the quickest ways to get things done. So I
This is the problem (Score:1, Interesting)
I recommend you try reading something by Don Norman.
Re:Um, no (was Re:er ...) (Score:3, Interesting)
This is a typical sort of 'engineer' type comment, naively thinking that people make rational decisions based on which products are technologically superior than others. The vast majority of people do not. Mostly they just use whatever everyone else they know seems to be using, and/or what they happen to already know how to use. If you made Linux far better than both Macs and PCs as desktop systems tomorrow, and they seamlessly ran all Windows and Mac apps, you still wouldn't get more than an additional tiny one or two (maybe three) percent new users. Because that is simply just not how people make purchasing decisions, especially not individuals. (You would however get some "corporate converts", and only once a reasonable percentage of corporations converted would you start seeing individuals following suit, because "this is what we use at work"). It would only really take off once it hits critical mass, which actually (depressingly) really just boils down to people deciding based on the fact that 'everyone else seems to be using THIS' --- 90+% of those people still would never have even the faintest clue that they'd "inadvertently" be using the best product from a technological perspective, nor would they even understand why it's the best if you tried to explain it to them.
Until programmers start trying to understand the "psychology" of "the man on the street", Linux on the desktop is dead in the water.
Good point, opinion is very dated. (Score:2, Interesting)
Now it's time to catch up with distros that are way easier to use than XP and have interfaces that also do much more:
The Free and Open source comments quoted were true when they were written, but are not anymore. People really have gotten into the works enough to make many usable and easy interfaces. Like other "Free software will never do X" arguments, this one was false.
The gentle reader may remember these famous predictions. Free Software will never:
As free software generated billions of dollars for big and small companies alike, runs on all manner of hardware for all kinds of companies that demand scalability and stability, we could be sure easy to use, polished interfaces were right around the conner. They are here and available to anyone with a good network connection.
Michelle, download and run Mepis today.
So right but so wrong - but STILL so right (Score:3, Interesting)
So what you're really saying is "hey, you didn't have to pay for it, so just sit there and shut up about how bad it is. We don't care about your problems with it and we're not going to fix it. If you think you know so much, why don't you go fix it?"
Why, yes. That's exactly what they're saying.
And why not?
People ARE getting their very useful stuff for free.
The authors wrote it to handle the problems THEY care about.
It took a lot of work to get it that far. Making it easy to use and fitting it into a common interface style with a bunch of similar problems is a LOT of extra work. Satisfying every critic takes still more - and is often impossible.
If the problem YOU care about is ease-of-use, why DON'T you do something about it, rather than bitching? Source is there. Have at it!
Put in all that extra work, do a GOOD job on it, and the original author might just adopt it into the future mainline and give you major contributor credit. If he doesn't, publish your patches, or write a wrapper. Or FORK the bastard and port his future changes into your fork as he releases 'em. (Either that will be easy, or you didn't make your changes well, which might explain why he didn't merge your stuff.) If your version is enough easier to use than the original, yours will be the one that's widely adopted.
A little constructive criticism may be handy if the authors' designs are awkward to use but easily fixed. But when fixing them would take lots of work, constant whining without contributing labor is just a pain in the butt. And it's more likely to make the author drop the project than spend still more effort changing it to conform to YOUR preferences.
When somebody says "If you think you know so much, why don't you go fix it?" HE'S JUST INVITED YOU TO JOIN THE PROJECT!
Put up or shut up!
And people wonder why average users consider OSS proponents to be arrogant and egocentric?
What do you expect? These are people with exceptional skills who are working, not for free, but for ego-strokes. Of COURSE you get arrogant egocentrics. They're in it for themselves, to make software THEY like. If they make an exceptionally good tool that achieves wide adoption on its merits they've got a lot to be arrogant about.
Get used to it.
If you want it done YOUR way you have to PAY for it - in coin, in work, in resource contributions, or in encouragement. TANSTAAFL.
And if you're going to live off other people's charity, biting the hand that feeds you just makes you hungrier.
Re:So right but so wrong - but STILL so right (Score:3, Interesting)
If you don't care about those "markets," (with scare quotes, since there is no money changing hands for the software per se), then you are correct. But those who lament Microsoft's domination of the desktop and then scoff at people who bring requirements to the alternatives are missing the point.
A few suggestions ... (Score:2, Interesting)
a.) SourceForgeMart
an open source client for any platform, that hooks into a "trusted" source, such as sourceforge, and allows joe bloe user to click and install over the web in one shot. I know, i know, they can click on a link, download, find the exe/zip, execute it, config it, and then run it, but if you want to ensure the future of open source, usability for the masses is crucial. MS is going to have a really hard time selling "MS Widget X" when joe blow can just open their SourceForgeMart browser, search on a topic, and click on "Get It", and then be using it in under 30 seconds. the ultimate in on demand computing, and in reality, what comcast/blockbuster want to do with movies. If that were to occur, and the "SourceForgeMart" browser became as common as the web browser (or was incorporated into one), ruling the desktop would not even be an issue.
b.) user interfaces
lets face it, as much as we all love Teh Gimp, its user interface could use some work. It can be clumsy, but as superficial as it is, I really believe that is what is holding it back. I keep wandering back to adobe ps, as much as i hate to say it. User interfaces have to become a focus in open source land. Some people are going to kick and scream "real geeks dont need shiny icons"; they need to face the fact ---
the user interface is the "merchandizing" of the open source world. it is the marketing, the distrobution channel, the shiny salesman that greets the user everyday, and as I've learned the hard way as an entrepreneur, these things are very important if you want to keep on keeping on.
c.) Documentation and User Manuals
when someone else gets something right, you have to tip your hat to them; MS got documentation right with VS.NET; its built in, autogenerated (hate to be the company that was selling that as a plugin before VS.NET, ouch) --- open source needs to take that to the next step, and create a framework that not only plugs into sourceforge/freshmeat, but its complete and integrates itself into those shiny new user interfaces that all you open source people are building after reading point b (sic). I could see it being composed via a web tool integrated into source forge and being delivered via a web inteface/service into the app as needed. And we arent just talking
If someone were to create this standardized documentation and article/help publication framework (ive commercially done something similar...), made a renewed (and even standardized? no?) commitment to shiny interfaces, and wrapped it all up in the SourceForgeMart (TM) browser, I believe thats what they call a "Turnkey Solution"
/Ant
Re:Motivation. (Score:3, Interesting)
You do Lightbringer? There are almost no good, sizeable, complete FLOSS games in existence. There are *many*, *many* open-source games that have been started but will never be finished. There are very few sizeable games. Even huge projects like WorldForge, with many, many content producers and coders *still* haven't finished. Based on what I've seen, I would estimate that your chances of finishing Lightbringer at being less than 1%. Just about every young developer I can think of has, at one point or another, considered writing a game of their own. You would be much better off contributing effort to an existing project.
That was criticism. It was constructive (encouraging you to move effort to a place that it will likely do more good), but it was also very discouraging, and I would generally want to avoid handing out such criticism out on an OSS project. If someone writes a feature, it's a *pain* to be told that it isn't going to go in, especially if they use that feature, like it, and have documented it, tested it, and bounced it off of other users. Sure, a few projects can afford to turn away features because they have developers breaking the door down. There is no shortage of people wanting to add features to the Linux kernel, for instance. But most projects can't afford to discourage developers much.
Re:So right but so wrong (Score:3, Interesting)
Fundamentals of hackerdom include fixing annoying things, automating everything, and generally trying to be as lazy as possible, while still writing the best software one can write. However, there are many reasons to write software for other people. One of them is cash, but it's certainly not the only one.
You want your local library/university/whatever to have a website (or a better one), but they aren't interested, because that'd cost money, but they MIGHT agree that there's something to be corrected, and they MIGHT allow you to deliver a new one, and you might want to do it for free, just to make the site more usable for yourself.
Here comes the first conflict though. While you ultimately want to please yourself, you have to please the "lesser masses" too, because suchs organizations are not going to install a system which only geeks can use, and even if they did, they probably won't be interested in supporting it. So here, you have to please the "masses" just to please yourself.
Another example would be IRC. You like to chat to people with IRC? Or how about email? You want to handle most of your communication with email and IRC. But here again is a problem. Everybody you want to chat with, whether technical or not, must be able to use (and often install too) an IRC client and an email (or at least one of those). So by implementing a more usable (to masses) IRC/Email clients, you can encourage people to contact you by those channels, and once again, you ultimately have to write software for others, to please yourself.
There are countless examples why it's a good idea to write opensource stuff for not only yourself, because in todays world, we communicate so much. You don't like Word .doc's? Well, the best way to prevent people from using them is unfortunately by providing them with a free word processor which provides some important benefits (to masses) over Word.
I claim, that in many cases, writing usable software for masses can ultimately make life easier for you. So in a sense, you are still writing for yourself, just more indirectly.
Re:Product Websites / Download Options (Score:3, Interesting)
The fact that I want to use the computer to do stuff doesn't make me a linux geek. Don't get me wrong... the developers have the right to do whatever they want. Especially since they do it for free, but ultimately it's their choices that make people stay with them or go away. If they don't care, then just fine. But I think such a stance is not too intelligent when you develop software.
Diego Rey
Dead on right (Score:3, Interesting)
As a programmer with over 24 years of experience going back to writing code on pads and entering it using on an IBM 029 punch to submit to a card reader under VS/9 on Univac's IBM mainframe clone back in the late 1970s and early 1980s, to using VB 6 and Delphi today, I can say, based on my own experience of both how I have written programs and how I've used other people's, both on Linux systems and on Windows, that the author is dead-on right about the unfortunate problems open-source applications have.
This is a sore spot even on proprietary applications. At one place where I was working, my supervisor (the lead programmer) and I had very serious differences of opinion when I mentioned the book The Inmates are Running the Asylum in which I agreed with its premise that in most cases interface design of applications is being done by people who do not know what they are doing and haven't thought about how the end-user is going to use the application, and in some cases the errors in the way the design of certain applications have been done have killed people! As an open-source application (usually) has even fewer resources than a commercial proprietary one, they tend to be even worse on their interfaces.
When you're writing an application for yourself, you often omit things that you don't think you'll need later, like comments in code, or making the thing look pretty or easy to use. Commercial proprietary applications (generally) have to be easy for the "dumb user" (this is how the typical programmer sees the customer) to work with when they are shown it for evaluation or they won't agree that the product is acceptable and his boss won't sign a purchase order for it, which means it won't get bought (unless the seller knows the right people to bribe and/or blackmail). When the programmer who is writing the code of an open source application is also the primary customer the product is going to be produced as it is even if no other person in the world will ever use it.
This is a universal problem with all software that has been around from the start; programmers in general hate with a passion having to write documentation. The only difference is on an application that is funded by someone they can either order the programmer to write docs (as part of his job), or hire someone to do so. I'm sorry to say that when the program you are writing is a labor of love (as opposed something you do because you're paid to get it accomplished), the production of documentation tends to be like getting a man to be responsible for using contraception during sex: it stops the flow of the action and it's not as much fun!
Note that this doesn't mean commercial apps always get good documentation. The stuff there often sucks as bad or worse than some open source apps.
Re:My thoughts (Score:5, Interesting)
I suspect you are actually talking about framing different windows that make up the interface to one document, such as various toolbars and control panels, so that they all move together. On more modern programs they are often "tiled" to be adjacent to each other and you cannot overlap them.
Please don't call that "MDI", as the term in wrong. Perhaps "single window interface" is more accurate, especially with the newer tiled ones.
Personally I don't think single window interface is necessary, except for an annoying bug that is in Windows and has been copied on all the modern Linux desktops: the fact that clicking inside windows raises them to the top. This makes use of overlapping windows almost impossible, and has forced everybody to go to a tiled arrangement, or framing a hierarchy of child windows, so that the raised windows do not obscure important things.
It would also be helpful if windows could be identified as belonging together in some way other than the child stacking order, so that iconizing the main document could hide them all, and they only take one entry in the taskbar. This is the other reason for the single window interface (in programs like Photoshop which still allow overlapping inner windows), and a lot of the reason for multiple desktops in Linux.