Several weeks ago at OSBC I posed a serious of “hard questions” about open source software. They weren’t meant to demean it, of course, but were really to say that software for the enterprise needs to be held to very high standards, whether it open source or traditional.
One of the sections was this:
Who will maintain your installation of the software?
- If you are planning for your IT staff to install and maintain your software, make sure it doesn’t get orphaned when you have personnel turnover.
- When software updates come along, you will need a plan to decide which ones to install and when, especially if major releases come along every six months or so.
- If you customize open source code for your organization, are you prepared to propagate those changes into newer versions of the code?
Today I saw the story “You may want to avoid hacking your open-source CMS” which discussed The Onion’s experience hacking an old version of Drupal. To give you an idea, version 7 of Drupal is about to come out and the latest official version is 6.16. The Onion highly customized version 4.7. That alone should make you nervous since clearly the software has moved far beyond the point where it was forked.
The original article referenced discussed how The Onion moved from Drupal, a PHP application platform, to Django, a Python framework.
The problems with highly hacking code is that it is very hard to maintain it for functional and security fixes, you don’t easily get improvements to the code base, and you may be doing similar work to what is happening in the community, and maybe not as well.
This reminds me of a blog entry I did in December called “Open source software: modify, extend, or leave it alone?”. There I concluded:
There can be innovation in the core application, but that same application can become a platform for innovation if it has a good extension mechanism. Choose good applications that can be improved or configured outside the core software, and you’ll save a lot of trouble and gain some real advantages. This is true for open or closed source software.
Postscript: As Jonathan Bennett pointed out to me on Twitter, I failed to mention a very important aspect when you do make changes to open source code: offer your modifications back to the community and your code may make it into the main trunk of the project. That is, since you are doing some coding, become a contributor as well. This may not always be possible, but consider it.