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."

Comments

Headline for the article is a troll

[Aron S-T]

Nearly all of the article's "myths" are relevant for all software development, not just FOSS. As for the first myth, and the one cited in the posting, that's just a troll. I don't think anyone believes that just releasing code makes it useful or desirable. In other words, this article should have titled: 7 Myths about Software Development. As such, it's not bad, although I didn't find any deep insights in it.

----------------
Mythical Man Month Methodology
http://fourm.info/

Re:Headline for the article is a troll

[goldspider]

You completely missed the point of the headline Myth. It has nothing to do with believing one's OSS is useful or desirable.

The myth is addressing the assumption that people who use said software will contribute to its development with patches and improvements to the code.

Re:Headline for the article is a troll

[RatBastard]

Nearly all of the article's "myths" are relevant for all software development, not just FOSS.

This is true, however, most commercial developement groups already know that these myths are just that, if not the coders, then their managers at least.

The issue he is covering is the fact that many people on the FS/OSS movements beleive that these myths are true. This article is not a condemnation of the FS/OSS community, but a reality check for them.

Re:Headline for the article is a troll

[Kris Thalamus]

If open source developers are ever going to shake their image of being zealots, they need more of the kind of self aware pragmatism that this article provides.

Defensively crying "troll" in response to criticism isn't going to help matters any.

Re:Headline for the article is a troll

[Tony Hoyle]

It's a complete straw man though.

Opensource works because even though 90% of users of a project won't contribute, the 10% that do (not just code, but bug reports, comments, newbie help, documentation, etc.) make a huge difference.

Half of the stuff is assumptions I deal with *every day* from management on my paid work, so to say that OSS makes these assumptions exclusively is a pure troll.

Some of it is plain loony - saying that writing code once and sharing it is a commercial advantage is ludicrous - the *point* of OSS is that we write stuff once then share it. Commercial development does exactly the opposite, by protecting everything with patents and forcing everyone to re-invent the wheel when they write anything.

Re:Headline for the article is a troll

[Aardpig]

No, what the first myth was alluding to is this: when you release your OSS project into the wild, don't expect an army of l33t coders to materialize and assist you in developing it.

I've found this myself; I wrote a code for performing spectral synthesis of stars undergoing quakes, and released it under the GPL. There are quite a few asteroseismology groups around the world using the code now; but not a single person has contacted me and offered to help develop or debug the code.

As chromatic pointed out in his article, the majority of OSS projects have very few developers, even in cases where the project has a large user base.

Re:Headline for the article is a troll

[Ed Avis]

But we know that people _do_ contribute patches and improvements to the code. Many developers have first-hand experience of this (from both sides, contributing and receiving). So it's hardly a myth.

Unless the author of the article has done some measurements to see what proportion of users send back improvements - and there's nothing in the article to say that he has measured anything or that he maintains any free software himself - then there's no reason to believe him rather than the 'myth'.

Re:Headline for the article is a troll

[Atzanteol]

IF you had READ the article, he mentions that many of the myths are general to all software development, and that only SOME are specific to OSS.

Re:Headline for the article is a troll

[karlk79]

Sometimes the prblem is ommunication. have you tried to approach them. Or talked to them asking for help. See women dont jump in my be because i have it hanging out, i have to talk them into helping. Its a community not a blog.

Re:Headline for the article is a troll

[hackstraw]

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.

So. Just because something is open or closed source, it does not mean that it is a good program nor does it imply that anybody wants to use it.

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.

I don't see too much disparity here between the "myth" and "reality".

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.

This "reality" again does not dispell the "myth". Try having new developers interested in a project and reading source code in a closed source project. Yeah, its difficult to read code, but infinitely more difficult to read it if you dont have access to it. BTW, the metaphor or whatever "osmosis" is trying to make a point is pretty silly. Osmosis is the transfer of water through a semipermeable membrane.

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.

Yeah, there not that important thats why we did silly stuff like create autoconf to configure and install software. That is why we carry around the install.sh form X11 to install software in a predictable and sane way. That is why we have plain readable text files to configure our software. The reality holds true for closed and open source as well.

Myth: Bad or unappealing code or projects should be thrown away completely.

Reality: Solving the same simple problems again and again wastes time that could be applied to solving new, larger problems.

This is again true for open and closed source projects. Go look at one of the windows (closed source) freeware/shareware depositories and you will find at least 5-10 programs that all do the same thing more or less. If these were open source projects, I would imagine that there would be a good amount of code reuse going on here.

Myth: It's better to provide a framework for lots of people to solve lots of problems than to solve only one problem well.

Reality: It's really hard to write a good framework unless you're already using it to solve at least one real problem.

Does anyone thing this is either a valid myth or something too terribly interesting to talk about? I will say however, that UNIX (I'm generalizing that opensource is more of a UNIX like thing here) in general is a framework and our stuff plays well with one another. We have programs have STDOUT, and STDERR messages that are formatted for external processing and parsing, we have exit statuses in our programs so they can be &&ed and ||ed or test for their success or failure. We have signals, pipes, and sockets for IPC. Look at the number of opensource installs and the wide variety of things that they do and tell me that we are not solving a number of real problems well.
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?

Axiom of life. If program sucks, noone will use it. This is true for opensource and closed source stuff.

Myth: Warnings are just warnings. They're not errors and no one really cares about them.

Reality: Warnings

Re:Headline for the article is a troll

[chromatic]

It's my experience that the percentage of people who send feedback or patches is much lower than commonly expected. See, for example, Nicholas Clark explaning the volunteer pool for Perl 5 core development:

You may not be counting, but there are about a dozen active perl 5 developers on p5p, about half with commit rights. Similarly parrot has about 5 active committers.

This is the number of competent volunteers that a well established 16-year old programming language used by many individuals and many organisations can muster. From the entire world.

Of course, there are hundreds of people in the CREDITS file, but a handful of people do the bulk of the work. Maybe it's an edge case, but 10% of Perl users aren't contributing back to the core. It's very much below 1%.

That's not bad. It just is. My point is that expecting a smaller, younger, and less-well-used project to attract more regular and frequent developers is usually unrealistic.

Re:Headline for the article is a troll

[redragon]

Some of it is plain loony - saying that writing code once and sharing it is a commercial advantage is ludicrous - the *point* of OSS is that we write stuff once then share it. Commercial development does exactly the opposite, by protecting everything with patents and forcing everyone to re-invent the wheel when they write anything.

Ummm...a large percentage of commericial code DOESN'T patent. They just don't share the code. It's closed source. You can't see what it does. That's all. You can't (of course our glorious patent office does stick their head in their bum quite often...) patent every piece of software under the sun. Most copanies that do patent, only have certain pieces that make them special/unique/whatever patented, but the rest of it is just copyrighted.

Re:Headline for the article is a troll

[Frymaster]

the difference is where the sense of "obligation" lies:

corporateware: the users feel the company is obliged to provide the featues, support, bugfixes and documentation regardless of the sticker price for the ware. once a company takes money and issues a eula, they accept responsibility.

fs/oss: the user understands that s/he is obliged to contribute in some manner, even if they choose not to. since most users don't contribute to any given fs/oss ware, there is a certain degree of guilt from the sense of unfulfilled obligation that makes them more appreciative of the ware.

Re:Headline for the article is a troll

[cduffy]

...and the article doesn't claim *nobody* will, just that a huge team won't materialize out of nowhere. That's about right.

I've been maintaining cscvs, a tool for breaking a CVS repository's history into changesets and (among other things) importing its contents into the GNU Arch revision control system. It's adopted a fair number of users (more as the documentation and such get better), and a number of developers have contributed patches. If I weren't quite so busy with my job right now, I'd have been able to help *another* developer with a bugfix he's asked for a hand in putting together (to fix mismangling of the repository locations of CVS repositories which have a delta between the path used in the CVSROOT and the one used in rlog output other than the single such case I'm currently fixing).

The other project my maintainership of which could be considered active within the past year would be the "Ticket Applet 2", a GNOME applet for showing and updating the status of ones' Kerberos ticket. It's received a quite major patch from one outside developer (providing compatibility with his alternate Kerberos implementation), and feedback from a number of users at my workplace -- but there was certainly no flood of support washing in the moment I put it up on freshmeat, and had I been expecting such I would have been mistaken.

I think the actual claim in the article is a lot more defendable than the little slashdot blurb -- to the point that the blurb really does both the readers and the author something of a disservice. (Indeed, the only one I completely disagree with is the argument that it isn't sometimes best to throw out working code for a complete rewrite should it become unmaintainable).

Re:Headline for the article is a troll

[prockcore]

but not a single person has contacted me and offered to help develop or debug the code.

An optimist would say that this is because your code, through some bizarre statistical anomoly, is perfect and doesn't need any further development or debugging.

A pesimist would say that you are the only one in the world who cares about spectral synthesis of stars undergoing quakes.

Re:Headline for the article is a troll

[Ed Avis]

I think it's unfair to count only the perl core; count the core and CPAN. Yes, even though most CPAN modules are not included with the perl core I think this is a fairer comparison. After all the point of programming in a higher-level language like Perl is that you don't have to make patches to the core in order to develop new features; you can write them as Perl libraries.

Re:Headline for the article is a troll

[PierceLabs]

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.

So. Just because something is open or closed source, it does not mean that it is a good program nor does it imply that anybody wants to use 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.

Re:Headline for the article is a troll

[PainKilleR-CE]

Commercial development does exactly the opposite, by protecting everything with patents and forcing everyone to re-invent the wheel when they write anything.

That is a strawman, as commercial and open source are not opposing viewpoints. I write a great deal of software that comes with the source code and is not commercial, yet that doesn't mean I post it on the internet, either. Red Hat, Mandrake, and many others are commercial software companies that happen to distribute (mostly) open source software. Microsoft, of all people, distributes some open source software (and charges money for some of it).

Furthermore, even closed-source software does not generally mean using patents or even forcing people to reinvent the wheel. You deal with a lot of APIs, frameworks, libraries, and so on in commercial software development, and you also produce those things. IT departments don't all buy MS Office just because it's the most used office software, but also because it's a rather minor job to write a piece of software that utilizes and controls any piece of software in the Office suite (which is also why Office has been such a problem when it comes to viruses, worms, trojans, macro exploits, and so on). It's easy to put an Excel worksheet in a window with a bunch of custom controls and save the data as an Excel file. This isn't re-inventing the wheel, it's high level re-use, without needing access to the code.

Open source works because, when they want to, anyone can work on it. It works because, as long as people are willing to host it, the code is always there. You can't kill it unless you drive out the desire to work on it. However, there are no guarantees, and this is what the myth is dealing with. Just because you write something and release it's source code doesn't mean that you'll find people that even want to use your software, never mind actually write code or tell you what's wrong with it. It's not just the OSS community that makes these assumptions, but it is an assumption generally made about OSS. My managers sometimes like to make threats, especially when software is taking too long to complete (in their estimate, not based on the estimates I gave them at the beginning of the project), that they'll just get someone else to finish it up. While that is possible (just as it's possible that people will help if you just open-source something), it isn't an easy road to take, and doesn't guarantee anything. Someone coming in to take my place on a software project has to figure out what's being done, what has been done, and where it needs to be to finish it. Someone coming into an OSS project has to figure out where they should start to contribute. For some people, just the mass of unfamiliar code will prevent them from getting anything done for days, weeks, or months, or even discourage them from doing anything at all. Many either won't see a need to add to the code, or won't see anything that makes your project any more valuable than any other project performing a similar function (or anything of value in the project at all). You have to get past all of these obstacles before you get a single contribution. All of these obstacles are also hidden behind the first major obstacle: making people aware that your project even exists.

Mozilla has, for most of the projects lifetime, been mostly a project of the same group of Netscape developers, whether they're the ones that open-sourced it in the first place or people that have been hired in the time since then. OSS probably saved Netscape from extinction, but how many projects have the recognition to survive the time of complete failure and uselessness that existed in the Mozilla project before a single good build came about?

Re:Headline for the article is a troll

[Anonymous Coward]

there is a certain degree of guilt from the sense of unfulfilled obligation that makes them more appreciative of the ware.

"*OW!*"
"What's wrong?"
"Oh, it's nothing. Just a quick jab of vague guilt. It seems to happen once a year or so then goes away. I don't know why."

Re:Headline for the article is a troll

[chromatic]

That's a good point.

Still, count the number of Perl users in the world and the number of registered CPAN authors. I can't find a reference now, but there are a few thousand authors and a few thousand modules. The ratio of CPAN contributors to Perl users worldwide is still much less than 10% -- probably still not over 1%.

Re:Headline for the article is a troll

[mark_lybarger]

If these were open source projects, I would imagine that there would be a good amount of code reuse going on here.

really? maybe building on others work from time to time, but not as much code reuse. lots of times it takes as much time to find out about code to re-use as it does to actually re-write the code. during refactoring is where code reuse is sometimes best implemented. sure, once a developer knows about a piece of trusted code, they're sure to use it often. but until then, lots of people prefer to home roll it.

Re:Headline for the article is a troll

[Anonymous Coward]

...women dont jump in my be because i have it hanging out...

You have what hanging out? And you expect women to help out? What the heck are you on about?

Re:Headline for the article is a troll

[calethix]

I didn't even know this myth existed. I thought it was far more common for people's feedback to be more along the lines of 'hey, why don't you have this feature in your software yet?' instead of 'hey, nice project you've got there but I thought it would be handy if it did this... oh and here's the code I added to accomplish that.'

I think a better term would be dream rather than myth.

Re:Headline for the article is a troll

[Junks Jerzey]

Opensource works because even though 90% of users of a project won't contribute, the 10% that do (not just code, but bug reports, comments, newbie help, documentation, etc.) make a huge difference.

The 10% figure applies only to very technical, programmer-oriented projects, like libraries. It's still pretty high, though; I'd put it at more like 1-2%. For most other projects, it's more like 0.0001% of users contribute. Most people--even programmers--just don't want or have the time to track through a complex 100,000+ line project to understand the architecture and fix bugs. Seriously.

Re:Headline for the article is a troll

[Tim Browse]

And part of me immediately wants to ask: if there were many more core developers for the Perl language, do you think Perl would necessarily be the better for it?

If I were Nicholas Clark, I'd be keeping quiet about it :)

Re:Headline for the article is a troll

[Clover_Kicker]

And look at what that 1% has created! CPAN is arguably the best thing about Perl.

Even if you hate Perl, you should be amazed that people were able to produce so many useful libs in Perl :)

Re:Headline for the article is a troll

[x00101010x]

Coming from a paid software development job, I'll have to say I really enjoyed this article (especially because I'm already doing a chunk of what it says and now I have something to link to some of my lazy teammates).

As far as the controvercial myth #1 goes, troll or not I'm glad it was brought up. I'm thinking about getting into open source development (I've got about 4 ideas I'd like to work on and I'm even considering changing jobs for a while to make time for it) and I don't have much of a "feel" for what the OSS community is really like yet. I'll find out for myself soon enough if myth #1 is troll or not, but I wouldn't have even been looking for it, <sarc>i just assumed it was one big happy family.</sarc>

Re:Headline for the article is a troll

[Physics Dude]

MYTH #1: ... the company is obliged to provide the featues, support, bugfixes and documentation.

MYTH #2: ... the [foss] user is obliged to contribute in some manner.

LOL ;)

Re:Headline for the article is a troll

[Afrosheen]

Mentioning Mandrake as a distributor of (mostly) OSS is wrong. Mandrake distributes 100% free code, including their in-house apps like drakx, urpmi, mcc, you name it. The download edition that anyone can get for free (as in beer and speech) is actually that: FREE. The boxed sets include some useful commercial and/or closed source apps (mainly to make life easier, like nvidia accelerated drivers) but overall, their distro and the work they contribute is open and free.

Redhat is another can of worms, however, as is SuSE and the other 'big' commercial distros. They have a few closed-source tools they won't distribute code for. There is more than one way to contribute to OSS so I respect their actions.

Re:Headline for the article is a troll

[spectecjr]

Yeah, there not that important thats why we did silly stuff like create autoconf to configure and install software. That is why we carry around the install.sh form X11 to install software in a predictable and sane way. That is why we have plain readable text files to configure our software. The reality holds true for closed and open source as well.

Plain readable text files don't validate parameters or combinations of parameters for you. That's part of the problem; they're just text. Put a GUI around it, and all of a sudden you can prevent users from saying that - say - they want to log all output to a file, but they specify a file which is invalid.

With a GUI in there, you can tell the user that they've made a mistake while they're editing that file. With a plain text file, they have to wait until they use the feature they're configuring, and that may be days or months from now - well after they've forgotten what they changed.

Re:Headline for the article is a troll

[hackstraw]

really? maybe building on others work from time to time, but not as much code reuse.

Really? How many apps share code with qt, gtk, gdk, openssl, zlib, and mozilla? Hint: a bunch.

Name the first few closed source examples you have of shared resources like this.

Not to meantion the numberous times I've found spurious utility files taken from one project and used in another.

Re:Headline for the article is a troll

[ziggyboy]

That's true. Most of these myths aren't just for OSS programmers. It just puts them on the spotlight because the code is available freely for crying out loud!

Re:Headline for the article is a troll

[Rallion]

It seems to me you just read those little Myth/Reality lines, not bothering to read the explanations. Particularly in the second, third, and fifth parts, though I see evidence of it throughout. I look at your post, and put it next to the article, and at times I just see no connection. Makes the whole thing rather meaningless to me, I'm afraid.

Re:Headline for the article is a troll

[tigga]

don't expect an army of l33t coders

I don't think coder could be l33t. Isn't l33t word belongs to wannabe hackers or plain gamers?

Re:Headline for the article is a troll

[tigga]

Plain readable text files don't validate parameters or combinations of parameters for you.

What the problem? Binary config files don't validate parameters either.

That's part of the problem; they're just text. Put a GUI around it, and all of a sudden you can prevent users from saying that - say - they want to log all output to a file, but they specify a file which is invalid.

Why a GUI? why not CLI, for example?

With a GUI in there, you can tell the user that they've made a mistake while they're editing that file.

That's kind of nice - then your configuration program would rival your real program in complexity. At the same time it's trivial to allow your program to log error messages in case of non-recognisable parameters or missing files/wrong paths. And sometimes your configuration program can't work properly - for example - it's downtime and files on network are nonaccessible and your config program do not allow you to enter them..

Re:Headline for the article is a troll

[spectre_240sx]

I'd also like to point at that this doesn't mean they don't appreciate your effort. There are a lot of people who are interested in the open source community that may not really be able to help development or may just not know the best way to go about it.

Re:Headline for the article is a troll

[spectecjr]

What the problem? Binary config files don't validate parameters either.

Yes, but with binary config files, you have a program which writes those binaries, and which does the validation.

The OP was claiming that plain text files are more than good enough for configuration. His mindset is "well, you can read, can't you?".

Why a GUI? why not CLI, for example?

Whichever you prefer. Radio button choices are easier to make with a GUI, and most end-users will be using a GUI such as KDE or Gnome, so I'd suggest a GUI. If you're doing all of your work from the CLI, you might well want to edit the text config by hand. *shrugs*

That's kind of nice - then your configuration program would rival your real program in complexity. At the same time it's trivial to allow your program to log error messages in case of non-recognisable parameters or missing files/wrong paths. And sometimes your configuration program can't work properly - for example - it's downtime and files on network are nonaccessible and your config program do not allow you to enter them..

Yes, but if you can't access the config file over the network, you can't edit the text-based config file either, so it's a moot point.

And as I said before, it may well be trivial to allow your program to log error messages, but that's of no use if the user only runs into a configuration error several weeks from now. Or the user isn't the person who knows how to edit the config file.

Oh, and if you're too lazy to code up a quick config editor even if it's in TCL or some other similar language, then I'm not sure I really want to use the rest of your code. Mainly because your attention to detail across the project as a whole would appear to be lacking.

Re:Headline for the article is a troll

[tigga]

Yes, but if you can't access the config file over the network, you can't edit the text-based config file either, so it's a moot point.

Config file is local, it's the log file on the network. And config program would whine about nonaccessible log file.

Oh, and if you're too lazy to code up a quick config editor even if it's in TCL or some other similar language, then I'm not sure I really want to use the rest of your code. Mainly because your attention to detail across the project as a whole would appear to be lacking.

So you do not use sendmail, BIND, dhcp, samba, apache, NIS, kerberos, ipsec, ipfilter etc? You Windows user then? ;) And you ideal is regedit? Stop - regedit does not allow to check anything you putting in there ;)

The problem with 'quick' config editor - it usually do not do anything usefull. It's not a 'quick' if you have to check spelling, dependencies, path validity, permissions etc. Maybe this thing shoul look into logs to suggest improvements..
My preference is self-configuring software, if it's possible. I hate to click on knobs to do self-evident things. And if something broken I have to fix it fast.

Perhaps we have different focus - I work with server software and it often should work in minimal environment. Consider firewall software. Folks who write it don't do GUI (usually). But there is fwbuilder (fwbuilder.org) which fullfill the need in GUI configurator for beginners or lazy. I'm fine with text firewall configs, I might fire up fwbuilder as well. And I like firewall developers to focus on firewall features - not to spend time on GUI.

Re:Headline for the article is a troll

[shaitand]

"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.

Yeah, there not that important thats why we did silly stuff like create autoconf to configure and install software. That is why we carry around the install.sh form X11 to install software in a predictable and sane way. That is why we have plain readable text files to configure our software. The reality holds true for closed and open source as well."

I'm sorry but that reality is definately TRUE. You are quite mistaken. Configure and autoconf are developer tools, not user tools. The sad truth is that 95% of open source projects are incomplete, and I don't mean in terms of version number.

The installer is not optional, it's part of the project and I don't care what project it is. RPM, APT, etc are NOT installers. Most projects don't even provide packages for these management systems, let alone provide installers. Package management is something in the underlying distribution that is AGAIN a DEVELOPER tool.

Your installer sits ON TOP of the package management system, it consists of a text AND gui "wizard" which takes care of the task installing the deps (which of course should be included in the end user release, unless blatantly obvious like when your app is a plugin for x, if there are any y's they should be included or clearly documented).

As for not having the resources to test an installer and binary package on all the possible systems out there, why not? If you've actually written source code for the rest of your project and managed to test it to the extent you claim it runs on those systems, then you obviously have people out there using them, how are the resources any less than for the rest of project???

Give me a break, even the lamest windows and mac apps have an installer. A good framework would be nice here having worked out most of the typical headaches already, but a lack of one is hardly an excuse for never starting let alone completing the most critical part of any project that is to be released to an end user. The installer of course, shouldn't have deps that aren't included either.

Re:Headline for the article is a troll

[spectecjr]

Config file is local, it's the log file on the network. And config program would whine about nonaccessible log file.

That was an *example* I gave, not a concrete catch-all-circumstances design architecture for configuration tools.

If you want better examples of configuration validation at config time, I can come up with them if you'd prefer.

So you do not use sendmail, BIND, dhcp, samba, apache, NIS, kerberos, ipsec, ipfilter etc? You Windows user then? ;) And you ideal is regedit? Stop - regedit does not allow to check anything you putting in there ;)

Sendmail, bind, samba, apache, NIS, etc etc etc don't tend to be configured or modified by end-users. They tend to be handled by administrators - who would also benefit from a robust config tool, but not as greatly.

As for regedit?

1. Yes, it does check things you're putting in there. Sure, it doesn't do much, but at least it makes sure you don't put text in a numeric field.

2. Who said anything about using a registry? Actually, come to think of it, who said anything about using binary config files? IIRC, it was you who brought up both straw-man arguments. All I'm saying is that a configuration user interface would be better to modify the configuration than editing it by hand.

My preference is self-configuring software, if it's possible. I hate to click on knobs to do self-evident things. And if something broken I have to fix it fast.

Believe me, it's much faster to configure something by clicking on buttons than by rooting through MAN pages trying to figure out exactly which combinations of parameters you can and can't use. As for self-configuration? Yet another straw-man argument. Self-configuring software doesn't need a config file by definition. Sheesh.

Perhaps we have different focus - I work with server software and it often should work in minimal environment. Consider firewall software. Folks who write it don't do GUI (usually). But there is fwbuilder (fwbuilder.org) which fullfill the need in GUI configurator for beginners or lazy. I'm fine with text firewall configs, I might fire up fwbuilder as well. And I like firewall developers to focus on firewall features - not to spend time on GUI.

True. In fact, I'd agree with you; server-side, it's a nicety - not a necessity. But there's a lot more client-side/end-consumer development going on these days than server-side development. For that, it's a necessity.

Re:Headline for the article is a troll

[nickos]

"...expecting a smaller, younger, and less-well-used project to attract more regular and frequent developers is usually unrealistic."

I would disagree. In my experience, early versions of open source projects will attract more patches as a result of their immaturity - they are less refined and any bugs that exist are more obvious and usually easier to fix. As time goes on the project becomes more defined feature-wise and only the hard to find/fix bugs are left.

Re:Headline for the article is a troll

[PainKilleR-CE]

Mentioning Mandrake as a distributor of (mostly) OSS is wrong. Mandrake distributes 100% free code, including their in-house apps like drakx, urpmi, mcc, you name it. The download edition that anyone can get for free (as in beer and speech) is actually that: FREE. The boxed sets include some useful commercial and/or closed source apps (mainly to make life easier, like nvidia accelerated drivers) but overall, their distro and the work they contribute is open and free.

How, exactly, does the rest of your paragraph support your first sentence? In fact, your last sentence contradicts your second sentence.

The Mandrake boxed sets still cost money, but I'm not condemning the practices of any of these companies, simply pointing out that they are companies that use OSS in a commercial manner, some (like Red Hat and SuSe) with more success than others (like Mandrake, which has had financial difficulty for some time). Even the FSF, which is arguably one of the most radical free software organizations in terms of their views, supports the idea of selling software and support, as long as the code is available to the people that have the software (and under the GPL primarily in the FSF's case).

Re:Headline for the article is a troll

[Anonymous Coward]

Most women get the idea when it's hanging out. Maybe you should ease up on the roofies.

Re:Headline for the article is a troll

[drsmithy]

Red Hat, Mandrake, and many others are commercial software companies that happen to distribute (mostly) open source software.

Red Hat, Suse, etc aren't selling software, they're selling services.

Re:Headline for the article is a troll

[Afrosheen]

