The Ogg project has nothing to do with the common surname 'Ogg'. Nor is it named after 'Nanny Ogg' from the Terry Pratchett book _Wyrd Sisters_.
... Vorbis, on the other hand is named after the Terry Pratchett character from the book _Small Gods_.
"Ogg" actually comes from Netrek. I think that's pretty cool, since I used to play Netrek. They've actually got a couple of things with "Ogg" in the name. There's Ogg Vorbis, and Ogg Squish. I think they should make something called "Ogg Base". (okay, lame Netrek joke)
Incidently, that page also has an explanation of their logo. That's Thor apparently, not Jesus or a picture of RMS from back when he was Mr. Universe...
I've got Linux on my machine, and I'd like to try out BSD. Is there a "HOWTO" or some such document somewhere that outlines how to instal OpenBSD on a system that's already got Linux, so that I could dual-boot?
Also, does OpenBSD have ext2 support? Since it's got Linux binary emulation, it would be nice if I could just load the Linux executables off of my existing ext2 filesystem...
The reusable shuttlecraft for now (in fact everything is reusable except for the big orange tank which fuels the shuttle burners; the two white O2 containers are picked up and reused) and in the future something that will be competley reusuable except for the fuel cost.
Those aren't O2 containers. The big orange tank contains both liquid hydrogen and liquid oxygen. The two white things are solid rocket boosters.
One of my pet hates about gmc is that you can't make the tool-bar icons at the top small.
Um... why not?
GNOME Control Center - User Interface - Applications - uncheck "Toolbars have text labels"
Two nits:
That's really hidden. Users don't expect to have to run a different program to change the behavior of the program they're in. (there are a few things about the GNOME Control Center that don't seem particularly well thought-out, from a usability point of view...)
Have you actually tried this? It doesn't work, at least on my machine. Looks like a bug in gmc.
Boyer-Moore, on the other hand, uses a similar idea to KMP, but to much better advantage. A typical search pattern will let you skip large chunks of data (when there is no match) where KMP would have to examine every character.
Huffman encoding is exactly the same thing as Shannon-Fano encoding, which predates it by at least 10 years.
No, it isn't. Huffman generates optimal codes. Shannon-Fano does not. Yes, Huffman is esentially a "tweak" of Shannon-Fano (the code generation is done in the reverse order), but it's a very powerful tweak that turns a "pretty good" algorthm into an "optimal" algorithm. (given certain constraints. I know arithmetric encoding is better in many ways.)
Bresenham's line drawing algorithm is nothing but solving the equation of a line, only with repeated subtractions instead of a division. (Faster on processors with slow floating point.) Including this would be ridicolous.
All algorithms are nothing but performing a bunch of simple computations to achive some bigger result. Bresenham's algorithms have become "staples" of computer graphics though.
Incidently, Bresenham's algorithm is useful even on machines that don't have slow floating point. Bresenham produces "nice looking" lines. Simple linear interpolation produces ugly lines. If you don't know what I mean, try drawing some diagonal lines in GIMP using the pencil and a 1x1 brush. See how ugly they are? That's because GIMP uses linear interpolation, rather than Bresenham. I hate to say it, but even MS Paint produces nicer looking lines, simply because it uses Bresenham. (and if you think how it looks isn't important... sorry, but that's the way it is in graphics...)
I think you mean Binary Splay Partition algorithms, which truly also are in widespread use. But in such a list it would be better to include some of the real raytracing algorithms.
No, I meant Binary Space Partitioning trees aka BSP trees, which are used for all sorts of things in graphics including polyhedral rendering systems, raytracing optimization, polyhedral set operations, and collision detection. Yes, there are other techniques for achieving all of these, but BSP trees show amazing versatility.
Incidently, I've never heard of "Binary Splay Partition algorithms". Are you talking about binary splay trees?
KMP search is hardly in use except in very special cases. There are more efficient algorithms around.
Yes, I made a mistake. KMP and Boyer-Moore are very similar (in much the same way that Shannon-Fano an Huffman are similar, actually...), but Boyer-Moore is clearly the superior algorithm. I think Boyer-Moore and KMP have become intertwined in my head, because I learned both of them at the same time. (perhaps also because "the BM algorithm" has nasty connotations...)
Okay, strike my vote for KMP, and add one more vote for Boyer-Moore...
In any case, the list I posted was not intended to be "the 9 best algorthms of the 20th century". It was more like "the 9 best non-numerical algorithms that came to me as I was posting to Slashdot". So take it with a grain of salt. I know I missed some great ones in there... I didn't have any tree balancing algorithms in the list, for example. Skip-lists are also pretty cool, and probably deserve a mention, despite the fact that almost no-one seems to use them. Systems algorithms like process scheduling algorithms, caching algorithms, and even the elevator algorithm (used for scheduling requests to "seekable" devices like hard drives) probably deserve a mention too. And how about database algorithms, like the various join algorithms? Or the numerous AI algorithms? A "top 10" list is really too short. We really need a "top 100" list...
Code that's already been written is no longer worth paying for, because the author clearly needs no more incentive than he got to write the code.
Let me get this straight... All that matters is that the work gets done, because once that's happened, the worker clearly needs no more incentive, since they've already done the work. So if you can trick someone into doing work for you, that's okay, and it doesn't matter if they're actually rewarded for what they produce?
Writing software and distributing software are both valuable services, and there's no reason to tie your reward for one to your skill in the other.
That's precisely what's happening in open source today though. Devlopers don't get paid, distributors do. If you want to get paid for development, you need to work for a distributor. And the only reason distributors even bother to pay the developers is PR. For distributors, paying developers is an expense, because their competitors benefit from it just as much as they do.
We should be commissioning new Free Software we need as works for hire.
That's fine. But assuming it'll take a team of 10 programmers at least a year to write the next "Killer App", do you have the roughly $1,000,000 to pay their salaries? Chances are you don't. And why would you even be willing to pay that much? One person can't get that much use out of a word processor.
Software takes a lot of time and money to develop. Certainly a lot more than the average individual can afford. Once a piece of software is developed, it can be used by many people though. It seems reasonable to require that the people who use it pay for the the costs of development. The cost becomes ammortized over the set of users.
It also seems reasonable that if a piece of software is useful to many people, then the developers of that software should be rewarded proportionatly. A free market economy with copyright is a reasonably good approximation of this. Without copyright laws, the whole cost of development would have to be paid up front.
I'm not surprised that the Fortran compiler is included. Like it or not, Fortran is the grand-daddy of high-level languages for science and numerical apps.
Like it or not, "The Fortran Optimizing Compiler" is not an algorithm. There are numerous Fortran compilers available, and each has its own algorithms (note the 's') for performing optimization. It's like saying "what's the best vehicle of the 20th century" and answering "interstate freeways". Yes, they help transporation, but...
Yikes, an awful lot of those were scientific/numerical computation algorithms. The only "pure CS" algorithm on the list was quicksort.
And the Fortran optimization one is... well, that's not really an "algorithm", now is it? It's a whole bunch of algorithms, and presumably each Fortran compiler does different things to optimize. Again, the numerical/scientific bias is obvious though... who else would use Fortran today?:-)
Some algorithms (and data structures) I'd nominate are (note that I'm purposely avoiding numerical algorithms here, because the article aleady lists more than enough good ones):
Dijkstra's Algorithm
Heaps and Heap sort
Huffman Encoding
Extendible Hashing
Converting a regular expression into a minimal DFA
Digital trie
Bresenham's Line Algorithm
Binary Space Partitioning trees, and related algorithms (rendering, set operations, etc.)
The license may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale.
So if you mean "free" as in $0 (gratis), yes. If something is open source you can't practically charge for the code, because people are able to get the same code for free. That's why the open source economy has become one of "who has the prettiest box, and the best tech support?" Code isn't worth paying for, to the open source zealot.
Of course, the title for this article is nothing but misleading. The Microsoft thing has nothing to do with "open source". It has only to do with them making portions of their source "available", which is a completely different story.
Perhaps a disclaimer too. You really don't want people using Perl scripts to manage a nuclear reactor or a life-support system, and then coming back and blaming you when things go wrong.
Here's a really contrived example... You open your code, giving your competitors an advantage, but making everyone more efficient and allowing the industry to expand the market.
That really is a contrived example...:-)
I don't think that if Nike gave Reebok a better accounting system (even assuming the relative scales you suggested) that it would "expand the market" in any way that would end up being beneficial to Nike. I don't deny that there may be other situations where this situation could be true. It would be interesting to determine how one could identify those pieces of software that would result in a mutually beneficial "market expansion", as opposed to software that would just give your competitors an edge.
One area where this may be true is the area of "B2B middleware". (I may be seriously abusing some buzzwords here...) Another, hopefully less contrived, example: If Nike released the portion of their purchasing/inventory system that communicated with their suppliers, that might cause more suppliers to become "compatible" with that software, allowing Nike to more efficiently get supplies from more sources. The fact that Reebok would then also be able to use this software wouldn't hurt Nike as much as releasing the software for suppliers would have helped. By having it completely open, it would encourage more suppliers to use it, than if they made it available to suppliers only, because then suppliers would know they're not getting locked in to Nike.
It looks like the key thing here (at least in this example) is interoperability. If you want the people you work with to be more interoperable with you, it might make business sense to release some code. By making it open, instead of on available to the people you work with, it encourages others to standardize on your interoperability layer. That in turn could expand the whole market.
In any case, my whole point in this thread has been that you can't just blindly say "we don't sell this software, so let's just give it away", because giving it away can, in many cases, give your competitors an edge. Instead of being an open source zealot and driving your company out of business, you've got to think about what advantages you'll get from releasing the software. Hopefully, those advantages will be at least as great as the implicit disadvantage caused by your competitors getting a free ride. If not, however, it's probably best to keep the software closed.
Pewople seem to ignore that there's more than profit to a business, there's also maintenance just alike any sort of physical or abstract machinery.
Since I'm not a suit, I've never heard the term "depend on commercially". To me, seemed logical that anything that a commercial entity depends on, whether for direct profit, internal infrastructure, or maintenance purposes, is something that it "depends on commercially". Apparently that isn't the standard definition.
Sure, other companies may be more efficent because of it, but I'm sure that they'd be putting as much time into supporting it as you are, so I don't see much of a difference there.
Except you put a huge amount of time and effort developing it in the first place. Sure, you might get a couple of bug fixes, but in return for possibly enabling a significant improvement in the efficiency of your competitors. It's far less risky to just keep the code closed.
"Depend on commercially" means selling it to make a profit. Nike doesn't sell their accounting solution, but I dare say that their business would be in big trouble if they didn't use it.
If that's your definition, then the answer to the original question "If you use a piece of software that your business doesn't depend on, commercially, why not free it?" the answer should be obvious.
Using your example, if Nike spent years developing a very efficient accounting system, and then open-sourced it, a competitor (let's just say Reebok) might say "hey, that's a lot more efficient than the system we use". Reebok could then start using it, save a lot of money with the more efficient system, and put the money saved towards making themselves compete with Nike better (perhaps through advertising, lowering their prices, or spending more on R&D). As unlikely as it may seem that a competitor would just start using the software, why would Nike want to take the chance? (and if nobody is going to use the software, who cares if it's open or not?)
Further it is interesting to note that "open-source" software companies have to be very heavily branded. Frequently the only edge they have over competitors is their brand name.
And this is one of my big complaints with open source. Companies can no longer compete on their technical merits, because everyone else can copy your code, so why bother improving the code? There's basically two strategies that work well when selling open source software:
Make pretty boxes, and advertise like crazy. Inlcluding bumper stickers in the box is a good way to get lots of free advertising. Good PR is essential, you want to become known as the defacto brand. If you're successful, the people looking for "quality" will buy from you, despite the fact that you ship virtually the same software as all of your competitors. (aka, the Red Hat strategy)
Sell as much software as cheap as possible. PR is less important (just don't do anything stupid). The cheapskates and people "in the know" but without a good network connection and/or CD burner will buy from you. (aka, the Cheapbytes strategy)
Note that neither of these strategies requires that the distributors actually produce any code. Code production is done at a loss, because your competitors get to use the code you produce. The only real reason to produce code for these companies is PR. Of course, that really only applies if you're using strategy number 1.
I regularly use VBScript in my Word documents, but rarely for much more than automated paragraph formatting.
Out of curiosity, why do you need a Turing complete programming language to do paragraph formatting? I just can't imagine what you can pratically do with VBScript wrt paragraph formatting that you can't do as easily, or even easier, without VBScript.
The GPL does not, and can not deprive one from selling one's own creation. It can do even less to deprive a third party from selling your creation
Looks to me like "through your written words, you've completely reversed the meaning of the thought you seem to be trying to convey." Since it can do even less to deprive a third part from selling your creation (your own words), and that third party only has to press CD's and make pretty boxes, rather than actually spending a significant amount of time developing code, doesn't it stand to reason that that third part will make a lot more money off of your creation than you will. Especially if they're more well known than you are, and are better at "adding value" through things like pretty boxes or recognizable logos. Case in point: Red Hat vs Joe Linux Developer.
How much free software have you actually paid for? Now how much of that money went to the developers, and not to a distributor? Should software developers really have to beg for donations (like the FSF) when they're contributing something useful?
While I think open source and free software are great in many ways (which is why I've worked on several projects), this isn't a world where most developers can actually make a reasonable living by writing "free software" full time. Yes, RMS would love people to make money writing GPL'ed software. The problem is that no-one has come up with a business model for open source that's viable for developers (as opposed to distributors). RMS likes to claim that GPL doesn't stop you from selling your software. No it doesn't stop you, not dirrectly. It makes it pretty damn impractical though.
Slashdot Mirror
Actually, if you look at the Xiphophorus names and logos page, you'll see that they explicitly state:
"Ogg" actually comes from Netrek. I think that's pretty cool, since I used to play Netrek. They've actually got a couple of things with "Ogg" in the name. There's Ogg Vorbis, and Ogg Squish. I think they should make something called "Ogg Base". (okay, lame Netrek joke)
Incidently, that page also has an explanation of their logo. That's Thor apparently, not Jesus or a picture of RMS from back when he was Mr. Universe...
I've got Linux on my machine, and I'd like to try out BSD. Is there a "HOWTO" or some such document somewhere that outlines how to instal OpenBSD on a system that's already got Linux, so that I could dual-boot?
Also, does OpenBSD have ext2 support? Since it's got Linux binary emulation, it would be nice if I could just load the Linux executables off of my existing ext2 filesystem...
The reusable shuttlecraft for now (in fact everything is reusable except for the big orange tank which fuels the shuttle burners; the two white O2 containers are picked up and reused) and in the future something that will be competley reusuable except for the fuel cost.
Those aren't O2 containers. The big orange tank contains both liquid hydrogen and liquid oxygen. The two white things are solid rocket boosters.
Hardware vendors pay Microsoft a lot of money for the right to put those stickers on their boxes.
Every time I see one of those stickers on a machine, I peel it off, and stick it on the closest trash can.
If you run NT and crash, would it be the "Blue 'Balls of Death"?
"Ever since I switched to UNIX, I don't have any blue balls..."
GNOME Control Center - User Interface - Applications - uncheck "Toolbars have text labels"
Two nits:
Boyer-Moore, on the other hand, uses a similar idea to KMP, but to much better advantage. A typical search pattern will let you skip large chunks of data (when there is no match) where KMP would have to examine every character.
You're right. I got them confused.
Huffman encoding is exactly the same thing as Shannon-Fano encoding, which predates it by at least 10 years.
No, it isn't. Huffman generates optimal codes. Shannon-Fano does not. Yes, Huffman is esentially a "tweak" of Shannon-Fano (the code generation is done in the reverse order), but it's a very powerful tweak that turns a "pretty good" algorthm into an "optimal" algorithm. (given certain constraints. I know arithmetric encoding is better in many ways.)
Bresenham's line drawing algorithm is nothing but solving the equation of a line, only with repeated subtractions instead of a division. (Faster on processors with slow floating point.) Including this would be ridicolous.
All algorithms are nothing but performing a bunch of simple computations to achive some bigger result. Bresenham's algorithms have become "staples" of computer graphics though.
Incidently, Bresenham's algorithm is useful even on machines that don't have slow floating point. Bresenham produces "nice looking" lines. Simple linear interpolation produces ugly lines. If you don't know what I mean, try drawing some diagonal lines in GIMP using the pencil and a 1x1 brush. See how ugly they are? That's because GIMP uses linear interpolation, rather than Bresenham. I hate to say it, but even MS Paint produces nicer looking lines, simply because it uses Bresenham. (and if you think how it looks isn't important... sorry, but that's the way it is in graphics...)
I think you mean Binary Splay Partition algorithms, which truly also are in widespread use. But in such a list it would be better to include some of the real raytracing algorithms.
No, I meant Binary Space Partitioning trees aka BSP trees, which are used for all sorts of things in graphics including polyhedral rendering systems, raytracing optimization, polyhedral set operations, and collision detection. Yes, there are other techniques for achieving all of these, but BSP trees show amazing versatility.
Incidently, I've never heard of "Binary Splay Partition algorithms". Are you talking about binary splay trees?
KMP search is hardly in use except in very special cases. There are more efficient algorithms around.
Yes, I made a mistake. KMP and Boyer-Moore are very similar (in much the same way that Shannon-Fano an Huffman are similar, actually...), but Boyer-Moore is clearly the superior algorithm. I think Boyer-Moore and KMP have become intertwined in my head, because I learned both of them at the same time. (perhaps also because "the BM algorithm" has nasty connotations...)
Okay, strike my vote for KMP, and add one more vote for Boyer-Moore...
In any case, the list I posted was not intended to be "the 9 best algorthms of the 20th century". It was more like "the 9 best non-numerical algorithms that came to me as I was posting to Slashdot". So take it with a grain of salt. I know I missed some great ones in there... I didn't have any tree balancing algorithms in the list, for example. Skip-lists are also pretty cool, and probably deserve a mention, despite the fact that almost no-one seems to use them. Systems algorithms like process scheduling algorithms, caching algorithms, and even the elevator algorithm (used for scheduling requests to "seekable" devices like hard drives) probably deserve a mention too. And how about database algorithms, like the various join algorithms? Or the numerous AI algorithms? A "top 10" list is really too short. We really need a "top 100" list...
Code that's already been written is no longer worth paying for, because the author clearly needs no more incentive than he got to write the code.
Let me get this straight... All that matters is that the work gets done, because once that's happened, the worker clearly needs no more incentive, since they've already done the work. So if you can trick someone into doing work for you, that's okay, and it doesn't matter if they're actually rewarded for what they produce?
Writing software and distributing software are both valuable services, and there's no reason to tie your reward for one to your skill in the other.
That's precisely what's happening in open source today though. Devlopers don't get paid, distributors do. If you want to get paid for development, you need to work for a distributor. And the only reason distributors even bother to pay the developers is PR. For distributors, paying developers is an expense, because their competitors benefit from it just as much as they do.
We should be commissioning new Free Software we need as works for hire.
That's fine. But assuming it'll take a team of 10 programmers at least a year to write the next "Killer App", do you have the roughly $1,000,000 to pay their salaries? Chances are you don't. And why would you even be willing to pay that much? One person can't get that much use out of a word processor.
Software takes a lot of time and money to develop. Certainly a lot more than the average individual can afford. Once a piece of software is developed, it can be used by many people though. It seems reasonable to require that the people who use it pay for the the costs of development. The cost becomes ammortized over the set of users.
It also seems reasonable that if a piece of software is useful to many people, then the developers of that software should be rewarded proportionatly. A free market economy with copyright is a reasonably good approximation of this. Without copyright laws, the whole cost of development would have to be paid up front.
Dictionary of Algorithms, Data Structures, and Problems is a pretty good "dictionary" of algorithms. Another good place, if you know the name of the algorithm, is of course Google...
I'm not surprised that the Fortran compiler is included. Like it or not, Fortran is the grand-daddy of high-level languages for science and numerical apps.
Like it or not, "The Fortran Optimizing Compiler" is not an algorithm. There are numerous Fortran compilers available, and each has its own algorithms (note the 's') for performing optimization. It's like saying "what's the best vehicle of the 20th century" and answering "interstate freeways". Yes, they help transporation, but...
And the Fortran optimization one is... well, that's not really an "algorithm", now is it? It's a whole bunch of algorithms, and presumably each Fortran compiler does different things to optimize. Again, the numerical/scientific bias is obvious though... who else would use Fortran today?
Some algorithms (and data structures) I'd nominate are (note that I'm purposely avoiding numerical algorithms here, because the article aleady lists more than enough good ones):
According to The Open Source Definition:
The license may not restrict any party from selling or giving away the software as a component of an aggregate software
distribution containing programs from several different sources. The license may not require a royalty or other fee for such
sale.
So if you mean "free" as in $0 (gratis), yes. If something is open source you can't practically charge for the code, because people are able to get the same code for free. That's why the open source economy has become one of "who has the prettiest box, and the best tech support?" Code isn't worth paying for, to the open source zealot.
Of course, the title for this article is nothing but misleading. The Microsoft thing has nothing to do with "open source". It has only to do with them making portions of their source "available", which is a completely different story.
I believe that the only legal information a program needs to have is:
*Copyright notice (if any)
*Trademark notice (if any)
*Patent notice (if any)
*Warranty statement.
Perhaps a disclaimer too. You really don't want people using Perl scripts to manage a nuclear reactor or a life-support system, and then coming back and blaming you when things go wrong.
shouldn't the plural of radius be radiii?
No, it's radii. (only two i's)
Here's a really contrived example... You open your code, giving your competitors an advantage, but making everyone more efficient and allowing the industry to expand the market.
:-)
That really is a contrived example...
I don't think that if Nike gave Reebok a better accounting system (even assuming the relative scales you suggested) that it would "expand the market" in any way that would end up being beneficial to Nike. I don't deny that there may be other situations where this situation could be true. It would be interesting to determine how one could identify those pieces of software that would result in a mutually beneficial "market expansion", as opposed to software that would just give your competitors an edge.
One area where this may be true is the area of "B2B middleware". (I may be seriously abusing some buzzwords here...) Another, hopefully less contrived, example: If Nike released the portion of their purchasing/inventory system that communicated with their suppliers, that might cause more suppliers to become "compatible" with that software, allowing Nike to more efficiently get supplies from more sources. The fact that Reebok would then also be able to use this software wouldn't hurt Nike as much as releasing the software for suppliers would have helped. By having it completely open, it would encourage more suppliers to use it, than if they made it available to suppliers only, because then suppliers would know they're not getting locked in to Nike.
It looks like the key thing here (at least in this example) is interoperability. If you want the people you work with to be more interoperable with you, it might make business sense to release some code. By making it open, instead of on available to the people you work with, it encourages others to standardize on your interoperability layer. That in turn could expand the whole market.
In any case, my whole point in this thread has been that you can't just blindly say "we don't sell this software, so let's just give it away", because giving it away can, in many cases, give your competitors an edge. Instead of being an open source zealot and driving your company out of business, you've got to think about what advantages you'll get from releasing the software. Hopefully, those advantages will be at least as great as the implicit disadvantage caused by your competitors getting a free ride. If not, however, it's probably best to keep the software closed.
Pewople seem to ignore that there's more than profit to a business, there's also maintenance just alike any sort of physical or abstract machinery.
Since I'm not a suit, I've never heard the term "depend on commercially". To me, seemed logical that anything that a commercial entity depends on, whether for direct profit, internal infrastructure, or maintenance purposes, is something that it "depends on commercially". Apparently that isn't the standard definition.
Sure, other companies may be more efficent because of it, but I'm sure that they'd be putting as much time into supporting it as you are, so I don't see much of a difference there.
Except you put a huge amount of time and effort developing it in the first place. Sure, you might get a couple of bug fixes, but in return for possibly enabling a significant improvement in the efficiency of your competitors. It's far less risky to just keep the code closed.
"Depend on commercially" means selling it to make a profit. Nike doesn't sell their accounting solution, but I dare say that their business would be in big trouble if they didn't use it.
If that's your definition, then the answer to the original question "If you use a piece of software that your business doesn't depend on, commercially, why not free it?" the answer should be obvious.
Using your example, if Nike spent years developing a very efficient accounting system, and then open-sourced it, a competitor (let's just say Reebok) might say "hey, that's a lot more efficient than the system we use". Reebok could then start using it, save a lot of money with the more efficient system, and put the money saved towards making themselves compete with Nike better (perhaps through advertising, lowering their prices, or spending more on R&D). As unlikely as it may seem that a competitor would just start using the software, why would Nike want to take the chance? (and if nobody is going to use the software, who cares if it's open or not?)
If you use a piece of software that your business doesn't depend on, commercially, why not free it?
If you use a piece of software that your business doesn't depend on, commercially, why are you using it?
And this is one of my big complaints with open source. Companies can no longer compete on their technical merits, because everyone else can copy your code, so why bother improving the code? There's basically two strategies that work well when selling open source software:
- Make pretty boxes, and advertise like crazy. Inlcluding bumper stickers in the box is a good way to get lots of free advertising. Good PR is essential, you want to become known as the defacto brand. If you're successful, the people looking for "quality" will buy from you, despite the fact that you ship virtually the same software as all of your competitors. (aka, the Red Hat strategy)
- Sell as much software as cheap as possible. PR is less important (just don't do anything stupid). The cheapskates and people "in the know" but without a good network connection and/or CD burner will buy from you. (aka, the Cheapbytes strategy)
Note that neither of these strategies requires that the distributors actually produce any code. Code production is done at a loss, because your competitors get to use the code you produce. The only real reason to produce code for these companies is PR. Of course, that really only applies if you're using strategy number 1.IIRC, VBScript wasn't only intended for paragraph formatting.
Yes, but the person I was responding to said:
I regularly use VBScript in my Word documents, but rarely for much more than automated paragraph formatting. [emphasis mine]
Hence, my curiosity about what kind of paragraph formatting one could possibly be doing that requires a Turing complete language.
I regularly use VBScript in my Word documents, but rarely for much more than automated paragraph formatting.
Out of curiosity, why do you need a Turing complete programming language to do paragraph formatting? I just can't imagine what you can pratically do with VBScript wrt paragraph formatting that you can't do as easily, or even easier, without VBScript.
The GPL does not, and can not deprive one from selling one's own creation. It can do even less to deprive a third party from selling your creation
Looks to me like "through your written words, you've completely reversed the meaning of the thought you seem to be trying to convey." Since it can do even less to deprive a third part from selling your creation (your own words), and that third party only has to press CD's and make pretty boxes, rather than actually spending a significant amount of time developing code, doesn't it stand to reason that that third part will make a lot more money off of your creation than you will. Especially if they're more well known than you are, and are better at "adding value" through things like pretty boxes or recognizable logos. Case in point: Red Hat vs Joe Linux Developer.
How much free software have you actually paid for? Now how much of that money went to the developers, and not to a distributor? Should software developers really have to beg for donations (like the FSF) when they're contributing something useful?
While I think open source and free software are great in many ways (which is why I've worked on several projects), this isn't a world where most developers can actually make a reasonable living by writing "free software" full time. Yes, RMS would love people to make money writing GPL'ed software. The problem is that no-one has come up with a business model for open source that's viable for developers (as opposed to distributors). RMS likes to claim that GPL doesn't stop you from selling your software. No it doesn't stop you, not dirrectly. It makes it pretty damn impractical though.