Slashdot Mirror

I'm not going to be redundant and go into it here, but you should take a look at this article and you may agree that it is in fact better for the source to be open with regards to security.

The biggest problem with license proliferation is that you can't combine OSS/FS programs with each other unless the licenses are compatible. So if your OSS/FS code isn't compatible with the most common OSS/FS license, there's a problem. Especially when you consider that the other OSS/FS software not licensed under the GPL is usually GPL-compatible (BSD-new, MIT, LGPL). If you make sure your license is at least GPL-compatible, then the problems of "how do I combine this software" generally vanish... no matter what, you can license the combination under the GPL, and use the results.

You don't need to agree with the GPL at all; lots of companies who certainly aren't wholehearted supporters of it use the GPL for completely pragmatic reasons.

For more info, see Make your Open Source Software GPL-compatible. Or Else.

See Comments on Open Source Software / Free Software (OSS/FS) Software Configuration Management (SCM) systems for more information on OSS/FS SCMs. There are several relatively mature centralized SCMs, but the distributed ones are less mature. See paper for details.

There are lots of such tools, including CVS, Subversion (SVN), GNU arch, Monotone, Aegis, CVSNT, Darcs, FastCST, OpenCM, Vesta, Superversion, Codeville, Bazaar, Arx, and Bazaar-NG.

There are lots of such tools, including CVS, Subversion (SVN), GNU arch, Monotone, Aegis, CVSNT, Darcs, FastCST, OpenCM, Vesta, Superversion, Codeville, Bazaar, Arx, and Bazaar-NG.

Please, protest this plan!! You have until April 4, 2005, to send your comments to PassportRules@state.gov and tell them to abandon this wireless approach, and use a system that REQUIRES contact instead (no more RFID). Do it, before someone dies.

"The better SCM initiative was established to encourage improved OSS/FS SCM systems, by discussing and comparing them. Among other things, see their comparison file. Zooko has written a short review of OSS/FS SCM tools. Shlomi Fish's OnLamp.com article compares various CM systems as does his Evolution of a Revision Control User. The arch folks have developed a comparison of arch with Subversion and CVS (obviously, they like arch). Another pro-arch discussion is Why the Future is Distributed. A pro-subversion discussion is available at Dispelling Subversion FUD. Slashdot had a discussion when Subversion 1.0 was announced. Kernel traffic posted a summary of a technical discussion about BitKeeper. Brad Appleton has collected lots of interesting SCM links. jemfinch has some interesting essays about SCMs (he uses the term VCS), including why he thinks the approach to branches used by Darcs, Arch, and Bazaar-ng is a poor one. A brief overview of SCM systems that can run on Linux is available."

There are lots of OSS/FS software configuration management (SCM) tools. CVS, Subversion (SVN), and GNU arch get lots of press, but there are many others such as Aegis, CVSNT, Darcs, FastCST, OpenCM, Vesta, Codeville, Bazaar and Bazaar-NG.

You might also take a peek at my paper Software Configuration Management (SCM) Security.

"The better SCM initiative was established to encourage improved OSS/FS SCM systems, by discussing and comparing them. Among other things, see their comparison file. Zooko has written a short review of OSS/FS SCM tools. Shlomi Fish's OnLamp.com article compares various CM systems as does his Evolution of a Revision Control User. The arch folks have developed a comparison of arch with Subversion and CVS (obviously, they like arch). Another pro-arch discussion is Why the Future is Distributed. A pro-subversion discussion is available at Dispelling Subversion FUD. Slashdot had a discussion when Subversion 1.0 was announced. Kernel traffic posted a summary of a technical discussion about BitKeeper. Brad Appleton has collected lots of interesting SCM links. jemfinch has some interesting essays about SCMs (he uses the term VCS), including why he thinks the approach to branches used by Darcs, Arch, and Bazaar-ng is a poor one. A brief overview of SCM systems that can run on Linux is available."

There are lots of OSS/FS software configuration management (SCM) tools. CVS, Subversion (SVN), and GNU arch get lots of press, but there are many others such as Aegis, CVSNT, Darcs, FastCST, OpenCM, Vesta, Codeville, Bazaar and Bazaar-NG.

You might also take a peek at my paper Software Configuration Management (SCM) Security.

Why OSS/FS? Look at the Numbers!

OSS/FS References

How to Evaluate OSS/FS Programs

Generally Recognized as Mature (GRAM) OSS/FS Programs

Make Your Open Source Software GPL-Compatible. Or Else.
by David A. Wheeler June 5, 2002; revised February 16, 2005
...

Why OSS/FS? Look at the Numbers!

OSS/FS References

How to Evaluate OSS/FS Programs

Generally Recognized as Mature (GRAM) OSS/FS Programs

Make Your Open Source Software GPL-Compatible. Or Else.
by David A. Wheeler June 5, 2002; revised February 16, 2005
...

