Note sent to sunlightlabs mailing list (subj: "Turning Government Data into Useable Information") regarding the U.S. government's proposal received for a $16 billion Medical Care software system:[David James wrote:]
> Let me continue to play devil's advocate by giving you a pointed > example: Would you rather have closed source software developed in an > iterative and customer-centric way (using agile, for example) -- or > would you rather have open source software developed slowly by a group > of volunteers that aren't responsive to the end users?
This is a false dichotomy, despite it being fairly true in practice today.
The problem here isn't Open Source, per se, it's that no one yet has invested the money to first create the tools that would provide a better development model (and internet market) using an open ideology; that is, to create a set of tools that would allow an open development model to negotiate and track deliverables, offer up portions of the work in real-time on a liquid market of skill trading, and post and track performance so that accountability can be an input back into the system.
If $1billion dollars of the [$16bil] software project was put up to first develop the tools to bootstrap the open development process so that it can occur in a way similar to an investment market, then that would be a billion dollars that will accelerate not only the quality and speed of development of that project but EVERY project for the indefinite future. I guarantee that a $1billion would make one of the most efficient and exciting development models ever created. I'd even drop everything to work on it myself for nearly nothing (as I'm sure hundreds of hardcore developers worldwide)--there's that much of a need for it as well as that much of a return. It would be something akin to investing in an interstate highway system to facilitate a vibrant information economy.
> To the extent that OSS projects prove themselves against these > criteria, great. But I don't think an OSS project automatically > deserves, for example, a 10% bonus just because it is labeled as OSS.
No, I would argue that they deserve 100% bonus for being open. You have to keep in mind that this would not just be a 3 year software project--large-scale software can last for decades. Could you really make an argument for being locked-in to a single vendor for 30 years?
> Though obvious, I think it is worth mentioning that open source > software is not a panacea. I saw this because it is easy to get > carried away. OSS by itself is no guarantee of success and not all > OSS projects are successes. There are many other complimentary > practices and paradigms that help real teams deliver value across > these dimensions such as agile and test-driven development.
To avert a misunderstanding here, I think it should be pointed out that FOSS is in no way contrary to agile and test-driven development.[Javaun:]
> My bottom line: the purpose of any software system is to solve a given > problem, pure and simple.
Haha, yes, of course, but "solving the problem" is the very nut trying to be cracked; that is, what is "the problem" and what does it mean to "solve it"?
> Folks have mentioned the > issues with proprietary as being closed and not in the public > interest. Again, it's all about solving the problem. > The easiest, most > open, most trustworthy open source software is worthless to you if it > doesn't solve your problem.
Please, sir, re-consider your statement thus: 'The easiest, most open, most trustworthy government is worthless if it doesn't "solve your problem" '. Now, I'm not suggesting a democratic or open government has solved every problem, it's just that history has shown that all other options are simply unsustainable.
But just what sort of problem does a closed, proprietary government purport to *solve*? Timeliness? Well, possibly, if you're only looking at a short time horizon--but that is never *fully* the case except for a company or person who just wishes to gain advantage at the expense of the larger whole, and, I would argue THIS IS ALWAYS THE CASE. Most so-called "vendor solutions", when truth be told, amount to little more than complicated sophistry and false authority to hide and befuddle just how little the vendor really knows about the problem, how much it will cost, and how much they hope to gain. Proprietary development, like proprietary governments, exist mostly to hide this embarrassing fact.
So the issue is a sort of categorical error: it is never the case that a problem can be spec'd before-hand completely because "the problem" in an open-ended system is never fully known--it is a living evolving thing--therefore, one must ask, under what governance/development model will the greatest efficiency (and least frustration) be gained for the long-term?
> Proprietary definitely has its downside, but it *can* be the right > choice. You can get just as locked in to an inflexible Open Source > system.
I think this is toying with imaginary hypotheticals. It seems a logical impossibility to have an "inflexible open source system" compared to a similarly complex closed system...
> Open source projects do end sometimes or the code forks, and > you'll have to decide whether to migrate or maintain.
Yes, but compare this to a proprietary "solution"--you have no choice: you MUST upgrade and pay for the new version or you won't be supported anymore. And where will you go then?
> Finally, any well architected platform (closed or open) is going to > have a ton of input from end users. That's standard software dev > practice. You can make blanket statements about an open source > solution being better because it was made with inputs from Doctors/ > hospitals. Organizations have different sizes, different levels of > complexity, different human processes, different staffing > requirements. One hospital IT manager may have a staff of good > programmers for OSS, another may have zero staff budget but can write > a check to a vendor.
Your point about the apparent ease of just "writing a check" for support deserves close scrutiny. Firstly, that ease is a red herring--it mostly leads to escalating support costs and eventually degrades the relationship between the end-users and the vendor until a replacement has to be found. Secondly, just "writing a check" is NOT a viable solution for a government program. Thirdly, most "vendor support" amounts to little less than shields of obfuscation to project a sheen of credibility to the end-users so as to justify their generally high maintenance fees. Most companies simply don't want their users to see their internal practices--not because of loss of trade secrets (their overt rationale), but because it would make the vendor's knees tremble to let their high-paying customers see *just* how sloppy it really is. Perhaps a bit of an overgeneralization, but I hope the truth of it can be seen.
Contrast this with a well-designed open-sourced platform for entering bug reports, tracking its progress right with developers. Both managers and end-users can see the status of the system at any time. The only lure of "the propriety solution" is really to managers and politicians who want to have that ever-illusory, pat-myself-on-the-back (for *now*) feeling of a "hassle-free", "turn-key" system--just write the check and "let us do the work". They, like the vendors, are mostly clue-challenged with respect to really knowing what is needed and so it is... the strange game of mutual chest thrusting that comprises the "enterprise software marketplace"....
> If both systems can export data to the same XML > standard, what's the difference?
It's not enough for "open document standards" and API's. To use an analogy, nations can have international units of measure and currency standards, but these alone are NOT sufficient to create an efficient market--the nation within must still *open it's markets* lest it be just another protectionist state--which gives only an *illusion* of advantage, and even then, only temporary and only to the protected. And it's always a bit hostile to the larger system as a whole, so sophisticated mechanisms must be put in place to keep up a sort of propaganda shield of "quality". This is called Public Relations and "customer care". In any case, to quote wikipedia: Virtually all modern day economists agree that protectionism is harmful in that its costs outweigh the benefits, and that it impedes real progress. Adam Smith agrees.[in another note:]
> Chris, that's a good example and I certainly won't disagree with you. > But that example also supports the point we're making about keeping > the decision value-based. If everything is apples to apples equal, but > as you say one solution is open source, then that is absolutely a > value add and the marketplace will reflect that.
Yeah, the marketplace will reflect that, *eventually*, if you want to wait a few decades for the market to reach equilibrium.
There is immediate value for public investment to develop tools for open source development to accelerate the "information economy", just as there was value for the nation to make the open-access Interstate highway system. This is a type of "value-added" that isn't easily met at the single project or single vendor level. You must consider that each of us: you and every other person who procures software is making a stand for or against an open society--it's not something "the market" just performs independent of you--you must affect the market with your own values and decisions.[...and from Sylvia:]
> "Once you've built this reference implementation, why on earth would you not > then open source it?" > > It is an expense that does not generate revenue or increase profits.
That candid reply is a very unfortunate way to look at it. Open sourcing your code need not cost anything yet always provides some non-material benefit (as the veteran's example showed) if the relationship to the project is positive. I wish I could give a thorough answer to this, but this message is already long, but essentially amounts to a paradigm shift that has only partially taken hold in the internet era.