Open source code and business models: More than just a license

I have an article up on directly related to the themes addressed here; outlining key decisions points, beyond the license, when considering open sourcing code.

Have a look: Open source code and business models: More than just a license

Posted in Open Source Business Models | Tagged , | Leave a comment

Three Key Cloud Questions for ISVs

There are excellent examples of large successful ISVs making the most with the cloud, many of which are the next generation businesses that natively benefit from cloud availability and scale models.  Netflix, Zygna,, and many other market making examples show how to leverage the power of the cloud, and in most cases are either designed for, or even built by the scale provided in cloud computing.

But what if your challenge is in taking an existing ISV business into the cloud?  What do you have to consider?  Where do you start?

A good starting point is with the basics:

 1. What is your value and how does it translate to the Cloud?

 2. How will you transact with your customers in the Cloud?

3. Where does this lead you and your customers?

At Red Hat we have (and continue) to go through this transformation to the cloud. I will use Red Hat as an example of the transformation that I am seeing with other ISVs, with the appropriate, and amplified, disclaimer that I work for Red Hat, and that these views are my own.

Red Hat is certainly building new solutions specifically for the cloud, but just as importantly we are molding our core businesses to both leverage and provide value in new cloud consumption models.  Under some definitions, Red Hat is as an ISV, having built a large enterprise business sold under a subscription model, metered via well defined metrics (sockets is our most prevalent example), through a large channel distribution relationship, with a large ecosystem of partners, backed by award winning support portals and services.

So how do you take a model like the above and translate it to the cloud? Following are some of the responses that we have conceptually made and how they might affect a typical ISV looking at the same situation:

1. What is your Value and how does it translate to the cloud?

  •  Red Hat’s response: One of the first determinations Red Hat made is that “consistency is king”, regardless of deployment method: public/private/hybrid, on-/off-premise, physical/virtual/cloud etc.   This consistency must permeate everything we do with our customers and even partners since business have been built on Red Hat being a trusted enterprise provider.
  • What does this mean to an ISV: If your value to a customer is helping them build solutions on top of your platform and the consistently of that platform is key, whether it is interfaces/APIs, service levels, availability, certifications, or even pricing, then you must strive to maintain that across all deployments.  This also means that you have to find ways to accommodate new models, such as hourly pricing, VM metrics, on-demand capacity, in a way that maintains this consistency.

2. How will you transact with your customers in the Cloud?

  • Red Hat Response: Don’t disturb the routes to market (see consistency above), but provide more flexible consumption models that are simple to acquire and permit customers to extend their relationship with you.  And above all: Keep It Simple.  Red Hat now offers many of our traditional products both through cloud providers, but also has made our traditional routes and offerings cloud consumable. Our sales teams, VARs, VADs, ISV partners are all part of many of our cloud transactions and many don’t even know that they are, it is business as usual for them.
  • What does this mean to and ISV: Find ways of simplifying the acquisition process.  Make the cloud part of the existing offerings that you have. Modify your business models such that customers who historically have transacted with you in a “traditional” model can take those relationships and move them to the cloud, but if they want new models, e.g. hourly, consider new ways of working with the cloud vendors, on-or off-premise, to enable new ways for customer to consume your models.

3. Where does this lead you and your Customers?

  • Red Hat Response: Red Hat now considers cloud models and offerings part of the product definitions. When we define a new offering, we evaluate how the newer models and consumption paradigms may alter or influence the design of the product.  Business, legal, and financial considerations and their cloud angles are key considerations when defining how we will work with customers and partners.  This in turn has led to new offerings.   Good examples include our OpenShift Platform as a Service and Red Hat Storage offerings which retain and build on many of the fundamental values of Red Hat (Security, Enterprise Quality, etc. ), but introduce both new business and transactional models with customers, extending their experience and value we can deliver to the customers.
  • What does this mean to an ISV:  Look to these transformations to Cloud as fundamental to your business, not as one-time migration. Just as ISVs (and all businesses) went from Mainframe, to Client-Server, to Web, the same will have to happen in the Cloud transformation.   New offerings will be built and became part of the daily conversations for product managers, engineers, marketing and sales. New business models may spawn new types offerings (PaaS in the case of Red Hat).

