The widespread acceptance of open source continues to grow as a cost-effective alternative to traditional network deployments. Well-known projects such as Linux have proven themselves to be in the enterprise environment, helping to dispel the fear, uncertainty and doubt preceding open source implementations. In the past two years, the industry has begun to shift from a total dependence on proprietary applications to a desire for more cost-effective, scalable and collaborative solutions.
Post a Comment
Member since:
2005-09-08
Member since:2005-07-06
Member since:
2006-12-28
...but not so much for system engineers and administrators. I can see the mixing of code in a proprietary project being of grave importance and appreciate the author's warning though.
I understand the problems with OSS projects no longer being updated but for me, when I install an OSS server product, it always comes with it's own form of update service.
For example, I run Sun's Java enterprise system which contains many OSS components (Apache and OpenSSH to name but two). When any one of these components get updates, I don't download the latest source code, I wait for Sun to issue it's next security patch or fix pack.
The same goes for any Solaris or Linux installation I might be running.
On the other hand, while I was working closely with our internal development team, I found the amount of OSS software used in any given project to be huge. I'm glad none of these projects are ever intended to sold as proprietary software as the sheer cost of replacing all those components would be staggering.
All in all, it's a good article with some excellent ideas about avoiding code 'cross pollination'.
Edited 2007-09-13 15:20 UTC
Member since:
2005-07-06
Pointing to the thousands of open source contributors on any given project, developers note that any discovered vulnerability is likely to be fixed within hours, whereas a security flaw in a proprietary application may not be fixed for several days depending on the backlog.
There's usually a reason for that. For important security flaws, they'll fix it right away, but they need to do regression testing, determine if the same flaw exists elsewhere, etc. It's not just a quick hack and they're happy.
Member since:2005-10-02
Member since:2005-07-06
Member since:2005-10-02
In the default installation? Very seldom. But fixing serious vulnerabilities in their packages (not default installation) ? Constantly. Just because a port isn't a part of the default installation, doesn't mean it's not meant to be fixed
And OpenBSD has so far fixed their holes within hours. It is typical for MOST FLOSS-projects. Security! Security! Security!
It is silly to choose compatibility over security. It is wiser to choose reduced functionality than it is to choose reduced security.
Member since:2005-07-06
It is silly to choose compatibility over security. It is wiser to choose reduced functionality than it is to choose reduced security.
That depends entirely on the application and situation. If the actual loss in productivity due to reduced functionality overshadows the cost of a potential security breach, then you probably want to reconsider. You want to find a balance between ease of use and security, taking into account all surrounding factors.
Member since:2005-10-02
That is however not a concern of the company behind the product, but merely a concern of those using the product.
1) It is the responsibility of the developers ( or the company/companies) to deliver a fix here and now.
2) It is the responsibility of the users to decide whether or not to install the fix.
If installing the fix breaks the users software and this is more expensive than a security breach, they shouldn't install the fix. If the security breach is more expensive than reduced functionality, they should install the fix. The developers however only have the responsibility to give the users the choice.
Finding the balance is solely the responsibility of the users.
Member since:2006-02-06
Keep this in perspective: Packages vs. what's needed to bring up a system are entirely different concepts.
If someone wrote a program to exploit a hole in the kernel, that's one thing. If an admin installs an FTPd, for example, they do so knowing that just because it's made to be compatible with the OS, doesn't always mean it's the most up-to-date port when dealing with Free/OpenBSD, which can result in an exploited system if the package goes unchecked - and that's up to the maintainer at that point.
If the port/package maintainers are lazy, then there's a HUGE problem. If the original authors are lazy, there's an even bigger problem with the solution to fork or take over the project somewhere else.
I've not meddled with the BSD's long enough to get into who's lazy and who isn't, so I'll let this one off here, but I will re-state that the differences between OS and other software packages are clearly distinct.
And yes, I get a "Thank you, Captain Obvious" here as well.
Member since:2005-07-06
What if the fix introduces another security hole? What if it breaks a major feature? I'm sorry, but except in extreme cases (say a worm thats been spreading over the net fast using the exploit), you need to properly test the fix first.
When possible, some companies do provide temporary workarounds until the fix is properly tested and released.
It requires a massive coordination to implement a proper fix.
Member since:2005-07-06
Who said anything about OpenBSD; proprietary vendors not only have to worry about their own products but products that rely on their own products; they have to ensure that in the process of fixing up a flaw, that in the same process they don't end up breaking compatibility with something that relies on it.
With that being said, however, I think the issue shouldn't necessarily be one of 'excusing' delays but instead asking why these companies haven't setup better communication with their partners so that rather than compromising on security fixes for the sake of compatibility, their partners are the first to know about the fix plus what has been fixed so that partners can issue updates for their respective tools at the same time updates are released for the main programme in question.
Member since:2005-10-02
sappyvcv attacked a specific security policiy of open source projects, and this specific security policy happens to be the security policy of OpenBSD.
So open source projects sponsored by Novell, Redhat, IBM etc. don't have to worry about the projects depending on them?
And isn't this also true for open source projects? Or do you claim that no products are based on open source?
Member since:2005-07-06
Hang on, did you actually read *ALL* the post; did you miss the second paragraph where I actually expanded saying that it could be avoided if the proprietary vendors communicated better each other. Communicated better just as there is good communication between the various open source projects.
I'm not trying to be mean, but do you actually read *ALL* the post before hitting the reply button? honestly - tell me, because I am confused as heck trying to understand how the hell you came to the conclusions that you did.
Member since:2005-07-06
Member since:
2006-02-22
Member since:
2006-05-26
Open Source Software and proprietary software have co-existed for about as long as there's been hardware capable of running it, pre-dating Linux and all the other more recent horses into the race by decades. History shows that there will has always been a combination of the two, and the future is most likely a combination of the two, with neither one completely replacing the other: anyone that states that "OSS will rule the world" is a zealot, as is anyone that states "All software will be proprietary!"
Why will there always be a mixture of both? Because neither one is the whole practical solution for all situations in the real world that also involves budgets, because while OSS and free software may be available for certain things and works best for those needs in a given situation, not all situations have the luxury of being able to afford the biggest resource cost of Open Source/Free software: that of time, with another factor being that of (in many cases) trade secrets/intellectual property being a part of something that needs to remain hidden from the general public and on a need-to-know basis for the entity that needs software to solve a problem. Add to that, there's many things that are different enough problems from anything readily available that it makes more sense to do a custom project to implement it, and again, there's the time element: while free/open source software and the ideology is nice in theory and all that, eventually developers need to be paid, because nobody else tends to accept "Well, he's doing something that he's not being paid for, so we won't expect him to pay for our goods and services, either" and as of yet, I'm not aware of any government that pays a developer a stipend for working on any free/Open Source Software, or any other single entity that does. If someone is doing a project on their time outside of regular full-time employment, there's no practical or logical expectation that they'll be able to devote nearly as much time or energy to it as a regular full-time job of doing it. Anyone donating their time outside of regular paid full-time employment towards such a project should be thanked for their generous donation of time and energy, and not merely for the time and energy expended for that specific project, but also all the time, money and energy spent studying to become skillful enough to accomplish that goal, which is what a HUGE percentage of people saying, "Do things for free! Produce all this open stuff for us because we want it! Why should you complain?" and those that don't decide to use up their time, money and energy to do free/Open Source Software outside of what they do for a paycheck should not be harassed, which is all too common.
Member since:2006-01-14
You make a lot of good points. I would just like to add that I see OSS development more like art than science when it comes to incentives. There are a lot of reasons to do it. Many people get paid to do the programming. You look at the major projects and you will see that the main contributors are working for Novell or Red Hat or IBM or Sun or someone else. Why? Because it gives that company some leverage into how the project moves forward. Then there are the people who write software that is incidental to their jobs. Some system admin needs a tool that does this. He writes it as part of his job and his company allows him to open source it. Then there are the people doing it for free to make a name for themselves. Many students do this to make themselves more attractive to employers. Then there are the people who do it just because the love it. everyone has a different reason for doing it. However, in most cases I would say that there is a underlying truth that they do it more because the love it than because they expect to get paid. This probably accounts for the higher than average quality of OSS software. The only people that I harass are the ones that use OSS and think that using it is all the thanks they need to give.
Member since:
2005-07-06
People like to poke at Apache and other projects - I think one thing people need to realise is this; these projects are developed in the open and under constant scrutiny by end users, developers and detractors alike.
Unlike Microsoft, IBM or any other large software company - these projects don't have the luxury of being able to hide things when problems are found. Whose to say, for example, that in Microsoft Windows, there aren't thousands upon thousands of bugs there are confirmed and verified but due to the lack of any motivation by management to allocate resources, these issues simply remain unfixed until such time all heal breaks lose in the case of 'code read' and 'blaster'.
As a company owner, would you rather have full discloser about the possibly risks with your software OR would you rather have a software vendor lie to you about the true status of the software security - and worse still, whose to say that, for example, there isn't a bitter and jaded employee who decides to disclose those list of vulnerabilities to a group for a set price. It might take a month before this is known by the parent company - and your software might be infected by then. Hardly what I would called 'secure computing'.
Opensource, as I see it, is like the individual that is too honest; sure, he is honest, everyone knows of his past, but at least you feel secure knowing the full details vs. another individual who is secretive and you never know what he is trying to cook up behind the scenes. You know what you're getting in the first scenario, its straight up and down honesty. The second, would you really trust them?
Member since:
2006-03-24
Seriously, businesses only trust the money they pay so they can setup requirements and expectations. It's not about the source or whatsoever. It's about business people, technical? do they care? After they paid, at least there is SLA they can be based on and blame the company if they don't meet any single on of the items in SLA. So who do they trust? their money then.
Member since:
2005-07-06
Member since:
2006-01-19
I mean to differ from this article's opinion.
He writes, that OSS might pose a risk to a business. I asked myself: What kind of business?
Obviously you do not run any risk if you are a food seller, because even if you use every line of OSS code on earth in-house, there is NO way whow you possibly could breach a license. Even if you adapt the one or other application to better meet your needs.
He is talking about software companies, proprietary software companies to be exact, and they should better stay away from OSS code altogether, or at least evaluate very carefully the license of every piece of code they are going to use. In short words: They should know ho to do their business.
But most proprietary software companies, who ran afoul of an OSS project, deliberately violated the license and knew it (no mercy for them!), or tried to find loopholes in the license (TIVO, NOVELL) and overlooked something.