All Source Code Should Be Open, Revisited 513
cconnell writes "In my last article, I presented the idea that all commercial source code should be open. In other words, part of the delivery package for any software purchase should be a copy of the source files. If everyone saw software vendors' design and coding, the vendors might stop shipping us such lousy programs. The article generated a fair amount of controversy. My latest piece follows up on this idea and includes a few adjustments that respond to reader feedback."
what? (Score:5, Insightful)
Re:what? (Score:2)
Re:what? (Score:3, Interesting)
Given the example of an auto versus a software product, why should these two creations be treated differently? Here is a scenario that could apply to both the products. Imagine an inventor who comes up with an idea for a new product or type of product. This person spends years designing and developing their new product. Finally, they complete it and release it to the market. Now imagine another inventor who, through industry research, finds the work of the first inventor and comes up with a great complimentary product idea. Because of the second inventor's dependency on the first inventor's product, they require details of how their product can be added on or interact with the first. Here is where the paths of the physical versus virtual worlds diverge.
Let's examine the auto industry first and assume the complimentary product is a cup holder. The design of the cup holder is dependent on the design of the car. In order for the second inventor to design their product, they could use a variety of devices and methods to inspect the car (or cars) to determine the best way to make their product compatible with the car.
Now, let's assume the complimentary software product is a browser and the original invention is an operating system. What methods can the inventor of the browser use to determine the best way to make their product compatible with the operating system? For a closed source product in the current legal system, the inventor would not be allowed to inspect the code to see how their browser should interact with the operating system. They would have no knowledge of any benefits or drawbacks to a particular approach. The only remedy for the developer would be to request details from the inventor of the operating system about how they should interact with it. Furthermore, they must trust that this is the best method of interaction without being presented proof. In many cases, the inventor of the browser may be required to pay to even get that basically blind and minimal information.
Why the distinction between the two scenarios? When advocates of this system are questioned about this discrimination, they usually cite one or more of the following reasons:
Protection of intellectual property and proprietary processes against theft or duplication
Encouragement of innovation
Security against attackers
The first reason has many different variations and aspects that people endorse. Who would want to be on the supporting end of theft and piracy? But this argument is empty. Individuals or organizations that want to steal or copy an inventor's creation can always find illegal means to accomplish their objectives; therefore, the only people it prevents from gathering information about the product are law abiding citizens. To clarify using our example, pirates and copiers of the operating system are not inhibited by the fact that it is closed source. The only person harmed is the inventor of the browser who is attempting to create a valuable addition to the operating system.
All three of these lines of reasoning offered by supporters of the existing system overlap in some way, which adds to their circular reinforcement of each other. The second argument is the most general and also the one that is the most incorrect. Patents and licensing have been created to encourage inventors to take the risk and time to create something valuable for the market. Somehow, supporters of closed source see their actions as an extension of this system. But as you might have guessed by now this belief solely rests on the first argument being true. People will always be willing to innovate as long as they believe they will be rewarded and that the distinctiveness of their product shall be protected. This means that they will be able to sell or license their product and that if someone should copy their product in part or whole that their rights will be upheld in court. In the software world, patent and licensing laws obviously provide the rewards for the inventor. But what is not always clear is that they also provide protection, especially when the source code is open. It is relatively easy for someone to examine two sets of code to determine if it had been copied. These facts are the reason that innovation will always thrive in an open source market. One need only look at the current open source initiatives to see some of the most innovative technologies.
But how does closed source systems influence innovation? Under the example I described with the operating system, there is only a detrimental effect on innovation. The operating system creator will be the only entity with the proper knowledge to create truly compatible products. All others will have to depend on that entity for information on how to create products that interact in an efficient manner. That dependency creates a barrier to entry that is quite formidable. If the inventor of the operating system also creates a browser product, the situation is even more discouraging for potential inventors. While the inventor of only the browser has to blindly trust the operating system creator about how they should interact with it, the inventor of the operating system can create a browser product with full knowledge and access to the source code of the operating system. This does not seem like a situation that promotes innovation.
The last reason cited to uphold the right to keep source closed is based on the fact that it already is. The argument contends that if potential attackers had access to the source code of a product, they would be able to find possible security flaws and exploit them. Empirically, this logic does not hold up to scrutiny. Closed source software has been found to have the most and worst security flaws simply because the number of eyes that get to inspect the code. Numerous entities typically inspect open source code whereas closed source code only one gets to inspect it. This leads to less overall flaws when the software is released and also the discovery and remedy of flaws at a much greater rate after the software is in general use. When presented with this evidence, supporters of closed source do not challenge it. They only contend that since there are already people using this less secure software, the source must stay closed to protect the existing user base. Again, this logic is flawed and contradicted by empirical evidence. New security holes are found and will continue to be found in closed source software. Making the source code open only speeds the location and correction of these security issues. Is it better to know you have issues and fix them or to know that there may be many holes lingering that you will never find?
Someone once said, buying closed source software is like buying a car with its hood welded shut. People sometimes dismiss this statement by saying they do not want to worry about what is "under the hood." I can understand this desire but the customer is not the only one whose desires matter. Closed source code provides no protection against piracy, theft or security breaches. More importantly, closed products of any industry stifle the spread of knowledge and therefore innovation. There should be a measurable economic and sociological impact that can be identified and analyzed. Many laws are brought into being when the rights of the many need to be enforced over the rights of a single individual (or entity). This inequity (between physical and information industries) is one such case where entrepreneurs and inventors need to be protected from entities seeking to stifle innovation, and therefore, economic growth.
Re:what? (Score:2)
I agree partially. The key concept here is the cost. Sure, I'd love to have source for all the programs I ever use. I still understand that creating that software has taken very much effort and generally companies are selling software at very cheap price. And they're able to do that simply because they can count on selling something more later on. As long as I use commercial software I'll rather use somewhat usable software that costs C bucks instead of somewhat usable software with crippled source (read the article) that costs ten times more.
Yes, it sucks that they implement some trivial changes and sell the result to their customers for full price as version N+1. I still don't understand how this differs from, for example, car manufactures: cars have had gasoline engine, four wheels and a steering wheel for god knows how long. Newer cars may have a radio with cd player, a little quieter sound, somewhat different looks and in best case the engine needs a little less fuel for the same mileage. I'd say those changes are trivial but still people aren't complaining. Yep, I'm aware that manufacturing a car requires material and stuff and should therefore cost full price even though the product is almost similar to previous one. When you buy a car, you pay for manufacturing it, but when you buy a piece of software, you pay for the design. What's the difference after all?
Re:what? (Score:4, Insightful)
I would just be fearful that the wrong people would look at the source and use the knowledge against others. But, I guess people do put sugar in gas tanks, cut brake lines (or worse) in a car scenario. The idea isn't too much different. Thank you for giving this analogy.
Re:what? (Score:3, Insightful)
Yeah, but intellectual property is VERY different from physical property.
Theoretically, you could acheive a complete comprehension of your Maxima by disassembling it and studying all the pieces. Can you now go into business competing against Nissan? Not hardly.
But with open source software, as soon as a company releases the source they are potentially in the position of defending against millions of competitors. Each one capable of matching them in distribution capacity and quality of product.
In the open source world if you want to make money you must do it through services. Period.
Re:what? (Score:3, Insightful)
Well, I can think of one big difference. I bought a car last year and it came with a warranty, and if the car turns out to be a total lemon, I can seek various remedies from the manufacturer to have it repaired, or if need be, replaced. Now, contrast that experience with your typical EULA - no warranty implied or otherwise, no guarantee of functionality, and the user absolves the manufacturer of any and all liability.
Big difference...
wow (Score:4, Funny)
Ciryon
Nonsense (Score:5, Insightful)
Hmm, not on any large software system I've ever worked on... The important part isn't some magic 1% of the source, it's the fact that you got a group of people together for long enough to ship the thing.
This negates one of his basic points, and doesn't really contribute much over his previous rant...
This guy cracks me up (Score:3, Insightful)
Furthermore, this guy somehow thinks that removing the #define is an effective barrier to piracy? I think I heard of something called a symbol table at some point.... maybe that would help black-beard?
This guy is just trying to stir up shit so that he can make a mark. The only customers that would be dumb enough to hire him, are the same ones that would believe his inane ramblings.
Good luck Mr. Connell, if you ever have a good idea, feel free to share it.
Wow, perhaps slashdot should add a new section (Score:2, Funny)
Won't benefit the users... (Score:5, Insightful)
The only people who would benefit are the releasing company's rivals, who would have the time & money to sit down and reverse engineer the code, and then rerelease it as their own.
Then again, maybe I'm missing the whole point of this and should RTFA.
Re:Won't benefit the users... (Score:3, Insightful)
And so it could be in the software world. Sure, 99.9% don't understand the code, but there's an opportunity for you to start up "Software Reports" in the same vein as Consumer Reports to translate and inform.
Re:Won't benefit the users... (Score:2)
What about Open Source projects? The linux kernel, for example is a HUGE program. Much larger than many (most?) commercial products. It is constantly modified and dissected by thousands of interested users. There would be plenty of people itching to get their hands on the inside of Oracle's database engine, I assure you.
The only people who would benefit are the releasing company's rivals, who would have the time & money to sit down and reverse engineer the code, and then rerelease it as their own.
As you said, RTFA. He addressed these points explicitly with the Tom Clancy analogy.
Re:Won't benefit the users... (Score:2)
So I can't use all the patches everyone else wrote for apache?
I thought that was all apache was
Reverse engineering (Score:2)
What must be realized is that, with a decent debugger/decompiler, it's possible to reverse engineer executable applications without the source code. It has been done for ms-windows, by Andrew Schulman et.al. some ten years ago, when they published a series of books on windows and ms-dos internals.
It can be done for hardware too, there are methods for dissolving chips layer by layer to photograph the lay-out, from which a schematic diagram can be recovered. It may be even simpler, if off-the-shelf chips have been used. I was once given a circuit board from which the manufacturer had scraped the chip part numbers. After removing the chips and reading the printed circuit connections with a multimeter, I put each chip in a test jig. Without much effort, I found they were all 4000 series CMOS chips and easily found the part number for each. It took me less than a half day to reach the exact circuit schematic, which wasn't very orignal, nothing that a patent could be applied for.
Re:Won't benefit the users... (Score:2)
Who said anything about modifying it? This is simply for evaluation purposes. We can now examine the code to be sure that it is of quality before we purchase. This might be only useful for large purchases or interested parties, but I still think it's a great idea.
Simply Answer (Score:5, Insightful)
If I spend 400 hours writing code for something I want to sell, I'm not gonna give it away. I'm sorry
I contribute to open source projects as well but, I have to eat. That's just the facts of life.
Re:Simply Answer (Score:4, Informative)
The article says nothing about giving it away for free.
Re:Simply Answer (Score:5, Insightful)
This is completely wrong, and I hope everyone realizes this.
If you pay for a program, you pay for the binary. You now own a program that will perform to the specified dimensions. You do NOT own the source. Presumably, you would want the source to make modifications to it. Well, depending on the licence that the program is released with, too bad. You may not get to tinker with the source. Not everything is GPL'd, and for a good reason, folks.
Like the other reply to this post, if you want to see the source, come talk to me, we'll sign a non-disclosure agreement, and then we can negotiate a price for a source licence.
Think security software - say, your intranet system. You don't want your customers to have the source to that, because 1.) they probably wouldn't know what to do with it, 2.) it might fall into the wrong hands, or 3.) if they do manage to muck through it and change things, and somehow make their secure data hackable, there's a liability issue.
There are only two other reasons you would want the source - to steal the program or to just sit and stare at it.
With a binary, or a CD, or whatever, you can add copy protection. Source code is just text. Cut, Copy, Paste, Compile. Now your friend has a working copy of a program he didn't pay for.
No, the grandparent is right. If someone spends months developing an application, they shouldn't have to release their source code. I can't think of a better way to shoot yourself in the foot.
Think the airplane business. When you buy a 757, you don't get the blueprints for the wing. That's a trade secret.
Note to new slashdot readers: This is typical thinking on slashdot. I want EVERYTHING for free. If it's not free, it's wrong. I want the source code to everything, because I feel that I could do a better job writing this software by mucking it up. What they mean is that they want to steal it if it isn't free. Don't fall into this trap. Some software should be closed source, and some people have to put food on the table.
Re:Simply Answer (Score:4, Insightful)
That's exactly the article's point. He's saying that should change.
An airplane wing isn't copyrighted.
Who said anything about free? All the original article said is that if you pay $99 for some piece of software, you should get the source with the package. The source would still be protected by copyright just like the binaries, so you could look at it and modify it for your own use, but you couldn't distribute it.
If anyone is getting something for free here, it's software companies. Copyright is a bargain, not an entitlement, and it should guarantee that the public can create derivative works when the copyright expires. In the case of software, that means the public should have access to the software in a form suitable for modification and study. Now you can argue for practical reasons that the source should be held until the copyright expires, but you can not justify letting it simply fall into oblivion.
Re:Simply Answer (Score:3, Insightful)
So, people who have no need or use for the source will end up having to pay more to get something they don't want. There's a turkey of an idea.
Re:Simply Answer (Score:3, Insightful)
Am I not allowed to modify my car? Or my computer case? Can I not add a light to my house just because it wasn't originally designed that way?
Re:Simply Answer (Score:3, Insightful)
Bad analogy. When you buy an airplane you have a reasonable expectation that it won't break, or that if it does, it's the manufacturer's fault and they are liable.
If I buy a piece of software, I should have reasonable recourse to fix problems with it. Other than filing a bug report to a corporation that isn't liable and probably won't listen to me.
Including source code could be a solution to the problem, but doesn't have to be. A corporation should provide some means for fixing problems. This could be a highly dedicated customer support staff, but it could also be access to source code. If depends on where they want to spend their money.
Re:Simply Answer (Score:3, Insightful)
First off, noone ever said all the code needs to be GPL. Noone is asking for the code to be released under a license that permits unlimited distribution. Your assumption that the desire for source code is simply a desire to get something for nothing is moronic. The desire is for power over what you purchase, the same power as you have with buying a car and opening the hood.
Second, why shouldn't the end user be able to modify their software to suit their needs? Lets say a bug is found. I could report the bug and wait for said company to fix it, generally in an uber-patch or I could fix it myself. With the former, you are stuck with said bug until the company decides to fix it. Do we really want to wait until SP1? What if said bug is a security risk?
With a binary, or a CD, or whatever, you can add copy protection. Source code is just text. Cut, Copy, Paste, Compile. Now your friend has a working copy of a program he didn't pay for.
Another misguided statement. No copy protection works. Hardware keys can be beaten. Keyservers can be faked. Copying binaries is just as easy as copying source. In fact, if you had the binaries and source and decided to give them to a friend, why would you bother sending them many many CD's worth of text instead of the much smaller, much more useful binaries? Remember, source code for various games has wound up on the net, as have binary game alphas/betas. Tell me which one gets copied more rampantly.
Finally, how is releasing the source a shot to the foot? You still have to PAY for the source, the source is still protected under copyright. Regardless of what you want to believe, it is possible to know if your source is being used in an app you do not have the source for. Many times it has been shown that GPL code is in commercial apps in violation of the license it was released under, it would be no different with the source you release with your binaries.
Think security software - say, your intranet system. You don't want your customers to have the source to that, because 1.) they probably wouldn't know what to do with it, 2.) it might fall into the wrong hands, or 3.) if they do manage to muck through it and change things, and somehow make their secure data hackable, there's a liability issue.
To #1, your customers would probably not care for it until they needed it.
To #2, if the 'wrong hands' are people interested in exploting your system then you should be flogged for creating a system that depends on its code being closed for its security. There are many programs that are considered quite secure that the source is viewable with. Also, remember that the source and 'secret data' such as passwords, etc are seperate and if said secret data falls into the 'wrong hands' then you have more problems than you can possibly know.
To #3, if I open the hood of my car and drain the coolant, it is not Ford's fault when my block catches fire. If you change it, the changes are yours and liability is too.
There are only two other reasons you would want the source - to steal the program or to just sit and stare at it
If I want to steal the program, the source is not going to help me, I'll just fucking steal it thank you very much. Source code, to those people who can grok it, understand it and use it is invaluable. Small fixes to a program's behavior, the ability to tie a glue language into a product without any such previous bindings, the ability to audit, all of these are things that the source provides. None of them has a thing to do with stealing.
With disclosing trade secrets often comes NDA's and lawyers. There's no reason this shouldn't be a part of the source code disclosure. Your inherent assumption that it's just some GPL hippies after free code is insulting and the fact that your post was Score:4 at the time of this reply only makes me further disgusted at the quality of moderation around here.
No... (Score:2)
The source is part of the product.
Hm. I think you missed part of how the market works. The Product is definied by what they throw in. It's thier choice - if they throw in the source code, it's part of the product. If they don't throw in the source code, it's not part of the product. The end user does not determine the extent or limitations of a product, the producer of the product determines those things.
Now, the issue of if it SHOULD be part of the product - that's a different story. Putting it into the analogy of real-world products - What you want in this case is a set of blueprints, architectural drawings, etc. that went into producing the product. (Ok, VERY loose analogy - maybe what you want is the CNC code that went into running the machines that made the molds, and the automation code that went behind creating the product.)
Re:Simply Answer (Score:3, Insightful)
So you think that Microsoft should include the source code to Windows if you pay them 100 bucks?
>If I pay for something you spend 400 hours writing, I want the source to that as well.
>The source is part of the product
Well sure, if it's contract work and you pay for the 400 hours. But if you pay 30 bucks for the product you haven't payed to get 400 hours work, but the right to use it.
What you suggest wouldn't feasible in the real world. But if you really want the sourcecode to the products you buy/use, use opensource or something. It's your own choice.
My 0.02
Robert
Re:Simply Answer (Score:2, Insightful)
Re:Simply Answer (Score:2)
Reproduce an author's work in your own work and you will be in violation of copyright, and liable for legal action. Furthermore, your reputation will be in tatters as a plagiarist and you will find it very difficult to find an editor or a publisher. The ideas of intellectual property applied to books long before there was a software industry.
Re:Simply Answer (Score:2)
The GPL has been used to catch stealers of code who don't follow the license its provided in. Most big companies have way more lawyers, so they'd be able to defend their IP even more successfully.
Competitive advantage. (Score:4, Insightful)
Support of user modified code is impossible
Competitors may take advantage of reading the source
It's "my money" that went into developing the source and "I" want to reap the benefits of "my" work
Bug handling would be a nightmare
There are several other reasons too. I'm not sure why all source has to be open source. Sometimes I feel that a lot of people just want a system to be Open SOurce just because it is The Right Thing (Tm), not because it would give them anything.
I have no problem with non-commercial software beeing open-sourced or even to a certain degree commercial software. But is it really necessary that ALL software is open source? I fail to see the need in all cases or the reason for it to be so.
RTFA (Score:4, Insightful)
In short, RTFA.
Re:RTFA (Score:3, Interesting)
If somebody lifts the plot of a Clancey book, and then rewrites it with different character names and different names for the setting, that's plagiarism. Now for the hard part: Prove it.
That's one problem the software industry would rather not have.
Re:RTFA (Score:3, Interesting)
Er, wot?
My reaction exactly. Some years ago (20 of them to be fairly precise) I worked in a place with a big IBM mainframe, and the engineering staff brought in Amdahl's UTS (a version of unix) to run on top of VM. When I asked the Amdahl people about source, their answer was "Oh, that's not an option; you get it whether you want it or not." The install tapes in fact included the source to everything.
A couple of weeks later I diagnosed some problems due to some incorrect configuring that our VM guy was doing, which UTS couldn't handle. A day later I had a fix, and I emailed it to the folks at Amdahl. They sent back a nice message of thanks, my patch was added to their source, and my name was added to their list of contributors.
This was exactly why they sent out the source to all their customers. True, not many could use it, but they really liked customers that had people on staff who could read the source and help them fix problems.
I worked on it a couple of years, during which time the question occasionally came up of whether they had any theft of the code. Their answer was "Not that we know of". They also added that they really wouldn't mind if a few of their improvements were to find their way into the general body of shared unix code. They thought that it was to everyone's advantage to have good code, and having pieces of code identified as coming from Amdahl could only be good advertising.
I have no idea whether they still have this policy. Considering how management attitudes have changed, they probably aren't doing this any more.
It might also interest some to hear that at that time, IBM also supplied a lot of source with their systems. I know the VM support guy had full source. I saw some of the CMS and MVS source, though I don't know if we had all of it. But there was a lot of IBM source available from IBM in the 70's and early 80's, and they seemed to do pretty well commercially.
Re:RTFA (Score:3, Insightful)
Nothing would stop some idiot from making a binary patch to your app *cough* crackers do this today to every app *cough* and distributing it wildly, and then have everyone calling your tech support for help. Your point?
Ever heard of a Xerox machine? A scanner? Having the source or not having the source has absolutely no effect of any kind or form whatsoever on the meaning of copyright.
And you're right, software is easy to copy. Exactly how is software in binary form harder to copy than in source form, again?
I see you've never taken a CSE class at a university. Software exists which will take two code bases, possibly with completely different names and formatting, and decompose them into structural parse trees and compare those for signs of copying.
It's a lot easier to do this if you have the source code, of course.
Re:Competitive advantage. (Score:2)
He's gone back and made amendments stating that code that would be thought of as 'the money maker' could be removed from the distributed code, remove constants and the likes as well. This would produce code that you could, for the most part, audit(or have audited) rather well. Basically speaking, this isn't just about the right thing as you put it. It is about responsibility.
It's like the saying goes, if you lived in a glass house, you'd behave better.
I agree on part of it (Score:2)
Now if this is a comercial distributed product , this is another kind of problem and what you said above apply.
A script kiddies dream? (Score:3, Interesting)
I understand the benifit is to be able to determine the weaknesses and report them back, but as fast a MS is at getting patches out, this would become insane really quick.
Hasn't stopped them so far (Score:3, Interesting)
Honestly, it would never fly. (Score:2, Insightful)
You would have no developers and no applications. Technological progress has always centered on riding the bleeding edge, where the programmers themselves barely have a clue what the heck they're doing. If people knew how much of the stuff they use was designed under impossible time requirements by bleary-eyed schizophrenics, we'd still be riding in horse carriages.
Look at how today's technology compares to NASA. They sit and pore over every detail, examine and re-examine; approve and check. What are they using in the space shuttles? 386's for main computers still?
Requiring open code would put many companies out of business. A lot of customers have their own businesses depending on applications, and they don't care if the code is nice; they just want something that works most of the time and keeps their business running. That and a support contract keeps them happy, and the developers can gradually issue fixes to reduce the twinges of sloppy-code guilt.
Re:Honestly, it would never fly. (Score:4, Informative)
BZZZT! And thank you for playing. They don't use '386s because they spent so long checking the code.... They use 386s Because they've been proven reliable. They spend hours and months poring over the code, providing traceability and working on correctness because if they fuck up, people die.
You can't compare NASA to today's "Ship it now! If we ship an hour later we'll lose $1M" business world. Totally different set of requirements.
Re:Honestly, it would never fly. (Score:2)
That was my point. If you want massively checked and proven code, as would be required when baring the source for everyone to see, you pay the price of slowed development.
You can compare NASA to the business world. If the business world had to do it the way NASA does (yes they HAVE to do it that way), development would be slowed to the point of being financially unfeasible.
Makes you wonder (Score:2)
I wonder if people expend the same effort on the embedded software that controls traffic lights. Seems to me that borking traffic lights are a lot more likely to kill large numbers of people.
This is 100% stupid (Score:5, Insightful)
Who do you think you are to require people to open their code ? If you don't like closed source software, don't buy it, it's as simple as that.
Authors also have a right to freedom, it's not only for the users.
Re:This is 100% stupid (Score:3, Insightful)
Re:This is 100% stupid (Score:2)
I have to ask (Score:2)
open source (Score:2, Interesting)
On the other hand, it could be a very Good Thing (tm) for those same systems because the Many Eyes concept would certainly "harden" the code. In the meantime however, more exploits and bugs would certainly be found, and DoD is not the type of establishment that wants to have known visible security flaws.
Where's the money? (Score:5, Insightful)
Some have said that the money is in tech support / documentation, but that is just as bad.
If your product generates enough tech support revenues to support a large project then you simply wrote horrible software, and chances are if you did write horrible software it won't be used. It's a paradox, so it probably won't actually happen. And people aren't that stupid - I hope.
And if you charge people for documentation, then I simply call that bundling. You are paying for a bunch of documentation that just happens to come with some software.
The way to make companies produce good software is to stop buying crappy software. It's pretty simple. If people stop paying for expensive tickets to go to professional sports then guess what, they will lower the price. It's simple economics of backlog.
OSS is the big dilemma (Score:2, Interesting)
Both OSS and closed-source have their software issues. Granted that OSS allows you to fix them, but in the end if the user is that at fixing the errors, why would the just write the program to begin with? It would take more time to figure out how the software was developed then it would the original developers.
Rather then continually say that lousy development practises show a good reason for open-source, wouldn't it be better to just enforce better development practises all around? This could help both big business and the OSS and stop the daily debate over which is better.
It's like listening to two guys arguing over who's better Mercedes or BMW (my personal fav).
It must be nice (Score:2, Insightful)
"Stubs" in place of "critical algorithms"??
Open Source is either open or it's not. There's no middle ground. What prevents the vendor from stripping out things that are useful and critical for me to support and enhance the software under the "well, that's a copyrighted algorithm" guise?
This article makes absolutely no sense whatsoever. The author seems to have come up with some lukewarm "solutions" to problems that have no easy solution, posted the article and got it plastered on /.
- Write article that rehashes why most software is not open
- Make weak arguments about why those factors are really not important at all
- Submit to Slashdot
- ???
- Profit!!!!
One cannot make a case for these issues in a six paragraph article, sorry.He kind of has a point - but not. (Score:5, Insightful)
Words of a novel can be yanked off a page. You can order enough parts, individually, to make your own car rather than purchasing it from a dealership.
You can always order wood and build a desk yourself. Got enough heat? You can make your own wine glasses that are exactly the same as those ones off the shelf. Everything, in reality, is pretty much open.
There's a difference with code, though. If I write a program, a person with the source can compile it and use it without having any sort of skill. Whereas someone lacking skill can *not* write Lord of the Rings. They can't build a car for themselves that I'd wish to ride in. Their desk would likely fall apart. Their glasses would end with them receiving severe burns.
If you wish to compare source code to everything else that's open, then, by the Gods, compare it fairly - compare the compilers, the availible libraries, etc.
The tools and materials are there. The skill? The skill is why source is often closed, and in many cases, should be closed.
How does this help piracy? (Score:3, Interesting)
Sorry, this is just wrong. (Score:5, Insightful)
What kinds of steel were the supports and cables made of? What was the mix of the paving materials and how thick are their layers? Did the contractors skimp on the re-bar? How deep were the foundations sunk?
Just try to get this information about any big public bridge. They'll say, "We can't tell you for security reasons." ...just like certain software vendors we know.
-Rick
Good Code vs. Good Products (Score:2, Insightful)
Is it possible to have good products without "good code?" Depending on the product, I think yes. Do great videogames necessarily have "good code" or whatever the author decides is good code? Maybe, maybe not. For games, the distinguishing factor is not as much the coding (ie fulfilling the designer's vision) as it is establishing a good vision.
YES, maybe it makes sense for security related products, but don't get greedy and claim that EVERY product needs to release its code.
Re:Good Code vs. Good Products (Score:2)
I agree with this. It is possible to write good software that has somewhat lousy code inside it. For exampe, an inefficient sort algorithm that is only used when a rarely-accessed administration screen is displayed. The code may be inelegant but practically speaking it does not matter and there is no reason for the vendor to be called up on it (which some smart-arse certainly would "ha ha Microsoft used the Breighton-Whirst Bubble sort when the Langer-Turston would have been 100 times faster ! What dipsticks !").
Much more important to quality of apps are "bigger picture" items such as schema designs for any RDBMS-based product (readily available now without the source code) or external interfaces (which, to use MS Word as the extreme example, it is made clear by the vendor that they do not intend to adopt any industry format nor to even be bound even by their own published formats).
Articles like these ones... (Score:3, Interesting)
The article itself is just blatant flamebaited advertising. I fail to see how he addressed any of the points in his previous article (which I also thought was codswallop).
Did anyone ever see films of the Verrazano Narrows bridge collapse? There's an example of a bridge that looks fine on external viewing, (even by TRAINED experts), but doesn't work for real. Joe Average knows squat about bridges, and won't recognize a faulty design unless he's falling into the river with it.
As for the 1% of "real" code in a product - what a load! If your key code is buried deep in some subroutine, then how can you "remove" it from your product and still make it functional?
Feh!
Re:Articles like these ones... (Score:2)
No. When did that happen? Was it anything like when the Tacoma Narrows bridge collapsed?
Re:Articles like these ones... (Score:2)
Although there is a Verrazano Narrows bridge, I was thinking about the one in the Pacific Northwest, but had a brain fart.
Re:Articles like these ones... (Score:2)
Was it too much damn trouble to do a simple Google search?
Re:Articles like these ones... (Score:2)
Really? [nyc.ny.us]
Like Houses... (Score:2, Insightful)
To beat a dead horse - If we built houses like we build software, .....
When you buy a house, it is either pre-existing or soon-to-be-existing. In the case of the former, you can only know as much as the owner tells you, and the builder's reputation and the packaging. In the case of the latter, you can visit the site as often as you want (just don't be shocked if you see some beer cans sitting around).
I agree that most software sucks, but to say that you need to take the walls down to inspect the plumbing both trivializes a nontrivial problem, and tells one no-more-than 'next house on the list' inasmuch as they know what they are looking at.
Ability of users to judge code quality (Score:3, Interesting)
Incidentally, the mass market products are those most likely to cause a security risk like worms or viruses, because of the very fact they are used so much by clueless folks.
I'm not saying it won't work, but it may not be as effective as it seems.
I really like the concept (Score:2, Interesting)
GPL and things alike aren't the whole truth, either. If the source code is licenced such that it may only be modified in private and not get distributed, this will of course not promote OS, but it will be a great thing for the users, as they can fix bugs and add features for their needs.
As a fine example of OS commercial software, look at the editing communities for id Software's games. Granted, Doom, Quake and Quake II don't really have any great commercial value any more. Case is, though, that the release of these games' source codes have sported heaps of enhancements to the game engines and helped preserved the communities, resulting in a fantastic respect for John Carmack and id Software.
If a company can read the code... (Score:2)
Posterity (Score:2, Insightful)
then again, by that point copyright will probably prevent us from looking at anything interesting...
-kscd
OS Isn't always the best tool for the job (Score:2, Interesting)
Windows runs like ass, and therefore it's a pretty safe bet it wasn't coded very well. I don't need to see the source code to figure that one out. And quite frankly, even if it was coded badly, as long as it were to run well, I don't think most people would care anyway. Hell, it DOESN'T run all that well and a lot of people still don't care anyway.
The only nice thing would be maybe if the source were available a few people would be nice enough to fix it up or something. Other than that, it's not too important, except for anti-trust reasons, so we can get a decent
As for everything else, source code just isn't always the best idea, or even very necessary. The government or other high security needing people should have source code, and experienced hackers to audit it. That makes sense. But other than that, to have everything done ONE WAY is usually not the best idea. That's the beauty of being able to choose a license or just make your own up-- you can choose the best tool for the job.
The biggest, buggiest program ever (Score:2)
Yes, it's possible to get certain specific bits of the code after signing Non-Disclosure Agreements and/or handing over large amounts of money. Get the whole of Windows source? Nope. Understand it all in any reasonable amount or time? Nope. Get busted by Microsoft for using part of their code in an OSS project? Almost certainly, and if in the process of trying to prove you didn't, you have to show Microsoft your code, expect to see a competing product soon after.
Let's open it, but not really...??? (Score:2)
He goes on to suggest that vendors withhold crucial functions or methods, and 'stub' them out in the source code. Well, those are easily enough to reverse engineer from the binaries and the debugger, so that's no real solution from the vendor trying to protect IP. And it doesn't help the 'customer' at all, because your still stuck with not having the full tranparency that Open Source is supposed to provide.
I'm actually not pro- or anti- open source. I kinda sit on the fence on this issue (Though I do like the BSD style license). However, I think that Mr Connell is trying to stand on both sides of the fence at the same time. It doesn't really work.
-jerdenn
Constructive comments on the article (Score:2)
1. How many people would understand/follow the code? How many people would even be able to find anything of interest?
2. If it is really of life/public safety/importance, then the big bucks would have paid for the code/testing/standards already.
3. Seeing code != perfect end product
You're joking (Score:2, Interesting)
2) the resulting executable would not operate in a meaningful way without the key routines. Why bother? How would the customer test or debug it, or suggest extensions?
3) Shame on the designers; their indiscretion should be on display for all to see If you have the rare privilege of working in an organization that doesn't need it yesterday, is understaffed, and has to scale up very quickly, then I can see your point. The rest of us have to deal with a competitive marketplace.
I agree that open source has an important role to play in many types of commercial software, but this article is a trivial discussion of the problems involved.
escrow (Score:3, Insightful)
We're young, new on the block, and competing against some big fish in the performance monitoring space.
One of the biggest issues we have is trying to placate potential customers that are worried about us going out of business and leaving them with un-supported code.
To get around this, we've put copies of source code, with docs, build environments/scripts, etc., in escrow. This way, if we DO go down in flames, all registered license holders of our software are entitled to complete access to EVERYTHING required to support the software themselves.
This keeps our investors happy, our customers happy, and us, the developers, happy. There's NO WAY IN HELL that our investors, or me, for that matter, would condone or support making our entire product OS. We've spent a couple of years working on this thing, and we'd like to get some benefit out of it.
There is an infrastructure (that we call Brazil) that will probably be put into open source in about 6 months, but the customized/specialized modules that plug into it that we've developed will NOT be made OS.
Obviously, our position could change in the future, but for now, it's not an all or nothing proposition.
Re:escrow (Score:2)
Read what Bruce Perens has to say on the issue in another thread:
Escrow contracts are voided by bankruptcy [slashdot.org]
-jerdenn
Non-trivial code for banks ALL has source (Score:3, Informative)
For some of their stuff on mainframes and PCs they HAVE to to comply with banking commission and/or SEC and/or government regulations. Its more than just a good idea, its the law.
They have to be able to TOTALLY reassure the auditors and inspectors that NOBODY is 'skimming' pennies from each transaction. When you're talking a trillion transactions a day, week, month or year, it adds up to big time fraud damn quickly.
You CAN'T do that with a "pig in a poke." They get the source code to keep the baddies who can shut 'em down from shutting 'em down.
It should be a requisite for copyrights (Score:2)
However, for things that have other forms of protection, such as encrypted DVDs or executable source, there should be no copyrights, because, for such works, there's no guarantee at all that they will be available to the public when the copyright period expires.
Judgement of whether source is good? (Score:4, Interesting)
What makes code good or bad?
Is it the resultant way in the program runs? Is it the effeciency of the code?
Finally, is it possible for two different programmers to look at the same source code and have strongly differing opinions about its quality, or is it a pretty much agreed upon criteria?
While I honestly do not think that an idea such as this will ever come to fruition, I cannot help but wonder at what the standard of judgement will be should it occur. If code is deemed to be good or bad based solely on subjective criteria, then I think the whole idea is doomed from the get go.
Re:Judgement of whether source is good? (Score:2)
What matters is the elegance of the thought behind the code. Simply put, it is code that transforms its inputs into its outputs using the fewest possible number of operations, variables, etc, and correctly handles unusual or unexpected inputs without behaving unpredictably. Coincidentally elegant code tends to be easy to maintain and efficient to execute, but these two factors alone are insufficient to make a piece of code elegant.
If you are interested in this sort of thing, I recommend reading Knuth [amazon.co.uk], generally reckoned to be the greatest authority on such things.
Unique code (Score:5, Insightful)
In an academic, Computer Science research sort of way, you're probably right. And there is a lot of common code in many applications, it's true - but that's what vendor-supplied and third party
The #1 cost in most software is time - to design, to code, to test and to document. That's what adds value. What you are saying is like saying that "houses should cost no more than the bricks they're made of, or that cars should cost no more than what the iron ore cost to mine. Hell, iron ore should be free, right, it's just sitting there in the ground waiting to be dug up!"
Here are the facts:
People like you will continue to say that software should be free, and you'll keep coming up with ways to justify your belief. That's fine, because you're fighting the laws of economics, and they're just as implacable as the laws of thermodynamics.
Flawed argument. (Score:2, Insightful)
I'd imagine a lot of really great code is fugly as hell, and just because code is design well doesn't mean it will do its job well. The two are relatively independant, unless you like to take a holier than thou stance, which it appears this article is doing.
In Other news (Score:2, Funny)
Canadian Geeks everywhere cheered Free.. as in Beer
Thinking along these lines (Score:2)
The benefits of Open Source [opensource.org] or Free software [fsf.org] to its users are undeniable. If the software has a bug, or the software does not do something you want it to do, you can change it. There are many advantages, and they have been explained at length by various people. If you are going to be using software, you are definitely better off if you have access to the source code.
Trust
The fundamental difference between open source software and closed source software is the level of trust required. For a business to use closed source software, the level of trust required is enormous. It is not simply a question of whether the money spent purchasing the software is a good investment. The time invested using the software is far more significant. Almost inevitably your own business information becomes tied up in a format that is specific to the software you are using. In order to buy software from a closed source company, you have to take the following on trust:
- They have not left gaping security holes in the code.
- They will fix bugs in a timely manner.
- They will eventually add the features you want.
- They are not using your computing resources to do things which are
not in your interest.
- They will not increase the price unreasonably once you depend on them.
- They will not go bust.
In fact, when you consider all the things that people are expected to take on trust when they purchase closed source software, it is amazing that anybody ever does so. The truth of the matter is that very few organisations properly considered these factors before they bought the software. They bought the software because they needed it and although there are terrible dangers involved in relying on closed source software, there is often no alternative. Companies and other organisations are only just starting to wake up to the dangers of closed source software.Business Models Having access to the source code makes good sense to the users. However the business case for the software vendor is far less convincing. In fact, the dangers of closed source from the user's perspective can be considered opportunities from the vendor's perspective.
The open source foundation proposes "4 ways to win" which is reproduced here: Four Ways To Win
Now for a higher-level, investor's point of view. There are at least four known business models for making money with open source:
In fact, the number of companies that have had success with any of these models is miniscule. This is hardly surprising, they are simply not very good business models for software companies.
Taking each in turn... Selling Support The better documented and more reliable the product is, the less support it needs. A business model where the more perfect your product, the less money you can make has got something fundamentally wrong with it. Loss Leader The very fact that this can be advanced as a viable business model for OpenSource shows desperation. What it comes down to is an admission that the best way to make money from software is by selling it. Widget Frosting This makes perfect sense if you are a hardware company, or when the software is a side issue. However, its no use at all for a business whose main product is software. Accessorizing Selling accessories is fine, but there is no pressing need to actually develop the software when one is in the accessories business.
There are of course other business models for Open Source. For instance, the one adopted by the Perl foundation and several others is begging. This is not a business model that many companies would find appealing though.
The basic problem is that for a business whose primary function is to make software, then the primary reward has to come from selling the software. We need a business model that actually works and we have one, it's called capitalism. It works like this: make something that people want and sell it to them. This model works for software too, and there is no reason why this model cannot work even when source code is available. Closed source vendors are relying on something a little closer to the business model of a heroin pusher. It starts off like capitalism, but there is the added feature that the user gets addicted and has to carry on buying the same thing even if he does not really want to. The more he uses the same vendor, the more reliant he is upon it.
The Solution Community software is software where the vendor can be paid a fair price for the software he creates, but where the buyer does not end up in a similar position to a junkie.
Community Source is software that guarantees the following:
- The right to see what the software is doing, ie access to unobfuscated source code.
- The right to add enhancements.
- The right to fix bugs.
- The right to sell his enhancements to other companies. This does not mean the right to the sell
software without the original vendor receiving any money. The buyer still needs a license from the original vendor, but he does not have to rely on a single vendor for upgrades and enhancements.
- The right to buy enhanced versions from 3rd parties.
Together these provide a guarantee that the buyers investment in the software is protected. The benefit to the software vendor is that he can sell to larger companies without them being scared of buying from an outfit which might go bust or be unable to properly support them. It is better for the client than software escrow since the client knows that if the original vendor does not maintain the software well, then someone else can do so.open source != more time/money to make it better (Score:2, Insightful)
I think it was wrong the first time, and I still.. (Score:3, Interesting)
Now, before someone decides I'm an anti-Open Source type o' guy, forget it. I'm not - I use Mozilla (1. 2 - woohoo!) for my browsing and mail, and Open Office as a most-of-the-time replacement for MS-Office (*SIGH* I still have office loaded for a few oddball things OpenOffice doesn't do right.) I've got a nice firewall (linux) and fileserver (linux) all running open source operating systems.
So, consider that before markin' it as troll when I say... Oh, PUHHHLEEZ!
Look, makin' an application Open Source does not garantee quality. It does not reduce code bloat (in fact, I'm starting to believe that at it's core, the Open Source way of doing things is starting to increase code bloat. However, the really slick thing is bein' able to fix that on a personal level with a simple recompile most of the time! But, that's a totally different article to write...) It does not garantee an increase in quality - just because you can LOOK at a bridge's construction, do you fully inderstand the architect & engineer's design methodology? Would adding another bolt hole here and throwing a bolt through it increase or decrease stability of the bridge. You have to be a specialist in the field to truely understand (just being an engineer doesn't cut it - you need to understand BRIDGES before you work on a bridge
Same applies to software engineering - while anyone could look at the source, and start hackin' at it, that does almost nothing for other people in the first place. You've got to redistribute the improvements, get it back into the source tree, and convince other people to re-compile before you do it. Most of the steps above require specialized knowladge of one form or another. (Before someone debates that point - no, not people don't understand how to run a compiler. I'm not talking about the
But, even then, some of this stuff is way above 75% of the
There's also somehow the impression that this would "change things". That somehow, because of magically having the source code available, this would make products better. Well, it's not going to increase the quality of the code from the original company who released it. And unless there's a clearing house for everyone to update thier application, what's the point? Overall quality doesn't improve, only single installations (or corporate installations where someone made the nessisary change and distributed it on the desktops - which to be honest, DOES indeed provide some promise to the concepts he presents in his article. Corporate licensing would be handy.)
Tech support becomes a nightmare too - "Oh, sir? You changed that bit of code? Sorry, can't help ya..." Let's face it, it's hard enough to support an application and all it's versions - it's hard to support it when someone can make a simple change. Add a public code repository to it, and man it just gets worse. Once the code is touched, there's no support anymore. (But, of course, if you know enough to mess with it, is it a downside? *SHRUG*)
Licensing would become an even deeper nightmare. If companies are putting horribly restricting EULA's on compiled products, imagine what they are going to want to do with the source? Sure, he talks about how to protect it with copyrights and excluding certain modules (more on that in a moment), but, companies aren't happy with copyright now, how will that improve with source code involved?
And of course, there's this interesting idea that you could just exclude some modules. Well, that does a couple of interesting things. 1, it defeats part of the purpose (but not all of it.) So there's still parts of the code that's buggy and unreleased. Whoo... what exactly did we fix there? 2, it would be an absolute Haven or Hell for Open Source developers. Companies would fall very quickly prey to people who simply replaced that core module, and suddenly have a working application - no need for the original developer anymore, just release a new open source core for the program. Open Source developers are going through a lot of effort to copy the current functionality of an application - if there was an even shorter route to gettin' the job done, someone would end up doin' it. Of course, given the paranoia level of some companies, Open Source developers could end up having to deal with ELUA's that prevent you from having looked at another company's source tree and writing your own. MS is already attempting this with a couple o' items. Why would the situation improve?
While it's an interesting set of thoughts, to me it comes down to a combination of personal choice, and company motivation. If you want the source code to an application, then choose your application wisely - use Open Office over MS Office. Linux over Windows. Etc. Almost anything out there has an Open Source equivalant (almost, not quite.) Use it.
As for companies - it's up to them to decide what resources become available to the end user, and under what license. If I can get one more feature out of Mozilla (contact synching with Windows CE... er.... PalmPC machines, not just PalmOS machines) I'll begin moving everyone in our offices to it - the combination of MS's licensing and features -vs- Mozilla's Licensing and features will make it a logical choice. Companies are now starting to have to take that sort of thing into account already - I'm not the only commercial developer out there deciding how much of my application (games, in particular) source I'm going to be providing to the end user. If Collaborative Source, Shared Source, Open Source, or model of choice where the user gets the source code, is truely of importance to end users, we'll see it happen. And the companies that didn't follow that path will have a hard time - adapt or die.
I personally choose to have applications that have the source available, as long as everything involved fits my needs. And, not including the "Everything should be free" crowd, I think that' show most users will have to make thier choice anyway.
Attacking the Problem from the wrong direction... (Score:5, Interesting)
The original article (and the subsequent followup) attempt to solve a problem using a desired tool, rather than looking for the right tool for the job. A lot like the old saying "If all you have is a hammer, everything starts to look like a nail."
The base problem that I think he's trying to solve here is that software quality is abysmal. That is, all commercial (and most free/open) software is riddled with bugs, many of which are well-known at ship time, but haven't been fixed.
Making source code available (whether as Open Source, Free Software, or a eyes-only copy-restricted) is orthagonal to this problem. yes, maybe, it could help. But that's incidental to the Free/Open software movement. And (as many people have pointed out), there are many problems with providing source with all programs, most of which are massive barriers to any help with quality of the software.
The fundamental flaw here is that commercial software's quality is the producer's responsibility, not the target audience's. In Free/Open software, the developers and audience have significant overlap, so it can be truly said that the audience can help quality. This is patently untrue for closed-source programs: the development community is very tightly controlled, and the user community has no real method of influencing quality (other than by not buying the product), even if provided with the source code.
So, this leaves us with the case of how to make the developer's produce better quality software. Fundamentally, we do this the EXACT SAME WAY all other industries insure minimal quality control: LEGISLATE IT. There are oft-quoted sayings about "if the car companies built cars like software companies build software..." and others to that effect. They all point a massive discrepency in the legal status of software: it doesn't play by any of the traditional product-liability and quality-control laws that every other product industry abides by. Yes, that will change the nature of the software industry: that's the point. And NO, it will not harm Free/Open software (as gifts - i.e. giving away something - are not coverd bty under the various product-liability laws)
You really want to fix the software quality problem? Require that software companies have a warranty of fitness. Require them to refund money for defective products (opened or not). Make them liable for damage caused by known defects. In short, treat them like anybody else. Software isn't special. It's time the software industry grew up.
See my previous post [slashdot.org] on why the software industry should quite being treated like a spoiled teenager.
The problem is real. The solution provided by the article is wrong. I'm right.
:-)
-Erik
Re:Attacking the Problem from the wrong direction. (Score:3, Insightful)
We need to see some civil cases in which software companies are challeneged based on nonperformance of their products. It's not my responsibility to check the source code. My responsibility ends when I pay someone for the product. Period. I don't want to see the source code. I want the product to work.
On the flip side... (Score:2)
An interesting idea, but:
That said, I agree that it would be great if more vendors shipped the source with your product. However, people just want software that works. They don't want to have to hire someone to fix the bugs in the software they bought that was supposed to 'just work' in the first place. Where it would be more useful to have the source is if you've got a system that has been around for a very long time, and it needs to be extended in some way -- especially if the original people who designed the system are not around any more. Anyway, I just wanted to point out the big 'might' in your statement.
Thousands of eyes (was Re:Won't benefit the users) (Score:2)
OK, I hear this over and over, so I ask you, the average
He missed the most valid point (Score:3, Interesting)
"I don't want to show the source because we make a ton of money from crappy code and the maitaince fees we get for fixing our bugs."
You laugh, but I've heard statment very similiar.
Of course if people would stop paying companies to fix broken code.
We just bought some code, it had some bugs, the company wanted 200.00 an hour to fix bugs in there code. Outrages.
Intellectual Property (Score:3, Insightful)
Anyone who understands the open source movement already knows that peer review is superior to any internal QA process. Despite what the FUD claims, there is little question that the quality of open source software has been higher than that of closed sources software. I think the fact other people might see their software as "lousy" only accounts for a very small % of the reason why most software companies are not open source.
Intellectual property is a much bigger issue, one which the article's author failed to address properly. Right now, I may have no clue what the best way to design a piece of software to do some particular task. If some other vendor has already designed that piece of software and released the source, I might not understand the details of what exactly is going on, but it would not be too hard to get a high level understanding of how the software works.
From there, creating the better mousetrap becomes a much easier task. The design of the software is often as time consuming or more time consuming than the implementation.
Sure, if I used their work in the creation of mine, I have created a derivative work. However, copyright law is a very grey area. If I kept my work closed source, how could anyone prove that I didn't steal my design from their product? They could sue me, but it would be at great cost to them, and if enough of the implementation was changed, they may not even win.
Managing any company successfully is not a trivial task. Executive board meetings are not filled with people who want to create poor software and hide that fact from the consumer. However, when someone presents a concept that could a) help competitors get into their market and b) result in a huge loss in revenue (directly and indirectly), what do you expect them to do? If you were a developer at that company, what would you want?
Regardless of how good you are, there's always going to be someone better out there. Most companies are realistic and realize this. Why give them an edge on your company's business? Do you really want to be out on the street that bad?
It used to be that way... (Score:4, Insightful)
- Customers didn't follow directions, so they always were screwing up the build and/or install. These were very simple tasks back then, much simpler than they are today. And in theory customers were far more educated since they were the very few who could afford those multi-million dollar machines and the huge costs of the rooms and facilities they required. Somehow, though, they still were able to find ways to screw things up, and support organizations spent much of their time walking
customers through these processes.
This would be worse today given many software users have no clue how to program.
- Support was a total nightmare as you never knew what source code customers were using.This was because customers would choose which patches to apply, and would add their own, leaving each customer with a totally unique piece of software. When something went wrong in it, it was impossible to know what the code was supposed to be doing, and what it was doing wrong.
While this might not be quite as bad today, since we no longer must rely on "core dumps" to diagnose bugs, there still is the basic problem of being asked to diagnose problems when you really don't know WHAT source code that customer might be using.
- the intellectual property problem... there were plenty of lawyers back then, but there really is a big problem with investing lots of money to build something, a unique set of code, and then making it easy for people to lift it. A variety of methods to secure it while still distributing it to all customers were attempted as there was tremendous cost associated with changing from a source distribution technique to a binary distribution technique, but none ever worked. If anything, today there is far more sophistication on the cracking side, so it seems even more doubtful that it is possible to secure code from mis-use when its considered IP. And there ARE valid arguments against giving away all code.
SO...
There were good reasons the computer industry turned away from distributing their software in the form of source code. I don't think they have been addressed, and thus I am unconvinced the equation has changed.
I think this is foolish (Score:3, Insightful)
Richard Stallman has talked about how all software should be open and that's always been where I start to disagree with him. Again, I agree that it would be beneficial to the world if all software were open, but I still think that people should be given the right to choose whether or not they want release it as "open".
Oh well, it's not something I really need to take a whole lot of time thinking about and defending against because it's really an unpassable law (and pretty unenforcable too). Just think about it, it'd be about as unenforcable as anti-piracy laws
Why not? (Score:4, Insightful)
Let's look at the problems described in the article:
1. Piracy.
How is having the source making it easier to pirate things? People have been swapping microsoft binaries for ages. It is actually easier to just copy the installation disk (whether floppy or cd) than to recompile the program from sources.
2.Copyright laws.
Wouldn't it make it actually easier to check if people conform to copyright laws? If I release all of my source code and you are required (by the marketplace perhaps, not as a law) to do the same than it is quite easy to see if you copied some stuff of of me. How many people have wandered whether Microsoft has copied some code from GPL licensed programs (I doubt it personally). How many have the opportunity to CHECK if they have?
3. National Security.
I do not have a lot of confidence in a nation that bases its security on the ability to sweep them under the rug. The idea is to avoid having those problems in the first place! Maybe if this practice became accepted we would not have destroyers being run on windows.
4. Safety-critical applications.
Even if there is little to gain from having this code available to the users - not having it is worse. What are you trying to hide? If this is a safety-critical application then the answer should be "nothing, have a look".
Nobody is asking to release the source code without compensation. It's just that the source becomes part of the application. IF most people will not use it - then fine. What are you worried about? Is your code really that bad that you could not write good code if forced to?
What people want is likely not what they want (Score:3, Insightful)
Like the bridge analogy, you can see that the bridge is sturdy and will hold a sherman tank. That's swell. What you don't see are the misplaced rivets that will cause the bridge to fail in unanticipated ways.
In other words, this is a kick-ass design, and I didn't notice that off-by-one bug until it was too late.
Another thing to ask is what do people really want? Bug-free software? Of course! And you know what they say they really want on airlines? More legroom and good meals!
Unfortunately, airlines that provide more legroom and good meals are running in the red. Unsurprisingly it turns out what people meant is they don't care about legroom and actually want the cheapest possible tickets and on-time flights. They complain that Southwest Airlines sucks, but everyone still flies with them!
My point is that people want the cheapest possible mostly-working software. Let's say, for the sake of argument, that there somehow existed some kind of free operating system for which anyone could look at the source. Would it have fewer bugs than closed-source OSs? Possibly. Is that really important to people?
No--really. Is it?
Re:Exhibitionary Code (Score:3, Funny)
Re:Exhibitionary Code (Score:2)
You forgot "#include <stdio.h>"
Re:Exhibitionary Code (Score:2)
Re:He's right, in more ways than one (Score:2, Insightful)
Re:He's right, in more ways than one (Score:5, Insightful)
Please tell me you are joking. Microsoft makes a lot of money off of software. How about Adobe? Macromedia? Real Networks? Symantec? The hundreds of game companies? Should I keep going?
I believe that source code should be released when the product is out of support (the source for Windows 95 should be release, for example). To release the source for commerical applications with many users (Windows 2000, Windows XP, even antivirus software) would just be insane because of the amount of hacking that would take place.
I do contribute on a few open source projects, but I do not believe that everything should be opened just because a few of us write code that is opensource. What is the percentage of OSS coders compared to programmers that code closed source applications. Might be a good
Re:Why open source software sucks (Score:3, Interesting)
Re:Walking on a bridge (Score:2, Interesting)
Another error in drawing similarity is that giving away code would beequivalent to giving away another bridge for free. (I'm myself not against that idea; I just think we cannot draw reasonable parallels).