Perhaps. But itâ(TM)s at 4.8 stars with 14 reviews on Amazon, so apparently there are many connoisseurs of poor writing out there. Or... ?

The FDA doesn't actually do testing. The device maker supplies evidence that development followed a process that includes testing, the types and amounts of testing being based on the risks posted by the device.

A company can potentially lie, and claim they did testing that they didn't - but Goddess help you if FDA figures that out: you're in deep, deep trouble. And they can definitely figure it out during a regular inspection, or if people get injured by your product, etc.

Sorry to quibble... but medical devices are normally developed using a process that conforms to ISO 13485, not 9001. Pretty similar, though.

I'm working with some other folks to start a company to develop, manufacture, and market open-source medical devices. We all have extensive experience in developing commercial medical devices - defibrillators, radiation therapy for tumors, etc - and we're convinced that getting more eyeballs to review software and hardware will substantially increase safety and reduce costs.

Yes, we know how to work with the FDA and so forth.

Stay tuned...

It turns out that in managing batteries and booting there are a ton of oddball cases that cause things like this to happen. For example, there may be enough power available from the battery to start the boot process with the CPU in a low power, but once some peripherals start turning on the power draw bec omes more than the battery can support, a voltage rail drops to low, and a reboot happens. Shameless plug: there's a chapter in my book on product development that covers some of these issues and solutions, http://www.goodreads.com/book/...

That's why you need to take the upload, check-out, copying out of the equation. Let them edit and save whatever they want to disk - the right technology can scoop those actions back up and bind it to the right repository transparently.

There is room for something in-between, more robust than simple timestamp versioning, but easier to deal with than full-fledged source control.

And what if you could?

It's been our experience this highly depends on the business. Some embrace GDocs openly, love it - good for them. Others don't for all sorts of reasons. GDocs is not for everyone.

If it's the right technology than it *can* certainly help. The naming convention and the organization is a burden, one that can be easily abstracted away.

Exactly - that's why you need something specifically tailored with documents in mind.

A filename solution is just not scalable and prone to error. Chances are they are using some sort of folder structure already, but they are humans, and things get forgotten. You come back to a doc two weeks later, you can probably find the last copy you touched, but everything else that's happened is forgotten.

Versioning != Version Control

When you are introducing parallel changes from multiple contributors, versioning alone doesn't help you. Say two people made a change to your document. The first messed something up, the second added something useful. With versioning if you revert before the first, you also lose the second set of changes. You need to be able to accept/reject change per user and versioning alone is not up to the task.

Google Drive and Dropbox have Versioning. When two people touch the same Dropbox file at the same time you end up with a conflicted copy that you have to sort out on your own. If two people edit a google doc whoever gets there first wins. But it's still just versioning. If after the fact you want to revert the first change, you also have to revert the second because you're just going to an earlier timestamp. Suggested Edits makes some progress in this regard, but you still have to deal with them immediately at next open instead of a time of your choosing.