Industrial Strength Open Source Code?

dnnrly asks: "I work for a company that writes software for the pharmaceutical industry. We have to work in quite a tight regulatory environment because some of our code ends up in the process of drug testing. Seeing as the FDA are quite picky about making sure that there can be no errors in testing new drugs, our clients have strict rules that we must follow for coding. We have to review all of the code that is written, making sure that everything is traceable to a design specification. Where we use 3rd party software/code we have to make sure that it comes from an ISO9000 source. This is a bit of a problem when we would like to use open source stuff in our code. Projects like log4net and NUnit would be tremendously useful in our code but we're not allowed to use them because they don't tick the right boxes. Now, *I* know that these projects (and others) are incredibly stable just because of the volume of use that they have seen but that isn't enough for some people. How can we certify such software?"

Comments

ISO 9000

[deanj]

No offense intended, but an ISO 9000 source?

ISO 9000 just means the people that "certify" this have all their procedures documented.

I'd be much more interested in a company that delivered software that worked, and stood behind it, rather than a company that puts all it's time and effort into ISO 9000. Every time I hear someone asking for that, they're more interested in being buzzword compliant than anything else.

Man, oh man.... The next thing people will be saying is that the company mission statements actually make a difference.

Re:ISO 9000

[Stradivarius]

I'm sure many of the companies that are certified would probably agree with you. But the fact is that many companies, particularly those selling to government entities, are required to be certified in ISO 9000 or similar programs as a precondition of doing business. So they have to go along, at least to some extent, with the fiction that certification equals quality.

IMHO, certification really means repeatability (do you always follow some established process). Which is certainly important, especially when it comes to very expensive/complex programs, in order to mitigate risk. But it's not the same as quality. One can repeatably implement a lousy process or procedure. One can also be repeatably bad at implementing a good process (you can have the best design process in the world, but a bad designer will still give you a bad product).

I think the whole certification buzz comes about in large part because it's difficult to evaluate the other big factors that impact quality, which are largely human factors - talent, workmanship, management acumen, etc. Because customers have little visibility into those factors, they instead evaluate the factor most amenable to measurement - process compliance.

People with some common sense recognize the certification as a useful but limited tool for evaluating a company. It's the other folks that you seem to have encountered - the ones who think process compliance is the Holy Grail for business success. Those are the ones I try to avoid :-)

Own it

[keithmo]

Could you, for the purposes of certification, take ownership of the libraries you want to use? By "take ownership" I mean either a) acquire, or b) create the necessary design documents for the libraries, then code review them as you would your own code.

The starving programmers

[w33t]

This brings to mind a conversation I had the other day.

I think the main reason that (F)OSS is still having trouble competing (despite the widespread acceptance amoungst industry experts) is because of budget.

In this case, the budget to get a piece of software properly certified.

There are many aspects of creating software that require non-technical administrative personell to handle. I don't remember ever hearing about OSA (Open Source Accountants) ;) These people cost money. And it's one thing to freely dedicate your time to devlopment, but it's quite another to freely donate large sums of personal money.

It is truly inpspiring that so many can work together so well towards a common goal, and it is truly stunning to take in the vast amount of software available which is written pretty much completely philanthropically.

But the problem is that few actually get paid to do this, it is done in spare time.

In my conversation I wondered how else software writers could make money, besides the tried and tested subscription and serial-activation systems in widespread use today. How else could programmers, who are doing some of the most mind-bending, skillful crafting of any career, get compensated for their work?

Wouldn't it be great if AMD, Intel, ASUS - or indeed any large electronics manufacturer - would offer up a pool to develop software?

The trick would of course be that the software should of course be standards compliant and thus run even on competitors hardware. But maybe AMD could have a certification that says, "written for and extensively tested on AMD hardware".

Software seems that it should be freely available - it just seems the nature of all information in general - but there is that problem that the programmer needs to make money.

It just seems to me that logically the consumer should buy the hardware - the physical, tangiable thing - and that it should be up to the hardware manufacturers to make hardware as a whole more useful.

Here's the irony in my eyes - right now hardware manufacturers pay Microsoft in order to get a little sticker that says "built for Windows XP".

This doesn't seem right. It seems totally backwards to me.

It reminds me of a quote from "V for Vendetta": "People shouldn't be afraid of their governments, governments should be afraid of their people."

In other words, "Harware manufacturers shouldn't be beholden to the software companies, software companies should be beholden to the hardware."

The fact of the matter is that I just wish that after I pay $2,000 for my nice new system that it would run right out of the box. Macintosh is close - but I would have the added stipulation that the software on any hardware system be standards based so that I don't have a Dell OS, IBM OS, HP OS, Alienware OS...etc.

These are just thoughts, and I understand that there are many counterpoints.

Re:Laff

[ClamIAm]

The testing has to be perfect. The drugs? Not so much.

And I don't understand why the parent is modded troll.

Problem is documentation

[Kadin2048]

I think the problem that OSS software has is documentation.

Namely, that there isn't any. And I'm not talking about end-user documentation here, I mean process documentation. Specification documents and all that. The kind of stuff that normally gets developed alongside code, in any commercial/industrial development methodology.

There is an unspoken assumption behind the OSS ideals, and this is that the program's source code is the only documentation that anyone should ever need. This, frankly, is not true. It might be fine for code that has an obvious purpose and scope, and for systems software, but it starts to break down when you get into business software. How are you supposed to know from the source code, what the business process is that a particular segment of code is designed to support? You don't. How can you tell if something is a result of bad coding, or an incorrect design? You don't -- unless the same person both understands the code and the processes involved.

While it might be a safe assumption in many OSS projects to have the same person reading the code and analyzing the processes, this just doesn't happen in the real world. You usually have different people (even different groups of people) developing the specifications and processes, and writing the software from those specifications. In many cases, the people developing the specifications don't have the background or knowledge necessary to read the code directly.

I've said this elsewhere, but there's a lot of resistance in the OSS world to writing specifications. I don't know if this is because most of the software is written by programmers in their free time, and these people detest structured methodologies because they have to work with them in their day jobs, or if it's just a consequence of the way OSS is developed, but we're starting to see problems -- it's very hard to merge free software, where the code is the documentation, into a workflow where you have distinct levels of docs, where the code is only the very lowest level of end-product.

It's not if the systems to maintain documentation alongside code don't exist: some sort of Wiki-type interface, which was kept up-to-date against a project's official sources, would do just fine, and go a long ways towards improving the usefulness of OSS. However, there's little motivation for most projects to go to that level of effort.

I really don't have a good solution; I just know that I work in a situation very similar to the OP's, and we don't use any OSS code ... not because we really even care about license issues, but just because it would require more effort to document somebody else's code than it would just to draw up the documentation and have a programmer rewrite it. The former would require running our entire system "in reverse;" it would require a programmer to read the source code of the outside project and write a specification from it, which they're not used to doing. (I can almost see the objections forming right now.)