You might be mistaking commercial software with selling software, which indirectly implies that only propriatery software can be sold.
This is of course nonsense. The business model might be sligtly different since the software itself isn't always sold like individual slices of pizza, but a lot of those companies out there are making software which they use to either support their infrastucture and/or sell support for it to their customers. Just because it isn't being shipped in boxes to a store doesn't mean that the software used isn't commercial. And by the way, you contradicted yourself when you said:

Claiming that GPL-style "Free" software can't be commercial is about as accurate as saying that human beings can't have 11 fingers.

and at the end you said:

The standard business model for 99.999% of today's commercial software CANNOT work with the GPL.

Those two lines are obviously contradictory as the former is in accordance with my conclusion (that commercial Free software is widespread and in increasingly heavy use in the industry) while the latter is the exact opposite. I therefore take it that you are in complete agreement with my conclusion since the evidence is so overwhelmingly obvious.

There is also a misconception that software can only be a product from one company but Free software is often developed by many individuals and companies who all see the benefit in spending their resources on it.
Claiming that Free software can't be commercial is about as accurate as saying that most human beings don't have 10 fingers.

You might want to take a peek at my paper Why Open Source Software / Free Software (OSS/FS)? Look at the Numbers!". Feel free to share it, or quote (attributed) information from it. The paper has lots of useful facts and figures on why people should consider OSS/FS.

David Wheeler has written some of the most fact-rich, fluff-free articles on OSS/FS. They're not actual presentations, but I can't think of a better source of material to make one.

This is absolute nonsense. In the U.S., you do not need to register a trademark to be the owner of it - just use the mark. Perhaps the MAME folks ought to register the name to prevent another clown from trying to steal their name. I've posted a trademark notice on my own site to keep away at least some of the predators. I did that after learning of the problems of problems of Katie Jones, owner of the katie.com domain. Linus Torvalds eventually had to register "Linux" everywhere because of a similar set of thefts.

What's different is the increasingly strenuous tone calling for people to reign in the number of licenses. In many ways, this basically demonstrates that OSS/FS has matured. Lots of people have created new licenses, essentially experimenting with different approaches. The marketplace of ideas has selected a few "winning" ideas, and it's getting increasingly hard for even a good new license idea to overcome the many problems of incompatibility with what already exists. Commercial development and use of OSS/FS is now widespread; a consolidation of common licensing approaches appears inevitable as the whole approach becomes common.

There's at least one simple test: make sure your license is GPL-compatible. You can do this by using the GPL, using a different license that is known to be GPL-compatible (in particular the LGPL, MIT/X, or BSD-new (modified BSD) licenses), or by dual-licensing the program (and ensuring that one of the licenses is the GPL). See my essay for info on why GPL compatibility is so important.

In many ways, this license winnowing is happening anyway. My paper More than a Gigabuck found that only a few licenses were used by nearly all the code; at the time it was (in order) GPL, MIT, LGPL, MPL, and BSD (counting by lines of code). You can look at Freshmeat's statistics, which counts the licenses per project. Today, 2005-02-16, the OSS/FS licenses in order of popularity were (from most popular) the GNU General Public License (GPL) (67.99%) GNU Lesser General Public License (LGPL) (5.89%), BSD License (original) (3.54%), BSD License (revised) (1.92%), Artistic License (1.80%), MIT/X Consortium License (1.26%), Apache License (0.72%), Mozilla Public License (MPL) (0.57%), Perl License (0.39%), and Apache License 2.0 (0.26%). I see a short list here, and notice that even in this list of the most popular licenses, the dropoff between the most-popular licenses and the next most popular licenses are really steep. Every project whose license is incompatible with all of these has a serious liability, and in fact, being only compatible with the lower-popularity licenses is a real problem. Few think Sun's CDDL code is going to go anywhere, solely because it's an odd license incompatible with the millions of lines of code already out there.

I wish he'd used proper terminology - I think he meant "proprietary" not "commercial". Last I checked, Red Hat, Novell, IBM, Sun, and many other distributors of OSS/FS programs (including those using the GPL) were commercial companies.

What's different is the increasingly strenuous tone calling for people to reign in the number of licenses. In many ways, this basically demonstrates that OSS/FS has matured. Lots of people have created new licenses, essentially experimenting with different approaches. The marketplace of ideas has selected a few "winning" ideas, and it's getting increasingly hard for even a good new license idea to overcome the many problems of incompatibility with what already exists. Commercial development and use of OSS/FS is now widespread; a consolidation of common licensing approaches appears inevitable as the whole approach becomes common.

There's at least one simple test: make sure your license is GPL-compatible. You can do this by using the GPL, using a different license that is known to be GPL-compatible (in particular the LGPL, MIT/X, or BSD-new (modified BSD) licenses), or by dual-licensing the program (and ensuring that one of the licenses is the GPL). See my essay for info on why GPL compatibility is so important.