I was trying to show there are differences inherent in delivery systems. When you say X distributes Y code, and mention OSS in the process, there must be some distinctions given. The point I was trying to make is that Mandrake distributes (via the web) 100% OSS software and distributes (via boxed sets) mostly OSS software. Wanted to make you and others aware of the distinction, which may have been nitpicking but nevertheless enlightened someone.

Re:Headline for the article is a troll

[saintlupus]

And part of me immediately wants to ask: if there were many more core developers for the Perl language, do you think Perl would necessarily be the better for it?

You're right. Confusion would reign. The language syntax would become well-nigh unreadable.

Oh, right. Heh.

--saint

Re:Headline for the article is a troll

[Xner]

Let's just say there might be significant overlap. And a measurable amount of sarcasm.

Re:Headline for the article is a troll

[sjames]

This "reality" again does not dispell the "myth". Try having new developers interested in a project and reading source code in a closed source project. Yeah, its difficult to read code, but infinitely more difficult to read it if you dont have access to it. BTW, the metaphor or whatever "osmosis" is trying to make a point is pretty silly. Osmosis is the transfer of water through a semipermeable membrane.

The point isn't that closed source would be better, it's more a matter of realistic expectations and taking steps to make your open source project the best that it can be.

The reference to osmosis is what we call a 'figure of speech'. It means that knowledge of your plans for the code and logical rational for the design will NOT pass into the downloader's brain through a process of osmosis, you'll have to document it if you expect it to be known.

When software uses tortured logic (perhaps for good reasons) and doesn't even come with a paragraph or two providing a roadmap, it's not reasonable to expect anyone to dive in and help. They'll prefer to work on the less mature but more straitforward or mapped out project.

In a similar way, most people who check out the latest from CVS and it won't even compile will likely move on rather than get to work. If the tarball won't compile out of the box, it's even worse.

Likewise, projects that REQUIRE a long list of the bleeding edge version of every library, and then won't compile anyway will certainly chase away nearly every potential contributor.

At the same time, I'm certainly not going to contribute to a closed source project (as if I even could!).

Re:Headline for the article is a troll

[Zygo]

A logical pessimist would point out that there are many people who care about spectral synthesis of stars undergoing quakes; however, you may be the only one in the world who cares about writing software for it.

Re:Headline for the article is a troll

[Eil]

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.

I don't see too much disparity here between the "myth" and "reality".

The author was emphasizing the fact that feature freezes *alone* are not enough to ensure the quality of your software. They have their time and they have their place, but they *must* be used in concert with other good development practices in order to be effective.

BTW, the metaphor or whatever "osmosis" is trying to make a point is pretty silly. Osmosis is the transfer of water through a semipermeable membrane.

Err, I've been hearing this metaphor for as long as I can remember. "Learning by osmosis" is a figure of speech used to imply a method of learning whereby the knowledge comes more or less automatically as a side-effect of simply being submerged in the material. The best example I can think of is living in a foreign country to learn their language. The author was trying to illustrate the general futility of trying to understand a program's structure just by skimming its hundreds or thousands of lines of code.

Myth: Bad or unappealing code or projects should be thrown away completely.

Reality: Solving the same simple problems again and again wastes time that could be applied to solving new, larger problems.

This is again true for open and closed source projects. Go look at one of the windows (closed source) freeware/shareware depositories and you will find at least 5-10 programs that all do the same thing more or less. If these were open source projects, I would imagine that there would be a good amount of code reuse going on here.


You imagine incorrectly.

I will say however, that UNIX (I'm generalizing that opensource is more of a UNIX like thing here) in general is a framework and our stuff plays well with one another. We have programs have STDOUT, and STDERR messages that are formatted for external processing and parsing, we have exit statuses in our programs so they can be &&ed and ||ed or test for their success or failure. We have signals, pipes, and sockets for IPC. Look at the number of opensource installs and the wide variety of things that they do and tell me that we are not solving a number of real problems well.

You both miss and prove the author's point at the same time. Unix is a framework, true enough. But the original intent of Unix (and I do mean original, as in "well before it was even called Unix") was as a development environment. Overtime it gradually became more flexible, hackers locked onto it and extended it in ways never dreamed and now, decades later we have an operating system whose design allows it to be used for almost anything from PDAs and embedded systems to the largest mainframes and clusters.

Open source software solves lots of real problems. That's the single reason that it's gaining so much ground these days. But there are a heck of a lot of projects out there that are essentially dead in the water because the developers are concentrating so much on the Next Big Thing rather than actually attempting to solve a problem. See the multitude of web content management projects as an example.

Re:Headline for the article is a troll

[mark_lybarger]

the point was that open source application developers don't really use other's _code_ in their applications. if someone needs an application, most often, they're not going to pick up somthing someone else did and expand on it. they're going to build the application from scratch, using the libraries they're familiar with.

Re:Headline for the article is a troll

[Anonymous Coward]

He's on about the prblem being ommunication. Duh.

Open Source all the way however.....

[vwjeff]

most of the work (mine included) is done on highly visible projects (Linux).

Installation and configuration

[Anonymous Coward]

This is a problem. Many OS projects out there require you to install to many things. I can't count the number of times I have stumbled over installing something like ImageMagick on a new version of Redhat.

Re:Installation and configuration

[Lussarn]

Having a nice dependancy checker is part of modern distros. If redhat don't have one you should probably choose something else. Have you tried apt for rpm?

Re:Installation and configuration

[hackstraw]

I have stumbled over installing something like ImageMagick on a new version of Redhat.

This is a redhat problem, not an opensource problem. I've had similar problems with some silly windows programs that required a certain versions of visual basic dlls or some other prerequisite dll or whatever.

Btw, doing 'apt-get install imagemagick' on Debian works quite well. Doing 'rpm -i imagemagick' on RedHat is more than likely only going to give you a list of reasons why it aint gonna do it.

Re:Installation and configuration

[mithras the prophet]

Where's Debian Troll's Best when we need him?

myth 9:

[Savatte]

writing open source software will get me laid!

Re:myth 9:

[AJWM]

Hey it worked for me.

(Semi-seriously -- I met my wife at a conference that I wouldn't have been at but for some software I wrote. Okay, never mind that at the time the software was proprietary (but we did provide source to anyone who bought a copy) and was only GPL'd years later...)

Re:myth 9:

[JustAnotherReader]

Writing Open Source Software will get me a JOB

Sorry folks, a programmer with no degree but lots of Open Source experience will still have a tougher time getting a job than a C.S. student with no experience.

It's wrong, but it's still true.

Re:myth 9:

[Bombcar]

Very true! I'm sure that Linus and Alan would just be overlooked in the software world.

Reality: Being an Open Source Software Writer can help you get a JOB writing open source software! But perhaps not writing Windows....

Re:myth 9:

[provolt]

Writing Open Source Software will get me a JOB

First we get the jobs.
Then we get the khakis.
THEN we get laid.

- Baseketball

Re:myth 9:

[chooks]

You are shirking the template:

4) PROFIT

Re:myth 9:

[aoteoroa]

The surprising fact is that many girls seem genuinely interested to hear about life in the tech world. I used to try to avoid all talk of software programming because I thought that girls would find in a turn off. But I've found that when a person is interested in you she will want to know everything about you and that includes what you do at work. The problems you face, and how you solve them.

In the last couple years I have dated a teacher, nurse, legal assistant, and a graphic designer, and the only one who didn't really enjoy talking tech was the graphic designer and I think thats because she, too, worked with computers all day.

Re:myth 9:

[satanami69]

Actually his template is from Scarface.
"In this country, first jou get the money, then jou get the power, then jou get the women."
- Tony Montana

Re:myth 9:

[Anonymous Coward]

Wot? It won't? Oh....darn.......

Tels

Re:myth 9:

[Kenja]

Its not wrong at all. Writting open source software in no way shows that you can write software to user specifications. If anything, it shows the oposite.

Re:myth 9:

[misleb]

Sorry folks, a programmer with no degree but lots of Open Source experience will still have a tougher time getting a job than a C.S. student with no experience.

But a degree and open source experience will get you a job. (over a person with just a degree)

-matthew

Re:myth 9:

[forevermore]

Sorry folks, a programmer with no degree but lots of Open Source experience will still have a tougher time getting a job than a C.S. student with no experience.

I'm not so sure about that. Every job I've interviewed for was more interested in the fact that I had experience (demonstrated by having their programmers look at my code) than the fact that I don't have a CS degree (my degrees are in other fields). I've been programming professionally since just out of high school (makes a good side-job in college), and those 13+ years of experience have made a difference in my getting (and keeping!) jobs.

Granted, I'm talking about industry-experience, not specifically open-source experience, and just because you write some open source software doesn't make you a good coder. But experience and demonstrated skill will almost always outweigh a degree with no experience to back it up.

Re:myth 9:

[Eric Savage]

It's wrong and its false. I'm pretty unlikely to hire a fresh out of school programmer, because I don't want to be the one that has to show them that at least half of the stuff they busted ass to learn in school is totally useless. I'd much rather hire a hobbyist who has opinions and experiences they can bring to the table with them.

Re:myth 9:

[randombit]

will still have a tougher time getting a job than a C.S. student with no experience.

Don't worry, having a degree doesn't help you get a job either. Apparently, having a degree and a couple of years work experience and several years working on foss projects doesn't either.

BTW, define "lots of open source exp.": hacking on GCC and Linux, or writing lots and lots of 10 line Perl scripts. Nothing wrong with either, of course, except for that a 10 line Perl script could have been written in just 3 using half as many alphanumeric characters.

Re:myth 9:

[iainf]

It's wrong,

No, it's not: CS is more, a lot more, than just programming.

Re:myth 9:

[Anonymous Coward]

' Every job I've interviewed for'

What about all the ones that silently round-filed your resume because you didn't have a degree?

Interviewers don't need to bring you in for an interview to figure that kind of thing out.

Re:myth 9:

[placeclicker]

I've never created a resume (yet.)
You can put Open Source projects you work on in your spare time on a resume?

Re:myth 9:

[Atmchicago]

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.

Re:myth 9:

[penguin7of9]

Anybody who creates a successful open source project has demonstrated that they are capable of creating something people want.

I'd be much more worried about people like you, people who seem to think that by "writing software to user specifications" they can create useful software.

Re:myth 9:

[Rallion]

It might not be useful, but it's the kind they want you writing at any place of business, isn't it? It's the kind that makes them money. You can't do that, you're just another paid non-worker.

Re:myth 9:

[Rallion]

Here's the problem, as I see it. If a person has a degree, that means they have obtained a certain set of skills that you can count on. A hobbyist, while they may be GREAT at some things, is liable to have holes -- sometimes nasty, gaping holes -- in their knowledge. If I were in charge of hiring I'd be more likely take the person with the degree, the person who is more likely to perform well in a wide variety of tasks. Not to say that I would never hire somebody based on experience, but I would need some kind of confirmation of their skills first.

Re:myth 9:

[CaptainBaz]

Depends on where you apply, and how well you market yourself. I have no qualifications past high school, but I've been a professional developer for going on four years.

And yes, I have open source experience on my CV.

Re:myth 9:

[ckaminski]

Actually, right now, not having a degree is a pretty sure bet that your resume will never make it past an HR-droid.

Re:myth 9:

[Penguinshit]

I tell my wife all about my day in the tech world, and she tells me all about her day in the marketing world. Neither of us knows fuck-all about what the other is saying, but it makes for good conversation.

Then we go shag like bunnies...

Re:myth 9:

[Anonymous Coward]

Yes.

Re:myth 9:

[Anonymous Coward]

But a degree and closed source experience will get you a job. (over a person with just a degree and open source experience)

Re:myth 9:

[shaitand]

I believe he was refering to a job programming. I don't know anyone who could be called "computer scientist" and has a CS degree rather than an engineering degree. CS theory is largely worthless. CS anything else but coding and theory. Is completely worthless (at least in terms of actually programming for food in the real world).

Re:myth 9:

[jrc313]

Most employers are not concerned about whether the software you can produce is useful. They want to know that you can follow a specification and produce software that fulfills the client's needs.

By producing software that matches the needs of the client your software is inherently useful.

Simply opening the source of your software does not make it useful.

Re:myth 9:

[Anonymous Coward]

Why?

Re:myth 9:

[ColaMan]

You can put Open Source projects you work on in your spare time on a resume?

I'd say if they were relevant to the position you were applying for, and that you have spent a fair bit of work on them, yes. Employers would like to know about any possible experience you have that is relevant.

Re:myth 9:

[penguin7of9]

By producing software that matches the needs of the client your software is inherently useful.

Yes. Where you are mistaken, however, is in thinking that following "user specifications" is going to result in software that is useful to clients.

Simply opening the source of your software does not make it useful.

Quite right. But I said that someone who creates a successful open source project has demonstrated that they can create something people want.

(Perhaps before going on about reading user specifications, perhaps you should read what you are responding to more carefully?)

Re:myth 9:

[Anonymous Coward]

I simply married an engineer.

Myth # 9

[Hayzeus]

Open source is more likely to be stable and bug-free because the code will be widely inspected by thousands of eyes

This may be true for a minority of widely used projects, but for most applications, I've never bought this argument. Bug swatting, and especially code inspection, is and always will be a tedious process, not well-suited for a volunteer-only development community. The only advantage I see for open source in this area is that bugs can be fixed as they are encountered -- but this only works where the end user has the required skills to do the fixing in the first place.

Re:Myth # 9

[elviscious]

Not really sure that this is a myth. Anybody can write crappy, buggy code. People do it everyday. Same thing with stability. Whether unix is a better platform than windows might be debateable, I don't think anybody denies that crappy code is written on both platforms.

The only thing that open source brings to the table is that people might look at it, and might point out problems. But if you are relying on both of those to happen you are making two big assumptions.

Re:Myth # 9

[iminplaya]

Here's a story that relates to that very issue
http://www.securityfocus.com/columnists/200
From the article
"...When a vulnerability is initially made public, things usually go one of two ways: if the vendor was notified first, that vendor typically tries to work with the researcher, and makes an effort to issue a coordinated release. Otherwise, if the vendor wasn't notified, the problem is disclosed to the public, and the community stands idly by, dumbfounded."

Re:Myth # 9

[xenoputtss]

"The only advantage I see for open source in this area is that bugs can be fixed as they are encountered -- but this only works where the end user has the required skills to do the fixing in the first place." this is true, but it does give more of a chance for small bugs to be fixed rather than overlooked because there isn't simply enough resources to do the job of fixing small bugs.

Re:Myth # 9

[leifm]

I'd say the area most crappy code resides is different in Windows and *NIX. Crappier behind the scenes code in Windows, crappier UI code in *NIX.

Re:Myth # 9

[LWATCDR]

I will say that one thing that I have come to really like about Open source is that it is possible to fix things as an end user.
I am using a CAD system that has a bug in it's STL export. I can duplicate the bug. I have sent it to the company I bought the software from and I still do not have a fix. It looks like a pretty simple bug but since I do not have access to the source I am out of luck.
PS I have not seen any good 3D CAD systems that are OSS.

Re:Myth # 9

[iandog]

It is a myth that since you have thousands of users you have thousands of eyes looking at the code. Most end users don't look at the code, it's true, but some do to some extent. Maybe several hundred.

Thats better than a closed source solution where that number is reduced to zero, in fact in many cases it's illegal.

Re:Myth # 9

[Anonymous Coward]

2 points:
1. I also am not sure about the "bug swatting/code inspection" end of making OSS code better. However, I am sure that knowing that the code will be widely inspected by thousands of eyes does make for better code. I see it in myself and have seen it in many I work with. You take a more rigorous approach and write cleaner code if you know someone will be looking at it (and judging it) later. And that leads to better code.

2. Now, that (#1 above) having been said, there have been many, many times that I have tracked down and fixed bugs in products that I had the code for. I would never have had the interest or the time to create such things from scratch but I find that needing a feature and not having it work are excellent motivators to find and fix problems even in a piece of software I am unfamiliar with. And where such a framework exists, I was always happy to contribute any bug fixes or enhancements back to the project.

This is a big plus to me for OSS; I do want access to the source code because I am capable of fixing some problems on my own. The argument that I see increasingly about OSS is; Well, the code might as well be hidden because nobody out there is capable of or going to take the time/trouble to fix anything anyway! And that is false!

Re:Myth # 9

[toganet]

I think you're right -- the majority of the software I use is OSS, (well, at home anyway), and I tend to look at the code only when there is a problem -- if everything works, I just keep chugging along as a happy user.

From my point of view, having access to the source lets me at least attempt to find the source of the problem, and if I can't fix it on my own, point it out to the community with the hopes that someone will fix it.

With closed-source software, that's not an option.

Re:Myth # 9

[MrKinkade]

Engy (is linked to from the www.enlightenment.org homepage) is the only one I'm aware of. I don't really know if it's usable, but it's probably worth keeping an eye open for.

Or contributing to :)

Re:Myth # 9

[Anonymous Coward]

PS I have not seen any good 3D CAD systems that are OSS.

PS There are none :-)

Re:Myth # 9

[Afrosheen]

I really doubt it's in usable condition, and the first hint is that it's linked from Enlightenment's page.

E17 will probably be released the same day that Duke Nukem Forever comes out. Sorry for trolling, but seriously, the E dudes are slower than Christmas.

Re:Myth # 9

[Tony-A]

I can duplicate the bug. I have sent it to the company I bought the software from and I still do not have a fix.

You can duplicate the bug. You do not have the source.
They have the sources. Their setup can easily be so that they cannot duplicate the bug.

There is also the strong possibility that fixing that bug just moves the bug-covering and by closing off one bug it lets a bunch of other bugs loose on the unsuspecting victims.

There is also the messy problem of tracking and propagating the fix. I'm an old fart, so bear with me on the manual drafting analogy. If a drawing is missing a line, you can't just go into the filing drawers, pull the drawing, add the line, put it back and be finished with it.

This is why methinks Open Source will ultimately win. Not (just) on the low-end, low-budget side, but more importantly on the high-end, high budget side.
If the fix fixes one bug that you care about and exposes ten bugs you do not care about, it is a good fix. For you. It is of course to your advantage that that fix, minus any assorted buglets that you do not care about, makes it into the general stream. In the meantime, you have something that is almost as good.

The net effect seems to be that Open Source gets almost another nine, almost for free. It's not a magic bullet, but it's a very cheap and effective way to aproximate reliability that would otherwise be prohibitively expensive.

Re:Myth # 9

[LWATCDR]

I looked at it but it is FAR from a true CAD system.
With a good CAD system I can take my 3d drawings. Convert them to an STL file, Email them to the production house down the road and get a part the next day.
Looks like a fun project but it yeas away from replacing AutoCad ro solidworks.

Re:Myth # 9

[Tony-A]

It is a myth that since you have thousands of users you have thousands of eyes looking at the code.

Myth: Thousands of users are looking at the code.
Not Myth: Thousands of users could be looking at the code.

Not Myth: It's that one out of thousands that because (s)he can when (s)he needs to and thereby does that matters. No silver bullet, but it improves the odds drastically.

Personally, mostly I wouldn't bother looking. But IF for some reason, what and how I'm doing something exposes an interesting bug, I will be looking to see "how come", code included.

You do forensic analysis on the airplanes that crash, to see "how come". You don't scrutinize the ones that are flying with the same severity. Aircraft safety would be much worse if aircraft designers could not obtain any information about crashed airplanes. (Part of the closed-source scenario. The developers do not have access to information about crashed applications. No I am not going to ship my servers, users, configurations and proprietary data to some vendor so that they can maybe get to something in a few months.)

Re:Myth # 9

[firewrought]

I will say that one thing that I have come to really like about Open source is that it is possible to fix things as an end user.

Ditto... One thing that I've been slow to appreciate about Open Source is that... when I start to wonder how a piece of software works, I can actually go examine the source. This becomes especially enlightening when I'm trying to solve a common design problem or I run into trouble using an API. For instance, I browsed the KDE archive to figure out how to create new kscreensavers...

Re:Myth # 9

[Etyenne]

A collateral effect of having people look at your code is that, assuming you have any pride as a programmer, you will take more care about what you write. I know I make an extra effort when I know my code will have an audience (even if it is just my colleague here).

I know elegant code can have bug too, but I think peer pressure is a good motivaton to write better code.

Re:Myth # 9

[gidds]

Absolutely. Open Source is generally better quality BEFORE anyone else ever sees it.

I'm co-author of an open source app which is at one extreme of this. It has an extremely limited audience: our potential users are in low double figures. So we weren't expecting thousands of eyes poring over our code, flurries of fixes pouring in, or lots of media attention! But the 10 or so who do use it find it extremely useful - I use it myself for an hour or two every day, so I have an extreme personal interest in it, and would be working on it even just for myself.

Why did we bother open-sourcing it? Well, at least two other users are developers (and were involved with a similar previous project), and we wanted the option of their input. (As it happens, we haven't needed any, and they haven't volunteered any, but there's always the option.) But also we'd learned from another similar previous project which never got off the ground because the sole developer wanted it to be perfect before releasing it, never finished it, and most of his work was lost. We wanted our work to last!

I always try to write neat, elegant, easy-to-maintain code anyway. But when I know the code will be released to the public, I make a special effort; it's only natural. Our project has benefited from being open sourced even though I'm not sure anyone else has ever looked at the code. And I'm pleased we did.

Re:Myth # 9

[Zygo]

No I am not going to ship my servers, users, configurations and proprietary data to some vendor so that they can maybe get to something in a few months.)

Ummm, this does actually happen in real life, although it's more common to have the vendor send one of their less assertive employees to the servers and users, than it is for the customer to send the servers and users to the vendor. I have seen both happen within my various employers, both as vendor and customer. Per-diem on-site support is usually available for around $2000 per day, give or take a factor of 10 depending on how poor the vendor feels on any given day. You might not get an actual, live developer, but you might get someone who is on an email basis with an actual, live developer.

Re:Myth # 9

[Tony-A]

Thank you! You're right of course.

I got a chuckle out of "send one of their less assertive employees".
It does happen in real life, when the problem does have to be solved. But it's not my decision to make. It's my boss's boss or higher that has to make that kind of decision. It's not cheap and it's not nearly as effective as it should be.

The real advantage of Open Source is that it's much less like doing watch repair wearing mittens.

Fear not, corporate developers

[the man with the pla]

My limited experience with open source is summed up with this article sentence:
~~~
Not all open-source projects are alike, however. A small number of open-source projects have become well known, but the vast majority never get off the ground, according to Scacchi.
~~~
Open source is obviously faster/better/cheaper when 1000's of people donate their time to a single project. The only open source project I've been involved in was a collaboration among several corporations, all of which wanted to leverage each other's resources, but none of which could really contribute their own.

There's nothing like money to motivate people to work on a project for which people aren't willing to donate their time.

Personally, I'm not convinced speed is related to developer quantity. There's too big a variation in productivity between experienced and amateur developers.

I'm also not convinced open-source is right for all types of software. How many open-source developers you know that conduct large-scale usability tests? How many open-source developers go around interviewing end users? When the developer and product consumer is the same, open-source makes much more sense to me.

Re:Fear not, corporate developers

[CAIMLAS]

How many open-source developers you know that conduct large-scale usability tests? How many open-source developers go around interviewing end users?

None. Why? One potential reason is because it's not needed. Ever consider that all the 'usability tests' that MS conducts are a bunch of shit? Look at the two 'major' - supposed - outcomes of such research: MS Bob and Windows XP's graphical interface. All that this illustrates is that MS found people are dumb, and that MS doesn't think most folks are capable of too terribly much, mentally. So make it simple to the point where it loses practicality for the marginal number of people that are skilled.

Consider that when an open source developer is using software, and he finds a problem, or he sees a feature he wants, he impliments it. It has happened on Windows, too, with projects like WindowBlinds and AfterStep. People want more features, so they write them themselves - and quite a few people will use them. Sure, most people don't (they just use the 'vanilla' configuration), but it's necessary to have that flexibility in the framework; otherwise there will be no innovation. The benefit to a system like linux is that flexibility is there due to the openness and availability of the source code: nothing needs to be reverse engineered.

When the developer and product consumer is the same, open-source makes much more sense to me.

Er, correct me if I'm wrong, but developers are not a higher form of life than everyone else. They are no smarter than anyone else. They, like everyone else, has a personal opinion and personal way of relating to their environment; considering that most developers are human, I'm guessing that such interfaces would generally be understandable enough for someone of similar origin to figure out. If not, that's of no fallacy of the interface itself, but of the user: there are more options. If you -need- MS Windows and can't 'adapt' to KDE's interface (which is undeniably more full-featured), then stay with MS Windows -it's what you were initially introduced to, and it's what you're more familiar with. Simple enough, quit bitching. That doesn't mean that other designs are worse. Look at the forever-going battle over the GUIs of Windows vs. MacOS - they both think their own is superior.

Not everyone is a Type A, Type C, or Type Z. Some of us are Type 1, Type 0, and Type 01010110.

Re:Fear not, corporate developers

[RealProgrammer]

The parent is redundant. I've seen it posted verbatim before.

Re:Fear not, corporate developers

[jrm228]

Nice - steal my post.

Re:Fear not, corporate developers

[Anonymous Coward]

What's that? 'V'?

Re:Fear not, corporate developers

[jrm228]

Originally posted here

Re:Fear not, corporate developers

[NineNine]

None. Why? One potential reason is because it's not needed. Ever consider that all the 'usability tests' that MS conducts are a bunch of shit? Look at the two 'major' - supposed - outcomes of such research: MS Bob and Windows XP's graphical interface. All that this illustrates is that MS found people are dumb, and that MS doesn't think most folks are capable of too terribly much, mentally. So make it simple to the point where it loses practicality for the marginal number of people that are skilled.

Oh please. Usability is THE REASON (well, ok, marketing too, to a lesser degree) that Windows runs 90%+ of the world's PC's. Usability is THE REASON why Linux isn't widely adopted as a desktop platform. So you just keep telling yourself that, and you'll keep Linux and other OSS projects to a tiny, tiny userbase.

People want more features, so they write them themselves - and quite a few people will use them. Sure, most people don't (they just use the 'vanilla' configuration), but it's necessary to have that flexibility in the framework; otherwise there will be no innovation. The benefit to a system like linux is that flexibility is there due to the openness and availability of the source code: nothing needs to be reverse engineered.