Ultimately, moving to the cloud requires that you rethink your Value as a business, what you mean to your customers, and how you want to be perceived going forward. It some ways this becomes an experience of really getting to know your own business in ways that you have not considered before.

Posted in Cloud Ecosystem, ISVs | 1 Comment

The Ecosystem Singularity

Cloud computing is blending the fundamental definitions of consumers, suppliers, and service providers in such a way that distinguishing one from the other is increasingly challenging.

An ISV, who built on top of my products before, may now want to resell my products with their software.   A customer who ran internal infrastructure on my products may now want to offer my product as a service to their customers.  These may not be new questions, but they are rapidly enabled by the emergence of cloud business models.

This ecosystem singularity (no, not the Technological Singularity) blends routes to market, handily breaks existing legal constructs, pricing frameworks, and most importantly – forces the reevaluation of what value is being provided and to whom.

A basic question that has to be asked today is: Does the cloud give you as much choice as before?

From a technical perspective, the debate on Cloud APIs is well underway. OpenStack, Amazon APIs, etc. all frame the questions on how to engage with a series of public providers from a technical perspective.  Openness is keen here so that an ecosystem member who will be consuming the services of one or more clouds, has the ability to choose between vendors.

However, when the concept of business relationships enters the discussion of cloud consumption, a path to answer the above question about openness is not yet as clear.

Example of Future Yore (Today?):

As over-simplified example:

Take an ISV that historically provided packaged software, priced as a license with annual maintenance, delivered via a distributor, who sold it via reseller, who delivered it to an IT department, who married it with: hardware from an OEM, an Operating System (disclaimer: I’m partial to Red Hat Enterprise Linux), installed it in a datacenter, and maintained it for an internal Marketing department, who used the running software to develop and distribute a marketing campaign to customers, who buy the companies product.


For simplicity and without reducing the value that each provides, I have excluded managed service providers, system integrators, hosters, and a sundry of other services that typically get injected into larger deals.   Note also that I conveniently ignore the complex topics of compliance.

Breaking down the actors in this example:

  • OEM: herself
  • ISV: himself
  • Route to Market: distributor and reseller
  • Service Provider: IT Department
  • Consumer: marketing department
  • Customer: purchaser of marketed goods

Sample value provided to/by each of the actors:

  • OEM: hardware, firmware, and support
  • ISV: software, updates, and support
  • Route to Market: acquisition and financial services
  • Service Provider: build-out and operational services
  • Consumer: receives a running service on which to do their work
  • Customer: becomes informed about the companies goods

While complicated, the story works and has evolved in the free market (when everyone plays fairly) to provide a competitive environment that encourages innovation of services, value, and cost.

The ISV knows how to craft legal language, price their product and sell it to the distributor, the route to markets innovate their services and build relationships with the service provider, the service provider knows who to call and how to buy more product or renew their maintenance, and the consumer knows where to go to get service for their application, while the customer doesn’t care about any of the above.

What is interesting in this, is that there are multiple, ingrained business relationships, backed by legal contracts, pricing constructs, support relationships, supply chain relationships, and ultimately expectations on appropriate business relationships.   These took decades to develop a natural ecosystem based on relationships that provides value to customers.

And relationships are free to change.

If a reseller does not meet the expectations of the company, then the IT Department can start purchasing from another reseller (or perhaps the ISV directly).   If the Marketing department does not like the software it is receiving, it can work with the IT department to find an alternative software vendor.   If the Software Vendor does not like the service that its resellers provide, it can contract with other providers.

Sure, lock-in does occur, but there are alternatives at each stage of the cycle bounded by multiple business and technical relationships.

World of Tomorrow (Today?):

So what happens when the Cloud enters the scene?

