“One persistent misfeature of open source development is thoughtless mimicry, copying the behaviors of other projects without considering if they work or if there are better options under the current circumstances. At best, these practices are conventional wisdom, things that everybody believes even if nobody really remembers why. At worst, they’re lies we tell ourselves.” Read the rest at OnLamp.com.
Myths Open Source Developers Tell Ourselves
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
One persistent misfeature of open source development is thoughtless mimicry
Like what? Show me any major OSS that mimics another piece of software thoughlessly. Evolution makes a lot of sense in behaving like Outlook. KDE and Gnome don’t even look remotely like Windows any more without themes.
Myth: Publicly releasing open source code will attract flurries of patches and new contributors.
Reality: You’ll be lucky to hear from people merely using your code, much less those interested in modifying it.
You’ll get feedback in direct proportion to the amount of enthusiasts that use your software. You’ll get patches in direct proportion to the amount of enthusiastic developers that use your software. It’s a popularity contest.
Most of the code in a given project comes from one or a few developers. That’s not bad — most projects don’t need to be huge to be successful — but it’s worth keeping in mind.
Most OSS projects don’t have a huge audience. Most developers know this. Developers don’t think that simply GPL’ing their software that hordes of patches will fly in the mailing lists. This is not a common myth.
Myth: Stopping new development for weeks or months to fix bugs is the best way to produce stable, polished software.
Reality: Stopping new development for awhile to find and fix unknown bugs is fine. That’s only a part of writing good software.
Right, most of the work was done before the freeze. Then the author goes on to make a statement that will make any developer, proprietary or OSS, laugh out loud:
The best way to write good software is not to write bugs in the first place.
Come on.
Think of your project as your home. If you put things back when you’re done with them, take out the trash every few days, and generally keep things in order, it’s easy to tidy up before having friends over.
No one starts to code with the intent of writing sloppy software; code trees get that way over time. This happens in both camps anyways. The guys that maintain large source trees like Linux know what good code is and what bad code is. This author should take a loot at Linux kernel mailing lists.
Many of the users you most want to test your code before an official release won’t. The phrase “stable release” has special magic that “alpha,” “beta,” and “prelease” lack. The best way to get user feedback is to release your code in a stable form.
Right; release early, release often. However, if code really isn’t stable, you’re only going to upset users by getting them to try out buggy, half-baked alphas. Some projects, such as alsa and grub, are very stable and still the developers refuse to release them as such. This is a problem in some projects, but not across the board.
Myth: New developers interested in the project will best learn the project by fixing bugs and reading the source code.
Reality: Reading code is difficult. Fixing bugs is difficult and probably something you don’t want to do anyway. While giving someone unglamorous work is a good way to test his dedication, it relies on unstructured learning by osmosis.
No, people take pride in software they write, or help right, and enjoy ironing out software. Most stable branches nowadays rely on bugzilla of sorts to tell the developers what to work on.
And now we get to the most questionable part of the article (for me, at least),
Myth: Installation and configuration aren’t as important as making the source available.
Reality: If it takes too much work just to get the software working, many people will silently quit.
In OSS, installation is not a developer issue. Release the source, and packagers will take it and make it work well with all the different distributions across the board. This is not Windows, applications aren’t required to install themeselves. I am happy to hear that the author wrote installation guides before writing software, but developers who use GNU autotools do not have to make packages for every distribution out there. End of story.
This isn’t a myth because people really believe software should be difficult to install. It’s a myth because many projects don’t make it easier to install.
I do NOT want software to ship with it’s own installation scripts/tools. Anyone who thinks that applications in Linux need to install themselves doesn’t understand package management. Anyone who thinks that this attitude is preventing widespread adoption of Linux doesn’t understand package management. Nothing about package management necessitates the use of the command line, or dependency satisfaction, or anything else that newcomers have trouble with.
I challenge anyone to think up a good reason why software should install itself (like InstallShield).
Solving the same simple problems again and again wastes time that could be applied to solving new, larger problems.
That implies that we’re solving the same problems the same ways. That is incorrect. We’re solving the same problems different ways, and that is a Good Thing. Progress hasn’t stopped because Linux isn’t a homogenous environment. I would argue that it’s been accelerated.
Myth: Even though your previous code was buggy, undocumented, hard to maintain, or slow, your next attempt will be perfect.
Reality: If you weren’t disciplined then, why would you be disciplined now?
I agree with this one completely (unlike most of the rest). Actually page two is all right, it’s just page one that I find to be a bit ill informed.
“Myth: Even though your previous code was buggy, undocumented, hard to maintain, or slow, your next attempt will be perfect.
Reality: If you weren’t disciplined then, why would you be disciplined now?”
Perfect, surely not. That said, I think coders can genuinely improve; no one starts writing bug-free, well documented, maintainable quick code.
This article blows the common OSNews/Slashdot-stereotype that “open source programmers are all antisocial nerds and elitists” completely out of the sky.
Suddenly all the anti-OSS zealots became quiet.
Suddenly all the anti-OSS zealots became quiet.
I don’t think there is such thing as an anti-OSS zealot. The zealots come from the socialist Stallman camp and a significant portion of Mac users.
Except Stallman is not socialist! http://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowMoney
“You’ll get feedback in direct proportion to the amount of enthusiasts that use your software. You’ll get patches in direct proportion to the amount of enthusiastic developers that use your software. It’s a popularity contest. ”
Depends: if your end users are developers, you are far more likely to get feedback than if your users are ordinary folks who know nothing about code.
I should imagine that something like GCC gets (relatively) a lot more feedback than, say, Firebird simply because developers are more likely to be able to look into the source code and try to fix things themselves. Most end-users simply don’t code that much.
No it’s just the majority of people that have an opposing point of view have stoppped hitting this site. Look at the article’s. Why bother.
> Except Stallman is not socialist!
I fail to see how your link proves this statement. Socialism isn’t anti-profit either. Socialism can still be capitalist (see Canada).
Communism *is* anti-[profit/ownership] however, and Stallman’s political views do seem fairly communist. There is nothing wrong with that — communism *in theory* is pretty utopian — I just happen not to agree with Stallman much of the time.
But it’s a silly subject for conversation anyway.
The “myths” piece is dead on, and should be required reading for OSS developers. Chromatic obviously speaks from experience.
Depends: if your end users are developers, you are far more likely to get feedback than if your users are ordinary folks who know nothing about code.
Ok, I’ll restate my original quotation here, and hope you read it again (even though you quoted it):
“You’ll get feedback in direct proportion to the amount of enthusiasts that use your software. You’ll get patches in direct proportion to the amount of enthusiastic developers that use your software. It’s a popularity contest. ”
How is this in disagreement with your comment?
I hope all of us get modded down (it is irrelevant to the topic at hand), but whether or not Stallman is a socialist does not change the silliness of pigeon-holing folks into silly groups so that we can attack them without considering the merit of their argument.
Roy Batty’s comment was purely naive in that regard. There are anti-OSS folks that come to OSNews comments sections on articles about specific OSS acheivements and distribution releases that remind us all how “Linux is just not ready for prime time.”
A “zealot” is a term that should be summarily avoided; it categorizes people in an unfair manner (just like “terrorist” or “socialist). How strongly I believe in my ideals is not important next to my willingness to adopt new ones in the face of compelling evidence.
I have often spoke badly about a lot of Gentoo users on this forum. I realize I’ve commited the same foolish act I’m speaking out against here. I apologize using such a fashionable yet empty term.
1) Communism is the abolishment of private ownership in favour of collective ownership on the basis that everyones needs will be satisfied ahead of simply going towards profit making. What is more profitable, finding a cure to a disease or simply producing a drug which would require the individual to take every day right through out their life. One is a once off payment, the other is one which provides a long term revenue stream.
Communism breaks down on the basis that it assumes that everyone who contributes will take only what they need. In reality, when people see that there is nothing holding them back from being glutenous, such as income difference, there results in shortages. Also, communism fails to take into assumption the fact that people are specialised and communism assumes that technology has got to a state where you don’t need to have hundreds of factories, each dedicated to one particular product.
On that basis, communism fails because as a result you end up with maket forces not taking place resulting, for example, a surplus of shoes when there is no demand, but when there is demand for cars, for example, the state cannot allocate the resources quickly enough to satisfy the demand, resulting in a very inefficient market system.
2) The problem with many opensource projects is that there is no plan and no direction laid down. The documentation is poor from a programmers point of view. A person who is interested should be able to pick up the development plan, the programme documentation relating to the various parts which make it up and actually be able to fix problems as they see it.
GTK for example is poorly documentated and the road map is atrocious. The focus should be right now on what 3.0 will encompass and they should plan it so that the only thing that needs to be done is the implementation side. What we see right now is design, write, design write.
That is a terrible way. You end up with ideas simply being added rather than the question of, “how does that fit into the over all goal of this particular project? how does it affect it? will other parts need to be adjusted to take advantage of this new feature?
There needs to be a long term road map so that third party vendors can also plan adhead. If the Adobes and Macromedias don’t know what is going to happen in 2 years time, do you really think they’re going to invest the cash with that sort of uncertaintly hanging over their head? heck no. They’ll rather stick with the baroque but “pretty stable” win32.
I think that Developers are more likely to fire off feedback than an end-user.
“Reading code is difficult.”
Well, yes if it is badly written. True.
If it is well written and design documentation is in order – it is not.
And whole myth is well… not a myth.
Agree with every point.
Uhm. As if that’s the only system open source people “like”.
Linus isn’t a socialist, he doesn’t want everyone to use Linux. He wants fair competition. He has said that multiple times.
Then we have RMS. I’m not sure where i have to put it. I think among the social democrats though i’m not convinved. He does mention Kucinich on his homepage, but tat doesn’t convince me.
ESR. A socialist? I take it you haven’t read his page then. He’s a libertarian aka anarcho-capitalist i think that much is sure.
Surely those are not the most popular ideologies. Then, there’s the people of VAlinux, OSDL. Plus a load of people we do not know about.
Now how is their source license ___CO___related to their political ideologies? Can you say that developer X who devs Y has political opinion/ideology Z? No. At most related, but surely not by definition. It would be a case to case (individual) judgement, by an individual.
Start for example here for more alternatives to our current system. The ones your government doesn’t want you to know about.
http://www.infoshop.org/faq
“there’s more than state socialism, state communism and plutocratic capitalism”.
Whenevre people in OSS try to deviate from the norm, people like Eugenia are there to complain that it’s different.