Slashdot Mirror
Myths About Open Source Development
jpkunst writes "A thought-provoking article by chromatic on oreillynet, listing eight "myths" that Open Source developers tell themselves. For example: 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."
The myth is addressing the assumption that people who use said software will contribute to its development with patches and improvements to the code.
"Ask not what your country can do for you." --John F. Kennedy
You can use GCC's attribute system:
int foo __attribute__ ((unused));
GCC supports all kinds of cool attributes, both for functions and variables. For example, the ((deprecated)) attribute marks a variable as deprecated, and will produce a warning if any code uses that variable.
However, these methods are not portable. On nearly any compiler I can imagine, the cleanest and simplest way to supress an unused variable warning is to assign the variable to itself:
int x; /* shut up compiler warning */
x = x;
Run 'info gcc' to get the full documentation. Go to the "C Extensions" section. GCC is littered with HUNDREDS of very cool extensions. Just make sure it's worth giving up portability...
Myth: Publicly releasing open source code will attract flurries of patches and new contributors.
;D
Myth: Stopping new development for weeks or months to fix bugs is the best way to produce stable, polished software.
Myth: New developers interested in the project will best learn the project by fixing bugs and reading the source code.
Myth: Installation and configuration aren't as important as making the source available.
Myth: Bad or unappealing code or projects should be thrown away completely.
Myth: It's better to provide a framework for lots of people to solve lots of problems than to solve only one problem well.
Myth: Even though your previous code was buggy, undocumented, hard to maintain, or slow, your next attempt will be perfect.
Myth: Warnings are just warnings. They're not errors and no one really cares about them.
Myth: Users don't mind upgrading to the latest version from CVS for a bugfix or a long-awaited feature.
For explanations of each RTFA
The difference is the pay! If I am working on a job I will suck it up and dig in to unfamiliar code to fix bugs and learn it.
But if I am on my own time, there is no way I am going to spin my wheels and rack my brain to learn someone else's personal spaghetti style. If the code is well organized and commented, I will likely lend a hand.
Basically, if I am helping for free, the barrier to entry must be lower. Call me lazy, but...
How many open-source developers you know that conduct large-scale usability tests?
I would imagine that many orders of magnatudes of more people have tried the lastest version of the Linux kernel as compared to Solaris, WINNT, and darwin kernels. Maybe that is not a usability test. For me I downloaded a few of the lastest Linux kernels for my desktop, I have found some good stuff, like performance increases. I've found some stuff was broke to hell, like sound and IDE when combined withe ACPI. You know what, these issues were already being discussed on the mailing list when I found them, and they appear to be working now that I am running 2.6.0-test11. Btw, I cannot get windows to play a dvd on the same laptop now that I have tried to patch it because of the RPC worms.
How many open-source developers go around interviewing end users?
I do. So thats one. How many closed source developers do this?
When the developer and product consumer is the same, open-source makes much more sense to me.
Hmm, sounds like the UNIX world to me. Built by developers and geeks for developers and geeks. Its working pretty well. All of the big boys are doing it now, IBM, HP, Dell, Sun, etc.
Alan Cox has a Ph.D in Computing Science
Linus also has a degree of some sort, I believe.
(strangely, can't seem to google up a reference to it)
And even if there are a lot of people who use it - don't expect them to be willing or ABLE to provide you feedback or software development assistance. Being open source doesn't mean that people will take the time to help the project along. Many people will use the software and download new versions of it without ever once providing any assistance of any kind back to the community that developed it.
You know, I think RedHat made a big mistake in calling the tool that installs RPM packages rpm. Because everyone thinks that the only tool that is capable of interfacing with the RPM packaged database is rpm. All it is supposed to do is install/update/remove/verify packages, and tell you about dependancies or package contents. It's a glorified front-end to the DB.
If you want apt-get like behavior, you should be using up2date. And then there's yum which has apt-get like syntax. Both of these meta tools use rpm(1) to do the actual work of installing and verifying the packages, but they do the work of automatically resolving dependancies and downloading packages you need.
They split rpmbuild out of rpm... so they should go full hog and rename up2date as rpmget (text mode only unless $ARGV[0] == up2date-gnome) or something like that. Then maybe everyone will wisen up, and Debian users will shut up.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Here's another common myth... "You can't sell open-source software". Not true! In fact, the FSF encourages people who distribute free software to charge as much as they want.
If someone has a degree from a reputable school of higher education, you know that the person knows his C.S.
Having experience is great, but the degree nowadays is required just because the employer needs confirmation of the abilities of the people he hires. If you have a degree AND oss experience, I'm sure you can find a job.
You can lead a horse to water, but you can't make it dissolve.