That's great and all, but flexibility is greatly overrated. I want my computers to run my businesses for me. That's it. "Flexibility" as a "feature" is something that's thrown around when a product is simply too difficult to use. Fuck flexibility. I want something that works. Hell, I want something with LESS flexibility. I don't need software that's going to do everything under the sun. Software should do it's job, and get the hell out of the way. If people wanted "flexibility" above all else, you'd find stereos that are sold without cases, and wires that you have to connect yourself every time you wanted to use it.

Re:Fear not, corporate developers

[hackstraw]

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.

Re:Fear not, corporate developers

[moonbender]

Sue him for copyright infringement! ;)

Re:Fear not, corporate developers

[Ogerman]

Open source is obviously faster/better/cheaper when 1000's of people donate their time to a single project. The only open source project I've been involved in was a collaboration among several corporations, all of which wanted to leverage each other's resources, but none of which could really contribute their own. ... There's nothing like money to motivate people to work on a project for which people aren't willing to donate their time.

This is definitely true. If you look around, you'll notice that most of the best Open Source projects are those where people are getting paid to contribute in some way. That's not to say that those same people would not have contributed otherwise, but money allows you to do things like drop your day-job and go full-time doing what you really love. The Open Source community needs to take a good hard look at how more experienced developers can be brought 'on-board' full time. OSS is beyond a hobby at this point. It's quite time to put that into clear perspective.

Open Source, at it's core, is about collaboration to meet needs efficiently. Part of that collaboration needs to involve paying developers so they can work full-time. Corporations who pool resources and collaborate on OSS projects to meet mutual needs are a perfect example. The same idea can work for individual users and smaller projects, however.

Take, as example, a typical desktop application like personal finance managers. We have GNUcash, which is a pretty good start, but it's missing a lot of the useful features found in the far more popular Quicken and Money. I personally have little interest in helping to developing GNUcash, though I wish it was a better fit for my needs. I'm not familiar with its codebase and I already spend most of my free time working on my own OSS project. (which I eventually plan to provide professional consulting services around..) However, I am willing to pay somebody $40 to develop a couple features I need in GNUcash. $40 is about how much I'd have to spend on Quicken or Money, which already meet my needs. But alas, $40 is not fair enough compensation for the developer. That's where collaboration comes in. There are millions of people who use personal finance software. If even 100 people contributed $40, that's $4000 compensation to add maybe one or two features -- easily doable in a month's time by an experienced developer. Realistically, there are far more than 100 GNUcash users able to contribute and far more than 1 or 2 features that need added. Once users start contributing financially to Open Source projects, allowing their developers to work full-time, we will see the true OSS revolution take place. The key is how to organize this process.

Re:Fear not, corporate developers

[markhb]

>How many open-source developers go around interviewing end users?

I do. So thats one. How many closed source developers do this?

Any decent closed-source software development house writing programs for general consumption (as opposed to strictly in-house line-of-business programming) should have teams of people doing this during the requirements gathering phase. Perhaps not the actual developers, but it's likely that the actual developers may not even have been identified at that point.

>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.

Working pretty well, if your desired audience is "developers and geeks." Perhaps not so well if your desired audience is people who do not fit that description.

Re:Fear not, corporate developers

[stuffduff]

It's not the quantity of developers as much as it is the quality of their communications coupled with the clear understanding of the task at hand. When developers share the vision of both the task at hand and similar programming standards things can evolve quite raipdly. But one or more weak links in either the skills or communication, or some genuine personal disagreements can sink projects like a stone. Development has to be a cooperative venture governed by logic, not a pissing contest!

Re:Fear not, corporate developers

[DunbarTheInept]

Usability is THE REASON (well, ok, marketing too, to a lesser degree) that Windows runs 90%+ of the world's PC's.


Bullshit. If usability was the key issue, MacOS would beat Windows, and the entire IBM-compatable PC line would have died out in the '80s when it was still young because the competitors like Amiga, Atari ST, and the like were a LOT easier, and prettier, and more powerful. Open Hardware is the reason Windows won. The IBM PC was (despite the best efforts of IBM) an open spec that everyone knew how to exploit, and all the advantages that gives to the consumer came out of that. Microsoft was just lucky enough to be the one providing the OS for it.

Re:Fear not, corporate developers

[Planesdragon]

Look at the two 'major' - supposed - outcomes of such research: MS Bob and Windows XP's graphical interface.

You obviously don't use Windows.

MS Bob was neutered into Clippy due to user research, and then Clippy was removed due to the same.

Windows XP's UI is vastly improved over 2000's, 98's, or 95's. A lot of customization and small things are now built-in and easy to find that were only avaliable through very-hard-to-find options or third-party hacks. Sure, the primary-color interface is garish, but it can also be turned off with all of four mouse clicks.

Oh, and as for KDE: I don't use it because in order to use it, I'd have to dump nearly every piece of software that I do use. Show me a KDE.EXE that can replace EXPLORER.EXE, and I'll use it.

Re:Fear not, corporate developers

[IM6100]

I've run Windows and I've run MacOS 9. Maybe I spent too much time running W2K before checking out MacOS, but there were just too damn many times when I felt all stiff and restricted when I wanted to do something with MacOS. I am sure there are some shortcuts that I haven't yet become aware of, but the interface has ended up feeling wooden and stiff.

Perhaps my many years using Windows have taught me too many of the keyboard shortcuts (i.e. F2 to rename a file works almost anywhere, you can delete files with a right click from within a File/Open dialogue box, etc. etc.)

I would definitely say MacOS is no better from a usability standpoint than Windows, and my personal experience is that it's less usable (for me).

I haven't come away with the experience seeing Mac advocates any less of an anything-but-Microsoft brigade, sadly.

Re:Fear not, corporate developers

[Anonymous Coward]

Dont metion ".EXE" around here if you don't want to get laughed at :) just a fiendly tip.

I agree on the XP ui tho. The colours are terrible, but once they are gone, it really is very good.

Re:Fear not, corporate developers

[Anonymous Coward]

Ever consider that all the 'usability tests' that MS conducts are a bunch of shit? Look at the two 'major' - supposed - outcomes of such research: MS Bob [...]

IIRC, Bob was not the outcome of any usability test. It was the result of someone at MS (rumored to be the same person who had the guns removed from certain version so MS Flight Simulator) with a stupid idea. BillG apparently wasn't too hot on the idea, but let this person go for it anyway. The result is legendarily bad, of course, but to the best of my knowledge, nobody even tried to justify that crap with a usability test.

Re:Fear not, corporate developers

[DunbarTheInept]

I would definitely say MacOS is no better from a usability standpoint than Windows, and my personal experience is that it's less usable (for me).

But would that have been the case back when Windows was just a large bulky application that ran on DOS? Remember it's back *THEN* that Microsoft beat out Apple. Today they're just riding the momentum from that, because the software industry has a huge inertia due to 'network effect'. Back when both platforms were on equal footing and had a chance to compete fairly, Windows beat Mac *even though* it didn't have a good interface back then. Hence my call of "bullshit" to the claim that the UI is the reason Microsoft is winning. It has to be something else because they were the *worst* UI of the field back when there were viable competitors in the '80s. Mac, Amiga, Atari ST - all of these were contemporaries with Windows 3.0, and somehow ended up losing to it. Therefore the user interface CANNOT be the reason for their success.

Re:Fear not, corporate developers

[PurpleWizard]

Because the end user is the developer in most Open Source cases.

Re:Fear not, corporate developers

[Odinson]

"I'm also not convinced open-source is right for all types of software."

Quality, funtional OSS projects are usually acceptable for many computational, orginizational and entertainment needs. There are many variables before you can say that.

But there really is one kind of software you should go that extra mile write/download/install OSS.

Infrastructure.

X needs to work with Y, but Xcorp said they can't write Y compatiblity in without 10,000 signatures and a million dollars.

Be sure you have the source to Y and are allowed to maintain your changes. And look we can dump the data from X into a database now. woooohoooo!

See you later Xcorp, here's a negitive million dollars.

Re:Fear not, corporate developers

[Steveftoth]

I'd also add that Open Hardware allowed for cheap computers which is a corollary to Open Hardware. It just makes sence to build a product that will sell more units.

Back in the late 80's the Mac was far superior to any PC in just about everything but price and userbase. You could do more and do it easier.

Re:Fear not, corporate developers

[knobmaker]

Oh please. Usability is THE REASON (well, ok, marketing too, to a lesser degree) that Windows runs 90%+ of the world's PC's.

Oh please, can anyone really be this stupid? Windows runs on so many PCs because it was pretty much the only OS available for the x86 architecture for many years. If you wanted to compute with relatively cheap hardware that you could upgrade yourself, you had to use Dos or Windows. Except for Apple and OS2 there were no challengers to MS supremacy until Linux came along and caught the attention of geeks wanting the same sort of reliability and capability on their x86 boxes that they'd had on big iron back in the day.

Re:Fear not, corporate developers

[shaitand]

Absolutely, people confuse this all the time. Windows hasn't and never did beat MacOS, the IBM PC Clone beat the macintosh... windows just happened to be what ran on it.

Re:Fear not, corporate developers

[shaitand]

"Any decent closed-source software development house writing programs for general consumption (as opposed to strictly in-house line-of-business programming) should have teams of people doing this during the requirements gathering phase. Perhaps not the actual developers, but it's likely that the actual developers may not even have been identified at that point."

In the open source world the developers ARE users. They get into the project BECAUSE THEY USE THE APP or NEED THE APP SO THEY MIGHT USE IT. I don't know many people working on open source projects who don't actually use the app they code! In the closed source world I know plenty who haven't and would never consider actually using the app.

Re:Fear not, corporate developers

[shaitand]

Yes but yours isn't really the big hole in financial software. The big hole is a quickbooks replacement NOT a Quicken or money replacement.

Honestly, linux is already ready for the corporate desktop and most medium sized business desktops. The next hole to fill is the small business desktop which comes another step closer to the home user, it has alot of the same demands as the home user but is different in that this market has lots of money to spend in pools that are large enough to pay developers to accomplish small tasks for them.

This group has little enough need of consumer type devices that linux can start to move in as is if there were an accounting app, but has enough need and is large enough to get consumer device drivers and support. The people who own these businesses or are high ranked in them are the same people who can afford gobs of usb this or that gadgets at home and who pay rather than pirate. They are the upper middle and middle class, you win them and you will inevitably win the lower class (the average person, yes even in the US and Europe the average person is poor).

Re:Fear not, corporate developers

[IM6100]

It was really 'up for grabs' wether Windows or MacOS would 'win out' in the UI battles. Windows 95 was the first case where Windows actually had a chance to compete with a consistent usable 'desktop,' though The Hewlett-Packard NewWave 'desktop' installed on top of Windows 3 was good enough that they were co-plaintiffs with Microsoft in Apples futile 'look-n-feel' suit.

Apple lost the 'OS War' when they decided to kill the Mac clone market. They conceivably could have 'won' and we'd all be running nice PPC clone boxes. To 'win' they would have had to give up a dual monopoly on both the hardware and software in their market segment. They make nice stuff. It'd be cool if 'the rest of us' could afford it.

Re:Fear not, corporate developers

[drsmithy]

Back when both platforms were on equal footing and had a chance to compete fairly, Windows beat Mac *even though* it didn't have a good interface back then.

But you also have to remember back then Macs were much, more more expensive (relatively) than they are now. Usability is a very important issue, but eventually cost will win (an analogy of a similar situation: processor architecture vs clock speed).

People think Macs are expensive now, but they've never been cheaper.

Re:Fear not, corporate developers

[CAIMLAS]

Usability is THE REASON (well, ok, marketing too, to a lesser degree) that Windows runs 90%+ of the world's PC's.

Bollix. You've got to be insane, foolish, or simply quite misinformed to believe that.

Look at the competitors for MS Windows when it first came out. There was OS/2, as well as several other contenders I can't immidiately recall. OS/2 (and its Warp kin) are vastly more "useable" than windows. It crashed less, it had more features, and what's more, it was much more technologically advanced that the earlier MS Windows.

useable
adj 1: fit or ready for use or service;
2: able to be put to use; "usable byproducts" syn: usable
3: convenient for use or disposal;

Look at each of those 3 definitions. None of them are met by what MS Windows is, or has been. Every single release has been buggy, unstable, and/or security ridden the point where it causes serious setbacks for its users. Maybe you forget how much Win9x crashed.

The only way that MS Windows could be considered 'useable' is in the 3rd definition, since it's goddamn everywhere - it doesn't take much effort to find a Windows machine. However, if you consider the hastle often involved in -making- it ready from scratch (compared to say, linux), your 'useability' goes down drastically.

But really, what is 'useability' and what is 'flexibility'? Isn't the main thing you want out of your computer the ability to do what you want with it?

Let's compare another definition for a word you throw about as if you know the meaning.

Flexible Flex"i*ble, a. L. flexibilis: cf. F. flexible.
1. Capable of being flexed or bent; admitting of being turned, bowed, or twisted, without breaking; pliable; yielding to pressure; not stiff or brittle.
(The other definitions are nearly identical in meaning.)

Now, would you consider flexibility a desireable goal in an OS? Would you like it to not break when you try and do things? I think so. Thus, flexibility in design and use is what you want. Flexibility has nothing to do with doing 'everything under the sun' (which is more a goal of MS and Windows, than linux, if you'd use your head). It's about doing things properly.

The only reason you diss linux is due to your insecurities. I've given KDE setups to people completely unfamiliar with computers, and they've had absolutely no problems. If you're so inept to even give linux a shot (IE, get familiar with it), you've got nowhere to stand from. People don't just 'know' things inately, like how to use a Windows computer. YOu didn't just 'know' how to ride a bike, or 'know' how to walk, as simple and as 'innate' as those things are. You had to learn them like everyone else.

Re:Fear not, corporate developers

[CAIMLAS]

You obviously don't use Windows.

MS Bob was neutered into Clippy due to user research, and then Clippy was removed due to the same.

Er, has the fact that those things existed in the first place due to "user interface research" crossed your mind? It took them, what, 2, 3, 4 product versions to get rid of the errors of their 'research'?

Sure, XP is now themeable, and you can modify little GUI artifacts more easily. But the default is fucked up, and quite a divergence from anything previous; there should have least been an option. As it stands, you've got to dig through things to fix what they 'enhanced'. Win2k was close to on track in those regards - KISS.

Oh, and as for KDE: I don't use it because in order to use it, I'd have to dump nearly every piece of software that I do use. Show me a KDE.EXE that can replace EXPLORER.EXE, and I'll use it.

Your ignorance proceeds you. I doubt you've even used linux - there are no such thing as .exe's in linux-land. (I'm assuming you weren't speaking figuratively, being as you haven't previously.)

Let's reverse the scenario: name one thing that MS Explorer can do that KDE's Konqueror (the file manager/web browser) can't do.

Konqueror can browse local filesystems. It can browse remote filesystems via SSH as if they -were- local. It can browse FTP archives without a hastle (unlike the hideous load-time for IE.) It can do file previews in any number of fashions, on local or remote file systems. It can have a split-view browsing and/or file management view. It has built-in translation access, HTML validation, and various other features via websites such as babelfish. It has various profile settings -just- for Konq, per user - so that you can have seperate layouts per task. You can customize default keystrokes to be whatever you want. You can change your browser identification. It can run SWF, java, javascript and the like. It can convert its bookmarks to Netscape and/or Mozilla bookmarks. It can import bookmarks from half a dozen Mozilla-based browser, Opera, and IE. It has a sane and flexible MIME file association 'editor', with reasonable defaults. You can set whether or not fonts will 'wrap' or be trunkated by the file manager's view. The list is exhaustive. Konq can even block pop-up adds! (Not as if that's anything to boast about. It's simply a minimal requirement for a modern browser.) There are dozens of more features than I'm listing. Nearly every one of these isn't in IE.

As far as 'dumping nearly every piece of software that you use'... well, yeah. You likely do that already - going from PS 5 to PS 5.5, etc. Most of the major applications will work in WINE quite well, anyway. You really have very little to bitch about. Media players in linux are quite superior to those of Windows. Granted, there are soft spots, such as audio editing, but unless you have a bone to pick or some uncommon requirements, that's not a matter of concern.

Re:Fear not, corporate developers

[CAIMLAS]

Er, I don't know about you, but I distinctly recall Macs being the desireable computer item when I was younger. Nobody wanted a PC: they were ugly, didn't do anything cool, and were just for writing text documents. There was marginal appeal of using a PC for games - but that was in DOS, not Windows. Windows 3.x had nothing at all on MacOS.

Re:Fear not, corporate developers

[Planesdragon]

Sure, XP is now themeable, and you can modify little GUI artifacts more easily.

It's more than that.

You can re-arrange your start menu, choose which folders are one-level menus and which ones are trees, and decide what options appear and don't appear--all under "properties."

The @#$ing system tray, overloaded with little and often worthless mini-icons, now auto-hides--and each icon can be set a different value, and if you really want to the entire thing can be turned off.

Oh, and there's a few other things--like "System Restore" or "Desktop Cleanup Wizard"--which really do look like they're built in response to what Windows users do.

But the default is fucked up, and quite a divergence from anything previous; there should have least been an option.

There is. Windows XP comes with exactly two themes--"Windows XP" and "Windows Classic."

And, considering that everything is in the same place, does essentially the same thing, and has the same words on it, it's hardly "fucked up" for new users. (I know some techno-novices who went from 2k to XP without a hitch--and they didn't even change the theme back.)

As it stands, you've got to dig through things to fix what they 'enhanced'.

Right-click on the start menu, and the first screen that opens up asks you if you want "Start Menu" or "Classic Start Menu." And the same window (in a different tab) lets you change the tasbar's program groupings and the system tray's auto-hide on or off.

That's almost every UI they changed in the core OS, all in one place. And the only other major UI element is a new default option in explorer's "view" menu.

Your ignorance proceeds you. I doubt you've even used linux - there are no such thing as .exe's in linux-land. (I'm assuming you weren't speaking figuratively, being as you haven't previously.)

I have. I wonder if you've ever tried to do something creative with Windows.

_All_ versions of windows, even Windows XP, call "Explorer.exe" as its "shell". This prorgram handles what you see on the desktop, what you see for the taskbar, and how you browse files. Editing one text file is enough to change what shell you use.

For a good side-by-side comparison, I'd want to see KDE (not just konqorer) run on windows at least semi-natively--native enough that it doesn't lose anything when compared with Explorer.exe.

Now, I could reinstall Linux, and spend a few hours getting Linux to do what I want it to do, but that's a different discussion. (I'll list my few reasons why not below.)

Nearly every one of these isn't in IE.

Who the hell said I used that piece of crap? The only reason I didn't delete it from my PC is that some programs call it for internal HTML rendering, and Gecko doesn't have a drop-in replacement yet.

I use Firebird to browse the web.

As far as 'dumping nearly every piece of software that you use'... well, yeah. You likely do that already - going from PS 5 to PS 5.5, etc. Most of the major applications will work in WINE quite well, anyway. You really have very little to bitch about. Media players in linux are quite superior to those of Windows. Granted, there are soft spots, such as audio editing, but unless you have a bone to pick or some uncommon requirements, that's not a matter of concern.

1: "Quite well" isn't good enough. "Exactly as well as it runs on Windows" would be the place to start--and no fair arguing that Linux's supposed better reliability equals out the problems.

2: I rarely change appliations--and when I do, it's often just to a new version and not something entirely new. I could start using OpenOffice now--but there are a few small nagging things (like synicing with Documents to Go, or a proper word count) that keep me in MS Word.

3: Why do I care about media players? I've got Winamp and iTunes, which is more than I need for playing MP3s and seeing the odd movie

Re:Fear not, corporate developers

[IM6100]

Clearly we hung out in different circles. Nobody who I knew except for a few people who copped an elite attitude had Macs. Many had Commodore 64's or PCs. Some had Amigas.

Windows 3.x was apparently good enough that Apple sued Microsoft over it. That's, umm, kind of a direct endorsement from Apple.

Re:Fear not, corporate developers

[DunbarTheInept]

You aren't looking far enough back. Windows 95 came out *AFTER* Windows had already won out.

Myth 9?

[Anonymous Coward]

Myth: The GPL is the only open source license
Truth: Although it's the most popular, it's not the only license.

Sadly, I think this is what most people think of when they think of open source.

Fortress of Insanity

Re:Myth 9?

[Anonymous Coward]

Well, it wouldn't be the first time those damn dirty, socialist hippies have ruined it for the rest of us!

Hmm...

[Anonymous Coward]

Could this be... Because not many people use open source software??

If (and it's a pretty big if) open source got more widespread notice and acknowledgment, don't you think there would be more people interested in the code developed via that process? Also, if the program "mimics" other programs, or is just plain shoddy, people obviously aren't going to be attracted to it.

That said, he does make some obvious points about good software development. Well documented and well designed software will always attract more developers then that software which is undocumented, poorly implemented and/or poorly designed.

MITH#1 open source is comminust

[argoff]

I cant tel you how many times I've herd this. That's crap. It's more like copyrights are an overbearing government regulation that locks out the little guy than a true free market property right. When you them for what it is, then the facts of why Linux is going to take over the marketplace becomes obvious.

Re:MITH#1 open source is comminust

[Anonymous Coward]

http://developers.slashdot.org/comments.pl?sid=890 27&cid=7703623

Re:MITH#1 open source is comminust

[jwsd]

MITH#1 open source is comminust
I cant tel you how many times I've herd this. That's crap. Open Source is to share source code among all users and developers.
Communism is to share all resources among all community members.
I'm not sure about you but I can definitely see similarity here.

wrong in at least one place

[krog]

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.

In my experience, this is not the case. I wrote a little rip-encode-and-tag script called choad and listed it on Freshmeat for the hell of it. This was two years ago, and I've received over 20 patches -- for a crappy little perl script!

I wrote it to solve my problem, and I continue to be pleasantly surprised when I get emails with feature enhancements, bug fixes, or just plain thanks and encouragement from people who had the same problem as me.

Re:wrong in at least one place

[Anonymous Coward]

I think one needs to differentiate between small and big projects. It's certainly easier to write a patch for a relatively short script, simply because it's easier to understand what it does. Try to write a useful patch for a big project like Mozilla and you'll spend quite some time trying to even understand which file you need to patch. It's obvious that smaller projects attract more patches while bigger projects attract more bug-reports.

Re:wrong in at least one place

[CoolVibe]

Exactly.

I also wrote a bunch of hacks that I just gave away, but I never expected patches, or for people to actually use it.

Open Source is like socialism, you just help out where you can, and share what you got. If people don't take it, then it's their loss :) At least it was useful for myself, and it might be useful for others.

To assume that one writes a few hundred lines of code, and then get instant fame is of course ridiculous :)

Re:wrong in at least one place

[Jellybob]

Just a me too... I'm the author of a PEAR package (Auth_PrefManager), and while I have very little idea who the 8,522 installs were done by, I do know several of them have reported bugs which then got fixed.

The important thing is to make sure you fix the bugs as they get reported, or people give up reporting.

BTW - if you're one of those people who installed... what are you using it for?

Re:wrong in at least one place

[plcurechax]

This was two years ago, and I've received over 20 patches

Um, 20 patches is not a flurry, regardless if it was just a like script you listed on freshmeat. The probem is your own experience doesn't scale. The best real life example of that it XFree86, which has hundred thousands of users yet has a regular developer base of less than 20 and less than 100 patch contributors.

That said, congrats on successfully sharing a open source project. Regardless of its size, it appears that it was useful (and hopefully helpful) to others.

Re:wrong in at least one place

[Anonymous Coward]

But that's an issue with XFree86. Those dudes are HOSTILE, it is managed in a "cathedral" style more closed than some closed-source stuff I've seen - the recent forks (xouvert and the freedesktop thingie) really were the only option in the end.

If you look at other XFree86-sized projects like Linux and Apache, you DO get huge numbers of patches and "alternative trees".

Re:wrong in at least one place

[timjdot]

Me too. I did a Cobol copybook - to - XML Java class and actually got good example copybook sent to me within a few days. How one could have done this without open source (sourceforge in my case) would be a mess.

The article could say: "everybody and their brother wants to do a project but sometimes nobody can understand what they are doing." And "They usually don't try to find pre-existing projects into which they can fit".

My exp is the issues are 1) PITA to setup an open source project (the first time) 2) Bad organization means lots of projects. If we could organize/work together better then we'd be much more productive; but maybe less productive; and probably still better efficiency than non-cooperative "old source development".
TimJowers
Ps. Another plug for Eric's Should Exist concept brainstorming site.

Re:wrong in at least one place

[ratamacue]

Open Source is like socialism

Don't even go there. Open source is voluntary. People contribute to open source because they want to contribute, not because they are forced to contribute. If you don't want to contribute, you can simply walk away from it.

Socialism is not voluntary. People contribute to socialism because they are forced to contribute. (If it was voluntary, it would be free enterprise.) You can't just walk away from socialism. What happens if you refuse to pay your taxes?

Re:wrong in at least one place

[martone66]

Wait... isn't that what happened to Shawn Fanning?

Re:wrong in at least one place

[Anonymous Coward]

Socialism is voluntary, at least in the European usage. If you refuse to pay your taxes, you are simply denied the things your taxes pay for, like water.

Re:wrong in at least one place

[Anonymous Coward]

You need to study more about socialism.

Re:wrong in at least one place

[schon]

The last "myth" ("I'll do it right *this* time") is entirely stupid...

The "reality" he says is "If you weren't disciplined then, why would you be disciplined now?"

Umm, how about because I learn from my mistakes?

Jeebus, but isn't that one of the things humans do? Learn?

It's got nothing to do with being "undisciplined" (well, usually nothing) it's about learning. The more you do, the more you learn, and the better you become.

Re:wrong in at least one place

[MourningBlade]

Open Source is like socialism, you just help out where you can, and share what you got. If people don't take it, then it's their loss :) At least it was useful for myself, and it might be useful for others.

I've been struggling with how to characterize Open Source development for a while now, so maybe you can help me out.

I don't think it's like socialism, as you do not do work "for the good of the community," you do it for yourself, and then contribute it to the community. It's not just a minor word issue: consider how code development under OSS is often characterized as "scratching an itch."

Also, there's no government in charge of allocating or re-allocating resources.