In many ways, this license winnowing is happening anyway. My paper More than a Gigabuck found that only a few licenses were used by nearly all the code; at the time it was (in order) GPL, MIT, LGPL, MPL, and BSD (counting by lines of code). You can look at Freshmeat's statistics, which counts the licenses per project. Today, 2005-02-16, the OSS/FS licenses in order of popularity were (from most popular) the GNU General Public License (GPL) (67.99%) GNU Lesser General Public License (LGPL) (5.89%), BSD License (original) (3.54%), BSD License (revised) (1.92%), Artistic License (1.80%), MIT/X Consortium License (1.26%), Apache License (0.72%), Mozilla Public License (MPL) (0.57%), Perl License (0.39%), and Apache License 2.0 (0.26%). I see a short list here, and notice that even in this list of the most popular licenses, the dropoff between the most-popular licenses and the next most popular licenses are really steep. Every project whose license is incompatible with all of these has a serious liability, and in fact, being only compatible with the lower-popularity licenses is a real problem. Few think Sun's CDDL code is going to go anywhere, solely because it's an odd license incompatible with the millions of lines of code already out there.

I wish he'd used proper terminology - I think he meant "proprietary" not "commercial". Last I checked, Red Hat, Novell, IBM, Sun, and many other distributors of OSS/FS programs (including those using the GPL) were commercial companies.

What's different is the increasingly strenuous tone calling for people to reign in the number of licenses. In many ways, this basically demonstrates that OSS/FS has matured. Lots of people have created new licenses, essentially experimenting with different approaches. The marketplace of ideas has selected a few "winning" ideas, and it's getting increasingly hard for even a good new license idea to overcome the many problems of incompatibility with what already exists. Commercial development and use of OSS/FS is now widespread; a consolidation of common licensing approaches appears inevitable as the whole approach becomes common.

There's at least one simple test: make sure your license is GPL-compatible. You can do this by using the GPL, using a different license that is known to be GPL-compatible (in particular the LGPL, MIT/X, or BSD-new (modified BSD) licenses), or by dual-licensing the program (and ensuring that one of the licenses is the GPL). See my essay for info on why GPL compatibility is so important.

In many ways, this license winnowing is happening anyway. My paper More than a Gigabuck found that only a few licenses were used by nearly all the code; at the time it was (in order) GPL, MIT, LGPL, MPL, and BSD (counting by lines of code). You can look at Freshmeat's statistics, which counts the licenses per project. Today, 2005-02-16, the OSS/FS licenses in order of popularity were (from most popular) the GNU General Public License (GPL) (67.99%) GNU Lesser General Public License (LGPL) (5.89%), BSD License (original) (3.54%), BSD License (revised) (1.92%), Artistic License (1.80%), MIT/X Consortium License (1.26%), Apache License (0.72%), Mozilla Public License (MPL) (0.57%), Perl License (0.39%), and Apache License 2.0 (0.26%). I see a short list here, and notice that even in this list of the most popular licenses, the dropoff between the most-popular licenses and the next most popular licenses are really steep. Every project whose license is incompatible with all of these has a serious liability, and in fact, being only compatible with the lower-popularity licenses is a real problem. Few think Sun's CDDL code is going to go anywhere, solely because it's an odd license incompatible with the millions of lines of code already out there.

I wish he'd used proper terminology - I think he meant "proprietary" not "commercial". Last I checked, Red Hat, Novell, IBM, Sun, and many other distributors of OSS/FS programs (including those using the GPL) were commercial companies.

What's different is the increasingly strenuous tone calling for people to reign in the number of licenses. In many ways, this basically demonstrates that OSS/FS has matured. Lots of people have created new licenses, essentially experimenting with different approaches. The marketplace of ideas has selected a few "winning" ideas, and it's getting increasingly hard for even a good new license idea to overcome the many problems of incompatibility with what already exists. Commercial development and use of OSS/FS is now widespread; a consolidation of common licensing approaches appears inevitable as the whole approach becomes common.

There's at least one simple test: make sure your license is GPL-compatible. You can do this by using the GPL, using a different license that is known to be GPL-compatible (in particular the LGPL, MIT/X, or BSD-new (modified BSD) licenses), or by dual-licensing the program (and ensuring that one of the licenses is the GPL). See my essay for info on why GPL compatibility is so important.

In many ways, this license winnowing is happening anyway. My paper More than a Gigabuck found that only a few licenses were used by nearly all the code; at the time it was (in order) GPL, MIT, LGPL, MPL, and BSD (counting by lines of code). You can look at Freshmeat's statistics, which counts the licenses per project. Today, 2005-02-16, the OSS/FS licenses in order of popularity were (from most popular) the GNU General Public License (GPL) (67.99%) GNU Lesser General Public License (LGPL) (5.89%), BSD License (original) (3.54%), BSD License (revised) (1.92%), Artistic License (1.80%), MIT/X Consortium License (1.26%), Apache License (0.72%), Mozilla Public License (MPL) (0.57%), Perl License (0.39%), and Apache License 2.0 (0.26%). I see a short list here, and notice that even in this list of the most popular licenses, the dropoff between the most-popular licenses and the next most popular licenses are really steep. Every project whose license is incompatible with all of these has a serious liability, and in fact, being only compatible with the lower-popularity licenses is a real problem. Few think Sun's CDDL code is going to go anywhere, solely because it's an odd license incompatible with the millions of lines of code already out there.

