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: http://www.rti.com/mk/webinars.html.  It’s free.  🙂

Introducing RTI Connext and The Next Era in Operational Technology Reply

Today is one of the most significant days in RTI’s history. Today, we are unveiling a new product line, a new corporate strategy, and our vision of a new industry direction.

Our new products target the challenging problem of building connected systems that will work together as never before.  The RTI Connext product line spans the gap from deeply-embedded devices, through high-performance real-time systems, all the way to enterprise IT integration.  It really is the first edge-to-enterprise “real-time SOA” platform.  We’ve been working on the base technology for decades; it’s truly exciting to bring the vision together—and the capability to market—for the first time.

Our new strategy is to leverage our “operational” technology into a unified system-wide infrastructure.  Our software is the key nervous system for over 500 major mission-critical projects in several industries including defense, industrial automation, automotive, and healthcare.  Our new products expand upon this footprint, both down into smaller devices, and up into system-of-systems integration.  We can now assemble large networks of mixed devices and applications into working systems, and hook those (and other) systems together into a connected whole.

Critically, we can also now connect operational systems to the enterprise IT infrastructure. Why is that valuable?  Because it enables a new way to run and control systems.  This is an important trend across many industries.  As networks become more powerful, and as technologies like ours make interconnection more possible, the worlds of IT and OT (operational technology) can, for the first time, interact. RTI Connext builds operational systems, but with our new Integrator product, it can also connect those systems with enterprise technologies in real time.  Since business intelligence and resource management are so well developed for the enterprise, this makes it possible to feed back smart directions to the operational system.  And that makes everything more efficient.

Thus, we let you use, control, and optimize all your systems as a holistic entity.  Our new tag line sums it up nicely: Your Systems. Working as One.

This is a big, complex vision.  Implementing it fully will take years.  But today’s launch represents a culmination of what we’ve learned addressing the needs of mission-critical applications for so many years. Our base technology has the performance, 24×7 reliability, and scale to succeed as the core transport for demanding real-time systems.  We are now adding IT-like technologies: central console administration, multiple messaging patterns, and a true service bus.  The result is a unique approach that enables a new level of system function.  We’re excited both by the current breakthrough and its implications for the future.

It’s great to kick off 2012 with such big news! Today’s announcement is the first step towards our goal of making all your systems work together as one. I’d like to offer my congratulations to the RTI family, as well as the customers and partners who made this day possible.

NASA HRS Program and RTI Reply

Yesterday’s press release on RTI’s success with the NASA Human Robotics Program is a great occasion for my first blog entry.  (http://www.rti.com/company/news/NASA-space-robots.html)

NASA was RTI’s first customer.  In fact, NASA funded the research at the Stanford Aerospace Robotics Laboratory that spawned the technology that became RTI and the DDS standard.

The progress in the NASA program during that time is stunning.  In the 1990’s, robot controllers were clunky boxes with primitive sensors and no real connection off board.  It was a huge accomplishment just to wander around dragging a huge umbilical cord for power and control.  Today’s program connects impressive vision systems, planners, and controllers.  They can be controlled live or run nearly autonomously.  The computing system networks dozens of processors in ground stations and vehicles.  The stovepipe systems (and rivalries!) at the different research centers years ago gave way to common system architectures that allow efficient sharing of code, data, and research progress.  The robots can work independently for long periods in realistic environments.  The researchers can work together in shorter periods on realistic progress.  That’s the Way Things Should Be…

Of course, the networking technology has also made great progress.  The middleware grew from a specialized data server to a general-purpose international standard.  From our research beginnings, RTI now claims hundreds of designs in a dozen industries, including many real-world mission-critical, 24×7 applications.  We are not alone; the DDS standard is backed by multiple vendors in a growing, competitive market.  That’s also the Way Things Should Be.

Anyway, I’m glad we could be some small part of this program.  I want to congratulate NASA on its decades of progress towards the vision of enabling capable, cost effective exploration of our universe.  The sky may be the limit.  It’s refreshing to see and work with those who know it’s the lower one.