In the past, many technologists had to evangelize open source within the enterprise. We had to justify its use, reassure executives about security, ability to support, etc. Recently, I believe those tables have turned. More and more, businesses are asking the question, “Isn’t there an open-source solution for this?”.
Not only has open-source been accepted, but its become the preferred solution. We are certainly in this position. Thus far, our technology stack is built entirely open-source components.
I see the following motivators driving this direction:
Control Your Own Destiny
With open-source, you are in control. You are free to fork the code, extend it, destroy it, whatever your pleasure. If you need a specific feature, you can develop it yourselves. Your roadmaps and timelines are your own.
If there is a problem in production, you can diagnose and resolve your own issues. In many cases, enterprises are larger than the emerging technology vendors. The enterprises can bring more resources to bear than the technology vendor. What they may lack in expertise, they can make up for in resources. (and bringing in consultants if the need arises)
Honestly, this one is always under-valued. Open-source technologies enable innovation, by attracting talent, and seeding ideas. Open-source technologies provide a treasure trove of ideas for tinkerers/inventors. Developers can look under the covers, mine ideas, and come up with new ways to combine and extend the technology.
It is often impossible to predict innovation, but enabling the right talent with the right technology certainly improves your chances. Talent often differentiates one company from another. It is the crazy idea from the morning shower and the ability to execute on it, that keeps technology companies innovating. IMHO, open-source technology stacks attract the best talent. Open-source communities are meritocracies that allow the best of the best to succeed, which results in commensurate accolades. This attracts the best of the best, and that’s who you want working/innovating for you.
Support Costs determined by Free Market
Open-source is the anti-monopoly. With proprietary software vendors, you need to pay their licensing and support costs. If they are entrenched, the vendor can theoretically charge a large percentage of whatever the replacement cost would be, and the enterprise has no other option but to comply. That becomes a tough pill to swallow.
With open-source, support contracts are new the license fee. But unlike license fees, an enterprise is free to shop around, selecting the best value for the dollar. Companies providing support must compete on customer service and price point.
In the end, an enterprise needs to make a decision. Inevitably, there will be scenarios where time-to-market, project maturity, and/or core-competencies influence the decision to build, buy or leverage open-source, and those may prevent an enterprise from selecting an open-source solution. But let’s take a quick look at the economics of such a decision, considering the motivations outlined above.
Let’s assume there is an Open-Source project, OpenZee, that is deficient in feature and function to a proprietary product ClosedOrb. Let’s assume there is an annual license fee of $25K for ClosedOrb. Over five years, that would cost an enterprise $125K. Because time-to-market is a concern, for the first year it may make sense to go with ClosedOrb and shell out the $25K, but strategically, at the same time, it might make sense to dedicate a resource to OpenZee to close the feature function gap and replace ClosedOrb in the stack. And although it might not be feasible to close the gap with a single enterprise’s cost-savings (e.g. $100K), if we recognize that other enterprises are in the same situation, it is likely that the a collective effort *can* close the gap. If there are a couple dozen companies all making the same trade-off, that would result in $2.4M annually of resources to apply to the project. That rivals many small-company R&D budgets.
In this scenario, OpenZee did not yet have the minimal set of functionality to produce a viable product. The project needed a set of early adopting companies that were willing to invest in the strategic vision. But once the project has the minimal amount of functionality, (The 80% in the 80/20 rule) the dynamics change quite a bit. While the company behind ClosedOrb continues to build out the 20%, more and more companies begin using OpenZee because the criticality of the functional differences begin to diminish. OpenZee eventually outpaces ClosedOrb and takes over the world. (okay — that’s hyperbole, but you get the point)
Now, I want to be clear. Although the scenario above focused on the financial motivation to invest in/contribute to an open-source project, the motivations outlined previously were not based on any financial incentive. I don’t believe enterprises are necessarily looking for “free software” as in “free beer”. The motivations above in fact are derived solely from the code being “free” as in “free speech”. (More on this topic here)
In many cases, enterprises will happily pay for support for software because that is a service that they would otherwise have to fill on their own. In fact, at larger enterprises, being able to pay for commercial support is actually a requirement for technology adoption! But as the world shifts from a “why open source” to a “why not open source”, more companies are going to take a strategic view and demand open-source solutions to “free” their development/innovation. They are also going to be more willing to invest in those projects that need it.
This bodes well for projects like Druid, which may just take over the world of Big Data Analytics. (yes, more hyperbole … maybe… just to emphasize the point =)
I think companies like Datastax have played their cards right. They understand that with community comes momentum and with momentum comes revenue. Sometimes that revenue comes directly from licensing proprietary extensions, sometimes indirectly via support, services and education. The color of the money is the same.
My advice: Seek free code. Find innovation.
This guide will introduce you to the world of Software Architecture!
This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.