It’s always fascinating to watch legacy/proprietary software vendor’s bloviate about the value of closed software. With the advent of Commercial
Open Source vendors such as Red Hat, one would have thought this argument would have been put to bed. Let’s explore three areas in which Legacy/Proprietary loses to Commercial Open Source.
Most proprietary software vendors handcuff their development organizations in the hope of building a consistent product. Product management tightly controls the requirements and strategic direction while technology choices are limited to tried-and-true options. Development projects are chopped into various pieces often time limiting a true big-picture view of the problems and solutions. Timelines are longer and deadlines are extended, as delays are a way of life.
Open software vendors strive to take advantage of the ideas and collective knowledge of the entire community. While Product Management is integral in the development process, developers are free to experiment with new and innovative technologies. Agile development combined with an open source community allows for ideas to be tested in real world environments while providing valuable feedback. Social Coding such as GitHub breaks down the traditional barriers of collaboration and makes it easier to write better code. Traditional timelines are a thing of the past as modular releases allow for incremental improvements while major infrastructure improvements are more tightly controlled.
Most proprietary software vendors call themselves open and flexible pointing to pre-defined APIs available within their product. Often times, there are well known APIs and internal APIs that may be used but the latter is reserved for professional services teams or internal development. Customers have little options to extend the product other than to pay for these custom services or wait patiently for a request for enhancement to make it into the product.
Open software vendors provide not only open APIs but also the ability to extend the core code itself. Published APIs may be adapted and extended by the community, customers, professional services organizations, or core developers to change the behavior of the software itself. In turn, this gives customers the choice to apply their own development expertise or outsource it to the software vendor. Of course the vendor takes feature requests, but customers have options on how to address issues with a deeper level of understanding of the product itself. Finally, the customers have the option of contributing their extensions to the community paving the way for more enhancements and additional value.
Proprietary software vendors live and die by how “sticky” they can remain within your company or organization. Maintenance and professional services revenue is the blood of the engine. Often times the apex of your relationship is when you sign on the master services license agreement; after that it’s all down hill. Any and all technology decisions are made to insure that you remain a customer.
Open software vendors live and die by how much value you obtain from the product or solution. While maintenance and professional services revenue may be present, the costs are simply less than their proprietary brothers. Since the products are open, the technology decisions are driven by the integration or extension of the product. In other words, the NIH (not invented here) syndrome has been cured.
The Open revolution is about developers regaining the control to build and innovate without legacy/proprietary constraints. Where do your thoughts lie on this subject?