Erik Funkenbusch wrote:
> On Tue, 22 Aug 2006 17:47:16 +0100, Roy Schestowitz wrote:
>
> > Shouldn't this be reason enough to opt for an Open Source development model?
> >
> > ,----[ Quote
> >| In a traditional software development model, the client asks for one
> >| thing and is delivered something else not to say anything about the
> >| galloping costs involved as is rightly illustrated by the cartoon below.
> > `----
> >
> > http://linuxhelp.blogspot.com/2006/08/shouldnt-this-be-reason-enough-to-opt.html
> >
> > Cartoon:
> >
> > http://photos1.blogger.com/blogger/8010/3608/1600/software_development.jpg
This is really funny, I've seen some of those slides, they go back
almost 25 years, back when I was a Unix programmer writing directory
assistance systems in C.
> This is bull. This is, pure and simple, a project management issue, not an
> open source or closed source issue. Good project management will give a
> client what they want, regardless of methodology used.
This is the classic example, the whole "build vs buy" scenario.
In a closed source solution, the components are very large and
granular, and are generally provided "as is" and then integrated with
the other systems using system integration techniques. If you don't
like the way an application talks to you, or you want to add a field to
the commercial application, or you just want to use the same customer
IDs on SIEBEL that you use in SAP, you're out of luck. You let the
integration system manage that for you, using a lookup table to convert
a "universal" ID to the appropriate application customer ID.
In the Open Source solution, you start with a well designed
application, some good solid general purpose components, and some
custom applications written using those tested components. If you have
the source code, you can add that extra field, synhronize with that
other application's customer ID, and you can even alter the user
interface or switch from a web based interface to a Python based
interface, or a Java interface.
Many companies use "shared source" solutions. These are applications
where the customer and the consultant create custom code, calling OSS
libraries and functions, using OSS components, and then the customer
keeps the code and can hire a different consultant or different group
in the company to support it.
Ironically, Microsoft has a very good shared source approach. You can
create UML documents, which generate class diagrams, which generate
source code in Visual Basic, C#, or even C++, which calls standard
Microsoft .NET components.
It's actually a pretty effective solution for certain types of
applications. DFS could probably give you volumes on the subject.
There are OSS implementations of this technology, and Rational has some
nice toolkits for doing this.
The advantage of OSS components, is that I know EXACTLY what I'm doing
and what the code is doing, because I have the source code for the
libraries. This makes it real easy to see if someone has tried to put
a "back door" in the code. With .NET, even the developer might know
where the back-doors are located, or how to close them.
|
|