And it's not really a cooperative, either: if one group really slacks off we don't suffer. Things might not go forward as fast, but we don't depend on others for immediate survival.

It's really more of a network of loose relationships and an attitude. Maybe "philanthropic anarchy"?

Re:wrong in at least one place

[Anonymous Coward]

I agree. I've released three small GPL apps and have received big improvements to two of them in the last couple of years!

Here is one email I received:- ........
I made some small modifications to your nice film.cls Latex-screenplay-style. I'm sending the file to you with changes listed
in the header. I hope you like it, and maybe incorporate in your own version. I will also spread it on my website when i update the site. ..........

So I disagree that anyone who writes a OSS app will never hear from any users. There are *millions* of users on the Internet, and if you need to create an app for yourself, someone else will also want it, somewhere.

Re:wrong in at least one place

[doom]

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.

In my experience, this is not the case. I wrote a little rip-encode-and-tag script called choad and listed it on Freshmeat for the hell of it. This was two years ago, and I've received over 20 patches -- for a crappy little perl script!

Just at a guess, you had a significant advantage here because you were writing in perl. The perl community genuinely works together quite well (CPAN is one of the world's great programming resources)... though you would never know this from listening to advocates of languages whose specialty is supposed to be encouraging code re-use.

Re:wrong in at least one place

[Anonymous Coward]

Look at his homepage - "free-market.net". There's no point arguing with a closed mind.

Re:wrong in at least one place

[CoolVibe]

I never said OSS development was socialism, I said it was like it. Well, the european interpretation of that at least.

But I do like your approach. It comes a lot closer.

Re:wrong in at least one place

[MourningBlade]

Any info or pointers you could give me on the difference between (modern, I'm assuming) European socialism, and classical or American socialism? I'm interested to know what you mean exactly.

And I'm still working on at least classifying the types and specifics of what the ideology/attitude is. Any ideas?

Re:wrong in at least one place

[CoolVibe]

Well, the best thing I could do is delve into dutch politics, since I am dutch. There's a political party called "SP" which is a socialist party.

Sure it's modeled after Maoism, which is a good philosophy. Too bad that china didn't really do it in practice.

So you could say the meaning of socialism I'm after is more Maoist. Dunno what american socialism entails, but maoist socialism has plenty of room for free enterprise, but it encourages people to share.

Are these really myths?

[Skyshadow]

Is the use of the word "myth" really intended to indicate that a large cross-section of people actually believe these things?

I mean, does anyone really think that how they package their product won't effect how many people start using it? Are there really a lot of people out there who assume that they'll have an instant dedicated following of skilled developers spring from nowhere the moment they publish their source?

I really doubt it, somehow. Charitably, I'd file the advice in this article under the "Obvious but sometimes in need of restating" catagory in that sometimes people will lose the forest for the trees. Still, no real revelations here.

Re:Are these really myths?

[aridhol]

Yes.

How many times have you seen a project that says "Here's our ultra-cool project. Just grab the files from CVS and build". No mention of the dependencies (the mailing list will tell you that you need libfoo-1.2; we depend on a specific bug in 1.2, so 1.2.1, which fixes the bug, will break our app).

Or "Here's our ultra-cool project. It's only a small app right now, but when we get people working on it, it'll do your dishes, write your thesis, and mow the lawn, with 3-D graphics and 6.1 surround sound."

Re:Are these really myths?

[chromatic]

Is the use of the word "myth" really intended to indicate that a large cross-section of people actually believe these things?

No, it's not. I tried to make that clear in the introduction. I don't believe that most open source projects deliberately believe that, for example, bundling up their code to make it easy to distribute and install is a bad thing. Too many projects fail to do just that, though.

The word "myth" was just more expressive than the phrase "things you'd think we believe based on our actions".

Re:Are these really myths?

[zx75]

Definition of Myth #3
A fiction or half-truth, especially one that forms part of an ideology.

A myth when used in this context doesn't necessarily mean it has to be widely believed. For example, it is a myth that Elvis is still alive. Some people believe it, most do not, but it still would be labelled as such.

Re:Are these really myths?

[Anonymous Coward]

For example, it is a myth that Elvis is still alive.

Sez YOU!

Amen!

[Horny Smurf]

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'm glad someone has the balls to say it. Of course, this isn't specific to Open Source, it's a myth that applies to ALL development.

Re:Amen!

[Tensor]

Lets face it, writing documentations SUCK, and it will suck forever.

When was the last time you saw an MS Office User's Manual ? it doesnt even come in digital form, and its a 600 usd software, and dont get me started on usd 3000 soft like Acad, or 3ds.

I think the buggy is out of place in this myth tho.

Re:Amen!

[rscrawford]

And not just software development, either.

"Tomorrow, I'll start my diet. No, really, I mean it this time."

Re:Amen!

[j3110]

I think that most people that agree that complete rewrites are not a good idea overlook a significant subset of problems that can be solved. The biggest issue is a fundamental design shift that would be better implemented in another language. You can't just keep tacking features onto a Perl/Shell script. In fact, it's never a good idea to just "tack" on a feature. You should look at overall performance and maintainance cost increases over optimal for your solution. Sometimes you need to replace an entire section of your software just because a library gets old and no one maintains it anymore.

Very occasionally, you'll get a set of additional feature requirements that make just about all your code obsolete. When design considerations don't take into account the proper scope of the problem, you don't have a choice. You can't turn a quick and dirty CGI shopping cart into one fit for Amazon or Ebay. Also, it's quite possible that you learned enough from the first pass, that now you can develop a much better design that actually is scalable (feature and performance wise). I don't like the average OSS phylosophy of "Evolutionary Programming". The amount of effort it takes to maintain a system is inversly proportional to the design that went into the system. If you just hack something together instead of thinking out the problem and designing an architecture and framework for your application, then there will be no end to the amount of work you'll spend maintaining it. A well designed system is much simpler than an evolved one, which makes it easier for other developers to contribute to, easier to fix problems, easier to incorperate new features that integrate.

Given this, a lot of people will hand a bucket of perl scripts and say "fix it" when it's just not feasible. Rewritting is necissary in a lot of cases. The only times you don't want to rewrite is when you can make a transition, and you have to keep up the old product until you get the new one out. Else, why sink time into something that will end up costing more time in the long run?

Re:Amen!

[dominator]

Maybe your next attempt won't be perfect, but I think that there's some credence to the adage that "one learns from one's mistakes." If we do not learn from the past, we're doomed to repeat it.

For example, I was careless when I was 16. Now, I'm 24, and I don't make 16-year-old types of mistake any more. There's some amount of wisdom that comes with experience and the right attitude. This carries over to code discipline as much as it does with (for example) driving.

Dom

Re:Amen!

[chromatic]

Do you believe it's possible to evolve a small program into a large program with a good design?

I very much believe that it's possible. It takes time and discipline, but I think it's usually much easier than getting the design right beforehand.

Re:Amen!

[chromatic]

As I said in the conclusion of that section:

This isn't a myth because it's impossible to improve your coding habits. This is a myth because too few developers actually have concrete, sensible plans to improve.

For fun, choose ten random projects on Freshmeat. Browse their complete changelogs, looking for the phase "completely rewrote". The results might scare you. (Or, you could just look at the change history for the Enlightenment window manager.)

Re:Amen!

[dominator]

That fact alone shouldn't scare anyone.

In order to be scared, one should know if what the author did was a good decision at the time (tm) or not. I'd have to see the before and after pictures, and take into account that the "after" picture the author was aiming for might still be a little ways down the road. I'd have to know the rationale and a lot more about those 10 random projects than I'd probably be able to garnish from changelogs, mailing lists, and CVS histories alone. And all of this assumes that freshmeat and SourceForge are good barometers for this sort of data - which I'm not entirely convinced that they are. And that's my point.

What would be more convincing is something more concrete than anecdotal, off-the-cuff divinations. Though we may not agree with all of his conclusions in "The Mythical Man Month," no-one contests that Herb Brooks spoke with a large measure of firsthand experience and data to support his claims. Your article, at least as presented here, has none.

Dom

Re:Amen!

[Rallion]

I gotta offer that beginning programmers simply don't have a ton of code to reuse unless they avail themselves of open source.

Also, depending on what you mean by 'beginner,' they'll often have trouble finding what they need, or knowing what they should look for. It's a big, big world. Without experience, anybody simply will be floundering for a while.

Whether that relates at all to the discussion, I'm not sure.

Re:Amen!

[gillbates]

And I really wish I had availed myself of open source.

A few months ago, I wrote a utility which would copy files from one directory to another, if and only if, the files in the destination directory were older than the source files. It turns out that XCOPY wasn't working the way I wanted it to, so I wrote my own utility. Then, I stumbled across rsync while Googling one night...

But I'm still rolling my own, because it would take more time for me to make sense of the documentation. Most OS authors give a very detailed, albeit useless description of their software. It usually goes something like this:

Xdoxmkr is a free implementation of the popular Winmkr software for resyncing Xdox nodes under UNIX. We have used it on our get-apt-xgs server for the past 3 years and it is quite useful. The new release 1.02.78.998_0z99s.dox-version10.2 fixes many of the bugs in the old release, 1.02.78.996_0z99x.dox-version10.1.

Version 1.01.78.999.dox.098 is ready for beta testing! This fixes the primary_resync_down_test bug in the Xdox.h header which would occasionally reindex the first x_node if the z_index and y_offset were different by more than 10 m_syncs.

Some of our users reporting conflicts with the new OpenXMod server when running Xdoxmkr on RedCoat Linux with kernel 2.3.88.01.7.69.10-smp-alpha. The recommended workaround at this time is to recompile OpenXMod with the -df, -rm, -fNoBignumsbutnotFloat_on_x86 flags. Then recompile the kernel with _scsi_super_fast_no_ide option set, flash the BIOS, and toggle the LBA_MODE jumper on the back of /dev/hda. If you're not sure which of your drives is /dev/hda, you can download Peter Friggin's Xdrive here.

Okay.... But what does it do?

I like OS, but I must admit that having English as a second language (as opposed to C++ or Java, etc..) is definitely a hindrance. We need to get our heads out of the sand and look from the perspective of our users.

Re:Amen!

[Oswald]

You almost made me snort wine out my nose from laughing.

You really nailed it, brother. But, I would argue that you answer your own first post with this one. Your point here goes far to explaining why the world seems powerless to move towards actual code re-use. By the time you find the code, figure out if the developer thinks it solves your problem, figure out for yourself if it actually does solve your problem, then learn the interfaces and fight your way through the bugs--shit, you could have built it yourself with time to spare, and the variable names would be easier for you to remember, too.

Re:Amen!

[oo_waratah]

I read up on bake (make replacement) after a presentation at my Linux User group. I read the doco and I was left with the question 'Why?'.

I emailed the project and gave them a patch for typo's and English then outlined that I had no idea why I would bother with the project. I then worked with the owner of the project discussing with him and strengthening the doco.

It is always worthwhile forwarding the question you have and referencing the doco. You really have to prove that you did read it as well.

Re:Amen!

[Anonymous Coward]

Keep in mind that people grew up with Microsoft's use of the term "Complete Rewrite".

What they actually mean is that 90% of the code is the same but they sexed up the buttons a little bit.

Re:Amen!

[j3110]

I'm not saying it's impossible. I'm just giving some scenarios where it isn't possible. Combining those two, I'm saying it's not always possible to start small then build up big and still end up with the same solution as design before hand. Most open source coders I've seen have been all about jumping into the code and solving a problem. They solve one narrow-minded version of the problem, thus they begin to think they should develop a framework as a blanket solution. They evolve code for doing one thing into code that does something that is quite different sometimes, and more times than not, not the best way to do the other thing.

Do that about eight times, and you have the same API for parsing xml as word files or something equally as ridiculous because they have code built on top that uses this API, and if they change it in one place, it ripples throughout the entire code base requiring extensive testing and often synergistic errors that unit tests can't catch for you. Even if you don't get errors, you'll end up with a system that has very little insight into anything but it's original domain.

You may think that compartmentalizing code would solve this, or maybe that you are just trying to make one program do three programs work, but that isn't always the case. In order to make a consistent feeling interface, that is consistent with the model, you have to actually design. Right now, Linux has a million small utility programs that use pipes to interact. If you think about it, a lot of the time, if they programs were actually integrated together, it would be much more efficient. Consider |grep blah |less. If I hit G to go to the end of the less, it will take forever for a significantly large file. Are you going to write a generic protocol over pipes to communicate stream positioning? Are you going to write one single program grepless to become the union of the two programs? Wouldn't be easier to just redesign an architecture involving filters, formatters, data sources, and pagers that are pluggable? Then it would be faster than running a protocol over pipes too. At some point you have to involve the file system, like the VAX did. You can seek to any line in a text file on a VAX, because it could indexed \n characters in text files with certain flags.

Haphazard programming without the discipline of design leads you to a psychotic system that is often beyond repair. You don't see a problem today, but your program will run into a dead end of functionality per code ratio. It takes exponentially longer to add functionality, and it's often much better to determine the purpose of your program, then design for the most general case, but code for the most specific.

Of course you probably don't have the experience I have of walking into projects that were done in VBA/Paradox that want to go multiuser. Some things just aren't technically feasible because of severely poor design. Complete lack of design that a lot of open source projects have will often lead to worse fates in a year than the startup projects that begin now to replace them. Basically, you can rewrite it, or someone else will for you. EXT2 would have never evolved into ReiserFS. The beauty of the Linux kernel though is that it has just enough architecture that obsolete parts get discarded and rewritten without disturbing the rest because it is modular. It gets better design all the time. The SCSI code was almost completely rewritten for 2.4. The memory manager was completely rewritten. The scheduler has since been replaced. Despite Alan Cox's claim that the Linux kernel evolved and wasn't designed, there is a lot of design in the kernel, and you'd be hard pressed to find much of the kernel that hasn't been rewritten at least once to improve this design.

Do keep in mind that the parts of the Linux kernel that have been rewritten are larger than some applications that people try to salvage. Blanket statements like "It's better to keep what you have than rewrite" is very wrong in a lot of situations,

Re:Amen!

[chromatic]

Haphazard programming without the discipline of design leads you to a psychotic system that is often beyond repair.

I agree. Thinking about the your design is good. That's why I suggest doing it as often as possible.

You may be a much better designer than I am -- I have a terrible time coming up with the right design before I start putting code together. I usually end up refactoring out useful bits and going off in a different direction than I thought. I'm happy with that because I end up with code I like much better. If you get everything right up front the first time, though, more power to you. I wish I did.

[The Linux kernel] gets better design all the time. The SCSI code was almost completely rewritten for 2.4. The memory manager was completely rewritten. The scheduler has since been replaced.

Amusing example; how many times have those subsystems been rewritten from scratch? The SCSI code seems to turn from "bright shiny nice new rewrite" into "terrible mucky old crufty garbage that really needs a rewrite" in the time it takes to branch a new development version. I also don't count the VM swap that happened around kernel 2.4.9 or so as a bright shining moment in history!

Re:Amen!

[j3110]

Well, on the issue of the kernel, you have to admit that the memory manager is at least twice as good as the old 2.2 memory manager. The SCSI code, I can't speak much for, but I assume it had something to do with efficiency of the drivers. All I know is that I couldn't patch the kernel with the promise SCSI driver that supported Promise Raid for quite some time on the 2.4 kernel. (I did manage to hack it statically into 2.2 even though it was binary.)

If think most people get the idea that XP is against pre-design and rewrites. It's just not true. XP just says you can't get all the design to begin with, that doesn't mean to not design to before hand, it means to design to be flexible to begin with. Now the "try the simplest thing that could work" mentality IMO, is the worst. Why not do it right to begin with, and move on to something else? If it needs to be changed, it'll be much easier than parsing through unreadable code that barely gets the job done. Rewrites happen when people do "the simplest thing possible" for so long that you really can't understand the code. It's better to rewrite code than it is to understand it. They also occur when such significant changes are being made to the way that something is done that there is actually not a single line of code that is useful anymore. There are reasons why this could be true, like the linux memory manager of 2.2 era. It was just not designed for how memory is used today, and it couldn't have been designed for it without a psychic developer. The API must have been pretty well designed to handle a change like that without headache.

I hope you are beginning to see the difference between design as you go and design before hand. They aren't the same kind of design. One consentrates on infrastructure, the other on the actual code. You can't change the infrastructure without significantly changing the entire source tree, and sometimes it's better to rewrite at least large sections of the code than it is to try to work in that infrastructure. It's always best to come up with the best infrastructure you can before you write any code.

Re:Amen!

[chromatic]

It's better to rewrite code than it is to understand it.

I don't understand this at all. How can you rewrite the code correctly unless you know what it's doing and why?

I think you're quite mistaken about XP. XP says, in cases where you don't have all of the requirements up front and you expect them to change, to design and code only what you need right now, and then to refactor regularly as changes come along.

If you don't refactor, of course you'll end up with a big ball of mud!

I'm not arguing against design. I'm not arguing against cleaning up code. I'm arguing against the idea that the best way to clean up working but ugly code is to throw it all away and start over.

As you suggest, why not do it right to begin with?

Translation...

[gmaestro]

Myth: Publicly releasing open source code will attract flurries of patches and new contributors.

...should be read as, "write any featureless, buggy program and then people in the community will do your work for you." I mean, how is this different than any other project you might undertake?

Hmm

[MasterSLATE]

One of the points brought up is about CVS... Personally, I'll have to agree with that. I know how to program, but CVS is just a concept I've never understood. I just never understood how to use it.

Regarding the other myths, I'd have to say that they are very good points. Some of them I'd agree with to a certain extent.

Re:Hmm

[MetalShard]

The answer to CVS is not to use CVS directly but to use the hundreds of other programs people have written to make CVS easier (like TortoiseCVS.)

Re:Hmm

[mark-t]

Once you've programmed on a team, you'll soon appreciate the concept of version control. This is especially true if you've ever tried working it without it in a group project at some earlier point in your career.

Re:Hmm

[iandog]

CVS is an important part of concurrent development. It solves the problem of how to maintain a single codebase with multiple developers working on it quite nicely. I think if you want to work with a group on an open source project you should take the time to learn this.

CVS isn't really that hard especially if you don't actually maintain the server yourself (i.e. sourceforge). If you know how to code I think it should be a piece of cake to pick up CVS and it's concepts.

On warnings

[Anonymous Coward]

They bring up an important point about warnings-- that if you don't fix warnings, even if the thing you're being warned about is fine, you'll miss important warnings later.

Their solution is, always fix warnings.

My solution is, GCC needs some way to suppress warnings!

Yes, GCC can already suppress *classes* of warnings. But I want to be able to suppress warnings on a per-line basis. What if in function x, there is a variable that I have defined but do not use for some specific reason-- but I still want to be warned if I do the same by accident in function y?

In Codewarrior, we had something called #pragma unused which worked like this. But that was just for that one case. Something generalized would be cool, something like "#pragma gcc.sw typecast" that would suppress typecast warnings for the next block, for example...

Re:On warnings

[pclminion]

What if in function x, there is a variable that I have defined but do not use for some specific reason

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;
x = x; /* shut up compiler warning */

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...

Re:On warnings

[Anonymous Coward]

The source is available, why don't you fix it yourself? If more people would contribute code instead of simply bitching about it then many projects wouldn't be in the state they're in. If you want a particular feature in a product don't endlessly email the developer. They have obviously created it the way they believe it should be. Code it yourself and submit the patch.

Jesus Christ! Some people are so lazy. It's no wonder Microsoft has the market share it does when nobody is will to learn or do for themselves.

Re:On warnings

[Horny Smurf]

maybe you should just remove the variable declaration.

Re:On warnings

[MouseR]

int x;
x = x; /* shut up compiler warning */

You only need:

1. ...
2. 
   x;

and it does the trick.

Re:On warnings

[mark-t]

Their solution really is better.

Always fix warnings.

In every case I can imagine, altering the code so that the warning will not occur would not ever result in code that executes more slowly, although I do acknowledge that the resultant code could be obfuscated somewhat. The maintainable solution to this is to accept the additional obfuscation where it happens and add a line or two of comments explaining what the code fragment accomplishes in a more readable form. If the warning is common, create a well named macro that hides the obfuscation, and document why the macro was made and what the macro does (eg, "Performs arithmetic on void* as if it were a char*. Created to suppress warnings by gcc about doing arithmetic on void*"). Now really... how hard is that?

Re:On warnings

[smackjer]

You really should never bury/disable/hide warnings. Even if the code compiles and works with warnings, it probably won't be portable to other compilers/platforms. This may or may not be a concern (usually isn't) but you never know who will want to borrow some of your GPL'd code.

Besides, there are ways around the "unused variable" warning. The most common is something like this:

int x = 0; // init it, instead of just "int x;"

or... in cases where an init isn't viable:

DataType x; // simple declaration

x; // it's "used" (referenced), but not to do anything

Re:On warnings

[FroMan]

/* function that used to need argument but does not need
* it anymore because it has been refactored but we want old
* code to work anyways.
*/
int foo(char *arg)
{
arg = arg; // suppress warning

return foo();
}


Now do you see why you might suppress an unused argument warning?

Re:On warnings

[Anonymous Coward]

or you could use the next version of C# which has inline warning control (and will be ECMA standardized so portable.)

Re:On warnings

[Decameron81]

I still think that the unused attribute is best for this purpose. The reason? If you declare a variable as unused it will remain highlighted someway, meaning that if you choose to actually use the var in the future, it will be easier to spot it again and remove the unused attribute. If you put x=x; in the code, or even just x;, it is not likely that you will easily remember that x is "unused". Plus even if the __attribute__((unused)) may not be standard in all compilers, most compilers offer an implementation of the "unused" keyword of some sort, which means it is not a real problem when it comes to portability (just use #ifdef).

In short, the unused attribute is good since it can be used as a label and is easier to find or spot.

Diego Rey

Re:On warnings

[pclminion]

If you put x=x; in the code, or even just x;, it is not likely that you will easily remember that x is "unused"

Hence the "/* shut up compiler warning */" comment.

In reality, whenever I do something tricky, kludgy, or non-portable, I put a comment which starts with /* XXX ... */ I always know to search for "XXX" if I want to find all the oddities in the code. It's a fairly standard way to indicate that something weird is going on.

The major problem with your #ifdef suggestion, is that a lot of compilers implement the unused variable thing as a #pragma directive. Sadly, you cannot call #pragma from a macro. #pragma makes it extremely hard to write portable programs for this reason -- you can't write a macro that expands into a pragma directive. That sort of makes pragma useless for just about anything, IMHO.

Re:On warnings

[Decameron81]

Good point, I also use comments in the same way, although for completely different purposes than yours. And I have to admit that if there are compilers that only have the #pragma directive for the unused keyword, then that's a problem, although I have never actually worked with one that doesn't accept at least another way to use the "unused" keyword (like __attribute__(()))

In my opinion it would be very nice if someone reviewed C++ to make keywords like that something standard. And maybe also improve the language in other ways.

Diego Rey

Re:On warnings

[Anonymous Coward]

I often search for XXX, but it doesn't usually involve any coding.

Re:On warnings

[swillden]

int foo(char * /* arg -- unused */)
{
return foo();
}

or

int foo(char *)
{
return foo();
}

work just as well, and are less verbose.

Re:On warnings

[Richard_at_work]

GCC is littered with HUNDREDS of very cool extensions. Just make sure it's worth giving up portability...

That would be called "embrace and extend" under a different thread and compiler name.

Re:On warnings

[runderwo]

int x;

x = x; /* shut up compiler warning */

Hrm? Then the compiler warns you about using an uninitialized variable.

Re:On warnings

[pclminion]

Hrm? Then the compiler warns you about using an uninitialized variable.

GCC doesn't. Are you using VC++?

By the way, the compiler will only warn about uninitialized variables if you have optimization turned on (it doesn't do the required data-flow analysis to detect uninitialized variables if the optimizer is turned off).

I'm assuming that the "x = x" gets optimized away during an earlier pass of GCC, thus the warning never gets generated. Other compilers might be different. It doesn't really make sense to warn about it anyway, because the statement "x = x" has no effect, regardless of whether x has a defined value or not.

Re:On warnings

[pclminion]

As would:

int foo()
{
return foo();
}

int main()
{
foo("xyz");
return 0;
}

Remember that in C, an empty argument list is equivalent to an unspecified set of arguments. If you actually need to specify that a function takes no args, declare it as foo(void).

If you don't believe me, just try to compile the above. The compiler will produce no warning.

Re:On warnings

[pclminion]

The giant difference is that GCC can target Wintel machines. Or 68000 machines. Or PowerPC. Or ARM. Or PA-RISC. Or R6K. Or a zillion other targets.

You do realize that you can use GCC to compile Windows applications, right? Let's see you use VC++ to compile something to run on Linux.

We're talking about giving up portability to different compilers here. Not different platforms. We're not even in the same ballpark as what Microsoft has done with their proprietary crap.

Re:On warnings

[isj]

x;

And then other compilers will warn you about "statement has no effect"

Re:On warnings

[Frank T. Lofaro Jr.]

If gcc hasn't been ported to that system, why should you bother porting your own code?

The platform is probably not very popular or open in this case.

Some people insist on using only K&R type function declarations so it will work with legacy compilers. Ugh.

Re:On warnings

[Uma Thurman]

That's just poor code. If you've refactored without fixing up your arguments, you've done a bad job. That's like stealing from your employer.

Re:On warnings

[Anonymous Coward]

What's wrong with x = 0? On most architectures, there's a fast instruction to set registers equal to 0 (it's usually slower to set it to some arbitrary constant); often it's as something as simple as x ^= x. I suppose some theoretical architecture might have a faster copy than set-zero, but I think the reverse is usually more likely.

Re:On warnings

[pclminion]

What's wrong with x = 0?

What if x is a struct? You can't assign 0 to a struct, but you can always assign it to itself.

Re:On warnings

[oo_waratah]

What I like about the AIX compiler is that it does actually pick this up as unused. I sometimes sweep my code with it to remove dead code.

If you are doing something like this why aren't you using #ifdef around it for the times where it is not used. Surely this is more obvious and solves the warning.

Re:On warnings

[swillden]

True for C. Not for C++. For C++ you need the argument, but omitting or commenting out the variable name will suppress the warning.

Re:On warnings

[Dr. Photo]

In the above case, you should let the warning remain intact until you've actually done something with arg.

Re:On warnings

[pixel_bc]

> What if in function x, there is a
> variable that I have defined but do not use
> for some specific reason

void test(void)
{
int unused;
(void)unused;
}

wow

[nizo]

New developers interested in the project will best learn the project by fixing bugs and reading the source code.

Oh my God, this sounds exactly like my last job. 10,000 lines of Tcl, with not a shred of documentation in sight. Running a financial system that processed millions of dollars a day. And I know to this day, my old boss is still trying to figure out why she keeps losing employees left and right, and why it takes so long for new people to come up to speed.

Re:wow

[Mephie]

Oi, yeah. I've worked on projects like that. In a related story, the amount and quality of //comments I add to my own code increased significantly after the first such project.

Comments usually aren't much, but jeez.. they're certainly better than nothing at all.

Re:wow

[nizo]

Yep, after that job I really realize how important comments and documentation are. No class I ever had came close to making this lesson so painfully apparent.

Re:wow

[Anonymous Coward]

This is your old boss. The fact that the system used Tcl is not relevant. You were fired due to the fact you would not wear pants in the office and walked around asking people to pet the elephant.

Re:wow

[Anonymous Coward]

You know what's worse? Comments like this in the code :

// Connect to the database
// Fucked string manipulation algorythm
// Warning garbage code follows :

I'm not kidding I've seen this stuff.

Re:wow

[MouseR]

You quit your job because of 10,000 lines of code?

Sheesh. Out of the 35,000+ SOURCE FILES I need to deal with, some of those have that many lines of sources.

With that sheer volume, comments yield good hints as to how things work, but still, you inevitably need to read and picture out the sources to gain real a understanding.

Re:wow

[Anonymous Coward]

Let me guess? The documentation doesn't get written because you are so far behind on bugfixes. You are so far behind on bugfixes because everybody is new and doesn't know what they are doing. Everybody is new and don't know what they are doing because people keep leaving and there is no documentation. People keep leaving because they are fed up with banging their head against a brick wall and getting yelled at for all the bugs.

Sadly, this is a common problem. The biggest problem is not with the employees or the program itself. It's with the manager.

Re:wow

[nizo]

Actually the stress came from, "we have a million dollars worth of transactions running through a pile of undocumented crap code, we have a deadline we can't miss in twenty minutes, we have no test environment that is even close to what is really running in production, and you have the pager, fix whatever broke NOOOWWWWWWW". I don't recall exactly how many lines of code there were either, that was just a random guess. Oh yeah, did I mention that code that was running in production for months (or even years) would fail with syntax errors (since it was Tcl you could have syntax errors and the code would still run until the line with the error is actually reached), with the added bonus that many of the errors were not caught, so you would get page upon page of Tcl spewage when there was a problem? The best part of all, when I tried to diplomatically explain these kinds of things to my boss, it pretty much fell on deaf ears, with comments like, "well Jimmy here [who wrote something like 80% of the initial code] doesn't have any problem fixing pager issues, what is your problem?" Wow, now was that a rant or what? :-)

Re:wow

[Anonymous Coward]

You were at a point I think where you should of just fessed up, and called your boss stupid to his face. (With professional reasons as to why he's stupid.) :)

Re:wow

[DunbarTheInept]

And that's bad exactly why? I'd MUCH rather see an ugly section of code prefixed with the author's admission that it's ugly and messy than with no warning at all. The admission of ugliness helps to remove a bit of the frustration over not being able to understand it easily. (Granted, I'd rather not have the ugly code at all, but if it's there, the comment admitting it's ugly is helpful as an apology and a word of understanding sympathy from the previous author.)

It was obvious

[flicken]

See my almost identical comment, which was unfortunately submitted too slow.

Re:It was obvious

[Anonymous Coward]

haha...way to suck

Re:It was obvious

[Savatte]

I saw that, and then when I refreshed the page, it was modded down to -1. I'm sorry. In retrospect, I should have put something like myth 9: "open source developers do not die as virgins," but since I was on the phone at the time, I typed the most obvious thing. I'll let you get the earlier post next time.

Re:It was obvious

[Anonymous Coward]

Hoping to catch some sympathy karma? It wont work because you are a retard.

Another myth

[bartash]

It's not worth writing good design documents because everyone will read the code.

Re:Another myth

[drxenos]

Good one. I once got yelled at for writing a design document. I was told to quit wasting time and just write the code. I quit that job soon after. I later heard from a guy that still worked there that they need to update my code, couldn't figure out the design (simple state machine!) and just had someone rewrite it from scratch. The really funny thing is that is was for a shared interface across a serial channel--why wouldn't you want documentation so the guy at the other end can match the protocol??

Re:Another myth

[Anonymous Coward]

Or its brother myth;
Well-written code doesn't need any documentation.

Re:Another myth

[Anonymous Coward]

Err, the problem is that there are no sufficient languages to create perfect code. I think we all would agree that perfectly understandable code would not need documentation (alternatively, the documentation would be the code/executable). But most code has to deal with impurities at the boundary of an abstraction layer (such as translating a parameter from the ideal to something lowlevel).

My rule is: only use comments when you are forced to violate idealism.

The problem with that is, without a good editor like Eclipse that is smart enough to show you a reasonable abstraction of the source (like an object interface) and can show you just the body of the function you are looking at (to focus on one problem at a time), reasonably near-perfect code becomes hard to understand as well.

When I'm reading/learning/reviewing (I work as a distance learning instructor) code, I need to be able to quickly grasp interfaces and study interactions. (The implementation is the least of my concern.)

Though, I usually just assume that no one will look at the plaintext. In fact, that may be my first comment: // USE A GOOD EDITOR -- THIS IS A STRUCTURED DOCUMENT

Re:Another myth

[Anonymous Coward]

I prefer to comment every single damn line, because my opinion of what is clear (as the writer) does not mean that it is the same of another's opinon of what is clear.

yea! just like myth 10:

[Anonymous Coward]

getting +5, Funny mods on slashdot will get me laid faster

Re:yea! just like myth 10:

[dasmegabyte]

Fuck, that explains it!

I thought it might be paralyzing social fear. But it's the karma whoring that leaves my dance card so empty, and my /porn share so full!

Re:yea! just like myth 10:

[nizo]

getting +5, Funny mods on slashdot will get me laid faster

They will, if you consider getting attacked by a pack of randy pit-bulls "getting laid".

Re:yea! just like myth 10:

[Anonymous Coward]

I thought it might be paralyzing social fear. But it's the karma whoring that leaves my dance card so empty, and my /porn share so full!

There may be a connection between the social fear and your /porn share. It's kind of hard to overcome social fear when the woman you're approaching reminds you of someone you saw inserting rutabagas into her vagina on some porn site. I'm not moralizing, just making an observation.

Re:yea! just like myth 10:

[Anonymous Coward]

>someone you saw inserting rutabagas into her vagina on some porn site.

URL, please?

As with all the projects,

[Tensor]

OSS or not, i report ALL bugs i find. At least the first times. If i keep reporting them or not depends on the attitude of the developers.

I've had good experiences with smoothwall, emule mods, azureus, and believe it or not Windows. (i am a MS beta tester ...)

Here's a myth I see a lot

[Anonymous Crowhead]

"I am sure that everyone will want to install Apache/mod_perl/mod_ssl and mysql and perl 5.8.3 and 17 non standard perl modules (8 of which are not available on CPAN), ImageMagick, python, zlib, libpng and glib2.1 and zend and php) to be able to use my practically useless and very buggy digital picture management system."

Re:Here's a myth I see a lot

[FroMan]

This I think is actually the cause of NIH code. It is not that developers do not want to reuse code, but when I have to look around 8 sites to find obscure blocks of code just to be able to compile a project, it isn't worth it.

Finding the solution between 80 dependencies and re-writing code, sometimes re-writing code is easier. I know I tried a number of times to get gnucash working under slackware one time and it simpley was not worth my time figuring out all the dependencies.

So, one possible solution is to take other people's code/libraries and package them with your own, but which packages do you do that with? While it is safe to say glibc is on any installation, is it safe to assume (for instance) a postgresql jdbc driver will be? Should you package that with your project or make it a dependency? That is where things get difficult.

Re:Here's a myth I see a lot

[Lussarn]

I don't want to install internet Explorer or windows media player to play need for speed, but I have too. What you are describing is not even a open source problem.

Re:Here's a myth I see a lot

[Anonymous Coward]

Reminds me of this system ...

Re:Here's a myth I see a lot

[Uma Thurman]

Can't get gnucash working? Unbelievable.

Re:Here's a myth I see a lot

[Anonymous Coward]

re-writing code? I just want to install something without having to figure out where to download the other crap to get it working. If projects that have dependencies just list where to get them, or *gasp* have them all in a single download (you could have the program download and a program+everything download) then I might acually start using more OSS.

Re:Here's a myth I see a lot

[Mike Hawk]

Interesting comparison...

Though I haven't played Need for Speed, I'll work with the notion that what you are saying is true, that one must have those programs on your gaming system for all of the game's features to work. So are you already running Windows? If so, there is a 99% chance that those programs came installed on your system. Its not that you don't want to "install" them, its that you don't want to have them installed and you removed them. In this case, this is not a closed source problem OR a Windows problem, this is a Personal Problem. You made the choice to make your system incompatible (or desire to do such). This is where Windows, not a philosophy of closed vs. open, actually has the upper hand. Windows is less of an OS and is really a platform. I can develop multimedia software for Windows knowing the end user has 1. DirectX, 2.IE, and 3. WMP. The end-user can acquire new multimedia software based on this platform and be assured that it will A. run out of the box or B. run after a single call to a corporate customer service department. This forms a closed circle of consumer trust and developer willingness. In summary, this could be a problem with either closed or open source, but in fact it is not a problem with Windows as your example implies.

Working from the other case of you not having Windows installed and running in some sort of compatability mode or emulator...it must have said Windows required on the bottom of the box so I would not pity you there if it doesn't work.

Open Source Software is all about need

[pbug]

If you write something that is usefull and/or fun. People are going to use it. For example I use the Spreadsheet::WriteExcel module at work. Yes perl writing excel documents. I used because there was a need. I fixed a bug in one of the optional modules because that was a feature we use and need to work correctly. Would I ever picked up and use that module on my own. Maybe if I came across it and wanted to create an spreadsheet for some silly reason but I highly doubt it. But I had a need to create an excel spreadsheet on a unix server so I filled that need.

Regardless of the general case...

[Anonymous Coward]

Regardless of the general case, what the article claims (specifically, that you won't receive patches or even comments) hasn't been true for me. If you write software that actually does something people want, it will get used.

I had bugs reports within a day of announcing my software. I received a patch to port my software to another OS within a week of it showing up on SourceForge (it's only in the 70-80 percentile range for activity too). I had feature requests shortly afterward too.

I've also written a library or two that never gets feedback simply because it's something only I would use (at least at the levels of completion they're at). But, I expected as much.

Publishing your Code Will Attract Many Skilled....

[SharpFang]

It's a myth. And here's a proof:
A few words from a desperate open source coder... /usr/src/linux/Documentation/networking/arcnet.txt :
Since no one seems to listen to me otherwise, perhaps a poem will get your
attention:
This driver's getting fat and beefy,
But my cat is still named Fifi.

Hmm, I think I'm allowed to call that a poem, even though it's only two
lines. Hey, I'm in Computer Science, not English. Give me a break.

The point is: I REALLY REALLY REALLY REALLY REALLY want to hear from you if
you test this and get it working. Or if you don't. Or anything.

ARCnet 0.32 ALPHA first made it into the Linux kernel 1.1.80 - this was
nice, but after that even FEWER people started writing to me because they
didn't even have to install the patch.

Come on, be a sport! Send me a success report!

(hey, that was even better than my original poem... this is getting bad!)

WARNING:
--------

If you don't e-mail me about your success/failure soon, I may be forced to
start SINGING. And we don't want that, do we?

(You know, it might be argued that I'm pushing this point a little too much.
If you think so, why not flame me in a quick little e-mail? Please also
include the type of card(s) you're using, software, size of network, and
whether it's working or not.)

My e-mail address is: apenwarr@worldvisions.ca

Comments

[aridhol]

Myth 1: Attracting patches and contributors

What most developers don't think is "Hey, I didn't contribute anything. Nobody I know has contributed anything. Why will my project be any different?"

Myth 3: Reading code

I've tried to read large bodies of code before. It's damn hard, even if it is documented. And when it isn't documented, your beginning developers don't have a chance.

Myth 4: Packaging

Um...duh? Of course it needs to be properly packaged. And dependency lists? If someone can't get it to compile, they definitely won't use it.

Myth 5: Start from scratch

Don't start from scratch if the code isn't clean. Make new code clean, and go back to clean up existing code. Make sure you have those regression tests ready.

Myth 7: Perfection

Developers are humans. Humans are fallible. I'll make a perfect program - when Bullwinkle pulls a rabbit out of his hat.

Myth 8: Ignore warnings

If the warnings were ignorable, they wouldn't be there. My profs would take marks off if you got warnings in compilation, unless your documentation explained exactly why you let the warning stand (and it had better be a good reason).

Myth 9: Tracking CVS

Users don't track CVS. Developers track CVS. Users want quick-and-easy, working code.

Either I miscounted, or there's more than 8 entries on the site (they aren't numbered)

Re:Comments

[Anonymous Coward]

Doesn't seem you get enough 6

Re:Comments

[Anonymous Coward]

you skipped #6

Re:Comments

[Wumpus]

Myth 3: Reading code

I've tried to read large bodies of code before. It's damn hard, even if it is documented. And when it isn't documented, your beginning developers don't have a chance.

They have a chance if they start by fixing a bug. It gives focus to the effort of reading the code, and imposes a structure on how you must do it. It's also a great motivator.

Instead of reading random files, and trying to make sense of things this way, you start with a symptom (Widget caption isn't updating to reflect a state change, for example), go straight to where the code deals with the part you're interested in (grep "Wrong caption" *.c) and get an immediate feel for how things work in the close neighborhood of the bug (Hmmm... There's a function here that looks like it should do this, but it doesn't. Who calls it? Under what circumstances? grep some more...)

And at the end, you've done something visible, that didn't take as much work as reading half the source files in the project, and you've earned some credibility with the project maintainers.

Re:Comments

[aridhol]

I skipped #2, as well. I didn't have anything to say about them (2 - feature freeze, 6 - frameworks vs apps)

Re:Comments

[Zathrus]

They have a chance if they start by fixing a bug.

Maybe. In a large project, it becomes difficult to find the right place to fix the bug. If you don't have a good understanding of the overall architecture your "fix" can easily break other concepts or code outright. Or you may be duplicating effort that exists elsewhere in the codebase.

Not to mention that a rather vast amount of bugs don't do something "visible", but just screw up things behind the scenes. You may know what the effect of the bug is, or the symptom that causes the bug, but that's not going to help you grep for a string in order to find the bug.

Re:Comments

[Zathrus]

I've tried to read large bodies of code before. It's damn hard, even if it is documented. And when it isn't documented, your beginning developers don't have a chance.

Hell, try reading your own code after some time.

I know I saw a fortune on this at some point:

XXXX's law:
Your own code may as well have been written by someone else after 6 months.

YYYY's corollary:
It's more like 6 weeks.

Pretty well true for any large project in my experience -- yeah, I may have a better idea about what it does in a broad sense, but the details? Forget it. I'll go look at the code and get back to you.

Re:Comments

[martyros]

Hell, try reading your own code after some time.

I've certainly found that to be true... that's why I document things. I don't have any anal ideas about "rightness", but I look at some section and say, "I know that in six months I'm not going to have a clue why I wrote this, I'd better leave a note..." Sure enough, six months later, I'm looking at some obscure if clause and going, "What the heck? Did I write that?" And behold, a note from myself explaining things...

Of course, that's targeted at a developer who already knows the overall structure and how things flow (i.e., me, or someone else already intimate with the code), not someone just coming at the code for the first time. That's always been my barrier-to-entry to help out with OSS projects: I don't feel like taking a week pulling at threads to try to find the big picture

Re:Comments

[Feztaa]

Our code has to compile clean on Redhat and solaris, AND lint clean

You lucky shit! Our code had to compile on Windows!

Re:Comments

[DunbarTheInept]

What used to tick me off was when a professor would require BOTH lint-free code AND clear easy to read code. Those were mutually exclusive becuase our lint made you do really DUMB things like cast your NULLs (I'm sorry, but *NO* - nothing can go wrong from failing to cast a NULL, since it isn't possible to follow it and use it's contents anyway it doesn't matter what "type" the compiler thinks it's pointing at. That's why it's defined to be void* - specifically so you *dont* have to cast it. Duhhh. I don't know if this was endemic of lint in general or just the version we had to use, but it kept making me have to uglify my code. Another one that bothered me was having to cast character literals to (char) since the compiler technically thinks of them as ints, leading to such stupid looking code as:
if( str[i] == (char)'A' )
I mean , come ON! It's a literal char. It can't BE anything other than a valid ascii code that fits in 8 bits or less, so you *know* it will not lose anything when truncating from the int to a char, so don't worry about it, geeze.

Re:Comments

[Samrobb]

Myth 1: Attracting patches and contributors

What most developers don't think is "Hey, I didn't contribute anything. Nobody I know has contributed anything. Why will my project be any different?"

Here's the real problem with this myth: desire to contribute, and ability to contribute, is nothing in the face of lack of premission to contribute.

Not suprisingly, a lot of people who contribute patches and development effort to OSS projects work in the field - they're developers themselves. Since they're most likely to work on OSS to "scratch an itch", it's got a pretty good chance of being related to whatever they're working on for their employer. Soooo... if you're in this situation, what are the chances that:

1) Your employer will not have any problems with you giving away something that may benefit a competitor?
2) The OSS project accepting your contribution without the requirement for a copyright assignment (see question #1)?

I've talked to developers who said they were pushing hard to get permission from their employers to "give back" to the OSS world. Easy enough to do in a small corporation. Much, much harder in a large one, even if your proposed contribution has zero relevance to the company's bottom line.

Does your company have a policy on OSS software contributions in place? If not, be prepared to argue... and argue... and argue, probably all the way up to the CEO; because whether you're talking about major patches to a large OSS project or a one-line fix for a one-person project on SourceForge, you will need to convince your management hierarchy that it is in their best interest to give something away. .

Assuming you get past this point, you still need to get approval for your specific change. You've got to convince your immediate management. You're probably going to end up waiting on approval from legal, because they need to look over the license to make sure that this isn't going to result in any liability for the company. If they OK it, you might be lucky enough to just be able to send the patch out on the authority of your manager; but you may also have to get Joe/Jane VP to approve each and every patch. You're going to have to do that anyways, if you need that copyright assignment for the OSS project to even look at your patch...

Understanding of how OSS development works is really just starting to make its way into most corporate environments. I wouldn't be surprised if the next 10 years saw a notable increase in the total # of OSS contributors, simply because the pioneers will ahve cleared a corporate trail that others will be able to follow. A project will still probably have trouble getting solid contributors, though, because there will probably also be an increase in the number of OSS projects available in the wild :-/

Re:Comments

[Wumpus]

Maybe. In a large project, it becomes difficult to find the right place to fix the bug

So? It's still easier than reading tons of source and out of date documentation (documentation is always out of date).

When I had to work with the Mozilla source code, I found that the most effective way to do it was to go right in and implement a feature. Some of the interfaces I had to use were documented, and some weren't. Where no documentation was available, I had to read the surrounding code, a few layers of calls, typically, to understand what was going on. I didn't really understand how things worked until I tried a few things, and saw how they didn't work.

Mozilla is a big project, it comes with its own middleware, and at least when I worked with it, it was poorly documented. Probing it was the only effective way I found to understand how parts of it worked.

Not to mention that a rather vast amount of bugs don't do something "visible"

Bugs always do something "visible", or they wouldn't be bugs. By "visible" I mean visible to the end user - it can be a protocol stack that sends the wrong message, an MPEG encoder that flips a bit in a picture header, or a real-time scheduler that's late to schedule a process - these bugs are all visible to the person who's bitten by them.

If you don't have a good understanding of the overall architecture your "fix" can easily break other concepts or code outright.

Of course. That's why you don't typically get cvs write permissions right away, and if you screw up, you typically get an explanation of exactly how you screwed up, but it's done in a context with which you're already familiar (you already worked with the code in question), so your chances of understanding the explanation are greater than if you just read the code and didn't try to work with it.

Re:Comments

[andy@petdance.com]

Sounds like the rules in my department, as created by me. Warnings are just not OK.

Re:Comments

[Wumpus]

Ugh. I have to correct myself here:

Bugs always do something "visible", or they wouldn't be bugs.

The notable exception are security bugs, which often don't affect the way the system works when given its expected input.

Re:Comments

[Anonymous Coward]

Our code has to compile clean on Redhat and solaris, AND lint clean, or we get a flat zero. NO ifs, ands or buts.

No ifs? Man, that's harsh. You have to write conditionals using while and break combos?

This IS a +5 troll article...

[Anonymous Coward]

Look at this line regarding the myth that releasing software as open source gets you tons of patches/contributors:

This isn't a myth because it never happens. It's a myth because it doesn't happen as often as we'd like.

Now, According to m-w.com:

Main Entry: myth
Pronunciation: 'mith
Function: noun
Etymology: Greek mythos
Date: 1830
1(a): a usually traditional story of ostensibly historical events that serves to unfold part of the world view of a people or explain a practice, belief, or natural phenomenon
2(a): a popular belief or tradition that has grown up around something or someone; especially one embodying the ideals and institutions of a society or segment of society
(b): an unfounded or false notion
3 : a person or thing having only an imaginary or unverifiable existence

This is not a myth. It is something which is true for a variety of reasons, and false under some circumstances. If it doesn't happen as often as some people would like, it is not necessarily a myth. Begone, ye article of the trolls!

Good points on ease of installation

[Anonymous Coward]

Congrats to chromatic for offering several points about ease of use, especially regarding installation, which are often missed. In particular:

- "Packaging Doesn't Matter"
- "Programs Suck; Frameworks Rule!"
- "Warnings Are OK"
- "End Users Love Tracking CVS"

I appreciate the difficulties involved for open-source developers in making their programs easy to download and play. At the end of the day, it's their choice whether they make it accessible to the masses. Many of them just want to give something to the world that they would have otherwise kept for themselves.

But it is clear from the number of ambitious projects that many developers to aspire to hit prime time. In those cases, I hope they will take the advice in Chromatic's article, and think very carefully about the experience of an end-user who just wants to have a look.

For one thing, provide some screenshots so they don't even have to download the thing to see it. Next, read your installation instructions and consider whether they might not be better represented as an actual installation script. And finally, have an automated test facility to make sure the installation procedure works correctly.

An example of a problematic open-source package is subversion, the "sequel" to CVS. Because of the decision to bootstrap version control, you have to go through some painful procedure (last time I looked), just to see if it's worth bothering about yet. I have better things to do than jump hoops to try out a bit of fresh meat. I'm sure it will be great when it hits 1.0, but I'll save my energy until then.

Remember: the risk of a crap product is high when it comes to picking one of the thousands of packages on SF. Therefore, the pain threshold for most people is very low: if it doesn't work after a few minutes, most people will give up and try one of the dozen alternatives.

Re:Good points on ease of installation

[Anonymous Coward]

Arch has the same bootstrapping problem. And they don't give you a way out of the box to adapt from a CVS-style of development with multiple committers.

For the LAZY ones (Myths List)

[Tensor]

Myth: Publicly releasing open source code will attract flurries of patches and new contributors.
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 ;D

BUT

[Jerry]

it is a "myth" to say the OpenSource development model is not working. Linux, KDE, GNOME, and thousands of applications prove otherwise, much to Microsoft's dismay.

Re:BUT

[RatBastard]

Gosh, I didn't see any claim in there that the OS developement model isn't working. What I saw was a list of logical errors many people make in their zeal to embrace the OS movement.

her work

[Anonymous Coward]

When was the last time you told a developer how her work solved your problem?

Umm... how about never? Well I sure don't know any female developers anyway.

Re:her work

[pclminion]

Umm... how about never? Well I sure don't know any female developers anyway.

Congratulations... You've just proven that you live in your mother's basement.

Re:her work

[Anonymous Coward]

Name an open source application where the primary developer, or even a significant contributor, is a woman.

Re:her work

[Anonymous Coward]

Umm... how about never? Well I sure don't know any female developers anyway.

Congratulations... You've just proven that you live in your mother's basement.

My mother is a developer you insensitive clods!

Re:her work

[pclminion]

My mother is a developer you insensitive clods! Hey, no worries, so is mine :-) And my girlfriend too, for that matter...

Just because she works on projects most people don't even know exist (research-related academic stuff), it's still technically "open source" and thus there's at least ONE female open source developer that I know of.

Re:her work

[character sequence]

Name an open source application where the primary developer, or even a significant contributor, is a woman

Obvious flamebait, but I'll bite anyway. The LAMARC package (Likelihood Analysis with Metropolis Algorithm using Random Coalescence).

Re:her work

[mirko]

Amaya.
Led by Irene Vatton.
(BTW: fuck you. machist asshole)

Interesting

[DroidBiker]

The specific myths don't apply to every project, but it points out what I've been saying for years. The only way to write good code is to study and practice. Associate with talented people, learn everything you can from them, keep up with industry best practices, and constantly evaluate everything you do in terms of its quality.

well done!

[MinorHeadWound]

This is a nice summary -- like any myths, YMMV for each project. "All models are wrong, some are useful." - I don't remember who said it, so I guess it was me!

Re:myth 12:

[Lane.exe]

You mean Microsoft is superior because they are nice enough to write shitty enough code to allow script-kiddos like yourself to keep exploiting it with viruses so that you can impress the rest of your "1337 friends" and dream about getting laid as you think of how hot it would be to be in a threesome with Keanu Reeves and Carrie-Ann Moss? Yeah, I guess you're right in that sense.

Come back in 5 or 6 years when you have a real job in IT and have actually used OSS projects in the workplace. Tell me that all those W2K server licenses were worth it when, after the 9 billionth time they'd crashed, you switched to Debian and Apache for free, and never looked back. Tell me this.

biggest problem I have with list

[tomphaedrus]

Granted, I don't think all of those are myths. But one really irks me as being false for any software developers:
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.

I work for a very niche market/profitable software company and thats exactly how the developers get their feet wet, by fixing minor bugs.

Seems like the only way to "learn a project" is to fix bugs and therefore read the code.

Re:biggest problem I have with list

[PureFiction]

I think the point was that fixing bugs alone is not sufficient. You need to approach the code base from two angles.

The first being a high level overview / design document that provides a big picture of how the pieces correlate and interact with each other.

The second being bug fixes and other tasks to get familiar with the low level details of the implementation.

The two together make for a great way to familiarize yourself with a project, but code alone with no other documentation is tedious and much less effective.

Re:biggest problem I have with list

[Anonymous Coward]

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...

Re:biggest problem I have with list

[benoitg]

>I work for a very niche market/profitable software company and thats exactly how the developers get their feet wet, by fixing minor bugs.

That myth does not usually apply when you have a physical team working on a project, as new members can (and usually are) coached by existing developers. When you have no one to answer the question "In what file can I find X" except by email, overview documents are essential.

>Seems like the only way to "learn a project" is to fix bugs and therefore read the code.

Off course, but no normal human being can linearly read thousands of lines of source code and efficiently extract the big picture from it. So unless they are paid to do it, most would be contributors to large open source projects will never reach the stage where they can fix bugs and in so doing acquire a deeper understanding of the project.

The kind of comment new developers need most when they join any new project is NOT:
-Watch out, the following snipplet is very complicated, let me walk you through it.

They need much more mundane info that most people completely forget to write:

-The following directory contains files related to functionnality X, and here is what each one does.
-This code is not currently used anywhere, but was writtent to allow support of X if someone writes code Y and Z
-This code will be deprecated, don't wate time on it, use X instead.

get off my case

[argoff]

Since you can't spell "communist", it's not surprising that you don't know what it means, either.

Fine, so I rushed it and accidently hit the submit button rather than the preview button. Sue me. Sheesh, I guess it's easier to rant about spelling than the facts.

Re:get off my case

[Anonymous Coward]

The "facts"? What facts? You only gave an opinion. Man, you really are retarded.

Re:get off my case

[Anonymous Coward]

Fact 1) Spelling is a "fact"

Fact 2) Open Source is communistic

Re:get off my case

[IM6100]

You're supposed to scurry off now and read 'On the Correct Handling of Contradictions Among The People' by Mao Zedong, and when you're done, it's assumed you'll run around waving a Little Red Book in the air.

Hop to it now. heh.

Major nitpick with "Warnings are OK"

[Gordonjcp]

When the "low oil pressure" or "low battery" light comes on in a car, the proper response is to make sure that everything is running well.

That's not a warning - that's more akin to an error. If the oil light comes on, and you don't stop immediately, you will stop in a very expensive way seconds later.

Re:Major nitpick with "Warnings are OK"

[iminplaya]

"...If the oil light comes on..."

It's already too late. Believe me, I know.

I detect some bitterness and pessimism

[bigberk]

From the article:

[Myth:] I'll Do it Right *This* Time... Reality: If you weren't disciplined then, why would you be disciplined now?

Talk about pessimism! People can do better than they did in the past, you know. Especially if they, uh I dunno, learn something in the process or possibly improve their style through help, education, or time commitment. Geez, guy.

Re:I detect some bitterness and pessimism

[Tony Hoyle]

True - I've seen some of the code I wrote 10 years ago... OMG!!! Shoot me!!!

No, I'm not disciplined by most peoples standards even now, but at least my code is logical and readable now.

Re:I detect some bitterness and pessimism

[aridhol]

But it seems to imply a next-try improvement. In reality, this will generaly be a slow improvement; it is very rare to go from complete, undisciplined slob to perfectly clean and maintainable style without a few steps in between.

Re:I detect some bitterness and pessimism

[Anonymous Coward]

All the more reason to get those few steps done in as little time as possible. The problem with knocking the "try, try, try again" approach is that you end up trying to climb Mount Everest in one fell swoop. It's usually easier (and faster) to just keep diving in and failing a bunch of times first until you get the hang of it. That's one of the great things about computers: if you screw up, you don't end up killing yourself (usually--I mean, you could be writing code for a nuclear power plant, but that's in a whole 'nother class of coding).

That's nice.

[RatBastard]

That's and well and good. But what does it have to do with the article in question?

why?

[theMerovingian]

The problem may be the definition of success. If your goal is to become famous, open source development probably isn't for you. If your goal is to become influential, open source development probably isn't for you.

No fame, no influence, no dollar bills - what motivates people to do it? This is not a troll, looking for answers from RealPeople(tm).

Re:why?

[Tony Hoyle]

Kudos.

And the fact that typing my name into google gets something like 6 pages of hits can't help either :)

Re:why?

[e2d2]

Sometimes it's just to solicit help and show off your wares to others at the same time. Thats why I have written and released code open source. By sharing what I've written it serves as an open forum to not only discuss the application but my techniques at the same time. If another developer has a better technique and shares it with me then I have become that much better. And vice versa. I cannot tell you how much this has helped me. Something you may think makes perfect sense might actually be a huge kluster f*#ck (been there, done that). In the end the development community benefits. At least that's my theory.

But I target developers with most of my code so it might be easier to solicit help than projects that target end users.

True Value of open source

[maraist]

I find that open source is not so valueable in that people inspect my code and provide feedback. Instead I find the following realizable benifits:

A) I can build apon other people's code.. It's effectively stealing their ideas, BUT since I'm GPLing my code as well, there is no net loss, and they are free to resteal my ideas back (if they are so inclined). I do often refer original authors to my new code.

B) I recognize that people MIGHT secretly build apon my code, so I get a warm fuzzy.

C) I can fix problems with open source drivers (postgres jdbc driver, GNU file-utils, etc. are some of my examples). Moreover, my debugger can jump straight to the line of maliscious code.

D) When I am about to release code publicly, I feel self conscious, and thus I put a TREMENDOUS amount of effort into cleaning up the code.. Making sure various platforms work, making sure there is no embarrasing spagetti-code, etc. Thus the mere possibility of people reading my code causes me to exert effort that I wouldn't otherwise. The end positive is a lower propensity for bugs, AND more modular/reusable code (especially with anything in perl).

The end-end result is therefore that Open source facilitates greater code reuse; less re-inventing of the wheel.. And more importantly code extensibility.

Now this begs a question of the distinction between modules and out-right applications. Open source is great for producing millions of reusable modules, but we often get chastized about the availibility of abundant QUALITY applications. Well, in my view, the merging of these two is two fold:

A) Open source applications tend to be more "plugagable"

B) Commercial sites will often pay developers to use open source modules and customize them to the particular needs of the corporation.. In doing so, serious feedback is provided to the various open source projects (because it is in their mutual interest to refine the modules). I as part of such a corp, have contributed (in various small ways) to several open source projects on the corp's dime, and with full authorization. This is of course, a completely unreliable source of income for a project, of course, but it is definitely a facilitator.

Re:True Value of open source

[apachetoolbox]

facilitator

I read this in my Arnie voice :)

