The State of Oregon vs. Oracle [pdf]
oregon.gov
oregon.gov
One developer experienced in Oracle products called Oracle’s programming “atrocious.” He added that “they broke every single best practice that Oracle themselves have defined. It is one of the worst assessments I have performed * * .” The same developer wrote to Oracle, “You are Oracle people, working on an Oracle hardware platform, with Oracle technology products, on an Oracle solution. * * Oracle should be delivering these environments and products as a solution, like they actually understood the products and owned the solution which has not been the case by a long shot.”
AND
Oracle’s responses to the Vendor Questionnaire also stated that OPA and Siebel, the foundation of the “Oracle Solution,” could be implemented by business analysts, not software developers, and without customization. Oracle explained that “government subject matter experts (not application developers)” could define rules in OPA “in the terms and vocabulary that they are familiar with and/or as defined in relevant statute, regulations and policy documents. * * * There is no scripting or programming needed.”
For what it's worth, I've seen comments within Oracle's own code that refers to their own code as being, and I quote, "a horrible kludge". And the quality of their middleware certainly backed up those comments within their code.
I will say in their developers defense, PL/SQL is such a nasty language that it does make it hard to write sane applications. Which is one of the many reason why I'd never touch Oracle again if I can help it.
That's not what open source is about: http://opensource.org/osd-annotated
Open source just means the source code is available. It doesn't mean the source code has to be distributed with a permissive, 'copyleft', licence. While it's true that when one usually talks about "open source projects" they typically refer Apache, GPL, BSD (et al) licensed code (and culturally that would be a fair description), but when one talks about the code being open source it can also refer to proprietary projects as well (as is the case with some of Microsoft's non-free open source licences).
So my comment makes perfect sense given the parent I was replying to: "I wonder if Oregon has jurisdiction to open-source this stuff. I'd love to see the atrocities.". In this instance, the less permissive open source definition would be valid since:
(1) you wouldn't be able to redistribute the code anyway (the government might force a company to release their source code, but it's even less likely they would want to alter the terms of a copyright agreement (and even less likely for US-based companies given the investment America has in intellectual properties)
(2) you can already read the source code to "see the atrocities" (which was the crux of my point rather than arguing about what classifies as "open source" - but well done for completely missing that point and every other subsequent point)
Lastly, before you turn this into an evangelical licence flamewar; I primarily write and contribute towards GPL projects, so I full endorse and support copyleft licences. In fact I'd go further than that and say that source code that's available for viewing but not for redistribution is more damaging than good; but that's a whole other topic of conversation.
It means what the definition says it means: the source code is available under a relatively liberal license that meets certain requirements:
http://en.wikipedia.org/wiki/Open-source_software
A more accurate version of what you meant might be "I wonder if Oregon has permission to make the source code available for viewing" or something like that.
But even that aside, I never said Oracle's middleware was open source per se, I said it was licensed similarly to open source (though my wording might have been clearer).
Oh and since this is now just an exercise in pedantry, I should point out that you posted a link to Open Source Software while talking about Open Source Licences. Obviously the two are related, but they're not specifically the same thing (though your confusion of the two might explain this discussion)
It's important that people understand that it's not just having the source code, but also a license that allows you to do a series of things with the code. That's a huge, and critical difference, not a minor quibble.
In any event, it'd be fun to see Oracle's crappy code.
Besides, if people want to understand what they can do with the code then they should read the software licence (that's the whole bloody point of it!) rather than just make guesses based on a common perception of a broader software term.
Perhaps some of you would like to come forward and offer your opinions rather than down voting and running like cowards? Or perhaps you're just davidw's alias ;)
At what point will people learn that this is... just not possible? We can dress it up with fancy terms (DSL, etc) but... any business system will require people to be able to think logically and critically about what they're trying to accomplish, and define it out in great detail. Computer languages are the best way we currently have to translate those details in to a computer, and likely will be for a long time to come.
I've long suspected that Oracle made and sold solutions that fit this description.
Which relied on cloning IBM's SQL implementation back in the day. Odd to see them now arguing APIs should be proprietary...
> still fills a niche no one else can really compete with.
Not really true. DB2 will do everything Oracle DB does, and more (12c is only now adding the multitenant capabilities that DB2 has had for a long time). IBM don't do as good a job of marketing it, though.
I got to Fatwire in your comment, and I laughed my ass off. Maybe I know of people who used it for a CMS, and boy does that continue to be a nightmare.
Let's say this. Someone evaluated all off the shelf CMS options for a large educational org, and somehow the org settled on the only CMS where sales engineers and businessmen have the gall to tell them "well, it is really more of a caching system than a CMS" many months into this project. My oh my did the turd get stinkier and stinker after I heard those tales.
Thanks for clarifying. It all makes sense now.
Oh yeah, and this org, after more than a million wasted, this uses Fatwire. Or whatever they call themselves now.
Browsing through the PDF, they make references to Webcenter Portal and Webcenter Content, but not Webcenter Sites.
Source: I implemented and supported the largest (in terms of assets and users) (allegedly, according to Oracle) installation of Fatwire as of a year ago. I work on a Portal/Content project now.
I've see plenty of Oracle disasters, but I think if you're going to rank horrible Oracle products, you should add Application Express to WebCenter and FatWire.
In the end, they dumped it after spending about US$ 10 million (licenses, fees, our time) and wrote a new CMS.
The main skill of enterprise sales teams sometimes seems to bein making sure no-one who can ask pointed questions is in the rooms where decisions are made.
Perhaps this may serve as a turning point for more governments to bring litigation to bear when things go wrong. In many cases, it seems, more money is thrown to the original vendor to fix their own mistakes.
I'm sure the state of Oregon screwed up, but I have little doubt Oracle was bilking them for every dollar they could get. Whether Oregon can prove this in court will be interesting to see, I assume Oracle will settle at some point, since they wouldn't want everyone to wake up and smell the $$$.
Don't know if this is a general term or what, but I always found it both slightly amusing and slightly terrifying.
It's almost like a human powered Markov Powerpoint slide Chain...you'll never see so many content-free slides generated so fast.
The best part is that every question about why a group of barely shaving 20 somethings with zero corporate management experience are charging out hundreds to thousands of dollars per hour to "advise" senior C-level staff on how to run their billion dollar companies is answered with "well these are Ivy Leaguers, we only hire the best!"
Meanwhile every 6-12 mo program turns into a scheduled 24 month program that inevitably misses every deadline ever set for it and runs millions of dollars over before producing a barely functional solution that gets scrapped and rebuilt a year later.
(B) Software developers should consider some pro-active steps to try to forestall "they lied!" accusations, such as: * providing a written risk-factors disclosure; * including a no-reliance clause in the contract; and * clearly labeling demos, mock-ups, and wire frames as such. These are discussed in the "related posts" linked at [1].
(C) Another example of "they lied" carrying the day: BSkyB Ltd. [Sky Broadcasting] v. HP Enterprise Services UK Ltd. [2], where the court found that EDS (later acquired by HP) misrepresented its ability to do a complex project; that resulted in the contract's limitation-of-liability clause being thrown out, which cost EDS hundreds of millions of dollars extra.
(D) For good measure, here's another example of a state suing over a software project gone bad: Indiana v. IBM [3], where IBM had a contract to overhaul the State of Indiana's system for administering welfare benefits. It didn't go well. IBM basically won in court.
NOTES:
[1] Self-cite: http://www.oncontracts.com/why-the-fraud-claim-is-the-lawyer...
[2] http://www.bailii.org/ew/cases/EWHC/TCC/2010/86.html, discussed at http://www.oncontracts.com/eds-british-sky-overpromising/ (self-cite).
[3] http://www.scribd.com/doc/100544020/Indiana-IBM-Decision
I am left with the impression that no one in a position of authority in Oregon has ever participated in software development, ever.
Having read both complaints, I'm on Oracles side more than the Oregons.
On so many big IT projects I would see the client constantly change requirements, be very vague, change stakeholders who then completely move the goal posts and effectively hold the project back for large periods of time.
It's not surprise that large projects fail when you see the state of most large clients.
This highlights a much larger problem. Our processes for delivering large IT projects need a radical change in order to stop toxic stakeholders tanking whole projects.
However, Some of Oracle's products are shit and do fuck all out of the box despite what the sales people say.
Or do you want to lead your local bakery in how your breads are made? The baker has to know, when and how to include the client, because he/she is the specialist.
I've worked with those kind of badly managed clients before. They likely ignored Oracle's advice, came up with nonsense strategies and requirements then kept being vague about the details.
Go and keep turning you bakers over off or requesting crazy ingredients that should never go into mixture (against the bakers advice) and see what kind of bread you get.
http://media.oregonlive.com/business_impact/other/oracle2.pd...
Kitzhaber should have appointed one person to be the RP for the overall project, and that person should have had a free hand to define the vendor relationship and delivery metrics.
As a citizen of Oregon, I'm embarrassed; I'm also pretty sure that the essential functionality of the project could have been delivered at a tenth of the cost of this shitshow.
I am sure Oracle (like every large consultant / supplier) over sold their capabilities and stuffed the project with over paid under experienced staff and fed back sweet smelling bullshit to the upper levels. But FFS if the administrators of a whole fucking State do not know this by now, they are the ones to go.
Yes, USGDS is calling the right moves, yes open sourcing reference systems would be a good idea for federal projects but in the end, if you cannot run a software project today, you are going to fuck up everything by 2025. Hospitals, buildings, water pumps, really everything.
Learning these lessons now is a good idea. Thinking "I can still hire Oracle and if they are bad we can take them to court in five years" is not the right lesson to learn.
Edit: http://www.lawteacher.net/contract-law/essays/the-case-of-wa...
The above is a UK case where a supplier provided defective software, then was sued and claimed defence behind limitation clauses - it went to the high court which said yeah, you were both big boys, they aren't liable.
The principle I think extends here.
Also - that PDF is incredible - things like "they lied about how flexible and suitable it was for us". Aaaaargh! Can you really sue for "we did not do our homework?!"
For starters, Oregon has less than half the population of Silicon Valley - there just isn't enough talent to draw from to get the in-house expertise the state needs.
On top of that, nobody wants to go work for the Government, and there is a dearth of talent at the state level when it comes to building huge software projects. Perhaps offering high salaries is a start, but the pace of the projects relative to other companies will always be a detractor. Combine that with the scrutiny of the public and constant need to practically over-document things, and you've got a culture that isn't attractive to talented software developers or analysts.
So what you seem to be saying, in essence, is that the minimum requirement for government (or perhaps customers in general) is to be perfect, but the acceptable practise for vendors is to be psycopathically dishonest?
Oregon clearly are not great at software. So they should either become great at it or buy commodity (ie OSS).
The fact there is no OSS solution for them is a problem but Oregon, Wisconsin and so on could club together to dove the problem or let USGDS do it.
I ask because many software companies include clauses in their software agreements that state they are not liable for software defects or damages.
Those kind of clauses seems to nullify any case I could foresee someone making against Oracle (regardless if you like Oracle or not).
Edit: fixed typo
This summarizing statement says it quite succinctly:
"In effect, Oracle used its purported superior expertise, coupled with lies and pressing deadlines, to trap the State and Cover Oregon in a deadly spiral: at each juncture Oracle charged more and Oregon got less."
Not to sound insensitive to Oregon, but simply speaking as someone who deals with contracts from major software vendors regularly, I still don't see what legal standing Oregon will have against Oracle.
I saw this because major system integrator's structure their contracts in one of two ways:
(1) Staff Augmentation. This construct clearly states the implementer (e.g. Oracle) is there simply to provide an expert service and no deliverable's are being defined and no responsibility is on the implementer to "complete" any work. You're essentially just paying an hourly rate for an consultant and that consultant is under your direction (as such, 0 liability in on the implementer).
(2) Fixed Fee Deployments. This construct clearly articulates deliverable's and earn-out. Once the implementer successful completes a predefined milestone, the implementer will earn-out a predefined amount. In this construct, the only liability the implementer burdens is the labor to achieve the milestone and typically they can disengage at anytime.
In both contract types, it clearly states the implementer is not responsible for damages, missed deadlines, etc.
So again, I'm curious to know how Oregon is going to win this case.
Disclaimer: IANAL
I'd like to think that, for projects over a certain size, independent systems integrators who are wholly unaffiliated with the winning vendor would be required for project oversight.
This isn't just an Oracle problem - they're obviously over the top in this example, but this seems to be a problem with other vendors as well. I witnessed an example of this in state govt in NC over the last 2 years - loads of promises, under delivered, and as an IT consultant, it was pretty obvious what they were promising was not possible on the time schedule provided. Having tech-knowledgeable external resources to review and look for clarification on muddied points I'd think would be a good thing for the taxpayer and end-users, but they seem to rarely be the focus of these sorts of projects.
Plenty of open source talent in Oregon. I imagine there'd be many volunteers for a big DB/web project. It should be possible to do, after all, would Cover Oregon be more complex than Firefox or the Linux kernel?
In theory, not be all that difficult to hire a good project management team, set up the framework and let contributors work on it. Probably get done much quicker and of course, at way less cost.
Of course, doing that is taking a risk which is routinely avoided by timid bureaucrats and enterprises. Though the lesson of Oregon's experience is there to be learned--it shows the far bigger risks of doing things the same old way.
Hire bigco, publish what they give you so the neighbours can also use it and you're not stuck with bigco for support. ie you can also fire bigco if they suck once you hired them.
Maybe my interpretation of your idea wouldn't work exactly as you has in mind, but I see your point, that maintaining greater control of the development process would likely lead to a more coherent and predictable product that functions in accordance with carefully designed specs.
Among flies in the ointment is the necessity for such a highly principled and skilled steering group to manage the effort with the requisite wisdom around scheduling releases and titrating the level of community involvement. The level of talent it implies is likely in short supply.
That said, an admiral proposal, distinctly possible, even revolutionary. To quote Spinoza, "all things excellent are as difficult as they are rare".
1. "The government is inefficient and doesn't have much experience with big IT projects." We should outsource things to the private sector, like we do the design of bridges and fighter jets.
2. Consultants want to maximise their profit by maximising billable hours. Obviously they don't recommend sharing things between states. Far more profitable to design a shitty 'enterprise grade' mess that will take ages to build, that nobody will compete to maintain, and that will need lots of (billable) maintenance.
3. The project fails, wasting loads of money.
4. People see all this wasted money. They conclude the government is inefficient.
5. People who know how to deliver working software see shitty designs, shitty incentives, and expensive cancellations. They conclude working on government IT projects would be bad for their sanity and their resume.
6. "The government is inefficient and doesn't have much experience with big IT projects."
the very "best" (scalable/widely applicable) solutions are supposed to bubble up. that's the idea behind american federalism!
I did not read the whole document, but I believe the first few pages are… unforgiving to say the least. I could already hear the heads rolling.
No public bidding process? Check. Favouring a vendor? Check.
In my eyes this lawsuit is a cover-up for a deal gone sour.
Jail whoever assigned this contract and this sort of failures will never happen again.
PS: If someone knows how to print 3 asterisks in a row in markdown please tell me.
\*\*\*Look up DIMHRS for merely one example. http://en.wikipedia.org/wiki/Defense_Integrated_Military_Hum...
One of my favorite quotes in the "Issues" section is the trouble the Army was having trying to adapt their personnel policies into standard PeopleSoft actions, with a contractor developer eventually claiming to the Army "you guys (Army SMEs) just don't know how to properly manage people...".
Perhaps, but somehow I doubt that the same exact methods suitable for personnel management for civilians is always applicable to the Army.
That was by far not the only problem; the Navy actually uses PeopleSoft for its military personnel management nowadays (presumably they found developers more willing to modify PeopleSoft).
This is a great way of making sure only EDS (sorry, HP), IBM, and the other usual suspects are the only ones who can do work. Not the best use of my tax dollars.