Practical Freedom and Open Business – As applied to DDS and Open Source 1

The open source movement, and notably the Free Software Foundation, rightly positions its value proposition as really about freedom.  Their lofty ideals, such as guaranteed access to source, unrestricted sharing, and open collaboration, drive the success of many key works.  “Free speech” software is a beautiful concept.

Unfortunately, these lofty ideals are often not enough in practice.  Open source software (OSS) famously struggles to find successful business models.  Without financial support, many projects languish.  Users, especially users of emerging core infrastructure software, need more.  They need the practical freedoms and open policies that ensure a healthy supplier relationship and mutual success.  These freedoms are no less profound.

What works for the mass, mature, server market may not apply to emerging niche applications.  That really matters to you, if one of those emerging niches is the core underpinnings of your $1b project. RTI has decades of experience in complex networking software for mission-critical projects.  By listening deeply to hundreds of teams, we have learned which freedoms are truly critical.  We recently made the most important announcement in our history, our new “infrastructure community model”.  That model implements both the practical freedoms and open business policies that our customers need.

Maybe it comes down to a platitude: Freedom isn’t free.  It also isn’t one thing.  It’s time we take a look at the practice of freedom and open business…

Source Freedom

Source code for a complex system is useful for understanding, for debugging, and to expose potential bugs to many “eyes”.  Contributions in the form of application, services, tools and other layered products are very valuable.  Likewise, using common architectures and platforms across an organization or a supply chain dramatically lowers software costs.  So, the freedom to share modules and resulting platforms is critical.

“Free beer” products, which do not carry any costs, are also critical to seed early exploration.  RTI now offers free beer, and it’s fresh, it’s the market-leading best brew, and we offer it with professional service (support).  You can modify it, share it with your cohorts, and ship it in your products.  There is no charge.  If you’re opening a brewery, it should be compelling.  Bottoms up!

How can we afford that?  Because free beer is best only for smaller, short term projects.  If your system is complex, long lived, and mission critical, there is danger in distancing yourself from the source of the infrastructure.  If I’m betting my career and $1b project on infrastructure software, I damn well want my vendor to know who I am, care about my needs, and aggressively maintain the software to ensure my success.  I do not want to hack that software myself, thereby cutting me off from effective support and future updates; “escrow” is a desperate last resort.  And, I’m willing to pay a fair price to ensure the software’s, and the vendor’s, continued excellence.  In short, I expect my vendor to see my success as a responsibility, and one that is shouldered in exchange for reasonable consideration.

Risk Freedom

These technical aspects are critical.  But the risks of system development go well beyond source and sharing.

The first consideration is freedom from legal strings.  The tar pit of copyleft is well known.  But, some code bases contain hundreds of different copyrights and license terms; it’s hard to know if the vendor has the right to grant you a license at all.  This problem, called code provenance, is a nasty trap waiting to spring on the unsuspecting user.  It’s the reason many open source vendors will not offer IP indemnification for their products…they make you take the risk.

Unintended patent licenses are an even more subtle problem.  The GPL and LGPL, for instance, contain well-meaning patent license clauses.  Unfortunately, these threaten unintentional licensing of your patents if you distribute the code.  The problem is sufficient to cause many organizations (ironically) to preclude use of LGPL code.

Of course, a vendor’s business model is more than a license.  Consider freedom from frustration.  Pulling your hair out late at night preparing for your system acceptance test is no time to consider support and guidance.   Support for current and old versions, both free and paid, is crucial.  That support should be available during extended hours at known and bounded cost.  Consider also the quality and availability of deep guidance.  Our experience with hundreds and hundreds of project teams means that we’ve made and learned from mistakes that you don’t want to repeat.

Speaking of mistakes, consider freedom from being stranded.  Fresh from yet another colonoscopy from a Fortune 50 vendor qualification, I can assure you that infrastructure customers expect crisp and complete quality processes, deep testing, financial health, and good corporate governance.  Some OSS companies offer this…others roam the wild west.