Interesting.

[Anonymous Coward]

I wonder what you'll have to say the next time a "Windows is ass" vs "But you can install stuff on it" flame war breaks out.

Re:Publishing your Code Will Attract Many Skilled.

[MarcQuadra]

AFAIK almost NOBODY uses the Linux ARCnet component, it's a very obscure protocol for what Linux is put to use for. I absolutely understand why this guy doesn't get any help. The protocol works though, and it's complete, so nobody's gonna make a stink about it until something breaks it.

Good Software Management takes effort...

[plcurechax]

regardless of whether the project is an open source (or not).

We (popular IT community) are re-learning the lessons of IBM in the 60s which Fred Brooks distilled in his famous The Mythical Man-Month.

I think the bigger misunderstanding is that new developers/IT types/CS academics thinks that everything is new. Most computer security issues were first discussed based in the 1960s or 1970s. Much of Distributed Computing is now being "re-discovered" as Grid Computing.

Re:Good Software Management takes effort...

[Anonymous Coward]

I don't think the grid computing folks are rediscovering distributed computing, but building on it. Granted, choosing a new name and representing what you're doing as something fundamentally new is kinda dishonest, and your average /. reader is probably willing to believe the hype, but I think people who are seriously working on the grid computing vision are focusing more on the end product than the mechanism, while the distributed computing research done in the past provides a lot of the mechanism to enable the grid computing vision.