Trying to keep the same example framework, and massively oversimplifying by using a Public Cloud with an ISV SaaS:

An ISV develops a piece of software, prices it as a service based on number of campaigns, which is premised on continuous consumption by, and possibly directly with, a consumer, then finds a route to market, which in this case is a Telecommunications Company who has released a public cloud and starts messaging directly to the Marketing Department (the consumer) using its own service on the Telco’s cloud and provides the service directly to the Marketing Department who builds and distributes campaigns to customers.

Breaking down the actors in this example:

  • OEM: Telecommunications Company
  • ISV: himself
  • Route to Market: Telecommunications Company
  • Service Provider: ISV
  • Consumer: marketing department
  • Customer: purchaser of marketed goods

Value provided to/by each of the actors:

  • OEM/Telecommunications Provider: operational services to both the ISV and the marketing department.
  • ISV: campaign SaaS (comprised of software, updates, and support, build out, monitoring services acquisition and financial services)
  • Route to Market: covered by the ISV or the Telco
  • Service Provider:  the ISV and the Telco
  • Consumer: receives a running service on which to do their work
  • Customer: becomes informed about the companies goods

Ultimately, the consumer and customer still receive the same service and hopefully on a more consumption based model. However, things that have changed:

  1. The ISV is a now in a direct relationship with the consumer as a Service Provider, not an ISV.
  2. The Telco (where were they before?) is a Service Provider to the ISV, who is now a consumer of the Telco’s cloud.
  3. What happened to the IT Department?
  4. What happened to the Distributor and Resellers?
  5. Does the ISV who builds on the Telco’s cloud have sufficient flexibility to migrate to another cloud?
  6. Most importantly, do the direct relationships that are being built provide a framework for choice?

I do not portend to state that the Distributor, Resellers, and IT Department don’t have roles to play – as simple tweaks to the above example would have included them just as easily with a Private Cloud.

Where this is leading us?

The relationships that have built up through the open market ISV, Channel, OEM, Consumer are changing.  Understanding the complexities that the cloud model introduce is not merely a case of understanding the technology changes, but as importantly – how the business models that emerge in the cloud will affect how you interface with your customers and suppliers.

The core question that you need to ask regardless of your role above is: How can I keep my choices Open.

Posted in Cloud Ecosystem | Tagged , , | Leave a comment

Making Hybrid Real: Disambiguation via Operations

Public, Private, Hybrid, Community – the deployment options for deciding how to use a cloud seem pretty clear…until you try to actually distinguish between them.

As many have done – you can start with the definitions provided by the National Institute of Standards and Technology in the NIST Definition of Cloud Computing by Peter Mell and Tim Grance.

I’ll leave it to you to read the very short paper (recommended) – but let’s focus on the definition of Hybrid Cloud from NIST:

“Hybrid cloud. The cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds).”

As I speak with consumers of public clouds, ISVs determining their cloud models, channel providers determining how they will participate in the cloud, and last but not least the service providers who are/will offer a “public” cloud – when the question about the hybrid cloud comes up the practice of Public and Private being “bound together by standardized or proprietary technology that enables…” is deemed insufficient. There are business and operational requirements that not only go beyond the technology, but make it even harder to distinguish between the public and private models and combine those into a hybrid model.

Rather than trying create a canonical definition for hybrid, I encourage everyone I speak with to look for a continuum that ranges from Public to Private, where the technology, operational support, and business models are considered as separate components in the definition rather than the defining characteristic of hybrid (or public or private). I have a hard time fitting the community into this model, but I’ll save that for a later tome.

To focus in on the Operational aspects of the hybrid cloud and its challenges I can take a real-world example from some of my discussions.


A large corporate IT department (think 1,000+ employees) builds a certified gold master server image. This image consists of configured OS, custom scripts, in-house applications, and even some 3rd party applications depending on target deployment. The image is managed by an internal release engineering team, released under strict certification guidelines, and rolled out uniformly to any servers within the corporation’s environment.