I wish he'd used proper terminology - I think he meant "proprietary" not "commercial". Last I checked, Red Hat, Novell, IBM, Sun, and many other distributors of OSS/FS programs (including those using the GPL) were commercial companies.

OSS is no silver bullet. Their last point is "OSS code quality seems to suffer from the very same problems that have been observed in CSS projects." Er, big surprise, they're all software.

May I simply point out the artciles More than a Gigabuck: Estimating GNU/Linux's Size and Linux Kernel 2.6: It's Worth More! by David A. Wheeler. That last one shows, that just the Linux kernel alone matches this gift easily. Just add up the rest of the GNU system and no individual (or single company) can match this kind of generosity.

May I simply point out the artciles More than a Gigabuck: Estimating GNU/Linux's Size and Linux Kernel 2.6: It's Worth More! by David A. Wheeler. That last one shows, that just the Linux kernel alone matches this gift easily. Just add up the rest of the GNU system and no individual (or single company) can match this kind of generosity.

Pardon me for being insistent, but "openoffice.org" is a Web address, not a name. If the company that makes it doesn't want their customers to call it "Open Office," they should change the name. (They should probably change the name in any case. "Open Office" doesn't exactly stir the soul.)

That's not being insistent, it's being stupid. OpenOffice.org is the name of the software. The original poster was correct, you tried to correct him but looked like an idiot because you were wrong and then I corrected you. It's a very simple sequence of events; do try and keep up. As for what you think of the name, nothing you've posted so far inspires me to assign any value to your opinion.

Numbers.

A meaningless non-response with nothing to back it up, almost certainly indicating that you have no basis for your opinion. This is unsurprising.

No, it was supposed to be illustrative. Reading comprehension much?

Illustrative of what? That you don't hire competent people? That you change your hardware and software platform whenever you change IT personnel? It's certainly not illustrative of anything regarding open source software.

> We use open source software because we like the support, reliability and licensing freedom.

How odd. Because it has none of those three things.

I don't normally go in for personal attacks but you're really not a very honest person, are you? Starting from the end:

For you to claim that open source software doesn't provide licensing freedom is either stupid or dishonest. Since you're apparently capable of operating a computer with at least minimal competency I find it difficult to believe that you could be stupid enough to believe what you said. So you've apparently lying. Unfortunately you chose to lie about a subject that the Slashdot audience understands reasonably well so you're not going to get very far.

As for reliability, there are plenty of studies that show the reliability of open source.

And finally, support. I don't think this will be news to anyone except (perhaps) you but paid support is available for open source software. Linux is supported by distributions such as Redhat and Novell, Apache & Tomcat are supported by companies like JBoss and Samba is supported by a truly huge list of companies in many countries. As another poster pointed out, OpenOffice.org has commercial support available from companies like Blue Point

You shouldn't bother replying to this, but if you do be sure to bring some facts to back up your position. Your blind assertions do not impress.

Engine blueprints are not like software and tt is not always in the best financial interest of a company to charge for traditional products.

You mentioned:
This is like saying GM should open-source the blueprints for all their car engines. It's ridiculous. Valve put untold millions into HL2 development, and there's absolutely no incentive for them to just open the source, and there's a strong disincentive...

But then you turned around and said:

To ignore the economic constraints of development is breathtakingly naive.

Form those of us who've actually developed software and taken classes on economics, these statement are very naive. For all projects, the return on investment varies throughout its lifecycle. This contraint is often overlooked by shortsighted money grubbing middle management in the pursuit of next-quarter's margins. As mentioned in the article, which you obviously did not read, game software that once garndered much money for each small (post-release) investment reaches a point at which few profits can be obtained with even large investment.

With your competitors producting higher quality engines (for which you are getting zero royalties) and using newer storylines, you product cannot compete. In this situation, it makes sense save yourself the cost of distribution while ensuring people see your logos and discover the quality of your work. Corner isle loss leaders at supermarkets are the same idea. In the case of software, you are getting free adversiting, marketing and publicity from an existing product by releasing the source code.

If you had read the article, you would understand that companies such as Valve are moving away from selling cars like Half-Life 2 to renting fleets of vehicles with systems like steam. For GM, keeping a blueprint seceret is not possible since the engine has to pass safety inspections. Very few peices of software have such mission critical natures. GM pays an engineer to make and sign off on their blueprints, but so do software companies that make 911 telecom software. Once built, it is very easy to reverse engineer a car engine. For the purposes of patents and publishing rights, the detailed methods of engine operation may be widely published with only a working prototype. Binaries of game software are easily encrypted and copy-protected. Usually such protection is kept until it interferes with enough of the customer base and generates enough bug reports to warrent removal.

