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."
"Developers focus on features in their software, rather than ensuring that they have a solid core."
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.
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.
-- johntracy.com, because everybody else is wrong.
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. 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.
52 Weeks, 52 Religions with John Hummel
The article brings up lots of good point that in general I don't have too many problems with, but frankly I don't see how most of these are FOSS specific. For every issue he highlights I can point to just as much closed source software that exhibits the same problems. I think the basic arguement behind all of this is a profit margin helps fix these problems, when in reality they don't. There's pleanty of closed source software that's counter intuitive, badly documented, bloated and doesn't do exactly what I want it to do, and there are examples in the FOSS world where the developers actually do care about the above issues.
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.
The pitfalls mentioned in the editorial seem to be more common to open source projects than proprietary solutions, and I believe the issue may be with control.
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.
------- "From bored to fanboy in 3.8 asian girls" ----------
come to think of it... the best way to solve this is to get non-programmer types involved. Make doing the documentation not an 'also ran' task for those who couldn't hack it as developers, but as a really important part of the project - maybe we need a sourceforge solely for documentation and support forums.
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).
1) User interface design
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.
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
I have written a truly remarkable program which this sig is too small to contain.
I can't say I'd disagree with anything in the article.
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.
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/.
Knowledge is power. Knowledge shared is power multiplied.
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