This gold master server image is defined such that the 1,000+ staff in the technical staff can rely on the fact that they have legal, technical, and support coverage. There certainly may be software or custom configuration that meets industry or government regulation that the corporation’s IT and legal departments require to ensure compliance. At any point in time, there are multiple versions of this image that must be tracked, maintained and supported by the IT department.

In many ways, the IT department is a Software Vendor (although not independent).

This model has worked for decades for both on- and off-premise. For example when a department in the corporation needs to leverage an external hoster or service provider. Yes, it’s hard work – but understood.

Enter the private cloud:

Things go relatively smoothly since very little changes in the operational models, whether (as the NIST definition promotes) the cloud is on-premise or hosted at a 3rd party. The IT department still releases the same software and manages those across now a virtualized set of servers. There will be changes such as managing sprawl, allocating resources efficiently, and tracking where things are deployed – but the management software and models exist or are tenable. As long as everyone deploys the same gold master images, the environment is controllable.

Enter the public cloud:

Taking the purist view of IaaS with virtual machines running on a multitenant server (and conveniently ignoring SaaS and PaaS), things may change more here. What happens when there is no import mechanism for the gold master image from the IT department? Are there tools for the IT department to rebuild the exact image in the public cloud and have a controlled release to their internal users? How are images and instances updated? Does the public cloud provider or service provider manage the images and instances on behalf of the customer?

Many of these questions will be eliminated by partnering with a provider who permits the IT department to do most of what they need, but changes will be injected to accommodate new public cloud models wherever necessary.

Enter the hybrid cloud:

Take the same questions introduced in the public cloud example and attempt to marry the complexity with the private cloud. As defined by NIST, the technology enables data and application portability, but does the operational model of the combined private and public environment work in such a way to permit a single gold master to be deployed and managed between both in a consistent fashion?

The hybrid cloud in this case is adding yet another layer of complexity that must find a match in the operational models between public and private for the gold master, without adding undue complexity, without reducing the benefits that are afforded the combined deployment models.

There is much more to the hybrid cloud than the technology enablement. Consider the impact to the operations team and how to serve or modify the models that have been built up, yet know what you are getting in the hybrid cloud and hopefully in the process we can start defining what hybrid means.

Posted in Hybrid | Tagged | Leave a comment

How Legacy befits the Cloud

Today, Red Hat launched the  first highly available file system for Amazon Web Services, Red Hat Virtual Storage Appliance.  One of the first articles written about it was from Barb Darrow on GigaOM, Red Hat attacks cloud-app gap, which I think illustrates a very important aspect of which the cloud is enabling.  Specifically, that there are existing applications and systems which may start to benefit from the cloud now that infrastructure services are beginning to present consistent and familiar services to what the applications already use.

Earlier in my career I worked at two startups which were focused on the “Legacy Transformation” market.   At the time the intent was to legacy COBOL/JCL/VSAM code into modern languages by extracting the nuggets of value – marketed as business rules – and transform those into manageable objects and constructs that both matched the state of the art in coding as well as were more malleable and reusable for other purposes.   I spent far too many hours using tools I had helped write to recode systems into Java and C/C++ so that they would mimic what was being done in the original system.

That is all they were doing – mimicking what had already been done.

There was no discussion about massive scale.  No focus on how the legacy systems could start to serve new markets in innovative ways.   Just that they would be “modern”.

Some of the biggest issues were not with the business rules themselves, but transforming the applications so they would work with the new services provided, including 3270 terminal to Web migrations, flat file to relational db migration, etc.   While there were, and likely still are, success with some of these migrations – many of these ended up either remaining in place on the original hardware and support infrastructure because the business benefits were not sufficient to justify the migration.

The older environment just worked well enough.

With Cloud, specifically the public cloud, I believe we are experiencing a change of capabilities, rather than a change of technology.   This means that while there will be new services which are built on and by the cloud – think Hadoop, Condor, etc. – which have and will engender, often in mind-blowing ways, new services such as Big Data – there will also be a significantly large category of applications and systems that can to take advantage of the business value the cloud presents without significant technology change.

