Slashdot Mirror
Does Open Source Need Quality Standards?
underpar writes "This Techworld.com article reports that a UK group called the Open Source Consortium is being officially launched today. The article further states that the goal of the group is to respond to claims that switching to open source is more expensive than using Microsoft products and to help smaller companies compete with Sun and IBM for open source contracts. They say they will not compete with other open source groups and they intend to eventually come to the US. The hype-filled about us section of their site says their Quality Standard Certification provides a "simple framework for self-assessment and performance improvement." The question of whether this is useful or even wanted in the US still remains to be answered."
Be careful what you wish for.
Something "free" or "cheap" might be so for a reason.
I still say best open source is that tied to proprietary hardware then you really cash in.
As for la-dee-dah software, operating systems, etc, I stay away from those.
More to the point, isn't ISO 9001 one of those standards where you prove your ``quality'' by committing to following a process, and documenting that you do indeed follow that process? The inevitable result is that you can commit to shooting your customer in the foot, and document that you have done so, and earn the highest ``quality'' rating for it. That sort of ``quality'' isn't very reassuring.
See what I've been reading.
Linux in medical devices should have follow FDA standards
Linux in automotive systems shouldd follow DOT standards.
Linux in voting machines should follow Diebold/MS-Access quality standards..
(sorry for the US-centric examples - for your own country pick your favorite certification organizations)
Nothing will stop them. If US companies want to listen to the US Open Source Consortium as you name it, then they will. If European companies want to listen more to another OSC, then they are free to to do so. Is this necessarily a bad thing? As long as there is some kind of control and legitimacy over these consortiums, this can be good. Establishing 15 different consortiums within one country just because some developers disagree would probably be overkill though.
F/OSS needs more unified standards first! (like for packages).
I can imagine an organized group like this, though, would be excellent at answering issues like corporate generated FUD in an organized and coherent way. That's our big problem, we lack representation (not counting eccentric geniuses with big ZZ top beards).
Luck favors the prepared, darling.
Not only an overgenralisation, it is a redundant idea to boot. OSDL already provides a lot of the stuff they publicly talk about - code quality etc. The real purpose of the organisation comes to light when you read deeper into the site.
You need to be skilled in their "consulting framework" and you need to conform to some "financial framework" as well. Their membership criteria are mysterious (hint, you probably need to be a member of their club of buddies) and some of the organisations that are members (and knowing those organisations intimately, they probably are the drivers behind this thing as well) are decidedly dodgy - Open Forum Europe has publicly spoken as "Open Source Representatives" and as such, have signed a declaration supporting software patents. Looks to me like just another group of people trying to corner a market. Anyone remember the Open Group, and the "good" they did for UNIX? (another hint - a lot of the same people are involved)
This is so much the wrong crowd to hang out with....
People who think they know everything are a great annoyance to those of us who do.
Good to see "Dumb overgeneralization" modded to +5 right off the bat. Other replies in this thread also deserve "insightful" moderation.
Software should be held to whatever quality standards the customer requires, regardless of it's proprietary or open development process.
For products where quality IS important, published documentation, including source, code-change-history, published test-cases and results of running those tests cases, etc. can help ensure quality. Commercial outfits typically rely on outside auditors or "trust us" to show that they probably ship quality code. At best, they publish their test cases and the results of those tests. If we are really lucky, a few outsiders have reviewed the code and pronounced it good.
For projects where quality isn't important, well, nobody cares but the authors.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I'll give you that, but for every binary decision, you're going to piss off roughly half the people.
:)
There are security analysts who do spend time looking at the kernel, but it's a big job. As with most of these projects, they usually start becomes someone pays a security company to spend millions auditing it (ie: a government wanting to use it for sensitive data or voting machines). If only we could get every linux user to do one line of code *smirk*
BTW: FHS is an attempt at getting some standardization.
You mention 'designed for linux' and 'interoperability' which I think are tough ones. The big difference I find between Linux OS and Windows OS is that one company merges the GUI, kernel, drivers, shared libraries of 3rd party applications (DLLs), and (sadly) web browser into one. Linux, while having folks like RedHat producing distros, has no consistancy.
Now of course, I'm not saying anything you (or anyone on Slashdot) doesn't already know. But the key factor is that I can make my new audio board 'designed for linux 2.6', but the actual installation is different on every system. Some want a kernel compile, some store modules in one place, others will scream that the kernel is tainted when you load them. So how can one ensure that their board will work properly (and easily)?
There are a few attempts at standardizing hardware (as you mention linux hardware). The most popular thus far is DKMS: DKMS stands for Dynamic Kernel Module Support. It is designed to create a framework where kernel dependent module source can reside so that it is very easy to rebuild modules as you upgrade kernels. This will allow Linux vendors to provide driver drops without having to wait for new kernel releases while also taking out the guesswork for customers attempting to recompile modules for new kernels.
See http://linux.dell.com/dkms/ for more information.
when you see the word 'Linux', drink!