Slashdot Mirror
All Source Code Should Be Open, Revisited
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."
However, right is a word that, in the English language, has several meanings. In this case, he is also right in a moral sense. Software authors are morally obligated to make their software and source code available to their users Free of charge. Any other action indicates that they wish to take away the rights of their users and forever enslave them under the tyranny of EULAs and closed-source software. They owe it to us, the buyers who have supported them for all these years, to let us see their source code.
I know that this view may generate a lot of controversy among those with a vested interest in seeing the rights of software users taken away, but I feel I must get this view out in the open and let my fellow open source coders know that they are not toiling away in a vacuum, that people out there do appreciate them. Thank you.
Software piracy is victimless theft.
Now imagine every script kiddie having the full source to W2K or XP, or heck even Office. Lets say, following the rules of the article, MS removes the 1% of intellectual property and replacing them with stub routine. There is still enough there to determine the weaknesses, and maybe even enough to create a new trusted OS that really isn't trusted?
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.
While I think the _quality_ of the code, when released as open source will certainly improve; a corporation would not want the image of having sloppy code, I think this could be a bad idea in certain areas, particularly for propriatary military and defense department systems.
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.
I'd rather be a conservative nutjob than a liberal with no nuts and no job.
http://saveie6.com/
...and the closed source version of a car wouldn't work, but you can pay for support to give you the run around and try to convince you that YOU must be doing something wrong.
come on fhqwhgads
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).
The law of excluded middle : Either I'm foo or I'm foobar
belong in National Enquirer, along with pictures of two headed babies and Michael Jackson.
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!
For mass-market products like Windows, Office, etc, (ie, those where the users themselves are not computer science people), I'm sure 99% or so are absolutely unqualified to look at the source code and make informed decisions about code quality, so they'd have to trust some third party. And even if there is some software "Ralph Nader", how much influence it would have over those users who haven't got any idea of the importance of "good" code is doubtful.
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.
There's 10 types of people in this world, those who understand binary and those who don't.
Packing the source code along with commercial distributions of software is an excellent idea, and it's really a shame that it doesn't happen. It looks to me like the company would benefit the most from such a solution - for one thing, they could leave patch-making to the community and needs for support would possibly decrease.
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.
The lack of MS source has not in any way slowed the discovery/exploitation of Windows flaws. But because the only peoples looking that intently at the poor design of MS products are a) the people who poorly designed them and b) the exploiters and the kiddies who use their tools, the vicious cycle continues. Opening the source code could allow others with a more positive inclination in to help fix the problems and point out the potential future points of trouble.
As interesting as it would be to be able to see the source code behind such programs as Windows or Office or even ICQ, is it even that important?
.doc handling program that's free, for example. But even that can be effectively remedied without complete open source. Even a behemoth like Microsoft could be made much friendlier through some well placed stubs, open protocols, etc.
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.
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.
It keeps coming to the forefront of my thoughts. As all the antitrust suits, patent battles, and digital rights management debates escalate; one idea continues to permeate my understanding. It seems simple enough. The difference between the protections required in the physical versus the virtual (or information) world is that in one you can inspect an object, hold it in your hand, and run an infinite number of tests on it; but in the other, the finished product can be like a black box, having only the properties that the creator desires. This is not profound, of course, and many people would debate the statement entirely. But the essence is true, at least if you were to follow the letter of the law. Closed source software puts limitations on what people can legally learn about it.
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.
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.
If brevity is the soul of wit, then how does one explain Twitter?
Ok, I thought the first one was pretty off base and utopian in it's thinking, and I don't think this one-page update to the artice does anything to improve matters.
:-)
/. crowd - we all know GCC or compiler of choice like the back of our hands. Or, for some, the palm of thier hands ;-)
/. crowd's heads part of the time (picking an arbitrary number here) So what point was it in handing the source for a accounting system to someone who who is a systems administrator? Parts and bits of it make sense, but, without the background in accounting systems, there's parts of it that could cause more grief than it's worth for a simple change.
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.
Davis Ray Sickmon, Jr - looking for something to read? Check out my three free novels at MidnightRyder.org
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 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
There are always four sides to every story: your side, their side, the truth, and what really happened.
He forgot:
"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.
The Kruger Dunning explains most post on
Only in the same way that Tom Clancey's competitors can take advantage of reading his books. The code is still under the full protection of copyright law, and since competitors would be required to disclose source as well, violations would easily be detected. Just like in the world of books.
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.
I do not know if we have a mission statement, but what money we make comes from the rapid development aspects of the software and the ease of customization of application code.
We sell through a network of dealers (you can be one) who usually deliver the source to the client. The client signs a NDA too.
People do manage to steal from us, and we do not like it, but it is not a day to day concern.
We do accounting software. The application code is called by the framework to do its business, like accept user input for a file maintenance design. The application code tends to be pretty much just business logic that is executed by our framework software. This probably all works for us because we use a third party language product that ties to the server.
So I conclude that shipping source *can* be a viable business model, even with proprietary software. But it is true that the user base is relunctant to upgrade, and this often is because of customization issues. So our new versions have to be pretty compelling to generate an upgrade.
Customization of application code is not otherwise a big problem for us. Usually, we can just talk our resellers through a customization bug. In some cases, we need a copy of the system.
This approach has a history back into the '70s. Application code and designs from that period can still be automatically converted to our current gui system. I think this history merits consideration.
Bug handling would be a nightmare
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.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Get yourself a disassembler, learn assembly, and then EVERY progam you get comes with source code!