Posted by
michael
on from the secrets-and-lies dept.
Tim writes "Tim Bray and Microsoft's Joe Marini are doing a back-and forth on Open Source. Tim serves (open everything), Joe returns (secret-source is good business) and Tim volleys (the closed-source niche is shrinking)."
My code is meant to be secret. If anyone ever saw it, I'd be ridiculed for my terrible coding style and lack of programming prowess. I don't think I could survive the shame.
Text of joemarini.com link
by
Anonymous Coward
·
· Score: 5, Informative
Some Things are Meant to be Secret
I was reading an interesting post by Tim Bray today about how he thinks everything should be open.
Now, most of my experience is in the packaged software world and not that of IT departments in big companies, so my view is somewhat different than his. I can understand why a customer company that is basing its business of a piece of software might want the right to look inside it to see what is going on, but that doesn't necessarily mean that it's a great idea across the rest of the software industry.
Here's why - when you develop a piece of packaged software, sometimes you only have a short amount of time to establish your product as a viable entity in the marketplace. If your competitors could just look inside your source code to see how you accomplished a certain feature that their product doesn't provide, then your fledgling product would be neutralized almost instantly.
When I worked at Quark, we had a heated rivalry with Aldus Corp (now Adobe) and their product, PageMaker. Quark introduced several key desktop publishing features in version 3.0 that essentially cemented our lead over PageMaker in the DTP market. Had Aldus been able to get a hold of our source code, Quark's trade secrets, along with the enormous amount of money we had invested in R&D to develop QuarkXPress 3 would have been for naught. Aldus would simply have copied our algorithms and updated their product to match ours.
I can go on and on with these examples - Dreamweaver, for example, had a fantastic feature whereby it would preserve the source code formatting that an HTML developer typed in. FrontPage didn't have it. GoLive didn't have it. PageMill didn't have it. NetObjects Fusion didn't have it. We spent a lot of time and money developing that feature, and it ended up being a key competitive advantage for us.
Now imagine that you're the one competing with somebody like Macromedia, or Adobe, or IBM. You have a great idea for a product, you've done your market research, and you want to make a go of it. Now imagine telling potential investors and customers that yes, because your product is Open Source, anybody can read the code and see how you solved a particularly prickly problem that up until now nobody else has tackled well. How much investment capital do you think you'll get? How many customers?
Tim says that "the days when the recipe for success included wrapping the engineering in a veil of secrecy, those days are gone". I don't agree - I think that this is one area where the very idea of Open Source just falls flat on its face. Tim, how do you protect your competitive advantage when your competitors can just look at your source code and cherry-pick the best ideas? Not every company in the world can just become a services company and compete on price. There's a reason why it's called "intellectual property."
Re:Text of joemarini.com link
by
dgatwood
·
· Score: 5, Insightful
Now, most of my experience is in the packaged software world and not that of IT departments in big companies, so my view is somewhat different than his. I can understand why a customer company that is basing its business of a piece of software might want the right to look inside it to see what is going on, but that doesn't necessarily mean that it's a great idea across the rest of the software industry.
Here's why - when you develop a piece of packaged software, sometimes you only have a short amount of time to establish your product as a viable entity in the marketplace. If your competitors could just look inside your source code to see how you accomplished a certain feature that their product doesn't provide, then your fledgling product would be neutralized almost instantly.
There are three problems with that argument:
All software can be trivially recreated. If a company wants a feature, they don't need to steal your company's code. It wouldn't do them a bit of good because the time to integrate your code into theirs for almost any feature is almost always greater than the time needed to write it from scratch. The rare exceptions are large features that are almost completely stand-alone tools, in which case even then, the amount of trouble they would get into for stealing it costs far more than writing it themselves.
There is no such thing as a product that businesses don't depend on. And even individual users want some control over their software---at the very least, some assurance that the company won't just abandon it after they've spent hundreds of their hard-earned dollars to buy the program only to find a dozen bugs that they can't work around.
There are very few "particularly prickly" problems anymore outside of the academic world. Commercial software development is difficult because of the difficulty of debugging such large pieces of code. There probably hasn't been a "really prickly" algorithmic problem solved (with the possible exception of game development) in the general-user commercial programming world in two decades, and algorithmic problems are the only ones that closed source really protects. For any other features (like "ooh, that's a cool way to integrate those tools" or "ooh, it keeps the line formatting when parsing HTML") can be trivially rewritten by a programming team of sufficient competence simply looking at what it does and coming up with a good architectural design that supports all of the desired features... usually in a matter of hours or minutes unless it's a really large feature.
The only place where your argument would be valid -might- be in areas like 3-D modeling/animation, audio/video/data compression, and audio/video effects processing, since there's still some algorithmic work being done in those narrow fields. That said, those things make up only a very tiny percentage of software development, and most of it will never be used by the general public (outside of games).
I can't say I'm too interested in the debate -- nothing new here, folks -- but I do like the reference Tim Bray made to Joel Spolsky's essay Things You Should Never Do, Part 1 about the dangers of rewriting code from scratch instead of trying to work with the existing code base. It's an old piece, but I hadn't come across it yet, and I like what he says. Go give it a read, then enjoy your weekend.
Eric
See Wiliam Shatner on my cereal box (soon to be updated)
Simple solution
by
YouHaveSnail
·
· Score: 5, Insightful
The simple solution to this problem/debate, and really the only solution, is to let the market decide in each case. There are many markets where a proprietary solution may in fact be the best solution, and there are others where open source, communally developed software is more likely to succeed.
A good example is the games market. Developing compelling games is a lot of work (just ask the poor schlubs over at EA). Some games are written as a labor of love and may be released as open source projects. Far more often, though, games are produced like movies, using expensive resources and labor. And they often have to be produced on a tight schedule for marketing reasons, so that their release coincides with the release of some movie or holiday buying season or whatever. For these reasons, there are few if any open source games out there, and I don't see that changing anytime soon.
Obviously, there are also many areas in which open source products are kicking the proprietary competition's collective ass. These are usually products which work best if they can run on multiple platforms, meet the needs of lots of different people in different situations, and provide enough value that smart people are willing to spend their time improving and customizing them. Linux, Apache, PHP, etc.
So lets stop worrying about whether open source software is better than proprietary software in all cases or vice versa. It's pretty clear that both bring value to our society and to our economy. Lets instead keep improving the ways we develop products under both systems, and make sure that we maintain an infrastructure that works for both. Software patents are a dumb and harmful idea, but copyright is important and should be respected and protected. Open standards are essential to vibrant markets and useful tools, and we should insist on vendor-neutral bodies to develop and maintain them.
On the contrary
by
eobanb
·
· Score: 5, Insightful
But they are *not* a good example of how a company can succeed by *being* generous
How do you figure? Apple's given a lot back to the open source community, especially in terms of user interface and networking. Yes, Apple used to be very unfriendly to open source, but now it's just as easy to dual boot a Mac with Mac OS X and Linux as it is with a PC. And Apple even directly controls the hardware. But back to software; Apple basically re-wrote KHTML for Safari, and then gave it all back to KDE. Rendezvous is also an important project, largely under Apple direction, that probably wouldn't have otherwise caught on.
And don't even get me started on user interface. Apple might not have contributed to this directly, but have you ever stopped to think how much of Gnome and GTK+ is influenced by the Mac OS? Cosmetically, the two are becoming more alike all the time. Example: GTKFileSelection really really sucked. But then Gnome took an idea straight from Mac OS X and brought us GTKFileChooser, which is way more intuitive and easy to use.
In the future, it'll all be even more prevalent. Jabber is coming to iChat in Tiger, for example. It seems like most, if not all, improvements Apple makes to open source libraries/programs all gets given back to the open source community, which is way more than can be said for a lot of other companies.
So stop bitching.
--
Take off every sig. For great justice.
Re:What happens when it's not secret anymore?
by
INetEngineer
·
· Score: 5, Insightful
Why don't we send a clincher message to people that think source code ought to be "secret", by not giving them any comments, ideas, suggestions, and/or replies, because we want to keep them "secret".
"Hey, what do you think of this software?"
"Can I see the source code?"
"No! I need to be able to sell it!"
"Oh... I think nothing of it."
"What?!"
"I'm a consultant, I need to be able to sell my opinions!"
Oh wait... then we would just be propogating the "secrets".
-- --I smoked my sig.
Re:What happens when it's not secret anymore?
by
Anonymous Coward
·
· Score: 5, Interesting
Software patents are doomed for one simple reason.
The equivalence of two Turing machines is undecidable. Turing proved this as one of the results of the halting problem. Since turing machines are equivalent to algorithms, which are equivalent to recursive functions, this is a statement in mathematics that as such should be sufficient to disallow software patents on the basis that software is a mathematical function.
Where, then, can software patents stand? By definition, patents cover a method, hence an algorithm. Since there exists no way to determine if an algorithm infringes on a given patent, the patent office must backtrack and declare that algorithms need only be *similar to* a patented algorithm to infringe. But this is also undecidable for the same reason. An incredibly complex algorithm that produces the same output, given the same input, as a patented algorithm will be intractable to compare to the patent.
The reason the patent office is spewing software patents is that it has no method for determining prior art, no method for determining functional equivalence, and no method for reasonably denying every software patent after the courts have incorrectly ruled in favor of them.
Note that if you really wish to infringe on a software patent, it will always be relatively easy.
Given a function F(x) that is patented, do the following.
Create a function G(x,y) where y is meaningless, random, or in some way constructed from x such that applying G to x,y is equivalent to applying F to x. If necessary, encode x as y and apply H to y such that H(y) is equivalent to F(x). No patent court will be able to prove the equivalence. Should they rule that simply because two functions *produce similar (not exact, that is intractable) output, despite being vastly dissimilar*, they will have contradicted the very spirit and letter of patent law. The whole point was to issue patents for *specific* methods and devices, and encourage derivations thereof by other inventors. Such is progress. Owning the result of applying a mathematical function to all possible inputs is not progress, it is the darkest feudalism.
Slashdot Mirror
My code is meant to be secret. If anyone ever saw it, I'd be ridiculed for my terrible coding style and lack of programming prowess. I don't think I could survive the shame.
Some Things are Meant to be Secret
I was reading an interesting post by Tim Bray today about how he thinks everything should be open.
Now, most of my experience is in the packaged software world and not that of IT departments in big companies, so my view is somewhat different than his. I can understand why a customer company that is basing its business of a piece of software might want the right to look inside it to see what is going on, but that doesn't necessarily mean that it's a great idea across the rest of the software industry.
Here's why - when you develop a piece of packaged software, sometimes you only have a short amount of time to establish your product as a viable entity in the marketplace. If your competitors could just look inside your source code to see how you accomplished a certain feature that their product doesn't provide, then your fledgling product would be neutralized almost instantly.
When I worked at Quark, we had a heated rivalry with Aldus Corp (now Adobe) and their product, PageMaker. Quark introduced several key desktop publishing features in version 3.0 that essentially cemented our lead over PageMaker in the DTP market. Had Aldus been able to get a hold of our source code, Quark's trade secrets, along with the enormous amount of money we had invested in R&D to develop QuarkXPress 3 would have been for naught. Aldus would simply have copied our algorithms and updated their product to match ours.
I can go on and on with these examples - Dreamweaver, for example, had a fantastic feature whereby it would preserve the source code formatting that an HTML developer typed in. FrontPage didn't have it. GoLive didn't have it. PageMill didn't have it. NetObjects Fusion didn't have it. We spent a lot of time and money developing that feature, and it ended up being a key competitive advantage for us.
Now imagine that you're the one competing with somebody like Macromedia, or Adobe, or IBM. You have a great idea for a product, you've done your market research, and you want to make a go of it. Now imagine telling potential investors and customers that yes, because your product is Open Source, anybody can read the code and see how you solved a particularly prickly problem that up until now nobody else has tackled well. How much investment capital do you think you'll get? How many customers?
Tim says that "the days when the recipe for success included wrapping the engineering in a veil of secrecy, those days are gone". I don't agree - I think that this is one area where the very idea of Open Source just falls flat on its face. Tim, how do you protect your competitive advantage when your competitors can just look at your source code and cherry-pick the best ideas? Not every company in the world can just become a services company and compete on price. There's a reason why it's called "intellectual property."
I can't say I'm too interested in the debate -- nothing new here, folks -- but I do like the reference Tim Bray made to Joel Spolsky's essay Things You Should Never Do, Part 1 about the dangers of rewriting code from scratch instead of trying to work with the existing code base. It's an old piece, but I hadn't come across it yet, and I like what he says. Go give it a read, then enjoy your weekend.
EricSee Wiliam Shatner on my cereal box (soon to be updated)
The simple solution to this problem/debate, and really the only solution, is to let the market decide in each case. There are many markets where a proprietary solution may in fact be the best solution, and there are others where open source, communally developed software is more likely to succeed.
A good example is the games market. Developing compelling games is a lot of work (just ask the poor schlubs over at EA). Some games are written as a labor of love and may be released as open source projects. Far more often, though, games are produced like movies, using expensive resources and labor. And they often have to be produced on a tight schedule for marketing reasons, so that their release coincides with the release of some movie or holiday buying season or whatever. For these reasons, there are few if any open source games out there, and I don't see that changing anytime soon.
Obviously, there are also many areas in which open source products are kicking the proprietary competition's collective ass. These are usually products which work best if they can run on multiple platforms, meet the needs of lots of different people in different situations, and provide enough value that smart people are willing to spend their time improving and customizing them. Linux, Apache, PHP, etc.
So lets stop worrying about whether open source software is better than proprietary software in all cases or vice versa. It's pretty clear that both bring value to our society and to our economy. Lets instead keep improving the ways we develop products under both systems, and make sure that we maintain an infrastructure that works for both. Software patents are a dumb and harmful idea, but copyright is important and should be respected and protected. Open standards are essential to vibrant markets and useful tools, and we should insist on vendor-neutral bodies to develop and maintain them.
But they are *not* a good example of how a company can succeed by *being* generous
How do you figure? Apple's given a lot back to the open source community, especially in terms of user interface and networking. Yes, Apple used to be very unfriendly to open source, but now it's just as easy to dual boot a Mac with Mac OS X and Linux as it is with a PC. And Apple even directly controls the hardware. But back to software; Apple basically re-wrote KHTML for Safari, and then gave it all back to KDE. Rendezvous is also an important project, largely under Apple direction, that probably wouldn't have otherwise caught on.
And don't even get me started on user interface. Apple might not have contributed to this directly, but have you ever stopped to think how much of Gnome and GTK+ is influenced by the Mac OS? Cosmetically, the two are becoming more alike all the time. Example: GTKFileSelection really really sucked. But then Gnome took an idea straight from Mac OS X and brought us GTKFileChooser, which is way more intuitive and easy to use.
In the future, it'll all be even more prevalent. Jabber is coming to iChat in Tiger, for example. It seems like most, if not all, improvements Apple makes to open source libraries/programs all gets given back to the open source community, which is way more than can be said for a lot of other companies.
So stop bitching.
Take off every sig. For great justice.
Why don't we send a clincher message to people that think source code ought to be "secret", by not giving them any comments, ideas, suggestions, and/or replies, because we want to keep them "secret".
"Hey, what do you think of this software?"
"Can I see the source code?"
"No! I need to be able to sell it!"
"Oh... I think nothing of it."
"What?!"
"I'm a consultant, I need to be able to sell my opinions!"
Oh wait... then we would just be propogating the "secrets".
--I smoked my sig.
Software patents are doomed for one simple reason.
The equivalence of two Turing machines is undecidable. Turing proved this as one of the results of the halting problem. Since turing machines are equivalent to algorithms, which are equivalent to recursive functions, this is a statement in mathematics that as such should be sufficient to disallow software patents on the basis that software is a mathematical function.
Where, then, can software patents stand? By definition, patents cover a method, hence an algorithm. Since there exists no way to determine if an algorithm infringes on a given patent, the patent office must backtrack and declare that algorithms need only be *similar to* a patented algorithm to infringe. But this is also undecidable for the same reason. An incredibly complex algorithm that produces the same output, given the same input, as a patented algorithm will be intractable to compare to the patent.
The reason the patent office is spewing software patents is that it has no method for determining prior art, no method for determining functional equivalence, and no method for reasonably denying every software patent after the courts have incorrectly ruled in favor of them.
Note that if you really wish to infringe on a software patent, it will always be relatively easy.
Given a function F(x) that is patented, do the following.
Create a function G(x,y) where y is meaningless, random, or in some way constructed from x such that applying G to x,y is equivalent to applying F to x. If necessary, encode x as y and apply H to y such that H(y) is equivalent to F(x). No patent court will be able to prove the equivalence. Should they rule that simply because two functions *produce similar (not exact, that is intractable) output, despite being vastly dissimilar*, they will have contradicted the very spirit and letter of patent law. The whole point was to issue patents for *specific* methods and devices, and encourage derivations thereof by other inventors. Such is progress. Owning the result of applying a mathematical function to all possible inputs is not progress, it is the darkest feudalism.