> It's about giving the State choice in who to outsource > support to. No, I > don't expect the State IT staffers to actually do very much with the > source other than turn it around to whoever won the support contract > this year. And who would that be? Now you're talking about the state having to engage not only suppliers, but also support organizations. And most support groups don't have the programming prowess to take on the complexity of re-engineering source code. > * Sun releases the source code for Solaris under the Community > Source license. Not an open source license, but you can > get the code. > * Microsoft has offered their source code to significant > customers, > under whatever-they're-calling-it licensing terms. In both cases, the source code being released is either a version back or it a fragment of the total. > And the quality of the support you can provide suffers as a result of > not having the code. The support you can offer for closed-source > products amounts to a really good user's manual: you know how to > configure & use the software really well, and thus can help with > configuration & usage problems. This is a very valuable > service, hence the thriving industry. That's what customer's want. They want and need people who are "a really good user's manual." This is particularly relevant when you consider that most user manuals are utter crap. I know - I wrote some of them. :-) Organization aren't looking for source code, they're looking for capability. Its the manufacturer's problem to make sure the products work correctly. And where the manufacturer can't do it VARs and consultants fill in the gaps. > However, because of the lack of source code, Anitian cannot > actually fix > bugs. Bugs have to be reported to the vendor, who may or may > not see it > as enough of a priority to do anything about it. If Anitian > had source > code, then bugs could be fixed as needed. I have source code to some of ISS products. Its fascinating. But by the time my engineers could debug and analyze a bug, ISS's own engineers have done the same thing and released a patch. So as a VAR we stick to extending and customizing the existing product into a customer's shop. The source code is rarely relevant to us. Moreover, very few (if any) VARs have the software engineering capabilities to modify, test, and deploy customized version of software. And in some cases customers don't even WANT that. They WANT the "blessed" version from the manufacturer. > >So, we already have this infrastructure you seek and companies can > >retain their intellectual assets. Why would we un-do this situation? > >What motivation is there to hand over source code when nobody really > >wants it or even needs it. > > > Because: > > 1. Some people really do want and need the source, and have been > saying so quite loudly. Some of them say so by choosing open > source products :) > 2. The State doesn't know what it wants; they're too busy fighting > allegators to drain the swamp. Kenji came to us to get input on > what the State *should* want, and in the opinion of at > least half > of the people who have responded so far, the State > should want the > source. I think the State should want practicality, simplicity, and sustainability combined with security. It needs partners that can build an infrastructure that is reliable, modular, and free of extensive customization. This will ensure that it can be easily supported and managed by staff. It also ensures that when new staff and new partners come on board, they can learn the systems quickly and begin improving them. Security needs to be integrated and relatively seamless. Users need training to respect security issues. Source code would open the door to excessive "tinkering" which is exactly what kills large IT shops. When people start tinkering with things, they break. And when stuff breaks, it means somebody has to fix it - and that's time and money. It also means people have to bracktrack and reverse engineer tinkering. I cannot tell you how many companies I have seen brought to their knees by the incessant tinkering of a few uber-nerds who refuse to follow procedures or policies, because they need to fiddle with everything. Maybe a good analogy is due: The state needs a good car. A reliable car that can drive them to where they need to go. The state could go to Beaverton Honda and work with a friendly sales rep who orders them a nice Accord. The friendly folks at Beaverton Honda helps the State install a bitchin' stereo so they can drive happy. When the Honda breaks down, they make an appointment at Beaverton Honda to get it fixed by trained mechanics. If there is a serious flaw in the car, Beaverton Honda sends it back to the manufacturer and orders the state a new Accord. Or the state could call Honda Motor Company who sends them a huge box of parts with a manual "Building your New Accord." They could build the Accord from scratch or hire Joe the Mechanic to build it for them. When it breaks they could disassemble the entire car and reassemble it from the ground up. Oh sure, they would have access to every last bolt in the car. But would anybody have the time or energy to learn how to disassemble an entire Accord and then put it all back together so it runs flawlessly. There is a reason we don't have Open-Source Vehicles. Or more specifically, there is a reason "Open-Source Vehicles" like the Caterhams and Dune Buggies are limited to a hobbyist market. Tinkering is cool for a hobbyist. Tinkering is deadly for the mass market. > Because screwing around with binary patches is an expensive > waste of time :) Okay, so let me see if I understand this: Installing a point and click binary patch wastes more time than cracking open the source code, learning how the product was coded, coding a change, recompiling, testing, and implementing. Riiiiiight. ------------------------------------ Andrew Plato, CISSP President / Principal Consultant Anitian Corporation (503) 644-5656 office (503) 201-0821 cell http://www.anitian.com ------------------------------------
This archive was generated by hypermail 2b30 : Tue Sep 24 2002 - 16:36:51 PDT