> I'm talking about the State having the right to kick a > supplier out and > swich to some other supplier, without having to burn a half-finished > project to the ground in the process. Similarly, I'm talking > about the > State being able to decide that provider X built a good product, but > provides crappy support, so they would like to hire (say) > Anitian :) to > support it. They can already do these things. The state could, for example, buy a ton of Netscreen firewalls (as an example). After a while they could decide that Netscreen is a pain in the arse to deal with. So they could call me up and I could come out and help them make their netscreens work better. Why do I or the customer need source code to do this? We can support the products as is and all is peachy. > >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. :-) > > > Sure, I didn't say that customers don't want the service you > offer. I'm > just saying that you could offer higher levels of service (at higher > prices :) if you had access to the source. If customers don't want something, then there is no way to make money off it. As such, there is no incentive for people to invest in that effort. > Here we seem to agree. But my point is that if VARs have source, then > they can offer greater capability. I would agree that they MIGHT be able to offer more capability. Assuming a VAR had a highly trained and organized software engineering staff, they could, theoretically, offer custom tweaked versions of products. However, the investment required to create and maintain a software engineering team, along with a consulting team, auditing team, executive team, etc. is prohibitively to expensive for most VARs. Most VARs are local or regional firms with profit margins of 5 to 10%. That means a firm that sold 10M in product, would only have 500K to 1M to cover all their overhead. Executives, consultants, sales people, marketing, etc. And 10M a year would be very good. Most VARs make much less than that because the market is so fragmented. > In an industry where source code availability is rare, it does not > surprise me that ability to make use of source code is also rare. Are you arguing against me or with me now? You're correct. Just as most people have no idea how the engine in their car works. > >Source code would open the door to excessive "tinkering" > which is exactly > >what kills large IT shops. > > > That is highly context dependent. I suspect that you are > right, for the > kind of commodity products that Anitian supports. However, when the > application is fully custom, developed from the ground up for the > Oregong Department of FooBar, then it is not "tinkering" to implement > necessary changes when the system does not meet the State's > needs. With > proprietary systems, the State is at the mercy of the initial > vendor to > get it fixed. With Open Source licensing of such systems, the > State can > entertain competitive bids to implement an enhancement or a fix. But commodity products have one huge advantage over custom built stuff: they're everywhere. Training is widely available, and knowledge is easier to come by. Furthermore, the state does not need to entertain competitive bids to get a fix. If they buy an off the shelf product, they just call the manufacturer and ask them to fix it. And when they work with a VAR a *good* VAR can help them communicate with key people at the manufacturer to get the fix implemented ASAP. And this is all free as it usually comes with a support package the manufacturer offers. Generally, software manufacturers are reasonably responsive to errors in their code. Clearly this is something that should be evaluated when looking at a solution. Does the company have the resources and reputation of maintaining their technologies. This is, for example, why I tend to steer folks away from products that belong to companies with financial troubles. For example, a lot of people are more than a little nervous about Enterasys because of all the corporate problems them had a while back. That could affect their ability to support and upgrade their products. > Sorry, terminology problem. By "binary patch", I meant "reverse > engineering some binary code to figure out how to patch it, > because the vendor won't" But the manufacturer will. How else would they patch it? ------------------------------------ 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 : Wed Sep 25 2002 - 00:58:00 PDT