Reality 9:

[a!b!c!]

Being a Karma whore will leave you with Open Sores.

Re:Reality 9:

[leifm]

Funny doesn't improve karma, just visibility.

Best Practices for Software Development

[Anonymous Coward]

Hi

I have made a eigenpoll for Best Practices for Software Development

You use it by ranking the Practices you have expriense with, the it does some data minning
and find the best.

Right now the list looks like:

100% Test Coverage
Onsite Customer
Continuous Integration
Layering
Scrum Project Backlog
Test Driven Development
The Planing Game
TDD & CI with Aegis
Pair Programming
Current Worst Problem
Big Visible Chart
Simple Design
Codeing Standards
Refactoring
Collectiv Code Ownership
CRC Cards

feel free to add missing options.

ps.) Eigenpoll is open source too.

A few more I would add

[PureFiction]

I've found a few other misconceptions in open source development that have irked me over the years.

1. Using autoconf/automake will make my code portable.

TRUTH: You need to know what system calls are portable, which ones arent, and the nuances in using each on different platforms. The auto* tools will only make detecting and utilizing the correct versions easy. It's up to you to identify and code for them in the first place. (Ditto for compiler flags, shared libraries, linker options, etc)

2. Network programming is easy.

TRUTH: I've seen a lot of projects that implement their own network communication using TCP sockets and sprintf text messages. A number of others transmit little endian integers around. And others still use a blocking style request->response form of communication.

Good network programming is really hard, and unless you take the effort to design and implement something robust from the start, this kind of ad-hoc, inflexible networking will become embedded into the application and require significantly more rework later down the road.

And PLEASE reuse something that might fit before even attempting to write your own layer. The gnutella protocol is a great example of this problem.

3. Threading is as simple as using pthreads and mutexes.

TRUTH: Good threading code is difficult to develop and difficult to debug. It is always preferable to use an event based model where possible, and rely on threads only when you need scalability on SMP, work arounds for blocking system calls (gethostbyname_r), or background tasks that you dont want delaying interaction with a user or network app (there are many other reasons, but these give you the general idea of where threading is appropriate).

Synchronizing access to shared resources between threads is also very tricky. The level of granularity of locking, and the structure of your data structures themselves, will have a significant impact on performance. Too much granularity and you end up with extremely complex locking hierarchies that are difficult to debug, more prone to dead lock. Too little granularity and you get lots of contention for these shared resources.

Finding the sweet spot is tricky, and often requires lots of experience or tuning to get right. The lack of tools to provide visibility to lock contention and latency also make this difficult.

I'm sure there are others, but these are the big ones that come to mind.

Re:A few more I would add

[Fnkmaster]

I've seen these exact same misconceptions occurring all the time in the world of closed source software (well, less so the autoconf/automake problem, usually people know in advance what platforms they are targetting and don't care fuckall about anything else).

In fact, I have seen (3) quite often - people think throwing shitty programmers into a codebase that uses threading is appropriate - ouch. The results are often disastrous, especially when a carefully crafted set of mutexes and locks gets fucked with and rearranged by somebody who doesn't really understand the codebase resulting in all sorts of intermittent failure madness.

Re:A few more I would add

[Anonymous Coward]

While I happily use autoconf, I don't trust automake because it produces makefiles which require GNU make. Now, due to widespread use of automake, GNU make is pretty much required in most installations (even proprietary *nixes), it generally must be explicitly invoked (as gmake, for example), as the primary, system-specific make takes precedence (except on Linux, where the only make is GNU make). Also, if the makefile wasn't written to use $(MAKE), submakes will invoke the wrong command. I only write POSIX-compliant makefiles, which is a real pain.

I often wish autoconf had more exhaustive documentation, or at least a pointer to some documentation, where you could learn what calls are fairly non-portable. As it is, figuring out what calls are portable or non-portable requires a lot of guesswork and scanning of man pages. Sometimes the information isn't available, unless you want to search and interpret the POSIX standard yourself.

My current approach is not to make something autoconf-friendly until it's proven not to work. Retroactive system portability. I think it's an approach that makes the most sense.

Network programming: the truth of the matter is, network programming is easy. It's just that a lot of people with no idea of the differences are using that easy-ness to enable some really dumb ideas (sprintf()'ing socket descriptors? That's a new one to me). The idea behind inetd (mapping stdio to sockets) is a triumph of practicality over robustness. Oddly enough, it works, at least for the little things.

Fact of the matter, network programming often needs to be idiosyncratic, simply because network technology is at a point similar to the days when people had to program in assembly language, or at best, C. When we've got 0 ms latency connections with infinite bandwidth around the world, then we can have a general purpose network communication system that will work for every application (OK, we'll probably have it before then, but whatever).

