Although the hype of open source has been eclipsed by the cloud, mobile and big data, you could argue that open source remains the biggest productivity driver for IT. If you ask most people what technologies they think about when it comes to open source, they'll probably mention Linux, or the Apache HTTP Server. Or if they are thinking data, they'll mention MySQL, or big data technologies like Hadoop. There are entire stacks of open source infrastructure technologies like LAMP and vendors like RedHat, Cloudera, and Zend have stepped into help organizations manage open source infrastructure.
But what about the components that developers use to build applications? Many organizations that we talk to assemble their applications from open source components. They no longer write a lot of custom code, they stitch together components from various sources - in many cases 80-90% of modern applications are made up of components. This may seem surprising until you think of the various types of components that are used to develop applications: utility classes, logging, caching, database access, testing frameworks, web frameworks, collection handling, etc. Why develop those feature from scratch when you can reuse components freely available on the Web?
So why compare Linux, Apache HTTP Server, and MySQL with open source components like junit, commons-collections, log4j? I think it helps illustrate the need for a dramatically different management approach.
When it comes to major decisions like operating systems, web/application servers & databases, many organizations...
- Architecture Review - conduct a comprehensive technology selection process driven by the architecture team… .vs. OSS components that are often selected by individual developers.
- Vendor Selection - go through a deliberate vendor selection process, including RFI/RFP, POCs, etc… vs. OSS components where the project team is not vetted.
- License Indemnification - protected from potential license issues via vendor indemnification... vs. OSS components with transitive dependencies on components with problematic licenses.
- Contractual Procurement - officially contract and procure software through purchasing departments… vs. OSS components that are "free".
- Production Monitoring - monitor as part of an overall enterprise level BAM strategy… vs. OSS components that are often hidden in plain site (organizations don't even know what they have).
- Financial Budget - built into the regular IT budgeting cycle… vs. OSS components - again, aren't they "free".
- Updates/Patches - update periodically via a pre-planned patch / update process… vs. OSS components where regular updates are not even considered.
Although organizations probably don't think risk management per se when making major open source infrastructure decisions, that really drives their decision process - minimize risk by selecting infrastructure software that is reliable, easily maintained and cost effective.
Shouldn't you be doing the same at the application level? With components making up the bulk of your applications, it makes sense to manage the components in a systematic fashion. But you can't use the same process for OSS components as you do for operating systems, databases, etc.
How to start? We call it Component Lifecycle Management. Stay tuned as we introduce this concept over the coming weeks and months.
