This detailed paper is a great reference to the advantages of open source over proprietary software. It eloquently and elegantly rebuts much of the FUD out there (such as "OSS is anti-capitalism").
On a related subject, a discussion of open-source vs. in house development has come up at a No Fluff Just Stuff discussion. The gist of it was, that with open source software, you don't have the same level of knowledge of the inner workings of a framework that you would have if you developed it in house. This makes in house frameworks more enticing than equivalent open source projects.
Erik Hatcher had a great response to that. Pretend that the open source project was developed in house. Have one team developer work with the "in house team" that developed the "internal project" to learn how to use it ... exactly the same way as you would if the project really was developed in house. The difference is that you'll use more email and less phone or cube visits.
You'll still do the same things ... build some prototypes and experiments, hit some brick walls, work your way through them. At the end of the day, the team will have expended the same effort to get up to speed on the "in house" project. The advantage is that there will be more expertise in the greater world on the open source project, and it will (generally) have more functionality, and be better tested.
In other words, have someone on the team "own" the open source project. In the unlikely event that the open source project is abandoned by its original developers, you still have the complete source code and necessary expertise to continue maintaining and extending the project.
In effect, open source gives you all the benefits of an in house development (such as availability of source code, and direct access to the developers) without the actual costs of developing the software in house.
A final note; more than one architect I've talked to has stated (more or less) "any project that begins by designing the perfect framework for the project, fails." That's because, at the outset of a big project, you don't know the domain well enough to design a framework for that domain. At the end of the project, you do.
With open source software, you can bypass that; you gain the expertise of others who have already blazed a trail into your domain. Or, at the very least, you get to build your project out of larger building blocks. Either way, you're likely to get to that first iteration, where you actually know something about your application domain, that much faster.
1 comment:
We wrote numerous custom frameworks for my current project, none of which is perfect. We have many ideas for improvement, but these changes are next to impossible without breaking our apps. My coworkers and I have often discussed this idea that you mention:
"That's because, at the outset of a big project, you don't know the domain well enough to design a framework for that domain. At the end of the project, you do."
We fantasize about starting over, doing everything "just right". But we pretty much came to the conclusion that starting with a clean slate is every good programmer's dream, and that each time you start over you end up making new mistakes along the way. Were we to develop "custom frameworks version 2", we speculate that we'd innovate and add in new features as we went. By the time we finished, we'd be in exactly the same boat we are in now.
Post a Comment