Efforts like the BEEP protocol (or is it BXXP, I don't remember) and SOAP, XML-RPC, and the like are the wrong hammer for problems like multiplayer gaming, video streaming, and distributed computing, at least at this point.

I wrote my own RPC-style protocol from the ground-up precisely for this reason. I suppose that might be an example of writing a robust networking layer so I won't have to deal with it later, but it is reinventing the wheel, and let me tell you, I didn't like doing it, but it wasn't rocket science.

Pthreads + mutexes: I personally think this is a bankrupt approach if you really need any sort of multilevel locking. Eventually, you'll end up deadlocking yourself, and it'll probably happen at the worst possible time. Better get a system which handles the multiple locks in a way guaranteed to avoid deadlock. One solution I can think off the top of my hat is a solution which sorts the mutexes by memory address and then uses two phase locking. However, it has a lot of downsides that you'd probably want to solve.

The fact that the tools aren't there is probably an argument for making the tools.

Not a myth, just a partial truth

[macrealist]

It's more like copyrights are an overbearing government regulation

I think you mean copyright abuse and special interest controlled overbearing government regulation. Copyrights and government regulations are a very important check and balance in the modern "free" market economy.

According to my Oxford Desk Dictionary

communism n. 1 political theory advocating public ownership of property.

I'd say that is not to far off of what SOME open source licences are about (GPL). The problem with calling something communist in the USA is that there is decades of hatred associated with that single concept. So even if it is a comparsion based in fact, biases against communism prevent an unbiased view of the analogy.

The "Myth" that all open source is communist is very similar to the "Myth" that the only open source licence is the GPL.

Re:Not a myth, just a partial truth

[aborchers]

# According to my Oxford Desk Dictionary communism n. 1 political theory advocating public ownership of property.

I'd say that is not to far off of what SOME open source licences are about (GPL).

Re:Not a myth, just a partial truth

[JWW]

But when I run linux, my copy is mine, its not public.

Thats where the magic lies and where businesses should catch on. You can use linux as much as you want without having to pay for or share it. Companies can use linux as a inexpensive platform to develop on top of and not have that platform controlled by anyone but themseleves. Only by changing GPL code do they have to contribute back to the public. Using and working on top of that code is completely private and completely free in all senses of the word.

Re:Not a myth, just a partial truth

[argoff]

# According to my Oxford Desk Dictionary communism n. 1 political theory advocating public ownership of property.

You're right about commnisim being a loaded word. I prefer to call it Marxisim which I take to mean a system of government that can decide your carrer, where you live, what property you hold, what you can do with the capital and resources you have, and even what religion is best for you.

Clearly, open source software is not that way at all. I resent the implication.

At the same time, people say that Open Source, specifically the GPL is not true to free market principals. I disagree, I think copyrights are not true to free market principals and the GPL is a way to fight that. Clearly if the the government so tightly regluated the supply and demand of commodoties in any other sector - people would rightly say they are intefering with the market place. But, thats exactly what they do in reguards to copyrighted information. Information has few natural limits in supply now, but services dont - getting rid of copyrights would shift things back more to the service side.

If we said that the first farmer who grows oranges has a right to lock out everybody else who does, and sell shares of those rights. People would see it as the controll it is. Does the farmer have no incentive to plant those first oranges if someone else can too?

Re:Not a myth, just a partial truth

[macrealist]

Don't confuse free market and Capitalism.

We live in al capitalistic world, and capitalism pays a premium to those that have the capital. Copyrights are very much capitalistic.

Free market is the balance of the buyer and seller's value of a thing/service to determine the price without external influence.

The GPL effects the free market (why would a buyer pay $$$$ for a app that is free?), but doesn't effect its principals.

Comparing Copyright vs GPL is more like comparing capitalism vs "a economic theory that gives no benefit to innovators", and this is NOT how I intended the word communism to be used.

But why resent the implication? If "possesion" is 9/10s of the law, then look at the similarities:

communism - theory advocating public ownership of source code

GPLism - theory advocating public right of posession of source code

on the subject of development frameworks

[BillsPetMonkey]

Myth: It's better to provide a framework for lots of people to solve lots of problems than to solve only one problem well.

I won't mention Microsoft's is the only widely distributed development 'Framework' there is. Then again if it's really as nebulous and unuseable as the slashbots think, why has it already been ported to BSD and Linux in it's original form and ::mono:: respectively already ...

Re:on the subject of development frameworks

[lanalyst]

the context of framework used in the article is beyond development tools.. think nagios, eclipse, xchat, gaim, xmms, etc.. an api that can be extended easily.

Re:on the subject of development frameworks

[radish]

*cough* J2EE */cough*

Re:on the subject of development frameworks

[BillsPetMonkey]

"J2EE is a triumph of interoperability over productivity. The .net framework is the triumph of productivity over interoperability."

I've no idea where I heard this, but it's the truest thing I've heard yet about the competing platforms.

BTW, Visual Studio.net is the dev IDE for .net, Eclipse is the dev IDE for J2EE - the difference is that one is free and open the other isn't. That doesn't mean one is better for making programs than the other though.

Re:on the subject of development frameworks

[radish]

Firstly, I wasn't trying to make any statments of the merits of one framework over any other, simply pointing out the parent's absurd remark that .NET was the only framework in town. J2EE predates it by some years, and there are others too.

As for IDEs (what has this got to do with anything anyway??) Eclipse is an IDE for J2EE - there are many, many others. You can go commercial if you want (IntelliJ is my personal fave, or JBuilder, or BEA Studio etc). If you want to use .NET you give MS a bundle of cash. End of story - there is no choice. I like choice.

But again, it seems a random comment for you to make in the first place.

Re:on the subject of development frameworks

[BillsPetMonkey]

Hehe. I didn't think you were making comments on the relative merits. You mentioned J2EE - a .NET competing product so I compared them in a soundbite.

The Eclipse bit was to address the other poster who mentioned it (why I've no idea).

Why Sad?

[Srin Tuar]

Sadly, I think this is what most people think of when they think of open source.

Why is that sad?

I think its appropriate that people look to the best of breed among Open Source, Free, and even proprietary software licenses.

Re:Why Sad?

[eparusel]

You feel it is best of breed.

However, many others do not.

Re:Why Sad?

[Anonymous Coward]

So you mean the BSD license?

Re:Why Sad?

[swillden]

What's better?

I'm considering releasing another litle app that I've built, and I'll probably default to GPL, but what's better? And how is it better? Note that I am not interested in giving away my software under a license that allows it to be closed by someone else.

Re:Why Sad?

[Pieroxy]

The problem with the GPL is that it makes any modification automatically GPL. It's a blessing when another open-source project uses your code. It's a problem for the closed-source company that wants to use your library.

If it was on a BSD-style license, some closed-source companies would consider using it. Of course, they wouldn't be constrained to give you back their changes, but that doesn't mean they would not do it. See, most of the developers out there are working for closed-source companies. If you want a broad distribution, it can be helpful relying on them too.

One question I don't know the answer to: Has Apple given back *anything* to the *BSD community?

Re:Why Sad?

[Unordained]

i was fairly sure i remembered that libraries were such that closed-source products could use GPL libraries, so long as they dynamically-linked to them. i'm sure someone will come along to quote us the GPL relevant to this section -- i don't care enough. i've got proprietary bugs to go swat. damn proprietary bugs.

Re:Why Sad?

[Pieroxy]

There is another "GPL" license for libraries that take care of this problem: The L-GPL. AFAIK, GPL libraries would make your product GPL, not L-GPL libraries.

Re:Why Sad?

[JonMartin]

I'm considering releasing another litle app that I've built, and I'll probably default to GPL, but what's better? And how is it better? Note that I am not interested in giving away my software under a license that allows it to be closed by someone else.

This should have been at the top of the myth list: If I don't use the GPL someone will come along and STEAL MY CODE!

Engage your brain for a second. No one can steal or "close" your code. Unless they delete every copy in the world and erase your memory.

Personally I prefer the BSD license. All it says is:

"I wrote this. Feel free to use and distribute it as you wish. I make no guarantees about its quality and am not responsible for how it is used. You cannot remove this notice."

It allows a much wider group of people to use my code. Isn't that the ultimate goal of releasing your code? To get as many people as possible to use your code instead of wasting time reinventing the wheel?

Re:Why Sad?

[syrinx]

Why is that sad?

I think its appropriate that people look to the best of breed among Open Source, Free, and even proprietary software licenses.

Excactly, so why would they look to the GPL?

Re:Why Sad?

[Anonymous Coward]

Note that I am not interested in giving away my software under a license that allows it to be closed by someone else.

Then you want to apply the GPL shackes to it. Period.

Re:Why Sad?

[Anonymous Coward]

It's a problem for the closed-source company that wants to use your library.

Well, they can go fuck themselves.

Re:Why Sad?

[Anonymous Coward]

This should have been at the top of the myth list: If I don't use the GPL someone will come along and STEAL MY CODE!

Well they will try to. Why else do you think Microsoft denounces GPL at every opportunity but not the BSD or the other licenses?

This may not matter for small stuff, but do you think companies will go ahead and develop something big when they can get it for free, and also don't have to tell anybody?

Re:Why Sad?

[DunbarTheInept]

If it was on a BSD-style license, some closed-source companies would consider using it.

That's not a good thing, because in the minds of the users, the credit doesn't end up going where it belongs. Look at how many ignoramuses credit Microsoft with the explosion of the internet, as opposed to UNIX, when Microsoft didn't become truly useful for internet work until after it scrapped it's own garbagy network protocols and instead started building off the BSD networking code.

Re:Why Sad?

[DunbarTheInept]

To get as many people as possible to use your code instead of wasting time reinventing the wheel?

For many people, it's to *share* their code, not just *give* their code. And sharing is a two-way street.

Re:Why Sad?

[eht]

Yes, Apple has given back Darwin

and from the Darwin FAQ we find the following

Q. Why did Apple decide to share all of its modifications with the BSD community?

A. Although the BSD licenses don't require companies to post their sources, divergent code bases are very hard to maintain. We believe that the open source model is the most effective form of development for certain types of software. By pooling our expertise with the open source development community, we expect to improve the quality, performance, and feature set of our software. In addition, we realize that many developers enjoy working with open source software, and we want to give them the opportunity to use that kind of environment while they're creating solutions for Apple customers.

Although many people think that the rather simple BSD license does little to protect the openness of the code, it has contributed significantly to Apple's ability to adapt the code for the benefit of Mac users. Its emphasis on sharing code has also heightened our own commitment to the open development process.

Re:Why Sad?

[Paradise Pete]

This one is pretty good.

Re:Why Sad?

[IM6100]

Note that I am not interested in giving away my software under a license that allows it to be closed by someone else.

How would they close it? They'd come over to your house with a gun and say 'you now have to close the source for your project?'

Or are you fearful that someone would make part of it better than it is, and by not releasing the source for their changes people wouldn't want to use your open version anymore? That seems selfish to me.

The way people use this as an excuse just doesn't wash. The BSD licensed OSes haven't disappeared in a puff of greasy smoke due to some vampirous closed source vendor grabbing the code and running.

Re:Why Sad?

[IM6100]

and also don't have to tell anybody?

Now you're spreading myths about the BSD license. They have to give credit where credit is due. Sure, Microsoft isn't going to make it a big announcement on their home page. It's up to the original authors to point out that Microsoft credits them, which Microsoft does in the documentation where it's supposed to appear.

I would say having something credited to one in the 'about' window of a Microsoft product counts for something (outside the sneering communties, of course)

Re:Why Sad?

[Anonymous Coward]

Let's see. I'll go look. Nope, I can't find many credits to 'Anonymous Coward' in Open Source project contributor lists.

So you're just adding to the noise, eh?

Then I can too. (clicks on Post Anonymously)

Re:Why Sad?

[IM6100]

So Apple contributes back to what is essentially a dead-end source tree (Darwin). Or are there people in the FreeBSD project regularly backporting Darwin code improvements back into the main FreeBSD source tree? I'd be happy to learn there are. Otherwise, let's not make Darwin into anything more than a Potemkin village, okay? It's mostly just another mkLinux (the 'Linux' from Apple that they used to 'chemically remove the itch' and keep 'scratch the itch' hackers from aggressively reverse engineering Apple technology in earlier Mac hardware/software)

Re:Why Sad?

[IM6100]

I have seen 'share' used by the Slashdot community far too many times where it means 'rip the CD and pass the MP3 around widely' for me to take you very seriously here. You have to use the language of this community the way it's defined by this community, if you want to be taken seriously. (no, actually, you have to softpedal and be a hypocrite, which is why this comment is gonna be modded down)

Re:Why Sad?

[tigga]

there is an effort to port msdos FS code from Darwin to FreeBSD.

Re:Why Sad?

[tigga]

For many people, it's to *share* their code, not just *give* their code. And sharing is a two-way street.

O, common - it's like kindergarten - "If I share my doughnut with you would you share your candies with me?"

Re:Why Sad?

[Anonymous Coward]

I have seen 'share' used by the Slashdot community far too many times where it means 'rip the CD and pass the MP3 around widely' for me to take you very seriously here.

Hey, if Britney wants an MP3 of me singing, she's welcome to it. Share and share alike, right?

Re:Why Sad?

[Anonymous Coward]

The BSD licensed OSes haven't disappeared in a puff of greasy smoke due to some vampirous closed source vendor grabbing the code and running.

But... but... but there's BSD code in Windows! Isn't that nearly as bad?

Re:Why Sad?

[IM6100]

Naw. The BSD code in Windows is good stuff. The Interix code, if you purchase Interix, is better, though. You even get GCC (from Microsoft!) if you purchase the Interix package. Not sure if MS still sells it, though. They've tried to absorb it and they deballed it considerably when they bought it from Softway Systems.

Re:Why Sad?

[swillden]

It's a problem for the closed-source company that wants to use your library.

That's not a problem for me. I like that.

Re:Why Sad?

[shaitand]

No

There are two reasons to release my code:

1. to make my product more valuable to my customers.

2. Because I don't want payment in cash, I want it in code. If you use it, I want payment, I want your code back.

Actually I find there is one major clause missing from the gpl. As it is, the original developer would have to buy a copy or otherwise aquire a binary to be entitled to the modifications of his own source. If the modified app isn't distributed at all that is one thing, but I should hardly have to buy a linksys router if it was MY code linksys modified to use in the firmware. If they used my code, I should be entitled to those modifications.

Re:Why Sad?

[shaitand]

Actually it's supposed to appear on the screen, in a prominent position. Not buried anywhere. If they have integrated it into the underlying system then this means it should be displayed as part of the windows boot process since that is when the code is initialized.

At least that was pretty much the way it was when I last read the BSD license (which was admittedly awhile ago). I might have the details mixed up, but it was stressed that the credit must be made bold and prominent and couldn't be buried somewhere (like say the registry or the docs).

Re:Why Sad?

[Pieroxy]

I might very well be a problem for you. The less people use a given OSS, say MySoft, the less feedback they have. That result in less QA, less features, and a generally crappier product.

We've got to stop picturing all closed source companies as our enemies if we want OSS to grow and expand. There is no reason the two world could not collaborate to a certain point. As a matter of fact, they already do: OS-X is a derivative of FreeBSD to some extent. That would not have been possible with Linux, obviously.

Re:Why Sad?

[swillden]

Look, it's my code, I can do with it what I want to, I stated my criteria and asked if there were any better licenses that the GPL. Why is everyone trying to convince me that what I want to do with my own property is wrong? I don't *have* to give it to *anyone*!

Re:Why Sad?

[swillden]

No one can steal or "close" your code. Unless they delete every copy in the world and erase your memory.

Of course not. What they can do, however (not that anyone is likely to want to, but that's a separate issue) is take my code, enhance it and close the result. If they're going to distribute my code, I want to to have a chance to see it.

If they don't like that, they don't have to use my code.

I thought I made clear what my criteria were, why are you trying to convince me that I'm wrong?

Re:Why Sad?

[swillden]

A productive comment!

What's better about the Artistic License?

Re:Why Sad?

[swillden]

We've got to stop picturing all closed source companies as our enemies if we want OSS to grow and expand.

I don't picture closed source companies as enemies. Closed source has paid most of my salary for about fifteen years now. However, I don't necessarily want to give my code to them for free. If they want to use it to make money, they can pay me for it.

As far as the potentially reduced user population, I'm okay with that. I understand the tradeoff.

Re:Why Sad?

[smittyoneeach]

There is the pragmatic view that the internet works because the free BSD TCP/IP stack was there.
This nips at the arguments of the closed-source and GPL crowds, though.

Open source contribs can be much easier

[joelparker]

If you want developers to help your project,
then please make it easier to contribute.

Show us your roadmap for development,
where you want us to contribute time,
and how we can get started helping you.

Make it easy to understand your software,
maybe by creating help files, diagrams,
real examples of how to use your software,
even comparisons to related software.

Source code comments are good;
technical overviews are even better.

Above all, get FEEDBACK from developers
on your source code and your documentation.
Is it clear? easy? How could it be easier?

The more your improve your documentation,
and your process for contributing code,
the more we can help you. Thanks!

Cheers, Joel

Re:Open source contribs can be much easier

[Tony Hoyle]

Diagrams? Technical overviews? Roadmaps?

Hell, not even most commercial software I've worked with has any of these.

It's easy to contribute. You want project X to do Y, you post 'I wish project X would do Y', and a developer either replies 'I'm all over it... next release' or 'Send us the patches & we'll look at them'. If the documentation sucks, post 'I'd like to write some better documentation.. give me a couple of weeks'. If the installer sucks, post 'Here's an innosetup script... enjoy!'.

Most software in the real world grows pretty much organically... roadmaps keep PHB happy but in the real world they're not that useful (where I work we talk loosely about where we want to be but noone has any clue about the detail of that - customer requirements change so fast by the time you documented it it would be wrong anyway).

Re:Open source contribs can be much easier

[scottking]

good suggestions joel, i agree. even if commercial software doesn't have features like this, why shouldn't we try to be better at documenting? set a new standard for developer usability. man if i had points would i mod you (that came out dirtier than expected).

No, just easier to completely discredit yourself

[Anonymous Coward]

Stop rushing. If /.ers stopped for a minute instead of trying to be high on the comments list, there would be more insight and less underthought trash for me to mod down.

Here's what you do

[Anonymous Coward]

List a cool new MP3/Warez/Kazaa-like app on Freshmeat and get people to contribute tons of code. But the trick is - it never was a MP3/Warez/Kazaa-like app in the first place - it was actually a B2B e-business CRM/procurement application! So now all that is left to do is sell it and collect your millions. Hmmm... wait a sec - Ariba already did this.

Programming in General

[Dayze!Confused]

It would seem to me that he is pointing out programming in general and that he's trying to give everybody some of his programming habits and opinions, not mythes.

Bug fixes, CVS and other things are just some benefits that you may experience by using FOSS, but all the benefits are more likely to happen on a larger, more popular project, but any experienced Open Sourcer should know that you can't expect all the benefits all the time, we're none-union.

Sorry, finger slipped...

[aborchers]

... as I was quoting you. The rest of my comment was to be:

Where in the GPL does it give public ownership to the code? The code's ownership, per copyright, is retained by it's author. GPL simply puts limitations on its modification and redistribution.

Not my experience

[soccerisgod]

I've made two little patches, one for the kernel and one for a user space application. Both were't really that significant at all, but I got feedback for both of them with suggestions...

Ooh ooh, I have some answers.

[Anonymous Coward]

When was the last time you reported a bug?

About a week ago. The fix was so trivial and suggested itself easily, so I didn't have to tell the author how to fix it.

When was the last time you tried to fix a bug?

A couple of weeks ago, if you don't count the above question. And not only did I try, I succeeded!

When was the last time you produced a patch?

Same as the last question.

When was the last time you told a developer how her work solved your problem?

Again, within the last week or two (I generally compliment the program whose bugs I'm fixing, because I obviously like it enough to go digging through the source). I also have, on a number of occassions, let authors know how much I like software they've written. It's the least I can do.

Flamebait??

[rscrawford]

Aw, come on. That was FUNNY!

Comments-Queries

[Anonymous Coward]

"Myth 3: Reading code

I've tried to read large bodies of code before. It's damn hard, even if it is documented. And when it isn't documented, your beginning developers don't have a chance."

Does tools like UML help with this?

"Myth 5: Start from scratch

Don't start from scratch if the code isn't clean. Make new code clean, and go back to clean up existing code. Make sure you have those regression tests ready."

What tools does Linux have for creating regression tests?

"Myth 4: Packaging

Um...duh? Of course it needs to be properly packaged. And dependency lists? If someone can't get it to compile, they definitely won't use it."

Debian and Gentoo does this well. I'm not certain how the others compare.

Re:Comments-Queries

[aridhol]

Does tools like UML help with this?

UML is a design system. It can be used to document the application; however, the point was that code is difficult to understand without documentation. Since UML would be the missing documentation, its use would invalidate the myth.

What tools does Linux have for creating regression tests?

I use dejagnu when I'm coding C, or junit when coding Java. I understand that Perl has a similar framework.

Debian and Gentoo does this well. I'm not certain how the others compare.

But these are distributions. In order to get your software into the distributions, you need to have a following. You won't have a following unless you have some way for your users to get your software; this requires some sort of packaging.

Step one: lose the maillists.

[GeekDork]

Maillists (at least the ones I know) suck for general support and/or sporadic suggestions and feedback. The ones at sourceforge are about unuseable unless you subscribe (I always wanted an eighty-meg mailbox), others get you a bunch of negative answers and a month-long OT-discussion for remarks like "please CC me since I'm not on the list" (debian-user, that's for you!). We live in a time where any bozo can set up a reasonable free forum for the folks who don't really want to get "involved", so use that possibility!

Myth 10: /. posters can read licenses.

[i_r_sensitive]

It's more like copyrights are an overbearing government regulation that locks out the little guy than a true free market

RTFGPL

Nevermind, I'll quote from it for you:

Top of the page:

GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc.

From the Preamble:

We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.

Please practice zealotry for some other product. There are enough Linux zealots in the world who DO understand that copyrights in and of themselves are not 'wrong.' In point of fact the archtypical FOSS licenese not only is copyrighted, but indicates within the preamble that the copyright process is invaluable to protecting both the user and author's rights to the code.

Zealotry is a big enough problem in our community without its being accompanied by ignorance and bombast. Please either take the two seconds required to verify the facts behind the slogans you want to shout, or become a zealot for some other cause.

Yeah, it's a troll, mod me down, my karma can take it.

Was Re:Myth 9? - Myth 10...

[Anonymous Coward]

...is that there are no open source repositories for other platforms. There are many others.

OSS == Service Business Model ( != Communist)

[mik]

IMO, OSS is essentially a movement to shift the software industry from a product/sales business model to a service/support business model... nothing more nothing less.

The old/non-agile industry is upset because they can squeeze more profit from product sales (especially with zero replication cost), than they can from services. This is, of course, a close parallel to the issues behind RIAA, et al. The difference is that the driver here is that OSS software has been freed by the authors, while the music has been "liberated" by the consumers.

Having worked in the service-oriented software development world all my professional life (Contract R&D), this coming status quo doesn't bother me at all.

Re:OSS == Service Business Model ( != Communist)

[IM6100]

You say you've worked in Contract R&D?

Surely someone has written all those contracts with you. Have most of them allowed you to release your work (which they paid for) to their competitors?

I would bet you've signed contracts which don't do that many times in your career.

Contractors are scavengers who thrive on the fringes of society. Nothing wrong with that, they contribute significantly in many instances. But it's ridiculous to claim we can all be scavengers living on the fringes. The fringes of WHAT?

Intent, not legalize

[macrealist]

The intent of the GPL is to provide "access" not ownership, yes.

The knee jerk reaction to the analogy that the GPL is like a communist licence, however, is absurd. It is very obvious that the GPL can not be equated to communism, as communism is a economic/political theory and the GPL is a software licence, but the intent in both is the benefit to all by the sharing of all.

If someone were to compare the GPL to Capitalism, Feudilism, Socialism, or an other economic/social "ism", the reaction of GPLites would not be so quick and forceful. The comparision would also not be very accurate.

Forget for a second your preconceptions about communism and try and accept the GPL / Communism analogy. Its not a perfect analogy, but it is a pretty good one. And not worthy of its own myth

Re:Intent, not legalize

[aborchers]

My reply wasn't based on my preconceptions about communism, which are not as negative as you might assume, but on the definition you cited. Sharing and ownership are conceptually distinct, especially in the context of an intellectual property right. We are taught in preschool that it's good to share, but we are not taught that all the toys are collectively owned.

So, you say that the GPL is "not too far off" from communism, but I'd say its very far off. The notion of a public domain, strong in our "capitalist" U.S. tradition, is much more communistic than the GPL, which is rooted absolutely in the right of the creator to set the terms for use of the work.

I concede your point about intent. Perhaps a shared altruism is at the root of communism and GPL, but it is interesting that good old greedy Western capitalist IP protections are the mechanism by which the latter must be exercised.

Re:Intent, not legalize

[shaitand]

The US public domain is not something the US invented or adopted or does not exist in everywhere in the world. Public domain is the default, the natural order of things.

Ownership by the individual is the made up concept. By default ideals and objects are posessed by those able to obtain them and only so long as they are able to keep them, and by default the ability and right to copy is also limited only by someone elses ability to stop you. This is neither wrong nor evil, it is the natural law.

Re:Intent, not legalize

[aborchers]

???

And here is the definition of non sequitur.

Can you explain to me how anything in your post is relevant or responsive to the prior thread?

Re:Intent, not legalize

[shaitand]

"The notion of a public domain, strong in our "capitalist" U.S. tradition, is much more communistic than the GPL"

I was pointing out that public domain is not the product of any system of economics, capitalist or otherwise.

Re:Intent, not legalize

[aborchers]

Ah, I see. Thanks for clearing that up.

The point of my post was that the public domain enjoys significant status/respect in the U.S. system. I didn't mean to imply it was created here or anywhere else, or that it was necessarily connected to any economic theory, only that the collective ownership concept in the idea of a public domain has more in common with communism than the GPL*, which was suggested by the original poster.

* = which mandates sharing but does not generalize ownership.

For the LAZY ones (Myths List)-Horizon line.

[Anonymous Coward]

"For explanations of each RTFA ;D"

Myth: Slashdotters will read the article.

"Think of your project as your home."

[farnerup]

I wish I could think of my home as my project. Then maybe I could reach the kitchen without mountaineering equipment.

Office User Manual

[Anonymous Coward]

MS Press does print them. And where not talking about a small manual, we are talking about a HUGE collection of books. Granted, they damn sure won't be giving away 7000+ pages of text with a every single user license. If they would have printed complete manuals for every copy of Office they have shipped over the years there wouldn't be many trees left standing in Washington state.
In reality, 95% of the people wouldn't read the manuals if they did ship them with the software. In many cases the help files built into Office are more than enough for most, and get better with every version. There might be an office suite somewhere with better built in documentation, but it's not on this planet.

Naw, you have hours to days before engine siezure.

[teidou]

If the oil light comes on, and you don't stop immediately, you will stop in a very expensive way seconds later.

False.

The oil light in my 1990 trooper used to come on regularly because of low oil pressure. After I while, I quit topping it off, always thinking "I'll take care of it tomorrow." The situation went on for weeks before the engine finally siezed.

Of course, the above is strong evidence that I am an idiot.

Re:Sorry, duder, you missed it by a minute

[stanmann]

Don't worry, we'll get him in meta.

Redundant should rarely be used and only in reference to something in the article or post.

Re:Another myth-Three for the road.

[Anonymous Coward]

stick your fucking troll up your arse. Your cozy little os is probably the one consisting of 90% open source. And you faulty like to call unix.

I DID!

[argoff]

The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users.....

Now why does it say most licences are designed to take away your freedom? If copyrights are truely free market, that shouldn't be the case!

....When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software...

Now why does it say it's referring to freedom and not price. What freedoms were the other licenses taking away? If they are true to free market principals, that shouldn't be the case either.

... To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it....

To me that implies that copyrights can deny rights? Doesn't it to you?

Look, I've even discussed copyrights with RMS personally. Maybe I misunderstood him?, but I doubt it.

Re:I DID!

[MechaStreisand]

The licenses for most software are designed blah blah communist propaganda...

Now why does it say most licences are designed to take away your freedom? If copyrights are truely free market, that shouldn't be the case!

Sir, that statement refers to END USER LICENSE AGREEMENTS. You know, the things that people click through that nobody really agrees to? They aren't real contracts, they're just licenses that the software publishers hope you agree to. But copyright is a different animal altogether.

I don't see how anyone can be against copyright. If people like you and RMS and Linus want to release their software to everyone, under the GPL, that's great. It's a good thing. But forcing EVERYONE to do the same? That roughly is what the end effect of no copyrights would be. What is wrong with you, man?

(By the way, for you mods on crack, the top quote about communist propaganda was a JOKE.)

Re:I DID!

[i_r_sensitive]

The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users.....

There is nothing there about copyrights at all. I agree apparently your problem is not with the reading of the license, but in comprehending it. Nowhere are copyrights specifically mentioned in the quote, nor can any of it be reasonably attributed to copyrights. In point of fact, it is comparing and contrasting the GPL to other licenses. The fact that both the GPL and the other licenses rely on copyright law to be enforceable is subsumed as common knowledge. Besides as an author, you have allready been explicitly advised within the preamble to copyright your work. Your diatribe about copyrights not being truly freemarket is so puerile as to not merit discussion. However, since you plainly cannot interpret the text of the GPL, I'll help you out. Copyrights are there to enforce an author or inventors rights to dispose of their original creations as they so choose. It is a cornerstone of the market in the US. Nowehere does that imply that by copyrighting your work that you are not allowed to distribute it under the GPL, and to require that all the provisions of the GPL be honored by the users of the software. In fact copyright law is the active mechanism of protection, after all it is the body of law which guarantees an inventor or author the right to dispose of their work as they see fit. In fact, by supposing that you have some freedom to distribute and change the property of others the GPL is deliberately stating a falsehood. There is no such freedom, the freedoms youa re entitled to with any software product are those reserved for you in the license. To pretend that by not offering unlimited rights to distriubte and modify someone elses property, without their consent, the GPL is misleading users and developers alike. The fact that the GPL is itself copyrighted, and that it makes the deliberate suggestion to authors to copyright their work gives the lie to this assertion.

....When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software..

Same deal, nothing in this quote specifically mentions copyrights. In point of fact, they are again contrasting the GPL and other licenses. In point of fact, the other licenses are not taking away anything you had a right to in the first place. As the copyright holder, they too are entitled to dispose of their property as they see fit, and they can introduce whatever conditions they wish. Likewise, when you copyright your code, you are granted the same rights, if you choose to release such code under the GPL, you are engaging in the same activity, placing conditions upon the use of your code. In fact, by opposing copyrights you are in favor of abridging the rights of authors and inventors to dispose of their work as they see fit. Period.

... To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it...

Again, no mention of copyright, no villification of the copyright process, nothing to support your position. Your assertion that the above statement implies copyrights can deny rights is absurd, deny what rights? Your supposed rights to tell other authors and inventors what they must do with their work? You certainly are entitled to that facile opinion, but by doing so you seek to abridge their rights.

Look at the statement itself for pity's sake. Does it not specifically state that it makes restrictions? But, according to you, copyrights ar

Umm......

[mindstrm]

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)

Re:Umm......

[ComputerSlicer23]

http://www.softpanorama.org/People/Cox/index.shtml #Biography%20Notes

According to that link, Alan has a BSc in CS. Linus Torvalds has a Bachealors degree in CS, and an honorary Ph.d from the same school in Finland. I'm too lazy to dig up links for that. It's in several of the books about his life.

Kirby

Open source contribs can be much easier-Plugs.

[Anonymous Coward]

I pointed this out months ago. The scriptable, pluggable, modular nature of OSS makes it easier for people to jump into OSS.

Myth of OSS

[BigJimSlade]

There is rarely a "3: Profit!"

Feature freezes help stability?

[dominator]

While I'm agreed that the best way to write good software is to not introduce bugs in the first place, I don't believe that this is an entirely avoidable problem.

There are certain types of necessary changes that inherently destabilize a codebase no matter how careful you've been. It's inevitable. Oftentimes, things like this are checked in to amortize the cost of producing, fixing, and improving said code. There are the unforseen interactions that your new subsystem has, that none of the regression or unit tests have picked up. I know - "write more/better tests" is a better solution. But omnipotence is an impossible goal.

To continue the author's "home" anology, relasing software is like preparing a meal. The pots and spoons simply must get dirty when you're cooking. Many try to "clean as you go," but at the end, you're still left with your dirty casserole dish. You can either choose to clean things up before your guests get there (feature freeze), or you can leave the dirty dishes lying on the counter for all to see.

I might be inclined to say that the shorter the feature freeze, the better. But I don't have any evidence to back this up - nor does Chromatic cite any evidence (except antecdoctal) to support or detract this claim. Maybe people by nature are better at fixing a slew of bugs at once. Maybe not.

Freezes, milestones (alpha, beta) and the like are inevitable parts of producing quality software fit for public consumption, short of "papal infallibility." We're only human.

Dom

Re:Feature freezes help stability?

[chromatic]

I wish I had the time and resources to do that kind of study... but I'm afraid anecdotal evidence is all I'll ever get.

I see two drawbacks to feature freezes.

The only way to get widespread testing of and feedback on open source software is to get it into the hands of users. Linus kinda has this right, as he knows that 2.6.0 isn't the be-all end-all of the 2.6 family, but people will start to migrate to it in droves because of the name. The first problem with a feature freeze is that it actually delays this adoption! Sure, you'll get more feedback than if you released completely unstable snapshots, but the label "stable release" is powerful magic.

The second problem is that every open source project has finite resources. A feature freeze means either splitting development into bugfixes and new development. If you have the resources to pay people to stabilize things (like the Mozilla Foundation or Ximian do), that may not be so bad. If you don't have those resources, you'll have to hope that your regular contributors will actually fix bugs instead of writing new features.

The longer the feature freeze, the worse it gets. The longer you delay new features entering the tree, the more time before you can get feedback on them and the less stable they may be. The Linux kernel went into feature freeze for 2.6 in October 2002! At some point, the pressure to add nice new features is too great.

I do think it's a good idea to give people a few days or a couple of weeks (depending on the size of the project) to find and fix showstoppers and to add polish, but given the drawbacks, I think developers ought to focus their quality assurance efforts much earlier in the process.

As always, I could be wrong. I do think the concept of quick feedback is incredibly important, though.

This one is way off for many reasons

[Anonymous Coward]

>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?

This is so untrue its not funny, what would be the point of praticing and learning if the next time around you were sure to do things as badly.

I've worked on a payment system previously written by someone else and the mistakes that were made by the core developper of this project as well as my mistakes are not repeated in this new payment system for this other company Im working for.

Its called evolution!!!

also there's that misundertanding that coders are supposed to be good at expressing themselves, for instance to document their code.

The skillset needed to be a good coder is very different from the skillset to be a good documenter.

if that wasnt the case, coders wouldnt have a hard time picking up chicks no?

also on a more general view of this article, one has to understand that we dont all work for oreilly's and contributors of opensource project dont have 100 hours a week to give to their project.

I work 50 hours for money, the amount of time I give to OSS dev. is much less. So for me to get involved to the point where I can actually contribute meanfully to a project is longer.

This article is de-motivating and elitist, I say to chromatic: "Give me your salary and time and I'll code for OSS only"

Re:This one is way off for many reasons

[Anonymous Coward]

It says "undocumented" not "well documented". If you need years of experience to know you need to document your code at all then you shouldn't be working on a highly visible public source project in the first place.

"I've worked on a payment system previously written by someone else and the mistakes that were made by the core developper of this project as well as my mistakes are not repeated in this new payment system for this other company Im working for."

Ok, how does this relate to the author's point? You got stuck with a mess someone else left. The article's issue is mainly with your predicessor, not you.

"the amount of time I give to OSS dev. is much less"

Work on small projects then or help debug.

"if that wasnt the case, coders wouldnt have a hard time picking up chicks no?"

I really hope you don't speak in software documenteaze to girls.

Re:This one is way off for many reasons

[Anonymous Coward]

"Ok, how does this relate to the author's point? You got stuck with a mess someone else left. The article's issue is mainly with your predicessor, not you."

Well if I can learn from someone else's mistakes I can learn from mine cant I?

On the documentation, the only places I've worked at with well-documented software that was developped at a fairly fast pace was when someone was in charge of the doc and only the doc

"Work on small projects then or help debug."

I do that already and I've built my own projects, that wasnt my point.

All I was trying to say is that if youre going to "release soon and release often" without many hours to put in the project, things wont be perfect on every release.

Re:This one is way off for many reasons

[chromatic]

Your project doesn't have to be perfect at every release. It should get better with every release though. I'm not convinced that enough developers are asking "Hey, how can we do this better next time?" and are following through. That's all.

Accessibility...

[polyp2000]

As Linux and Other Open Source software get used more and more by less tech savvy users, eg non-programmer types, as a percentage of the community contributions will seem to decline.

I think most people, tech savvy ,or not. appreciate the work that has gone into the free software that they use from day to day. When was the last time you took stock of just how incredible that linux box with its flashy gui you are using is when you consider that it has been bought to you by the hard work of the OS community.

I think people need to find their niche, as to what they can and can't do in order to contribute. Many people think because they are not a hard-core coder they cant do anything to help. I've only contributed to a couple of things since I've been using Open Source stuff.(the past 4yrs) But when I do fix a bug or create something a project might find useful I usually send any files or useful info over to the project maintainers. It is the least I can do when I owe my redmond-free world to so many dedicated geeks!

I wonder just how many regular Open Source users feel that if they could, they would help, but maybe dont know how.

I would say project maintainers should encourage people to help out in other ways, There are loads of things people can do. Artwork, Documentation, Website maintennance heck , even give free support to people if they are nice enough.

I've been helping a few newbies through their first forays into linux, as indeed friends helped me when I got started. If you plant the right seeds in those newbie minds, they most certainly will grow a giving and generous attitude.

There is one more way people can support Open Source.. Lets introduce a "Send your favorite project A Beer Day" send em some beer money!

Nick !

Comment removed

[account_deleted]

Comment removed based on user account deletion

Ahem. It's called up2date or yum.

[Ayanami Rei]

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.

Re:Ahem. It's called up2date or yum.

[shaitand]

umm or you could just install APT on your rpm based distribution to do the exact same thing as those other tools, as well or better, and not have to fight with them at all?

Header files are a contentious issue

[Anonymous Coward]

Whether including header files constitutes copying isnt a cut and dry issue ... assuming it doesnt then yes the GPL is irrelevant EXCEPT if you distribute the library together with the application (if you do that the application has to be GPL too).

If you want to use the GPL, and if you can live with the inability for non GPL apps to ship your library together with the app, you should probably dual license the header files to remove ambiguity (under GPL and under a disclaimer only type license such as BSD).

One word:

[M. Baranczak]

APT

No one does CAD in their spare time.

[Ayanami Rei]

It's not like they can cheaply do something with their results either. So what's the motivation for an open source programmer (aside from pure thrill working on something very complicated).

Re:No one does CAD in their spare time.

[IM6100]

The open source CAD community will just have to sit and wait for a worthwhile CAD vendor to die and 'open source' their code base. That proved to be necessary in the case of OpenOffice and it proved to be the case with Mozilla (even though the original carcass was ditched eventually). Those are two of the 'open source' flagship projects, incidentally.

Re:No one does CAD in their spare time.

[Anonymous Coward]

Excuse my ignorance, but what died and allowed open office to be spawned?

Re:No one does CAD in their spare time.

[rowanxmas]

Opensource does not mean free. His company could give hime the source, let him fix it if he wants to, and he would probably sign an NDA to do it.

Re:No one does CAD in their spare time.

[IM6100]

The Star Division. The people in Germany who wrote Star Office, a closed source product, before Sun Microsystems bought it and 'open sourced' it, as the new verb goes.

Re:No one does CAD in their spare time.

[LWATCDR]

I do not expect to see any great 3D CAD OSS anytime so. The PS was more to disarm the "Well that is what you get for using EVIL closed source software!" posts.
I do want a good 3d cad program that runs under Linux and supports the AMD64bit chips. And yes I will pay for it.

Re:No one does CAD in their spare time.

[LWATCDR]

Open office and Mozilla? Never heard of them :)
Actually I tend to use Firebird for my browser and Thunderbird for my mail client. Other OSS I use all the time are.
Eclipse
NetBeans
Postgres
GCC
PHP
Perl
MySql
and Open Office. We are using Open office all through the company since it is very good and free. Open source does provide some very good solutions. The reality is that it does not fill every nich. I am not fond of my CAD vendor right now but then it was a "Cheap" package. Only around $900.

Re:No one does CAD in their spare time.

[shaitand]

Open source means free (as in speech) source code, an NDA is NOT free as in speech OR as in beer. That would not qualify as open source.

Re:No one does CAD in their spare time.

[rowanxmas]

no, FreeSoftware means free. OpenSource does not imply open to all.

Re:No one does CAD in their spare time.

[shaitand]

yes, they have a term for source code which is open to a closed set of developers silenced by NDA's. Closed Source.

Open source means EVERYONE being able to manipulate and use the source code AND excercise their free speech rights and express knowledge contained therein. By your definition microsoft's shared source initiative would have qualified as open source!

Hell giving portions of the source code to extremely high profile customers for review and even modification is not unusual in the closed source world at all. Microsoft does it all the time.

Re:No one does CAD in their spare time.

[rowanxmas]

Under the GPL you only have to release code to someone if they buy your product. RedHat has spolied us. So, one you have the code you can keep releasing it yourself, but someone had to pay at some time. But it is still OpenSource just not really "free".

Re:No one does CAD in their spare time.

[shaitand]

No nobody has to buy anything. You must give the source upon request to anyone you give a binary to, whether they paid for said binary or not.

Either way, they then have the right distribute the code once they have it on the same terms which is what makes it open source. They don't merely have the ability to view the source. They can modify it and compile their own binaries without waiting for te vendor or without even telling the vendor. Or one person could get the binary (by paying if you will) request the source and distribute it freely to anyone and everyone who has not purchased the binary.

Myth: You can't sell open-source software

[bigberk]

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.

Throwing away code?

[dominator]

Throwing away code blindly is a mistake, especially if it is working code. Then again, keeping crufty, bad code around is an equally large mistake. The larger point that Chromatic misses is that making uninformed code decisions is playing Russian Roulette. Throwing away code (or keeping code around) is only a mistake when one has no concrete rationale for doing so.

The important part is to have a good understanding of the problem scope, previous attempts (if any) at solving the problem, and what their advantages and drawbacks are.

You have to remember that code doesn't exist for code's sake alone. We write code to solve problems. Code is a window into how someone solved a problem. And not all solutions are created equal.

What is important is to understand the "whys" and "hows" of these previous attempts, and then chart the best course you see toward success. It may well be that the best solution is to scrap another's design. It may be the best solution to build off of another's success. However, it's probably a bad decision to build off of another's failures.

Dom

Re:Throwing away code?

[oo_waratah]

Isn't the point to not create "yet another" anything more than redeveloping bad code.

Re:Throwing away code?

[chromatic]

The main point is not to throw away a working solution without considering the cost of reimplementing all of the parts that work. I consider "does it solve the problem correctly?" to be slightly more important than "is it beautiful?".

Of course, I think that you can do both, but that's me wearing my Test-Driven Development Evangelist hat again, and no one wants that on a Friday night. (I also think that refactoring is usually the right approach -- but it depends on the problem you're trying to solve. Dom and I probably agree far more than it may sound.)

Try again.

[phliar]

int x = 0; // init it, instead of just "int x;"

x; // it's "used" (referenced), but not to do anything

Sorry, not with gcc. For the first line, you get "warning: variable unused" warning either way; for the second, you get "warning: statement with no effect".

Assign a 0 (or NULL) to the variable. Or pass it to a null function. Both are hacks, and a pragma would be nice. (It sometimes happens when you comment out a section of code while debugging, gcc prints an annoying "unused variable" warning.)

Counterpoint to the Framework "Myth"

[DCheesi]

Programs Suck; Frameworks Rule!

Myth: It's better to provide a framework for lots of people to solve lots of problems than to solve only one problem well.

Reality: It's really hard to write a good framework unless you're already using it to solve at least one real problem.

Really-Real-World Reality: Frameworks that are developed in conjunction with one specific project are likely to produce lousy results when used in a different project.

I've seen a number of "generalized" frameworks that came out of one large project, only to wreak havoc when they were forced upon the developers of another project. When people are writing support code for a project, a lot of project-specific design decisions get mistaken for generic architecture because the developers are only looking at it from an insider's perspective.

Re:Counterpoint to the Framework "Myth"

[chromatic]

You might be surprised, but I agree. It usually takes me finding three instances of similar code before I can generalize it correctly.

This article was talking about the open source world, though. There seems to be a penchant for writing frameworks without any projects that actually use them. That's the myth I was trying to address. Extracting a framework from only one project isn't spectacular, but it's much, much better than extracting a framework from zero working projects.

Tsk. Troll.

[Ayanami Rei]

Mod down -1: cutnpaste.

the man with the plan is a new, different person every day, with a new, limited perspective that gets a +5: informative for ambiguity due to being factually unverifiable.

Re:Tsk. Troll.

[kmcg83]

According to some of his old posts, he's Iraeli, Indian, and has no fingers. And he cuts and pastes a lot, too.

Re:Publishing your Code Will Attract Many Skilled.

[Anonymous Coward]

I think that's called a couplet.

Re:Naw, you have hours to days before engine siezu

[Myxorg]

You were very lucky, the oil light came on in my car but I decided to drive the remaining 500 feet or so to my house. I didn't make it. Now I call it the "change engine" light. Light comes on ,time to change the engine.

No

[Anonymous Coward]

There are 2 types of developers who like the GPL, those who agree with RMS ... and those who simply like reciprocity.

Personally I like reciprocity, my goal in releasing anything is to share it with people. Not with as many people as possible though, but people like myself ... that is to say people who arent making money from my code :) If someone wants to use my code he can give me his under the same terms ... if that isnt to his liking he can buy a license off me.

How many times?

[Ayanami Rei]

Never.
Please cite examples. They don't get publicized, that's for sure.
Maybe it's because I don't hang around in IRC channels so I wouldn't hear about these lame proposals anyway.

Re:How many times?

[Anonymous Coward]

Never. Please cite examples.

You're telling me you have never heard of any vapourware? That's quite an impressive record.

Okay... so how about ReactOS? It's going to be a totally free replacement for Windows NT! They've even got a console running now, and like gcc ported to it, and Minesweeper! All that GUI work is going to happen real soon, and it might even have caught up with NT 4.0 by the time Longhorn is released!

(Note: I have nothing against the ReactOS developers, and it's pretty impressive for a toy OS, but really, have you read their timeline? They're anticipating government funding by April next year...)

thousands of applications

[Anonymous Coward]

How many applications are actually used in linux if you exclude all of the ones specifically written to recreate the functionality of existing Solaris/Aix/Ultrix/Sco/SystemV unix functionality?

yep, doesn't bring patches or contributions

[RouterSlayer]

No one has yet contributed to trek7 on sourceforge, its been there for months.

So yes, the myth is true, just making something open source does NOT mean people will flock to it, no matter how good an idea or concept it might be.

I'm still waiting...

Re:yep, doesn't bring patches or contributions

[Anonymous Coward]

I can see why... "ugly old depricated (sic) Fortran code from the 70's???????"

I doubt this project will EVER attract any patches or submissions...

Re:yep, doesn't bring patches or contributions

[RouterSlayer]

that's the whole point.

Convert it to something useful, get it running in a decent language.

Oh, I'm sorry, I guess sometimes I expect too much from coders, I guess it's too much of a challenge :)