According to modern studies 95% of all in-house software fits the criteria for F/OSS release policy. Those fortunate enough to adopt service models, like content distribution via Valve's Steam or support offerings like RedHat's Enterprise Linux, are getting continual revinue which scales very well. (I'd much rather pay the taxes on $0 million in sales now and $4 million in income over the next 5 years than $500k from sales now with nothing to show for the next 5 years.)

Engine blueprints are not like software and tt is not always in the best financial interest of a company to charge for traditional products.

You mentioned:
This is like saying GM should open-source the blueprints for all their car engines. It's ridiculous. Valve put untold millions into HL2 development, and there's absolutely no incentive for them to just open the source, and there's a strong disincentive...

But then you turned around and said:

To ignore the economic constraints of development is breathtakingly naive.

Form those of us who've actually developed software and taken classes on economics, these statement are very naive. For all projects, the return on investment varies throughout its lifecycle. This contraint is often overlooked by shortsighted money grubbing middle management in the pursuit of next-quarter's margins. As mentioned in the article, which you obviously did not read, game software that once garndered much money for each small (post-release) investment reaches a point at which few profits can be obtained with even large investment.

With your competitors producting higher quality engines (for which you are getting zero royalties) and using newer storylines, you product cannot compete. In this situation, it makes sense save yourself the cost of distribution while ensuring people see your logos and discover the quality of your work. Corner isle loss leaders at supermarkets are the same idea. In the case of software, you are getting free adversiting, marketing and publicity from an existing product by releasing the source code.

If you had read the article, you would understand that companies such as Valve are moving away from selling cars like Half-Life 2 to renting fleets of vehicles with systems like steam. For GM, keeping a blueprint seceret is not possible since the engine has to pass safety inspections. Very few peices of software have such mission critical natures. GM pays an engineer to make and sign off on their blueprints, but so do software companies that make 911 telecom software. Once built, it is very easy to reverse engineer a car engine. For the purposes of patents and publishing rights, the detailed methods of engine operation may be widely published with only a working prototype. Binaries of game software are easily encrypted and copy-protected. Usually such protection is kept until it interferes with enough of the customer base and generates enough bug reports to warrent removal.

According to modern studies 95% of all in-house software fits the criteria for F/OSS release policy. Those fortunate enough to adopt service models, like content distribution via Valve's Steam or support offerings like RedHat's Enterprise Linux, are getting continual revinue which scales very well. (I'd much rather pay the taxes on $0 million in sales now and $4 million in income over the next 5 years than $500k from sales now with nothing to show for the next 5 years.)

The unserialize() bug issue is rather serious, though.

It's true that all systems have vulnerabilities, but that does not mean that all systems are equally secure. What you want is a track record that shows good things. Frankly, I'm not all that impressed with PHP's track record so far. The good news is that the PHP developers have been willing to change critical pieces (like turning off globals) to deal with security issues, and it looks like at least some of them are taking security more seriously. But I'd really like to see evidence of serious steps to not just provide a niftier OO model, but provide a programming language where programs are more likely to actually withstand attack. PHP has a lot going for it, but an implementation that can't handle harsh attacks is simply not appropriate for today's network.

I'd like to see Hardened-PHP, or something like it, merged into the mainline PHP. Why is it that only some users will get a PHP that tries to defend against attacks? Does this mean that other PHP users never get attacked? Does this mean that PHP programmers have stopped making common mistakes? Nonsense. There's no reason that there has to be a separate project to modify PHP to be secure against attack; that should be part and parcel of PHP itself. The performance impact is tiny, and much less important than keeping control over your own machine. Why should anyone be impressed at the speed of a system that's about to be controlled by an attacker?

One of the best ways to get a secure setup is to find out what product has the better security track record with evidence of a secure design (modular parts, etc.), and switch to one of them. That's true whether it's OSS or proprietary; OSS is no guarantee of security, it simply makes some kinds of worldwide review possible. Using Internet Explorer or Outlook? Switch to Firefox and Thunderbird. Using Sendmail? Switch to Postfix. That doesn't guarantee perfection, but you're generally better off in the long run. I think you could make a very good case for switching from PHP to Perl or Python or Java. If the PHP folks want to keep their large user base, they need to get on the stick.

For more information, see the section on TCO in "Why OSS/FS? Look at the Numbers!". Basically, TCO is very sensistive to the specific environment and requirements. It's clear, though, that there are many cases where OSS/FS does have a lower TCO.

It's not free nor Free Software, but if you need a word processor / spreadsheet / presentation program, get Documents To Go if you have a Palm. It works well.

It's worth noting that there are a number of open source software products that run on top of PalmOS. See my Suggestions for PalmOS PDA Users, freshmeat.net's list for the PalmOS Operating System category, and http://www.palmopensource.com.

"Apple worked secretly on their version of KHTML for a year before making their fork public. Apple also tends to submit their changes in large patches that incorporate a great number of changes, in some cases leaving code to do with future feature additions barely documented, making it difficult for the KDE developers to sort through and incorporate the changes"

"The value of an OO language in larger projects is enormous."
And the kernel, at more than 4 MLOC isn't large enough?

Non-optimizing compilers can be very fast. Basically you just have to parse it and output pre-defined asm for each bit. According to this page, Turbo C 2.01 (a 1989 product) compiles over 16,000 lines per minute. Given that this number is also on the advertisement shown in that picture, which is actually from that time, it's 16,000 lines on the hardware of that time (i.e. 386). Now IIRC the 386 had at most 33MHz, so from the clock speed difference alone, on an 2.4GHz computer it should compile about 1.16 million lines per second; assuming a factor 4 in efficiency (i.e. modern processors can do 4 times as much per clock cycle as an 386), it should be possible to compile the same amount in 15 seconds. Now according to this page the Linux kernel has 1,526,722 lines of code, so if either my efficiency factor of 4 was too low, or TCC can compile about 1.5 times as fast as Turbo C 2.0 could (or maybe a combination of both), it's clearly not that far-fetched that a linux kernel could be compiled in 15 seconds.

However, your next statement is somewhat missing the point: "Estimating based on what it would cost in a commercial environment is also flawed, because there are too many variables to consider." Yes, salaries and overheads vary, and they'll certainly affect the answer. But I used a U.S.-nationwide average for salaries, and several sources for the overhead value. See "Gigabuck" for more info. So this is an "average" kind of development. If you don't like those assumptions, I gave enough information for you to recompute everything using different values. But you have to make some assumptions, and I think these are quite reasonable ones; I basically picked averages to represent an "average" development project's costs.

But then you say stuff that I think isn't right: "The bottom line is, since the developers have always been paid nothing for their work (except those that are being sponsored by commercial entities) ... since in all likelihood if these guys weren't writing the code in their spare time, they would be doing some other hobby... The bottom line here is, the only time that you can assign a value to is the time that someone actually received a wage for. This is a small minority of the overall code base, so by that method the code would not be worth much at all."

Two problems: first, I'm computing re-development cost, and presuming that the developers would be getting a wage. And second, most of the changes in the Linux kernel are from developers getting a wage to do so.

In fact, the move to wage-earning OSS/FS development has been one of the silent trends in the IT industry. In 2004, Government Computer News reported in July 2004 on a presentation by Andrew Morton, who leads maintenance of the the Linux kernel in its stable form, and confirmed the trend towards paid OSS/FS developers. Morton spoke at a meeting sponsored by the Forum on Technology and Innovation, to address technology-related issues, held by Sen. John Ensign (R-Nev.), Sen. Ron Wyden (D- Ore.) and the Council on Competitiveness. Morton noted that "People's stereotype [of the typical Linux developer] is of a male computer geek working in his basement writing code in his spare time, purely for the love of his craft. Such people were a significant force up until about five years ago ..." but contributions from such enthusiasts, "is waning... Instead, most Linux kernel code is now generated by corporate programmers." Morton noted that "About 1,000 developers contribute changes to Linux on a regular basis... Of those 1,000 developers, about 100 are paid to work on Linux by their employers. And those 100 have contributed about 37,000 of the last 38,000 changes made to the operating system."

For more about the general trend of employed OSS/FS developers, see http://www.dwheeler.com/oss_fs_why.html#wont-destr oy-industry. This isn't new in a sense; X Windows was started this way, as was Apache. It's just become more common.

Security should always be important whether you're providing a network server, a setuid application, or neither of these things.

In many cases security issues arise from having malicious input cause an exploit, even in non-security-sensitive applications if you're not careful unexpected input can cause a crash which might be just as painful from a user point of view.

Too many people forget that security is a process, and not an addon.

Many good tips on secure programming can be found in David Wheeler's Secure Programming For Linux and Unix HOWto.

Read it, even if you dont think security is important for you yet. It's only a matter of time until it will be.

What the heck is FLOSS ?

There was a 2002 paper published by the Mitre Corporation that used the term "FOSS", meaning "free and open-source software". As far as I know, this was the first use of the term, but it may go back a bit farther than this.

I don't, however, have any idea what "FLOSS" is supposed to mean. Assuming that it isn't related to dental hygiene, what is it supposed to stand for ? "Free {Linux, liberty, low-cost} open-source software" ? Just a nonsense corruption of "FOSS" ?

The closest explanation I can find is this blog entry by David Wheeler: "Free-Libre / Open Source Software". Is this really what people are trying to say ?

Increasingly, people are being paid to work on OSS/FS software. That's how X and Apache were developed, so this isn't new. The Linux kernel is almost entirely developed by people paid to do so (37,000 out of 38,000 changes a few months ago). There are lots of articles about this trend, referenced in the paper. Also, nearly all software is not developed for sale, but is custom-developed for a particular purpose (most estimates place this at 95%). For custom, you're paid to develop it anyway, and having an OSS/FS program to base it on makes many things easier.

My site's up, but it's not handling Slashdotting as well as I'd hope. I'll see what I can do.

Increasingly, people are being paid to work on OSS/FS software. That's how X and Apache were developed, so this isn't new. The Linux kernel is almost entirely developed by people paid to do so (37,000 out of 38,000 changes a few months ago). There are lots of articles about this trend, referenced in the paper. Also, nearly all software is not developed for sale, but is custom-developed for a particular purpose (most estimates place this at 95%). For custom, you're paid to develop it anyway, and having an OSS/FS program to base it on makes many things easier.

My site's up, but it's not handling Slashdotting as well as I'd hope. I'll see what I can do.

What an absurdity. You are talking about compact simple functions. What we are talking about are fundamental changes involving perhaps 10-15 million lines of code.

Okay, I call bullshit. At this point, you absolutely have to be either trolling or uninformed.

What on *Earth* are you talking about? What piece of software, what project, is hit by a 15 million LOC impact to add *any* feature, no matter how major? Every single project in Red Hat Linux added together has on the order of 30 million lines of code. Windows NT, the entire distribution, had about 10 million, and Windows 2k under 30 million, IIRC. The Windows kernel doesn't even begin to approach the kind of LOC count you're talking about. Let's look back at your first post:

So this is what is MS thinking: implement the things that FOSS world can't do thanks to its red-tape laden world-view. Implement a filesystem layer that provides nifty functions that while aren't new are new in this scale.

And you're talking about a lousy metadata-using filesystem taking that much? Man, a basic filesystem under Windows takes a lot more code than a basic filesystem under Linux, but Linux's ramdisk filesystem is 183 LOC. I doubt that WinFS breaks 100K LOC, much less 15 million LOC.

As for new filesystems, I suggest that you might want to reconsider Linux doing a poor job of competing with Windows. ls /usr/src/linux-2.6.8.1/fs|grep fs$|wc results in 29 filesystems. How many filesystems does a Windows box support? FAT, FAT/w/DOS-naming, NTFS, CIFS? And you're complaining about a lack of people adding new features?

I think that they might be the most *popular* vendor of a number of things, but still not the first to market
No, you are not following me. I am talking about taking things that are mature, and making them accessible to the masses. FOSS hasn't done that widely, except perhaps FireFox, and a few P2P clients. What FOSS software is in daily use by millions of desktop users?

So basically, your reason for saying that FOSS is "red tape-laden" -- I just want to get this straight -- is because there is a minimal number of FOSS projects that:

*) Run on Windows.

*) Have a large installed base.

