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
I assume the author isn't aware that the code often contains comments that can be helpful (especially if they are in some language you don't know). Seriously though, I wish universities would put their English students to work writing docs for the piles of open source software out there, rather than sticking them with meaningless brain-dead assignments. Get a grade, and do something useful you could even put on your resume, cool huh?
I Am My Own Worst Enemy
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.
Open source projects consistently do a great job at replicating stuff that non-open source groups develop. GNU/Linux itself is more or less a remake of Unix. MySQL reimplemented SQL. Samba emulates Microsoft's protocol, etc. That's because coming up with and delivering completely new things is hard. It usually requires pain, and some really unpopular decisions which fly in the face of the Open Source culture.
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!
Does it hurt to hear them lying? Was this the only world you had?
OPen Source, almost by its very definition, won't create standards, it'll just fork. So yes, you are spot on, but the solution to that vexing problem is almost impossible to implement.
So rise up, all ye lost ones, as one, we'll claw the clouds.
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).
Well, that article was rather short (figures, I actually read the article and find it wasn't worth the effort). I think two points that need some greater detail are as follows:
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.
Fred
"A fool and his freedom are soon parted"
-RMS
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.
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?
Always going forward, 'cause we can't find reverse.
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.
Here's motovation for you -- criticism. As part of the motovation in Open Source is recognition, the last thing you want is your project to be seen as "This is why you shouldn't use Open Source". On my project I hold everyone to a high standard of quality. This is a high expectation, but a reasonable one if F/OSS wants to make a place in Joe User's machine. I have my family using certain F/OSS on their machines, not because of ideology, but because it's good software. I think that is what the author of the article was trying to get it with "Religious Blindness". "Use Free Software, because it's Free!" imho is an act of faith than an act of judgement.
Mod me down if you will, but I felt it needed to be said.
Karma whorin' since 1999
That's interesting. I have PhotoShop, and I do most of my work in Gimp. And the Gimp doesn't work as well on the Mac as it does in Linux..not even if you use Apple's version of X window and the fink's version of the gimp. (Nearly, though.)
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.)
I think we've pushed this "anyone can grow up to be president" thing too far.
A well designed program does not need documentation.
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
Disclaimer: I have not read the article, but the gist of the post is reasonably clear and see things the way I see them... so it must be right!
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.
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.
John
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 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
668.5
"You get what you pay for."
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.
I Browse at +4 Flamebait
Open Source Sysadmin
Firstly, I think the author is WAY off with the comment that open source software is feature driven. I believe the contrary is true. Open source software is design driven because of one of her other points - it is made for other developers. You will not gain much in terms of bragging rights if your underlying architecture is sloppy, especially when everyone gets to look under the hood. And so what if is is made for other developers. I like the UNIX philosophy and the command line and so what if she doesn't! Open source software is kind of the kit car of the software world. If you are into cars you love to tinker but if you just want to go to the store you don't want to know where the manifold is. Its all about CHOICE.
rootsmith Inc.
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.
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.
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
I recommend you try reading something by Don Norman.
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.
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.
Friends don't help friends install M$ junk.
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.
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.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
There are a few things that ive noticed that could really improve the visibility of open source software (imho, as always):
.nfo files here, more like a complete - end - all - be - all of information right inside a mini browser that pulls in things like data from google.com via a webservice and www.everything2.com for simple word definitions. Something that could educate joe blow as he went.
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
Here's motovation for you -- criticism. As part of the motovation in Open Source is recognition, the last thing you want is your project to be seen as "This is why you shouldn't use Open Source". On my project I hold everyone to a high standard of quality. ...I generally don't like criticism, just because it discourages people from volunteering their time.
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.
May we never see th
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.
Software should be free as in speech, but if we also get some free beer, all the better.
Why should I? I was just curious to try the game out, but I'm not going to die just because I couldn't do so. In the end the developers get one less potential user.
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
diegoT
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.
The lessons of history teach us - if they teach us anything - that nobody learns the lessons that history teaches us.