You seem to be confusing "no one loses anything if someone makes a copy" with "no one loses anything if the internals of this program are made public".
These are two very different beasts.
The first sentence refers to a business model based on selling copies.
The second sentence refers to trade secrets.
If the code implement some secret method giving the company a competitive advantage, making it public might make the company lose this advantage.
If the code contains some obvious security flaws (e.g hardcoded passwords), making it public might decrease/increase the security of systems running this code.
I think this is what we're dealing with here (is the software refered to in TFA meant to be sold as off-the-shelf software?)
Nichols also thinks coding tools will become powerful enough in the next decade that the demand for actual, dedicated coders will diminish
Then, we will tackle more difficult programming problems, like we always have.
The sole action of rewriting a piece of code doesn't magically make it faster. Nor does it make cleaner, or more stable.
You have to put something more into the equation. Like a new programming language, or a new team.
You might want to have a look at Joel Spolsky's post named "Things You Should Never Do", explaining why a big rewrite is almost always a bad idea.
Slashdot Mirror
Pirate here.
You seem to be confusing "no one loses anything if someone makes a copy" with "no one loses anything if the internals of this program are made public".
These are two very different beasts.
The first sentence refers to a business model based on selling copies. The second sentence refers to trade secrets. If the code implement some secret method giving the company a competitive advantage, making it public might make the company lose this advantage. If the code contains some obvious security flaws (e.g hardcoded passwords), making it public might decrease/increase the security of systems running this code. I think this is what we're dealing with here (is the software refered to in TFA meant to be sold as off-the-shelf software?)
Nichols also thinks coding tools will become powerful enough in the next decade that the demand for actual, dedicated coders will diminish
Then, we will tackle more difficult programming problems, like we always have.
The sole action of rewriting a piece of code doesn't magically make it faster. Nor does it make cleaner, or more stable. You have to put something more into the equation. Like a new programming language, or a new team. You might want to have a look at Joel Spolsky's post named "Things You Should Never Do", explaining why a big rewrite is almost always a bad idea.