Crawl, Walk, Run.

That doesn’t mean that these systems can’t and won’t take advantage of where the cloud can lead them – but it does provide a starting point for systems that provides incremental value, whether Shadow IT, or basic scalability, that would have otherwise been more challenging or impossible to achieve outside of a cloud environment.

For this, these applications will need a consistent environment in which to run.   Whether the OS, database, networking services, security constructs or, as Red Hat announced today, a consistent file system.

As these support systems come online and present familiar APIs and services within the cloud – they in turn will start to provide more capabilities to the “legacy” applications than would have been available in the legacy environment.

A good example is with a single Virtual Storage Appliance being able to scale to 100TB linearly.  Sure, that could happen outside of the public cloud, but it is the business and operational model of the cloud that makes that type of scale possible. The Public Cloud business model provides the storage, immediately, that many IT shops could never provide…without requiring changes to the design of the application.

Consistent application, consistent interfaces, but massive scale enabled via the business model of the public cloud.

There will always be improvements possible, such as applications specifically written to take advantage of cloud-scale.   But the first step is to make sure that applications work as they did before and can take advantage of capabilities provided by the new business models of the cloud.

Posted in Uncategorized | Tagged , , | Leave a comment

BOT: Business, Operations, Technology

As I speak with my co-workers and industry associates, one of my favorite quotes is: “product management is hard.”   So hard, that academic studies, personal careers, and massive industries are built around just defining the practice of identifying, building, delivering, and maintaining a new product in a market.

But what happens when what is being built is not a product, but an amalgam of new and old technology, offered under non-industry-standard business models, condensing multiple sales routes and channels, which spans global markets simultaneously, and holds the promise of transforming every industry by enabling new solution categories, all while delivering infinite power and data directly to an individual sitting on their mobile device in a remote part of the world.

This is the Cloud.

The Cloud is not a product that needs to be managed, but a change in the business, operational, and technology models that affects every individual and entity that sells or consumes information technology.

So, if product management is hard, how do we even start to address what happens when the technologies enable an entirely new consumption model?  How does a business adapt? What are eventhe questions that need to be investigated?

Keep it Simple, Stupid.

I have worked with ISVs over the past 20 years building new products, integrating new products, and partnering with offerings from partners.  While there have been many checklists on launching a new products, different development models, and curriculum and certifications of excellent frameworks for creating a business and product; none of these seem to work when the question is as broad as what Cloud presents.

Rather than focusing on the breadth of the question of how to address Cloud Computing and its flavors, such as SaaS, IaaS, and PaaS – I have found that by thinking of three arenas; Business, Operations, and Technology, we are able to start communicating where the questions may lie.  With the caveat that some of the below are tainted toward both Red Hat, some representative questions we continue to ask:


  • What are the legal implications of the new model?
  • Who are the consumers, providers, and channel?
  • Pricing, is it even still relevant?
  • Who is selling what to whom?
  • What is the value of our current offerings? Are things fundamentally changing?
  • Where does our existing business model go from here?
  • What does Open Source react to this new model?


  • How are these new services going to be delivered?
  • How and what are we going to count?
  • What is the consumer going to have to change in how they do business?
  • What happens to our support, finance, and engineering services?
  • How is a partner ecosystem going to work with us on this?


  • Are there new technologies that have to be integrated with the old?
  • How do we connect the systems that support the offerings?
  • Can the systems we have in place deliver deliver under the new operational model?
  • Are there new services that require additional technology that we haven’t discovered?
  • What happens after the release, does the technology go through a different lifecycle?
  • How are we going to handle change?  How do we recognize if change is happening?

There are many, many other questions to be asked so the above is not inclusive by any measure.  However, by repeating the conversation around Business, Operations, and Technology – I have found that we can at least articulate to those that are not part of the conversation how they can participate.

Posted in Tenents | Tagged , , | Leave a comment