The Good Old Days
There used to be a time, and I remember it well, when working in the software industry was straightforward and well-understood.
You had your categories of vendors (such as OS and database and development tools and big and expensive business applications and desktop productivity and utilities and so forth) and, per category, you and the market had a clear understanding of organizational architecture and price points and buying center and release velocity (or the lack thereof).
And if you were an engineering or a marketing or a sales executive you could easily hop from one company to the next because they pretty much all worked the same way.
Especially when it came to how the various markets structured their partner ecosystems.
So everybody understood what it meant to be a distributor or a VAR or an ISV or an SI or an MSP. A very clear and very specific understanding of who added value how and how much across the extended delivery chain.
O Brave New World
None of that really works anymore. The world has changed in many ways:
- Agile: We have learned that fast is good and incrementally optimizing a crappy first attempt can often deliver infinitely more value than designing a full-fledged solution that takes lots of time to develop. And by the time you’re done the requirements have changed or, and this happens every time, you didn’t understand them correctly to begin with.
- Software is eating the world: Everything is software. Your TV, your car, your toothbrush. Who is going to write and maintain and evolve all that software? And it’s not like we’re increasing our supply of programmers by the orders of magnitude that would be required to keep up. On the contrary.
- Full-stack expertise: If software is eating the world and new solutions are required everywhere for digitally enabling or transforming entire industries, then each and every one of these efforts will require skills in systems and networking and application design and business logic and security and user experience and so forth.
- Open source: This changes everything. Self-organized swarms of hundreds of developers work to create joint products and systems. Think Firefox or Chrome or Android or WordPress or Linux. Seriously big and powerful and good pieces of software. Yes, sometimes it’s more self-organized and sometimes a lot less, but the framework of hundreds of senior developers working in a shared Github repository that grows in scope and goodness and does not explode is truly mind-blowing for anybody who has seen traditional commercial software development teams not scale well at all.
The tried-and-tested models for organising the value chain from software product owner to the end customer now break down, as serial handovers across the chain make any kind of agility very hard to achieve and the amount of diversity of talent required cannot be staffed redundantly in the various companies involved.
And so we look to the miraculous productivity and scalability demonstrated in a whole number of open source projects. And we start asking: Why can’t we have that?
On the face of it, the answer is simple. As a software vendor, we want to make money. Making promises to professional customers based on the assumption that some “if you build it they will come” open source project will attract hordes of committed and competent volunteer engineers is at best naive, if not downright exploitative.
For our customers, it’s much the same. They expect quality and service levels and they will gladly pay for it. They cannot run their businesses on stuff that might not work or disappear just because the hordes of volunteers moved away to the next adventure.
So if you’re a software product company, how do you structure an ecosystem of partners that can deliver agility, that orchestrates the full stack of expertise required for customer success regardless of where these people work, and that makes sure everybody in the value chain is paid more or less in accordance to their respective value-add?
The underlying assumption is of course that you do want to keep your organisation as compact as you can and that you do want to leverage a partner ecosystem to increase your reach and scalability and that you do not measure your success by counting the armies of people working for you. If that is not your basic assumption then you can stop reading and go back to dreaming about being Larry Ellison. Unless you are Larry Ellison. Hi Larry.
So let’s try a Gedankenexperiment and put ourselves in the role of a new and emerging software vendor. Probably a pretty specific business application, probably SaaS. Because that’s where all the innovation and momentum is in enterprise IT. Remember: “Every spreadsheet shared in a business is a SaaS application waiting to be built”. Let’s call our company Acme. As you do.
To make things more interesting, we assume that Acme is a startup attempting to create a new category of enterprise applications software. Think Siebel and CRM, think Successfactors and HCM. Because why not.
This means that we at Acme are free to decide how much of a value chain we want to build in-house vs. how much we want to orchestrate a partner ecosystems. It also means that we had better have a damn good business proposition for potential partners out there. Because they don’t know us from Adam and they couldn’t care less.
Now what? Let’s look at what kind of partners and skills and competencies we might want to orchestrate in our wider ecosystem. We’ll probably be looking at a set of diverse partner types who could be playing important roles in our value chain. Candidates include:
A smallish (15-70 people typically) staffed with specialised software engineers. Typically focusing on a small handful of technologies or products that they concentrate on and where they are the go-to specialists for customers or systems integrators. Organizational structure and decision making pretty agile, so if they can allocate a small handful of engineers to a new topic and take it from there they get interested. Especially if they see the potential to grow that into a practice of maybe 15-25 over time.
This type of partner can be pretty easy for us to work with, provided that we (!) deliver the projects for them to execute.
A company who has built or can build something that fits really nicely into our framework. This could be anywhere on the stack, but, to make things more specific, let’s assume that they have a special application that they want to add to or build on top of our platform. And that this application requires some kind of deep domain expertise that we do not have and are unlikely to develop on our own.
This type of partner looks easy to work with, if (!) we assume that our platform is sufficiently stable and documented to enable arms-length application development by a third party. That’s a big if for Acme, where our stack and structure and interfaces are all still evolving.
Things also get interesting when the combined solution set touches the customer: Do we sell the platform to the customer and our partner just sells their bit? Or does the partner resell the combined solution? Who provides support for the combined solution? What if that customer wants to do more with our platform and/or buy from other product boutiques?
And what happens if our stack isn’t yet where it would need to be? And the partner has to help us do some heavy lifting inside our own codebase before they can hook up their complementary software product? And how does this partner get access to our global customer base who have decided on our framework and might have a need for this additional application?
Big systems integrator:
A big to very big systems integrator providing soup-to-nuts for large customers and who hold those customers captive. Nothing happens there that they do not participate in. And we do want to work with them, because they have deep customer knowledge, strong trust, and scalable skills in technology and service that we could never dream of.
But when it comes to building strategic relationships with new emerging software vendors, the SI companies can be tricky to work with. Initially they will likely wonder if they shouldn’t just build it themselves with the large number of engineering resources that they own and that need to be fed. Then they’ll be wondering if our products are stable and secure and just generally good enough to be allowed into their captive customers. And they will be continually wondering if the joint business potential will ever be big enough to move their oversized needles. Not easy at all.
So now we start looking at how we at Acme might structure a new kind of ecosystem for optimal agility and maximum scalability and optimal distribution of investment and return for the diverse parties within that value chain. And now we’d be looking at a variety of scenarios and trying them on for size. Such as:
I’m SAP. I’m big and strong and I have lots and lots of engineers. The best in the world. Engineers who don’t work for me are either not good enough or will end up working for me. But I am also an incredibly talented and ambitious software architect so I build something beautiful. Probably a services-oriented architecture. Where I decompose big systems into small modules and define clear interfaces and contracts between them. And where the modules can be released independently because nothing breaks as long as the contracts are maintained. And I call it Netweaver. And many other names.
And this helps me manage my own development efforts because I can reach a pretty good amount of decomposition. And it enables the definition of handovers and touchpoints to outside companies, who may have complementary skills to mine and who I want to bring into my overall solution set for my customer.
So I take the SDK that my own people use and make it available to selected external parties and I build a training and certification program and charge enough for it that it both funds itself and also acts as a filter for the external software developer, just to see if they’re serious and have thought about their business case.
The good news for me: From an architecture point of view, the external partner is not so different from one of my internal development groups. So there is not that much incremental investment needed, except in training and certification, and I will make the partners pay for that.
The good news for the partner: I am so massive and have so many customers that the partner will have strong hopes for increased visibility in the global marketplace.
The bad news for the partner: I might at any time decide to extend my own functionality and cut off their air supply. Sometimes without even meaning to. Oops.
The bad news for me: The services-oriented architecture requires a maturity of product structure that takes time to evolve. In the first several years of developing my complex software system I will not really know where to cut things apart and where to put them back together. And once I do know I will have to define and maintain the external interfaces for my components. Which immediately slows down any kind of rapid innovation or system-wide architecture overhaul. And, more often than not, the whole construct grinds to a standstill. Agile this is not.
I’m Microsoft. There are a couple of things I do really well. Tools and platforms and frameworks and databases and operating systems. I have absolutely no desire to go acquire deep domain expertise for specific verticals or business processes. Better leave that to the outside world.
So for something like my Sharepoint Portal Server I focus on the overall framework, such as user management and access control and a repository and a precise presentation layer etc. And I leave ample space for a whole universe of third parties to add value on top of that platform. I invest systematically in a well-managed and highly scaleable partner ecosystem, where VARs can add value by configuring and training and where ISVs can build their own products on top of mine and where SIs can deliver and operate custom deployments for their customers.
My partner machine is highly programmatic and has a strong infrastructure for training and certification, which accelerates partner recruiting and onboarding, helps in ecosystem quality control, and creates a job market for certified engineers. Partners pay for some of that, but that’s really partial cost recovery. Mostly this ecosystem is an investment, required to complete the last mile to the customer.
The good news for me: This is probably more efficient and more scalable than bringing everything in-house. There is talent and expertise out there that I can harness in the customer’s best interest. Everybody wins.
The good news for the partner: There is a clear value proposition and a fairly good understanding of where Microsoft might extend their own product stack and where they will definitely keep white space open for partners. Exceptions apply. Oops.
The bad news for the partner: They have to work with what they’re given. API-call missing? Need to change the storage substrate? And, God forbid, bugs in the underlying framework? Tough luck, thank you for your business, all our agents are helping other customers, your call is important to us.
The bad news for me: Again, this requires a mature software structure, a complete set of APIs, a mature documentation and training machine, and once it’s out there I cannot take it back. Agile this is not.
Also, as these ISVs and VARs and SIs sell independently into my customers and I really don’t know what they’re shipping I have essentially no control over quality and portfolio overlaps and channel conflict and the overall customer experience. So I end up adding a layer of key account management and strategic consulting to help the enterprise customer navigate through the solutions catalog and the partner universe and to ensure a positive platform experience.
I’m Apple. I provide platforms for experiences. Let’s call them MacOS or iOS. I want to harness the creativity of the developer universe. I want to create an ecosystem of application developers to ensure that the long-tail of customer needs can be satisfied on my platform. But I care deeply about the overall end-user experience for my devices. So I build a storefront and a process for developers to offer applications to my customers. I sell and invoice these applications and I curate the catalog and I make sure that there is no garbage in there and no overlaps and I quality-control every single app that is submitted.
The good news for me: This makes my devices and platforms provide infinite value to my end-users, because, no matter how long-tail their needs are, there will be an app for that. And I take 30% off of the customer invoice and that is a significant additional revenue stream. Especially as that is is potentially long-term and ongoing and therefore nicely complementary to the one-time payment dynamics of the original device sale.
The good news for the partner: This gets them massive distribution.
The bad news for the partner: The platform capabilities are controlled by me and they completely depend on my whim. And I may take ages to quality-control their software update. And I may reject their software update. Sometimes a big price to pay.
The bad news for me: I have to define the framework and freeze it (agile this is not). And I have to actively curate and quality-control the contents of the app store. Because everything delivered via the app store is part of my end-user’s overall experience. About which I care so much.
I’m Google. Actually, I’m Android. I understand the benefits of the open source tooling and process and framework. And I’m not afraid to use that where it makes sense and I’m able manage a fair degree of complexity. But it’s worth it. So I pull in a Linux kernel via GPL as a base OS layer. Then my engineers build a whole bunch of stuff on top. Which I pay for and I own. Nicely separated so no GPL infection.
Then I transfer the whole thing to a foundation as open source under BSD. That is my reference implementation for device manufacturers. In parallel, I build the Android brand and establish that in the market. Device manufacturers who want to use that brand (and most do) have to license that from me. And in that license agreement they sign up for a whole bunch of terms of what they can and cannot do. Pretty neat. Some people (e.g. Fire OS) don’t sign that license agreement but then they can’t use my Android brand.
And inside my massive Android system there are a varying number of components that have varying qualities of open-source-ness. So there may be component where I just pull in something from outside. There may be a project out there that is important to me so I staff some of my one people into that project. Or I may just pay some people in a relevant open source project. And none of that is cast in stone, as these subsystems may come and go.
Also I ship some proprietary software on top of the open stack (e.g. Google Play Services), so the overall experience includes essential parts of software that I have not open sourced or licensed to anybody.
The good news for me: I get a lot of the OSS qualities, such as transparency, faster learning curve for partners, partners can send me PRs for stuff in my code base that should work but doesn’t, orchestrating some arms-length OSS project so that it lines up with my own stack, etc.
The good news for the partner: They can look inside the technology. They can fix stuff that they need fixed and keep maintaining the fork themselves (bad) or get me to accept their PRs (good).
The bad news for the partner: The system and the stack are never ever stable. Releases happen frequently. And they need to keep up.
The bad news for me: I have to provide the bulk of the engineering and of the processes and tools required to make such a massive yet pretty dynamic piece of software not break down. That is a lot of engineers and a lot of overhead.
And now, just to give it a try, I’m Elon Musk. Or some other maverick story-teller that can move whole markets with what is initially nothing more than hot air. So I don’t give a damn about the olden ways and the more I can break the better. What is all this talk about value chains and handovers and partner categories and business frameworks? Makes no sense to me. Time for First Principles Thinking, you know.
So I start imagining a worldwide community of software developers, all one big happy family, regardless of where they live and who they work for. And then I think of a value chain where the customer can pull in all the developers needed for their specific needs, including their own personnel (who usually have the real domain expertise), systems integrators for modeling and designing and deploying and supporting, special boutiques with business and/or technical skills, and ISVs with relevant product components that need to be licensed. And my own people, of course, since it will be a long time before my platform is so stable that critical customer projects can be executed without my participation.
And of course I am at the center of the universe, providing the technical framework in terms of platform products, as well as the process framework in terms of how to structure this value chain, as well as the business framework, defining the distribution of investment and return according to everybody’s respective value add.
By this time you probably start imagining a federation of Github-repositories, governed by some kind of modified MIT license. And you’re also imagining some kind of ICO currency that structures investment and rewards for all people and companies involved in the value chain, and the payment stream from the end customers providing the exchange mechanism for the virtual currency into real money.
Well, you’re thinking in the right direction. We’ll leave the rest as an exercise to the reader. If you’re Elon Musk, that is. Hi Elon.
Coming Back to Earth
So what does this all mean to us at Acme. Remember, we are a startup well underway to creating a new SaaS business application category and we are fundamentally committed to orchestrating a robust and scalable partner ecosystem. That has to be, first and foremost, truly agile in how it works internally and with customers. And where our tooling and technology may not be quite as mature and stable as we would like to be. But maybe it never will be stable and mature. Because then we’d lose agility.
Grabbing bits and pieces from the frameworks described above we might very well end up with something like this:
Our development process and tooling is all Github. Repositories and maintainers and contributors and reviewers and pull requests. The repositories will not be open, but customers and partners have access to our private repository and can read and lift code and fork away. Plus a really efficient and streamlined process for integrating, building, testing the overall system in sync with the release cycle. Both for our code and for any partner or customer code that may be integrated or dependent on our deliveries.
The license for the source code is a modified MIT license. It defines ownership and usage rights, defines what rights, if any, external partners have and who, if anybody, they can pass the code on to. And what rights, if any, people can claim if they build artifacts that are derivative of our code.
In those cases, and there will be many, where our product has missing pieces and capabilities that stand in the way of partner or customer success, this customer or partner may well decide to help out and contribute important code fragments just to fill the gaps and to speed things up. In most cases these developments will be submitted as PRs to us, because the external party will really not want to maintain their own fork, given our rapid release cycle.
If we accept the PR they become our property. Well, actually they were our property all along, because they are derivative works. This makes business sense as we have now also assumed responsibility for the ongoing maintenance and development of this code fragment. We do not have to accept the PR. But the rights the third party has to the fork are still highly restricted via the modified MIT license. These are derivative works after all.
From time to time we may, as an exception, provide some level of funding to the third party submitting PRs, subject to specific commercial agreements. As an exception, because the primary interest of the partner or customer was in filling the gaps, so they could go back to their original business case.
As the footprint of our technology grows in the market there may be an ongoing number of development projects that have potential for our wider customer community. These can be customer one-offs that turn out to be of wider interests or partner-led product investments.
In the case of customer one-offs, the likeliest scenario will be for the customer to transfer ownership of the code to us in exchange for ongoing maintenance and further development. We may, as an exception, provide some level of payment or revenue sharing on top of our assumption of the maintenance cost and responsibility, subject to specific commercial agreements. As an exception, because the TCO incurred for maintenance and support is typically a multiple of the original development investment, so the customer should be really happy if we decide to take over.
In case of partner-led product investments, the partner will likely stay involved in the maintenance and support of their product as it evolves. And we would want them to, as their products require their expertise.
This will have us replicating a lot of the “Apple App Store” mechanics, whereby we curate a storefront of certified partner solutions, let’s call them “apps”. The apps are proposed by partners, we decide what goes in the app store and what doesn’t, and our large customer will find a wonderful array of solutions to pick from and thus will find dramatically more value in their strategic commitment to our platform. From time to time we may also develop some apps ourselves and put them into the app store. Ditto for customer one-offs that they have transferred to us.
We may also replicate the quality-control mechanics of the Apple App store, as customers will see these apps as part of their overall Acme product experience and don’t want to worry about version control and incompatibilities. So partner apps listed in the app store all come together in our product packaging and we will build and test and integrate everything into one overall customer delivery.
This is independent of the invoicing chain. It might seem reasonable to not copy the Apple model and to allow the various ISVs to contract directly with the customer.
But then we would need to make sure we recover our cost for quality-controlling the partner app, via e.g. a program fee or a store-placement fee.
And we would also need to make sure that the relative value creation for the customer derives to a significant part from our platform capabilities. If our platform were to degrade into a lowly SDK then we would very much want to get a heavy margin on the apps sold in our app store.
The ISVs will also provide direct customer support for their apps to the customer. At best, our first-level support may route tickets to the respective ISV and provide a unified contact point to the enterprise customer.
Is that it?
What on earth is new here I hear you ask. Well, not very much. Which is exactly the point.
Remember our original baseline: How can we create a new category of enterprise software by orchestrating all relevant expertise, regardless of which company that expert works for. And make sure that everybody gets paid appropriately.
What we didn’t do is start from scratch and invent a new business model and prepare an ICO. Sorry, Elon.
Instead we took a whole bunch of stuff that the industry is very familiar with: Github repos and forks and pull requests and more-or-less-MIT-licenses and maintenance contracts and reassignment of commercial rights and curated app stores. Pretty complex, but look at Android. It can be done.