Written by Frank Tucker
I absolutely love the concept of Open Source products, especially harnessing the power of the community to deliver unprecedented value. I particularly like the fact that when there is shortfall in the “out of the box” Open Source product; I can build or configure the very capability I want even though others may not view it as a priority. Open Source products are free for redistribution and access, which as a start-up company, we would not have been able to afford the commercial option. With that said, I’m still challenged from a business model perspective by these products.
I see the success of Open Source products like the Android and conversely, their number one proprietary competitor, iOS, is successful with an opposing philosophy. I have an Android tablet that works fairly well; however, my iPad is near flawless in its operation. Although I love the diversity of Android, it frustrates me when things just don’t work; applications install on one model and not the other, or the system crashes. That is the crux of some of the challenges I find in Open Source. With diversity, there is no unified approach to solving some of the challenges and the solutions are not necessarily user centric. For example, the many forks and dependencies are partly resolved with a variety of package management solutions; however, it rarely works “out of the box.” I spend an enormous amount of time getting Open Source systems up and running by either compiling, configuring a text file, issuing command line commands, or finding dependencies, etc. Although these products are “free”, the true cost is the time I spend getting these Open Source products operational.
Today, approximately 70% of our company’s infrastructure runs on Open Source, so I don’t discount its value. However, that was a business decision to fully understanding leading Open Source products as alternatives for customers who are looking to broaden their enterprise support base. As part of this journey, we discovered that many of these products were Open Standards based open architecture. We enjoy the extensibility with the rich assortment of plug-ins that allow us to customize the solution to our needs. When there are missing components, we are able to fill in the gaps with development, then contribute those back to the community, benefiting all. We also find that Open Source technologies tend to reuse similar components or methods. As a result, one could make the transition from a product like Apache HTTP to Nginx or Lighttpd, with a far lower learning curve. Many of us are so familiar with how Open Source products are built, defined and how products are implemented that, often with little research, we are able to quickly adapt to changing needs.
I find that is not the case with proprietary products. It takes an enormous amount of retraining to make a switch from Microsoft suite to IBM Lotus suite, for example or products of similar function. Therefore, a benefit for those of us that are going through the pains of setting up and configuring an Open Source product, we can easily transition to other Open Source products with similar functions such as Mule to Apache Service Mix without extensive retraining efforts. The result is a talent pool that fundamentally understands the technical approach of Open Source products, which allows us to easily move not only within a family of products, but also outside that family faster, with comparable quality deliverables. We also found that if a capability doesn’t exist in proprietary products, it is much harder to extend, forcing us to have to wait until the vendor builds that component in their roadmap, which could be years away. That results in “work around,” scattering users across multiple systems to accomplish a task within their workflow.
Today, we are capable of harnessing the power of Open Source with agility matched with unparalleled ability. We have donated source code to the community for customization that we performed on our Open Source collaboration portal. (You can see an example of this here:http://www.contentreich.de/alfresco-extended-datalists-migrated-to-4-0.) In addition, we will continue to contribute in the spirit of collaborative development. However, we also see the value of bringing in more of the licensed model from organizations that support the Open Source products that we use. We will balance this with proprietary products we simply want to use and not administer. One example of this was our recent move from LDAP to Microsoft Active Directory, which works well, has a number of powerful features and quite frankly is far easier to manage than your typical Open Source LDAP servers. Once again, this was a business decision that we would rather support Microsoft Active Directory than LDAP for customers to lower total cost of ownership.
So what did I learn on our Open Source journey? Yes, Open Source has value, but really no different from a licensed commercial product. For us, Open Source is just another tool in the toolbox, along with other commercial and proprietary products. It’s about balancing the approach based on business goals and outcomes. We believe in selecting best “athlete” based on requirements not on solutions or “in fashion” technology trends. By doing so, it builds a more sustainable model with higher customer satisfaction at lower total cost. Sometimes that best “athlete” is Open Source, other times its proprietary, but frequently a mix works best. The bottom line for any company is that the decision should always be objective and outcomes based, not on personal preferences or media hype.