Open Source Software Productization
How to ensure convert an open source project to an enterprise product
General rules for the enterprise productization of open source software are:
1.) Deployment options:
a.) the code MUST be easy to get, easy to install, and provide clear benefits to a developer/evaluator in a short period of time
b.) enterprise software should support hybrid deployment modes, i.e., it should be easy to deploy on premise, on a private cloud, or to a public cloud.
c.) The code should be either easy to deploy to virtual machines (VMWare), or into Kubernetes (in a container native way), [the best is to start with VMWare, K8s is still hard to do]
2.) Code Access:
a.) the code should be available from Github (if open source), or from the company's website (a "download here" button)
b.) if the code is not open source, the code should at least:
i.) be available to download and try for free without needing to contact a sales person
ii.) have a commercial license that limits it's use to trials only (non production env.) or with some other limit such as # of connections/users/runtimes, time span (e.g., 90 days), or features
c.) it is fine to have enterprise-scale features to be separate from the basic version, e.g., the base version can support upto xyz connections but the version that can support millions of connections is only available after talking to sales, buying the product, etc.
3.) Software Management:
a.) The standard approach for management of enterprise software is for the Vendor to sell Customers annual subscriptions to their software, where the Customer owns the management of the infrastructure/platform and all custom code built on top of the platform, and the Vendor builds patches and new versions.
b.) Customers who pay for this annual support, allows them ability to call the vendor (Little Horse) when they have issues and the Vendor builds hot patches. The vendor will over time, merge multiple hot patches into consolidated patches (e.g., 1.3.1 to 1.3.2), and over time, the vendor will produce new releases (e.g., 1.3 to 1.4, or 2.0) which include both all patches and new features.
c.) This standard approach of annual subscriptions allows the customer to access a private code repo that includes the code, hot fixes, and consolidated patches, and the customer decides when to install these updates, and manages the process to install those updates.
d.) If a customer stops paying for the annual maintenance, the customer must know if they can continue using the product (without support), or if they are not allowed any updates, or if they must stop using the product
e.) the first alternative to the standard approach is to sell managed hosting, where the vendor will support installation of hot patches, and consolidated patches, but is not responsible for errors created by code on top (requires coordination with the customer for any issues caused during an update). Managed hosting can be for on-prem or private cloud deployments, but is usually done only for public cloud deployments in a multi-tenant environment.
4.) Multi-tenant Managed Hosting vs SaaS
a.) The main difference between managed hosting and SaaS is based on the provisioning process.
b.) Both should be built on a multi-tenant infrastructure to save the vendor money for the cloud costs. However, SaaS must have auto-provisioning where the user/developer can click a UI and have an instance deployed for them, while a managed hosting offering requires the deployment to be configured after a sale.
c.) These deployments are often a coordination between the vendor (who provides the sale, docs, training, and ongoing patches), a Systems Integrator (who deploys the software, creates the customization, and installs patches) and the customer (who pays, has the requirements, and manages the requirements and KPIs). Note, many SaaS vendors support auto provisioning for smaller deployments, but still require the customer to contact sales if they want Enterprise scale.
d.) This latter offering is essentially a managed hosting environment. What is interesting is that this means that a vendor can setup a managed hosting offering but market it as a SaaS.
e.) A main aspect of SaaS after auto provisioning, is the aspect at all hot patching, feature updates happen in the background and the customer does not have to worry about them.
f.) The added benefit is that the cloud costs are also embedded in one price (cost = software + patches/updates + installation of patches/updates + cloud runtime costs)
g.) THERE IS A BELIEF, that companies are happy to pay their own cloud cost, if they can get the software they want easily deployed into their public cloud account. (Note, this is not managed hosting, and is not SaaS. It is where the vendor allows the code to be easily deployed into the developer or enterprises own AWS/Google Cloud/Azure account, and they they managed the software updates after that.)
5.) Marketplaces (e.g., AWS, Azure, SFDC, Oracle, Google)
a.) Marketplaces are different than deployment options, maintenance, or Managed Hosting/SaaS considerations (all can be used for the Marketplace offering)
b.) a Marketplace is simply a way to get eyeballs onto your product, and a method to accelerate their installation and testing of a product
c.) one way to think about these marketplaces is that they are mostly to simplify the process to help developers get started quickly, to test your product or to build a quick service
d.) however, once built, the Ops team may decide any of the items above for the production system, meaning, they may still deploy the product into on prem or private cloud infrastructure
e.) Marketplaces often have "opinionated stacks" or other software that they Marketplace/Cloud vendor can support along with the chosen software, e.g., you may choose a rules engine, and decide then to use the cloud vendors storage, logging, messaging systems with it.
f.) If you do a multi-marketplace strategy, you have added cost if you want to support every combination of opinionated stack
g.) There is a belief that most software is being choosen from the marketplace today, with AWS attracting the most developers, however, emerging cool tech is often found outside of a marketplace and developers love getting code from Github as it feels more "flexible" (note, Ops will want full flexibility and are unhappy when developer start with very opinionated stacks)
h.) There is also a belief that Microsoft is working to be the most independent, most vendor neutral, more enterprise friendly. So far this seems to be true.
j.) there is a belief that Salesforce is the best marketplace to generate independent income due to integration with full enterprise sales operations