When Corporates Embrace Open Source
Listen to this article
It is common for organisations to justify the use of popular Open Source Frameworks on the basis that developers with these skills are easy to come by. In addition, because the source code is readily accessible, it's easy to make bug fixes and patches whenever needed. This is clearly justification enough that no analysis need be performed in order to ascertain if said framework actually fits the technical requirements of the application.
The next step always seems to be to download the source code and check it into a local repository. Then, have a core group of developers maintain it internally. This team will be responsible for checking out the source code, building it and distributing it to all the other teams ensuring that changes are controlled and all teams keep up to date with the correct version.
After using the framework for a few months, it becomes obvious that the way the code was originally written is either: broken; wrong; or doesn't quite fit with The Way We Do Projects Here ™. This then requires massive changes to "simplify" the design and add enhancements wherever "necessary" - Like masking all those pesky exceptions that get thrown and instead returning null.
Of course now that so many changes have been made, and coupled with the requirement that all projects be uniform in quality, it becomes necessary to ensure that project teams cannot and will not use the version(s) available from the original project site but instead are forced to use the highly tailored internal version. In fact it's probably a good idea to make the framework a "black box". I mean, why would the non-core developers need or want access to the source code. The core team are providing a service after all and that is all that's important, so access to the internal repository must be on an as-needs basis.
And finally, after 12 months of development and hard-work, it is customary to allow the The Architect who made ALL the proprietary changes (to the supposedly open framework) to go on 4 weeks holiday, just prior to delivery to System Test, leaving the project team to fend for themselves so that when a bug is found, the only solution is to fork the code (again) and check it in to the project repository on the proviso that the changes make their way back into the core ASAP.
Comments
No.. say it isn't so !
Actually, that sounds more ambitious then most corporate environments that I have come across.
Which is probably a Good Thing.
Although the current abundance of frameworks (especially lightweight ones) can make things confusing... I would expect there to be some consolidation in the medium term, which means there will perhaps be less choices to make, and maybe lower risk... so people will take the frameworks as is, and take frequent updates ! (yay).
As long as there is some choice...
Posted by: Mic | October 26, 2004 10:20 PM
Speaking as The Architect... we don't allow modification of open source projects 'cept for bug fixes... and they have to be contributed back.
Posted by: Robert Watkins | October 27, 2004 07:37 AM
You are, however, a responsible and seasoned OS developer ;-) That's rare for someone in your position.
Posted by: Simon Harris | October 27, 2004 07:42 AM
Such a good global citizen ;)
Maybe a side effect of the "contribute back" policy is that there would be a natural tendency to do it the Proper Way rather then a point solution for you problem. As people know that it will be going through a more intense review then would otherwise happen internally.
Posted by: Mic | October 28, 2004 09:29 PM