Since the advent of freely available source for kernels, compilers, windowing systems, and application frameworks, I've found it difficult to justify, for myself, the use of anything else. Not for ideological or pragmatic reasons publicized by others, but for scientific reasons: the ability to independently reproduce and verify results; the ability to pursue investigation and experimentation where-ever it might lead.
I definitely agree that OpenSource
is an important part of ComponentDesignPatterns
. Outside of the language, though, I've been primarily thinking about open source and its benefits and consequences in a global investment bank (naturally, I work at one) production environment.
We have a build based on Windows NT 4.0 for desktops and a global permissioning scheme that allows us to control who's permitted to access what applications. We use roaming profiles and base all settings and permissions on the user, allowing for a free-seated environment for users. This means I can log out in New York, fly to London, log in using the same user ID, and continue work where I left off.
Today, well over 500 third-party and in-house applications run in this environment. In addition, if a change to the environment causes part of the floor to crash, many millions of dollars can be lost, and heads roll. Therefore, you can imagine how complicated both deployment and testing/piloting can be.
My thinking is along the lines of this: what benefits and consequences would the deployment of a large amount of open source components and applications have on this environment?
One benefit of source-based development is the ability to rebuild binaries from scratch at anytime, letting the compiler highlight potential incompatibilities due to evolution. It certainly doesn't eliminate the need for adequate testing before rollout, but it can eliminate a certain class of run-time errors depending on the language and compiler.
One possible drawback is lack of support for the components and frameworks you rely on. But then, that is a possible drawback of binary-only approaches as well. The advantage to having the source is always having the freedom to attempt solving problems yourself.
...also, an interesting side-effect of OpenSource
is it makes it easier for organizations who don't want to publish or share their source code to use third-party frameworks and components. When the inevitable problems crop up, there is no need to transmit your entire setup to the component/framework developer to prove to them there really is a problem, and no need to search for a simpler example which evidences the same problem. Just solve it yourself, and share the fix if you want.
I rarely find the need to modify kernels or compilers, but often find the need, while debugging, to experiment with different versions of the same utility on one machine, or the same version of one utility on multiple machines. OpenSource
facilitates that. I only look at the source while using or extending object-oriented frameworks. -- ScottJohnston
I think the advantages for doing OpenSource
in-house (where 'house' is a large company) are that:
- you can fix the bugs locally and get on with things while waiting for the component owner to ship the real fix.
- being able to propose fixes may increase the probability and speed with which they get released
- OpenSource should increase the EmbarrassmentFactor? of shipping bad code
That said, there has to be a repository of Authorized Versions somewhere that somebody owns, and no code goes out until it's been accepted into that repository. If the components are any good, most people shouldn't have to touch them (few people hack linux kernels), but there are times when you really
need to know what's going on inside. -- SteveFreeman
As long as there is a free market for authorized versions. The right to fork a source distribution is fundamental to OpenSource
. -- ScottJohnston
Working with TurboGeometryLibrary?
a few years ago...
(not OpenSource, but we had paid the extra money to get the source)
I found a few bugs severe enough to bring development to a halt.
So, using the source and debugger, I tracked them down and fixed them - and told the vendor >exactly<
what the problem was and how to fix it.
Thus, I did not have to go through a painful, long, and expensive "support" process just to have someone tell me they'd fix it "when they get around to it."
And it was good for the vendor too.
Would that all software were this way.