Freedom from stranding does not just mean that your vendor survives.  The vendor must proactively strive to meet your needs.  Great software requires ongoing investment in features, usability, quality, platforms, and standards.  The business model must reward more than just hours.  It must also allow and encourage you to leverage the latest technology, even if parts of your system are using free or old versions.  These are not trivial.  But without them, you risk long-term lack of the features, tools and services that you need to succeed.

Relationship Freedom

Perhaps the most important freedom is freedom from surprise.  RTI commits to a high bar: absolute honesty; it’s written into our founding core values.  This does not mean we will tell you all our plans.  It does mean that we commit to you, to our employees, and even to our competitors that we will never intend to deceive.  More to the point, if there’s something you need to know to deal fairly with us, we will not hide that information.  We strive for no surprises.

We are very open with our license; it’s posted on our website.  Our “open community source” concept is not “genuine” open source, and we do not claim that it is.  However, it strives for the elegance and freedom seen in the best of the OSS licenses, albeit within an IC.  The IC concept allows us to offer you a great deal: almost all projects qualify to be in an IC, within the IC we are very open, we ship the latest version of core library free or paid, and we support everything we ship. We genuinely believe this model is in your best interest.

You cannot divorce the license model from the pricing model.  Few pure-play OSS users expect to be someday faced with the Hobson’s choice of living with a critical flaw in their infrastructure or paying a $250k bill.  Few users who start with free-but-limited versions expect to someday have to upgrade to a pricing model they have never considered.  These primrose paths are, unfortunately, significant sources of revenue for many companies.

RTI matches straightforward licensing with straightforward pricing.  Like our software, our source of revenue is completely open, predictable, and known.  Your cost depends on only one metric (developers).  When you purchase all you need from our broad product line, you will pay only a few $k each.  We request only predictable, fair consideration for extraordinary value (another core value).

Our customers count on us for weighty things:  The core of multi-$b product lines.  The success of critical programs.  The survival of their compatriots.  Infrastructure middleware is a responsibility, and one that we at RTI take very seriously.  Our product quality, performance, and reliability are covenants with our customers.

We also consider both our license and our pricing as fundamental covenants with our customers.  We are fully dedicated to an open, honest, successful relationship.  There will be no surprises.  We will walk that extra mile, with you, to ensure success.

That is also freedom; maybe it should be called freedom from loneliness.  Because, in the end, selecting and using infrastructure software is a long journey.  It’s a trip you don’t want to take alone.

You are likely betting your career and project on infrastructure software.  We strive to be worthy of that trust.

Learn more about OSS business models and open community source at my upcoming webinar entitled “Open Source 2.0?”; register here:  It’s free.  🙂

One comment

  1. Its a weighty thing to create a whole new business model and customer engagement model, and as part of it to provide free access to the crown jewels, your source code . Its an even weightier task to educate prospective markets of its benefits.

    I suspect its the key realization that access to code is insufficient for large projects that is the cornerstone understanding of this shift. Customers don’t want access to source so they can fork it and evolve it and develop it to their own agenda. As you state they actually want you to evolve it to their needs using your team who understands this code base at a deep deep level, The sort of understanding that cannot be obtained just by throwing a huge bunch of code to a whole new dev team inside your own organisation. Most customers don’t want to be infrastructure builders, they want to be expert infrastructure users. And if they do want to be infrastructure builders you allow that too, but make it clear that at that point you divest yourself of certain maintenance and support responsibilities. A fair trade indeed.

    By providing source access you empower them to check the code quality and even give them an insurance policy if you do evolve the code base in a direction that’s really a problem for them.

    A bold mix of freedoms and weighted responsibilities between supplier and consumer.

    Best of luck with the IC model.

    (disclaimer – I do work as an external consultant to RTI – but I was not involved in this model creation)


Submit a comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s