heh

But closed-source...

[Anonymous Coward]

... and using closed-source software will get you shafted.

Tell that to the Defense Department.

[Ayanami Rei]

Ass.

Re:Publishing your Code Will Attract Many Skilled.

[schwaang]

This driver's getting fat and beefy,
But my cat is still named Fifi.

This poem supports only cattle and felines. Suggested patch:

+
+ She likes to romp about the house,
+ and chase my USB Intellimouse.

Bollocks!

[schon]

The answer to the (rhetorical) question is simple:

BECAUSE I LEARN FROM MY MISTAKES.

Imagine an art critic saying to a painter: "Your first work is sloppy, so therefore everything you do will be sloppy, and there's no way you can improve."

Generally, the more you do, the better you get.

Re:Bollocks!

[Anonymous Coward]

Yeh, the problem is though, as soon as you get to the end of version 2.0, you realize you need version 3.0. Its the endless cycle of developer pain. Hatred of old work.

Related: Gnome / KDE

[Anonymous Coward]

Any program that requires Gnome or KDE will not be installed on my system.

Just use the GTK/QT lib, not a million other libs that no one has ever heard of.

Re:On portability

[Xtifr]

You can use GCC's attribute system...

And one of the advantages of that (unlike some gcc extensions) is that you can fairly easily make the code still portable:

#ifndef __GCC__
#define __attribute__(x)
#endif

Of course, this way you'll still get the warnings on non-gcc compilers, but so what? Nothing's perfect.

GCC is littered with HUNDREDS of very cool extensions. Just make sure it's worth giving up portability...

Even if you do use non-portable gcc extensions, you're not giving up that much portability. Unless you're still working with 16-bit (or smaller) platforms, you're going to have a hard time finding systems that don't support gcc!

Compiler-independence is much less important when your target compiler is nearly as portable as the language it provides. :)

(Note: I generally avoid gcc extensions myself, unless there's a good reason to use them -- I'm just saying, it's not necessarily a big deal if you do use 'em.)

GPL is restrictive.

[Thinkit3]

From your other writings, I take it you are a libertarian. The problem with the GPL is it forces you to make source available (by way of copyright). This is limiting, just like not being able to copy is limiting.

Re:GPL is restrictive.

[argoff]

Very perceptive, you are right about me being libertarian.

I agree with you in that in a normal world that forcing people to reveal source (even if it was modifications to code they didn't originally make) would be limiting. Of course, in a normal copyright free world, a service based paradigm would emerge and natural interpersonal and market forces would likely compell people to share source or become irrelavent or outcast.

Since we don't live in that normal copyright free world, I suspect the GPL's probably the best we can do immitate it.

Roll your own/adapt exising software?

[herrvinny]

Wouldn't it just be better if the whole thing was rewritten from scratch, or if you could adapt a program already available into what you need? I don't know how f***ed up your system is, but 10,000 lines isn't that much, especially if you take some preexisting code from sourceforge or somewhere and adapt it.

that's a good one

[Anonymous Coward]

The truth is you were a terrible programmer.
I'm surprised that you don't name our clients either. Moron.

Re:Myth: Parrot will run Perl6 eventually

[Anonymous Coward]

This was ontopic.

See also: Kitchen Sink Syndrome, Second System Syndrome.

Sometimes it's better the opposite approach

[Nicolay77]

I usually mark some warnings as errors so that compilations stops when it founds one.

It also runs all regression tests as part of the compilation process. It is not a separate step.

Yes the whole thing takes a minute. But then I am more careful when coding.

Code reuse...

[gillbates]

Solve your real problem first. Generalize after you have working code. Repeat. This kind of reuse is opportunistic...

This is sheer idiocy. If anyone disputes this, I've got some code I'd like to show you...

(Trying not to flame) This guy doesn't know what he's talking about. The proverbial "reinvention of the wheel" is not really reinvention. The problem is that programmers do just what he suggests - rather than think through the problem, and how they can create reusable code, they proceed to cobble together some garbage which solves only the specific problem at hand. Which leads to other programmers having to "reinvent the wheel" because the first programmer didn't make his code reusable!

You can't have it both ways. Either you reinvent the wheel every time, or you write reusable code. It's a discipline, folks - sometimes you have to put forth the extra effort up front to make gains in the long run.

The first three years as a programmer, I must have written at least half a dozen linked list implementations. It wasn't until I had worked on some large projects that I learned that writing reusable code is well worth the extra effort. I was the guy who "just coded the solution". It took me a long time to learn that the more time I spent thinking about the problem, the less time I spent on coding and debugging.

Re:Code reuse...

[oo_waratah]

Firstly, don't write it reuse it. The hard thing is to find a framework that suits or is close to your needs. This is one of the problems he raises.

Secondly, over generalisation makes a project more complex and ultimately doomed to failure because you , as sole developer, just get sick of the project. Why do I say this for the same reasons sited you need a working prototype to bring in developers. I have learnt this to the death of one of my projects.

Certainly write your code according to the rules of good software development by defined interfaces. This should lead to frameworks that can be pulled out easily and reused later. This should not be your focus.

Extreme Programming calls this YAGNI - You aint gonna need it. I don't follow XP but I believe that we as developers should strive to understand all the major development concepts and pick the eyes out of them. Notice how test rigs are also mentioned. These are two concepts I use fairly regularly to stop myself gold plating solutions that do not need it. When the problem exists is when you shoudl solve it.

Re:Code reuse...

[Tony-A]

The proverbial "reinvention of the wheel" is not really reinvention.

The wheel as implemented does not start with a perfect wheel to which assorted stuff is tacked on. The wheel as implemented starts with something cobbled together which bears some resemblance to a wheel, quite possible with no knowledge of wheels. It's only with lots of time and lots of effort that the essence of wheel can emerge from the cobbled togethered messes.

After a half dozen linked list implementations, you probably have a much better understanding of what a linked list is than when you started. For all I know, the attempts at implementation may well be the easiest way to get at that understanding.

There is much that is non-trivial about making a perfect ball bearing.

Re:Code reuse...

[Anonymous Coward]

You can't have it both ways. Either you reinvent the wheel every time, or you write reusable code. It's a discipline, folks - sometimes you have to put forth the extra effort up front to make gains in the long run.

While you do have a point, many developers (and looking at many of the projects in sourceforge, many open source developers) get way too ambitious in their generalization of the problem at hand.

It's nice to have reusable code, but if what you really want is to calculate 3+3 then there are better ways than writing a framework that could calculate that and be reused in many other situations (the equivalent of mathemathica say ;)

The objective is to solve the problem(s) at hand. In many cases where there are many similar problems likely to need solving, it is best to generalize so the solution can be reused, but many other times it's best to actually just solve the specific problem.

Amen!

[djeaux]

As you point out, though, the logic of code reuse was something that came to you after working on some large projects. Hmmm...

Is this correct?
Code reuse = maturity + experience
:-)

I gotta offer that beginning programmers simply don't have a ton of code to reuse unless they avail themselves of open source.

Nice Idea

[Anonymous Coward]

I like the thought process for open source discussed here:

http://www.tyma.com/modules/news/article.php?sto ry id=20

packaging

[rifter]

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.

No, they will quit and then bitch about it on slashdot. :)> Oh the perils!

Re:On portability

[Anonymous Coward]

IMO a nice alternative for doing the unused trick is to do it the other way round, i.e., to have a define that explicitly says UNREF:

#if defined(__GCC__) /* for GCC */
#define UNREF(x) ((void)(x))
#else
... support for other compilers
#endif

and then use UNREF instead of GCC's attributes. This has the nice property that you can do warning suppressions for other compilers and tools (Lint for example).

The same approach naturally works for a variety of different attributes and keywords such as always_inline (e.g., with MSVC you would want __forceinline for this) and __restrict__. Of course none of this matters if you only use GCC, but many times there really is a need to compile code using many different compilers, each having their own set of exotic attributes used for controlling compilation.

I agree with the parent who mentioned that GCC should have some way of suppressing warnings locally. Unused variables is only one example of these warnings (and easy to avoid with proper defines). There are many others, some of which seem to be nearly impossible to suppress without resorting to globally disabling them from the command line. Some of these can be coded around, but then there is the problem of conflicting warnings across compilers, i.e., compiler A gives you warning A' and compiler B doesn't. If you modify the code so that compiler A does not issue a warning, it might make compiler B issue warning B'. Which is kinda annoying.

some tips for opensource happyness.

[illumen]

I often submit patches to random projects. It's nice when the authors thank you and give you credit.

Some people may take your patch or bug report as a personal attack. The project is probably their baby after all. So make sure when you report a bug, or patch that you are humble about it.

Thank people for their bug reports. They are doing you a favour. If you are nice to them they will probably help you out in the future.

If you can, try and make a patch for the problem rather than make a bug report. Allthough bug reports are still quite useful :)

Some groups don't apply a patch. If this happens ask them why. Common problems are they can't test your patch, they don't know how to apply it, or there are 500 other patches and they just don't care. Perhaps they don't understand your patch. Maybe they are hiking in Nepal ;)

If you respond to user problems quickly, and fix them your work will decrease. If lots of people ask the same questions on a mailing list, instead of making a FAQ try and answer their questions when they use the software. Then you don't have to get angry and tell people to rtfm.

Credit people for their work. Some projects get lots of patches yet basically claim all of the work as their own. I have make bug fixes, added features and made optimizations to projects that didn't even recognise me as doing those. Made me think twice before spending weeks working on their software.

Some bug fixes, or features take weeks to make. So try and give a little time to help people get their changes into your code base.

Have a Features list on your site. Also have a Problems list. Having the problems list/limitations list can save a lot of disapointment, and time for people. Listing that a function is buggy on such and such a platform, or is slow, etc can be really helpful for people.

One nasty person in an irc channel, or on your mailing list can ruin the reputation of your project, and send away lots of users. Try and persuade that person not to be uncool and heavy ;)

Any other things you can do for a better open source project?

Have fun!

Feature Bounties

[skyfaller]

Open Source projects should start using a system of "feature bounties", where a person can post a feature that they want implemented on the site, put down their money, and when enough other people chip in for that feature, some hacker works full time to get the feature working and earns the bounty. KDX, a closed-source BBS-like program for Mac and Windows, used a system like this when it was still freeware, the one programmer working on it suggested people should pay him bounties for features, and apparently some people did it. Now it's paid software, $30 for the client, but oh well, it was a good idea. The only issue is, will it destroy the community to have these "mercenary hackers" running around implementing features for cash and then moving on? Or will it make free software more robust?

My experience on a GCC bug

[r6144]

In August I found a bug in GCC, reported it in detail, and it got fixed by some GCC geeks in a few days. Finding the bug is really not very easy, although it didn't require me to understand GCC sources.

It came up when I was trying User-Mode linux on 2.6.0-test3. The user-mode-linux process keeps crashing when an IPv4 packet is received. I gdb'd around a little (I didn't know much about linux's network stack, but it is not too hard to find the usual code paths), and found (after two hours) that the crash happens upon returning from ip_vs_in(). This function is usually not compiled in, especially on user-mode-linux systems, so maybe that's why other people haven't found that. Every subroutine in ip_vs_in() runs normally, so I traced instructions and found that the return address is wrong. It is probably stack corruption, I thought, so I put a watchpoint on the original return address on the stack upon entering ip_vs_in(), but it was never hit. Then it happens that the stack pointer is not the same when exiting from it! Looks like a GCC bug, and disassembly confirmed it (it was a large routine, but in this particular case only a small part is executed).

I don't know much about GCC, so I can't fix it, but making a testcase is relatively easy because it is a reproducible bug. I just sent a bug report to redhat's bugzilla (because it is the gcc in redhat 9), which contains the exact gcc versions, the options used, the preprocessed file, and the corresponding incorrect assembly output (with some explanation about where the error is). As for simplification, I think gcc developers can do it better than me (after all, the bug is obvious even in the unsimplified test case), so I didn't do it. The bug got fixed in a matter of days.

Re:Publishing your Code Will Attract Many Skilled.

[Slamtilt]

Go on. Send it to him, I dare you. And I think he'll laugh.

Subversion isn't hard to install now

[r6144]

RPMs are available now, with detailed instructions, on the project site. It is just four RPMs without too much dependencies if you don't want to run the Apache-based server (which is harder to install, but most people won't need that at first). It worked well for me.

I call bullshit!

[Kent Recal]

That guy doesn't know what he's talking about.

I got news for you Mr."chromatic":
There is no such thing as "OSS-developement". Therefor there cannot be any myths about "it".

There are all kinds of flavours of OSS-projects, little toy projects by bored students, beasts like mozilla or OOo, projects that are partially (or fully) backed up by a company and many other constellations you might not even be able to imagine.

So some of the "myths" you claim (most of them sound as if you made them up while taking a break from digging your nose) might apply to some individual OSS-projects.
But as someone who publishes articles you should know how the really-old saying goes: Broad generalizations never work well.

And in case you feel like you are the prototype of an OSS-developer and therefor qualify to define "myths we tell ourselves" I've got even more news for ya: you're not.

Don't throw code away, reuse it if you can find it

[oo_waratah]

We must work on other people projects, not create our own. We must be able to locate that project if it exists.

I think that the comment about not throwing away code might be misconstrued somewhat. The text appears to be more about not working on a similar project and fixing that. The text talks about "yet another" IRC, text editor etc.

The biggest problem I see is being able to locate that project or even part of a project that you want. Take a look at perl CPAN for an idea of how it should work. I though SourceForge would help however this is only part of the FOSS base and it is very difficult to search. For example I am doing a perl course and I searched for notes, I could not locate spork project for searching, I found it by looking at a paper copy.

Take you ideas talk to those working on similar projects, see if your ideas meet and start working with a project. Fork if you have to, reference the original project in your documentation, track the original project. Above all be prepared to merge and become a single project with another, be humble shut yours down in favour of another egoless programming.

Its about time

[t0ny]

Lots of people here on Slashdot fully buy into, as well as perpetuate, these myths.

The fact that you find them obvious just means that you actually work in software development, and have real experience. Neither of those two can be said for 98% of Slashdot's OSS 'supporters'.

I can add another myth: most people who claim to love the fact that they have access to OSS source code dont really program anything, or even know how to. The term 'script kiddie' comes to mind.

Re:Naw, you have hours to days before engine siezu

[Anonymous Coward]

What kind of car??

Stealing mindshare

[gidds]

No, they can't steal the code.

But they can steal your users, your developers, your testers, your mindshare. To take an extreme example, what if M$ released a 'new, improved' version of your app? Wouldn't it take but a short time before most people used their version, complete with incompatible extensions and lock-ins? After that point, they could close the code, and it wouldn't matter that you still had your original code; it wouldn't do you much good.

In practice, of course, it's not likely to be as bad as that. Few companies have the clout to take over a project like that completely. But many companies and groups of people could do serious damage to a smallish project on those lines.

It's that loss of mindshare that licences like the GPL were designed to avoid. For some types of project, that sort of top-level mindshare isn't important, either because they have their own captive audience, or don't need anyone else. And some care more about getting the code out there and getting it used. But for others, mindshare may be important, and so, rightly or wrongly, licences like the GPL are there for them.

Community

[foniksonik]

The surest way to gaurantee involvement in a project is to create a community around it. Forums, user/contributor publishing, blogs. Anything that will let your contributors express themselves regarding the project.

Let people get involved, encourage them, provide a forum.... hopefully provide the tools (sourceforge) but also provide a unique community experience. Create a brand (read a book on marketing) and you will reap the rewards for years... think about Aibo for instance...

Yup... sorry.

[mindstrm]

I guess I did a quick google, and the first few links came up with an Alan Cox who was a Professor of Computing Science, and I just jumped to conclusions.

The original point still stands... these people do have degrees.

Re:Publishing your Code Will Attract Many Skilled.

[Dr. Photo]

+ She likes to romp about the house,
+ and chase my USB Intellimouse.

Your patch creates a tight coupling between two disparate modules. The arcnet documentation should not know about the USB HID internals. ;-)

It's OK

[flicken]

I'll just have to be quicker next time. (-;

User participation in OS coding

[StrawberryFrog]

I've found this myself ... not a single person has contacted me and offered to help develop or debug the code.

It all depends on who your users are. I have put two small projects out as open source - The first never attracted any code fixes, but the second, a coding utility, (ie the users are also coders) atracts a small but steady stream of patches.

car analogy

[SanityInAnarchy]

This isn't going to be as cool as the car analogy in Neal Stephenson's "In the beginning, there was the command line" essay. Sorry about that.

My car is an 86 Lincoln Town Car. I can take it to pretty much any dealer -- or even just a good friend -- any motorhead at all -- and they can service it, or even mod it. Some modern cars won't even let you get a spare key without going straight to the dealer and spending $50-100.

Open source is like my car. If you find a bug and no one wants to fix it for free, you can hire someone to fix it. Need a new feature, and the community's a little sluggish? Hire someone to do it for you. Then release the improvements to the community -- if not because it's the righ thing to do, you'd do it that way so that the next version would already have your feature, without a lot of work from another hired coder.

The best example I can give is Counter-Strike. Valve made Half-Life, which was cool enough itself, but they let people mod it. I know it's not open-source, but modding still has a community. In fact, several very good, entirely new games came out of that community -- Counter-Strike and Natural Selection, for example.

Now, as an end-user, I don't make half-life mods myself. But the fact that others can make such mods definitely benifits me.

Re:Naw, you have hours to days before engine siezu

[Gordonjcp]

Was it coming on intermittently? If so, it probably means that the oil was too low, leaking perhaps, and sloshing about. Of course, very old and worn engines might have the oil light come on at idle no matter what you do, but by then they're well overdue for a set of bearings and rings.

Re:Publishing your Code Will Attract Many Skilled.

[Grant29]

Now after publishing his email address, he will get lot's of SPAM. I'm sure he'll aprecciate the email though....

--
For great deals on electronics and computer equipment visit Retail Retreat

Re:Naw, you have hours to days before engine siezu

[teidou]

Yeah, it was low and leaking and sloshing about and would usually first come on during a prolonged right turn, like at a freeway on-ramp. I'd just add a little oil now and then to make it go away, so my experience is not universal...just pointing out that you don't always come to an expensive stop seconds later.