Your arguments for existing, installed base doesn't say a thing about maturity or ease of use which you've flipped to. Take, for instance, Rosegarden. Quite usable music composition software. Not used by "millions of desktop users, however."

Because that explains a lot. I was saying that you were talking about a large installed base, and it seems that you *were*. Don't get me wrong. I think that Microsoft is *very* talented when it comes to sales, marketing, and business relationships leveraging a monopoly. That can buy them a lot of desktops. The thing that I take issue with is that you're claiming that FOSS can't get new features out to users, which is patently absurd. Yes, when Microsoft bundles a new feature into the next release of Windows or Office, it will reach a lot of users -- because a lot of people use Windows or Office!

As a Linux software developer, can you claim that?

Nope. Let me bundle my software with Windows, have it installed on a vanilla box, bootstrapping off of an existing monopoly, and we can talk again.

Except that your cross-platform ideas involve the time-consuming and error-prone problems of cross-compiling.

Time consuming? I don't know what the internal Red Hat build procedure is, but I'm sure that it's automated. Gentoo *definitely* is automated -- it's easy for someone to just say "I'm PPC, suck down the latest binary packages built by Gentoo.

As for error-prone -- the kinds of errors that turn up when you move across platforms (generally when someone's using C), like shoving pointers into ints and relying on a certain form of packing, are the kind of problems that would turn up anyway on a single

Free software is written in C (65%), C++ (25%), and Python and Perl (all but the last 1%).

The latest complete count of a Linux distribution was of RedHat 7.1, http://www.dwheeler.com/sloc/. Shell, Lisp and Assembly all beat out Perl, and Fortran is also above Python, then TCL and then Java. So Java's tenth, with a half percent of code, and there's a lot more variety than you would imply.

GPS = global positioning system (but you knew that)

ephemeris calculation = modeling a satellite's orbit based on a handful of numbers, demonstrated by http://ssd.jpl.nasa.gov/eph_help.html

RINEX = Receiver Independent Exchange Format, http://www.ngs.noaa.gov/CORS/Rinex2.html

SLOC = source lines of code .. a simplistic and rather poor metric used to gauge the effort required to develop software. http://www.dwheeler.com/sloc/

COCOMO = an obsolete software development cost model http://www.jsc.nasa.gov/bu2/COCOMO.html

The answer: there are none.
Originally published March 26, 2001

gewg_

Note that these are year 2000 U.S. dollars.

SLOCCount measures "physical SLOC", and thus ignores blank lines and comment-only lines (including Perl PODs). It's not the same as "wc -l". Go read its documentation if you want to understand exactly what it does; it has a lengthy description of exactly what it measures, and why, along with references to the (substantial) research literature behind such tools.

1. It would cost over $1 billion (a Gigabuck) to develop this Linux distribution by conventional proprietary means in the U.S. (in year 2000 U.S. dollars).
2. It includes over 30 million physical source lines of code (SLOC).
3. It would have required about 8,000 person-years of development time, as determined using the widely-used basic COCOMO model.
4. Red Hat Linux 7.1 represents over a 60% increase in size, effort, and traditional development costs over Red Hat Linux 6.2 (which was released about one year earlier).

Another related paper (that I didn't write) is Counting Potatoes: The size of Debian 2.2. They found that Debian 2.2 includes more than 55 million physical SLOC, and would have cost nearly $1.9 billion USD using over 14,000 person-years to develop using traditional proprietary techniques.

So what's the purpose of all these studies? Insight. There are all sorts of limitations in any measure, including any source lines of code (SLOC) measure. But, in spite of those limitations, there are things you can learn. Using tools (like SLOC counting tools) to measure software can help you understand things about the software, as long as you understand the limitations of the measure.

In particular, many studies have shown that SLOC is very strongly related to effort (so much so that you can even use equations to predict it). If you want to determine effort in CPAN, you can't just go ask people; few open source software / Free Software (OSS/FS) developers record exactly how much effort they invested. So, these kinds of measures are really helpful for estimating how much effort went into developing the software. Obviously, not all effort is equal (a genius can turn a hard problem into an easy one). And not all code is good, or even useful. But if you want to understand and measure effort, then these measures do have a value. In particular, these results have shown that OSS/FS can scale up to large projects requiring large amounts of effort.

1. It would cost over $1 billion (a Gigabuck) to develop this Linux distribution by conventional proprietary means in the U.S. (in year 2000 U.S. dollars).
2. It includes over 30 million physical source lines of code (SLOC).
3. It would have required about 8,000 person-years of development time, as determined using the widely-used basic COCOMO model.
4. Red Hat Linux 7.1 represents over a 60% increase in size, effort, and traditional development costs over Red Hat Linux 6.2 (which was released about one year earlier).

Another related paper (that I didn't write) is Counting Potatoes: The size of Debian 2.2. They found that Debian 2.2 includes more than 55 million physical SLOC, and would have cost nearly $1.9 billion USD using over 14,000 person-years to develop using traditional proprietary techniques.

So what's the purpose of all these studies? Insight. There are all sorts of limitations in any measure, including any source lines of code (SLOC) measure. But, in spite of those limitations, there are things you can learn. Using tools (like SLOC counting tools) to measure software can help you understand things about the software, as long as you understand the limitations of the measure.

In particular, many studies have shown that SLOC is very strongly related to effort (so much so that you can even use equations to predict it). If you want to determine effort in CPAN, you can't just go ask people; few open source software / Free Software (OSS/FS) developers record exactly how much effort they invested. So, these kinds of measures are really helpful for estimating how much effort went into developing the software. Obviously, not all effort is equal (a genius can turn a hard problem into an easy one). And not all code is good, or even useful. But if you want to understand and measure effort, then these measures do have a value. In particular, these results have shown that OSS/FS can scale up to large projects requiring large amounts of effort.

SLOCOUNT?

It's not an acronym. It's a program to count lines of code and estimate cost to produce said lines.

Check out the homepage for SLOCCount - a set of tools for counting physical Source Lines of Code (SLOC).

Here, I'll repost the link from the article you never read:

sloccount

More details on this story are in my appendix The Cautionary Tale of XFree86, part of my essay Make Your Open Source Software GPL-Compatible. Or Else.

More details on this story are in my appendix The Cautionary Tale of XFree86, part of my essay Make Your Open Source Software GPL-Compatible. Or Else.

In the 80's, there was a GCC Public License, an Emacs Public License, and a GDB Public License. This made it awkward for people to mix the source code of these projects, so Stallman wrote a General Public License. The goal was to enable projects to share code. (remove the legal reading and interpretation and let hackers hack.)

Every now and again, someone who doesn't know the history, repeats it's mistakes.

Stallman asks people to use the GPL, but he doesn't take issue with people using other compatible licenses. He asks people to move to a compatible license - not necessarily the GPL - if their current license is incompatible. He's seen the problem, he's seen the solution, he tries to show people the two.

Another on-topic article is David Wheelers "Make Your Open Source Software GPL-Compatible. Or Else."

Language SLOC (%)
C 21461450 (71.18%)
C++ 4575907 (15.18%)
Shell (Bourne-like) 793238 (2.63%)
Lisp 722430 (2.40%)
Assembly 565536 (1.88%)
Perl 562900 (1.87%)
Fortran 493297 (1.64%)
Python 285050 (0.95%)
Tcl 213014 (0.71%)
Java 147285 (0.49%)