• Tech Book of the Month
  • Archive
  • Recommend a Book
  • Choose The Next Book
  • Sign Up
  • About
  • Search
Tech Book of the Month
  • Tech Book of the Month
  • Archive
  • Recommend a Book
  • Choose The Next Book
  • Sign Up
  • About
  • Search

May 2023 - Constellation Software Letters by Mark Leonard

We cover Canada’s biggest and quietest software company and their brilliant leader Mark Leonard.

Tech Themes

  1. Critics and Critiques. For a long time, Constellation heard the same critiques: Roll-ups never work, the businesses you are buying are old, the markets you are buying in are small, the delivery method of license/maintenance is phasing out. All of these are valid concerns. Constellation is a roll-up of many software businesses. Roll-ups, aka acquiring several businesses as the primary method of growth, do have tendency to blow up. The most frequent version for a blowup is leverage. Companies finance acquisitions with debt and eventually they make a couple of poor acquisition decisions and the debt load is too big, and they go bankrupt. A recent example of this is Thrashio, an Amazon third party sellers roll-up. RetailTouchPoints lays out the simple strategy: “Back in 2021, firms like Thrasio were able to buy these Amazon-based businesses for around 4X to 6X EBITDA and then turn that into a 15X to 25X valuation on the combined business.” However, demand for many of these products waned in the post-pandemic era, and Thrasio had too much debt to handle with the lower amount of sales. Bankruptcy isn’t all bad - several companies have emerged from bankruptcy with restructured debt, in a better position than before. To avoid the issue of leverage, Constellation has never taken on meaningful (> 1-2x EBITDA) leverage. This may change in the coming years, but for now it remains accurate. Concerns around market size and delivery method (SaaS vs. License/Maintenance) are also valid. Constellation has software businesses in very niche markets, like boating maintenance software that are inherently limited in size. They will never have a $1B revenue boat maintenance software business, the market just isn’t that big. However, the lack of enthusiasm over a small niche market tends to offer better business characteristics - fewer competitors, more likely adoption of de-facto technology, highly specialized software that is core to a business. Constellation’s insight to combine thousands of these niche markets was brilliant. Lastly, delivery methods have changed. Most customers now prefer to buy cloud software, where they can access technology through a browser on any device and benefit from continuous upgrades. Furthermore, SaaS businesses are subscriptions compared to license maintenance businesses where you pay a signficant sum for the license up-front and then a correspondingly smaller sum for maintenance. SaaS subscriptions tend to cost more over the long-term and have less volatile revenue spikes, but can be less profitable because of the need to continuously improve products and provide the service 24/7. Interestingly, Constellation continued to avoid SaaS even after it was the dominant method of buying software. From the 2014 letter: “The SaaS’y businesses also have higher organic growth rates in recurring revenues than do our traditional businesses. Unfortunately, our SaaS’y businesses have higher average attrition, lower profitability and require a far higher percentage of new name client acquisition per annum to maintain their revenues. We continue to buy and invest in SaaS businesses and products. We'll either learn to run them better, or they will prove to be less financially attractive than our traditional businesses - I expect the former, but suspect that the latter will also prove to be true.” While 2014 was certainly earlier in the cloud transformation, its not surprising that an organization built around the financial characteristics of license maintenance software struggled to make this transition. They are finally embarking on this journey, led their by their customers, and its causing license revenue to decline. License revenue has declined each of the last six quarters. The critiques are valid but Constellations assiduousness allowed them to side-step and even benefit from these critics as they scaled.

  2. Initiatives, Investing for Organic Growth, and Measurement. Although Leonard believes that organic growth is an important measure of success of a software company, he lays out in the Q1’07 letter the challenges of Constellation’s internal organic growth projects, dubbed Initiatives. “In 2003, we instituted a program to forecast and track many of the larger Initiatives that were embedded in our Core businesses (we define Initiatives as significant Research & Development and Sales and Marketing projects). Our Operating Groups responded by increasing the amount of investment that they categorized as Initiatives (e.g. a 3 fold increase in 2005, and almost another 50% increase during 2006). Initially, the associated Organic Revenue growth was strong. Several of the Initiatives became very successful. Others languished, and many of the worst Initiatives were terminated before they consumed significant amounts of capital.” The last sentence is the hardest one to stomach. Terminating initiatives before they had consumed lots of capital, is the smart thing to do. It is the rational thing to do. However, I believe this is at the heart of why Constellation has struggled with organic growth over time. Now I’ll be the first to admit that Constellation’s strategy has been incredible, and my criticism is in no way taking that away from them. Frankly, they won’t care what I say. But, as a very astute colleague pointed out to me, this position of measuring all internal R&D and S&M initiatives, is almost self-fulfilling. At the time Leonard wasn’t concerned with the potential for lack of internal investment and organic growth. He even remarked as so: “I’m not yet worried about our declining investment in Initiatives because I believe that it will be self-correcting. As we make fewer investments in new Initiatives, I’m confident that our remaining Initiatives will be the pick of the litter, and that they are likely to generate better returns. That will, in turn, encourage the Operating Groups to increase their investment in Initiatives. This cycle will take a while to play out, so I do not expect to see increased new Initiative investment for several quarters or even years.” By 2013, he had changed his tune: “Organic growth is, to my mind, the toughest management challenge in a software company, but potentially the most rewarding. The feedback cycle is very long, so experience and wisdom accrete at painfully slow rates. We tracked their progress every quarter, and pretty much every quarter the forecast IRR's eroded. Even the best Initiatives took more time and more investment than anticipated. As the data came in, two things happened at the business unit level: we started doing a better job of managing Initiatives, and our RDSM spending decreased. Some of the adaptations made were obvious: we worked hard to keep the early burn-rate of Initiatives down until we had a proof of concept and market acceptance, sometimes even getting clients to pay for the early development; we triaged Initiatives earlier if our key assumptions proved wrong; and we created dedicated Initiative Champion positions so an Initiative was less likely to drag on with a low but perpetual burn rate under a part-time leader who didn’t feel ultimately responsible. But the most surprising adaptation, was that the number of new Initiatives plummeted. By the time we stopped centrally collecting Initiative IRR data in Q4 2010, our RDSM spending as a percent of Net Revenue had hit an all-time low.” So how could the most calculating, strategic software company of maybe all time struggle to produce attractive organic growth prospects? I’d argue two things - 1) Incentives and 2) Rationality. First, on incentives, the Operating Group managers are compensated on ROIC and net revenue growth. If you are a BU manager and could invest in your business vs. buy another company that has declining organic growth but is priced appropriately (i.e. cheaply) requiring minimal capital outlay, you achieve both objectives by buying lower organic growers or even decliners. It is almost similar to buying ads to fill a hole in churned revenue. As long as you keep pressing the advertising button, you will keep gathering customers. But when you stop, it will be painful and growth will stall out. If I’m a BU manager buying meh software companies that achieve good ROIC and I’m growing revenues because of my acquisitions, it just means I need to keep finding more acquisitions to achieve my growth hurdles. Over time this is a challenge, but it may be multiple years before I have a bad acquisition growth year. Clearly, the incentives are not aligned for organic growth. Connected to the first point, the “buy growth for low cash outlays” strategy is perfectly rational based on the incentives. The key to its rationality is the known vs. the unknown. In buying a small, niche VMS business - way more is known about the range of outcomes. If you compare this to an organic growth initiative, it is clear why again, you choose the acquisition path. Organic growth investments are like venture capital. If sizeable, they can have an outsized impact on business potential. However, the returns are unknown. Simple probability illustrates that a 90% chance of a 20% ROIC and a 10% chance of a 10% ROIC, yields a 19% ROIC. I’d argue however, that with organic initiatives, particularly large, complex organic initiatives, there is an almost un-estimable return. If we use Amazon Web Services as perhaps the greatest organic growth initiative ever produced we can see why. Here is a reasonably capital-intensive business outside the core of Amazon’s online retailing applications. Sure, you can claim that they were already using AWS internally to run their operations, so the lift was not as strong. But it is still far afield from bookselling. AWS as an investment could never happen inside of Constellation (besides it being horizontal software). What manager is going to tank their ROIC via a capital-intensive initiative for several years to realize an astronomical gain down the line? What manager is going to send back to Constellation HQ, that they found a business that has the potential for $85B in revenue and $20B in operating profit 15 years out? You may say, “Vertical markets are small, they can’t produce large outcomes.” Constellation started after Veeva, a $30B public company, and Appfolio, a $7.5B company. The crux of the problem is that it is impossible to measure via a spreadsheet, the unknown and unknowable expected returns of the best organic growth initiatives. As Zeckhauser has discussed, the probabilities and associated gains/losses tend to be severely mispriced in these unknown and unknowable situations. Clayton Christensen identified this exact problem through his work on disruptive innovation. He urged companies to focus on ideas, failure, and learning, noting that strategic and financial planning must be discovery-based rather than execution based. Maybe there were great initiatives within Constellation that never got launched because incentives and rationality stopped them in their tracks. It’s not that you should burn the boats and put all your money into the hot new thing, it’s that product creation and organic growth are inherently risky ventures, and a certain amount of expected loss can be necessary to find the real money-makers.

  3. Larger deals. Leonard stopped writing annual letters, but broke the streak in 2021, when he penned a short note, outlining that the company would be pursuing more larger deals at lower IRRs and looking to develop a new circle of competence outside of VMS. I believe his words were chosen carefully to reflect Warren Buffett’s discussion of Circle of Competence and Thomas Watson Sr.’s (founder of IBM) quote: “I’m no genius. I’m smart in spots - but I stay around those spots.” While I appreciate the idea behind it, I’m less inclined to stay within my circle of competence. I’m young, curious, and foolish, and I think it would be a waste to pigeon-hole myself so early. After all, Warren had to learn about insurance, banking, beverages, etc and he didn’t let his not-knowing preclude him from studying. In justifying larger deals, Leonard cited Constellation’s scale and ability to invest more effectively than current shareholders. He also laid out the company’s edge: “Most of our competitors maximise financial leverage and flip their acquisitions within 3-7 years. CSI appreciates the nuances of the VMS sector. We allow tremendous autonomy to our business unit managers. We are permanent and supportive stakeholders in the businesses that we control, even if their ultimate objective is to eventually be a publicly listed company. CSI’s unique philosophy will not appeal to all sellers and management teams, but we hope it will resonate with some.” Since then Constellation has acquired Allscript’s hospital unit business in March 2022 for $700m in cash, completed a spin-merger of Lumine Group into larger company, WideOrbit, to create a publicly traded telecom advertising software provider, and is rumored to be looking at purchasing a subsidiary of Black Knight, which may have to be divested for its own transaction with ICE. These larger deals no doubt come with more complexity, but one large benefit is they sit within larger operating groups, and are shielded during what may be difficult transition periods for the businesses. It allows the businesses to operate more long-term and focus on providing value to end customers. As for deals outside of VMS, Mark Leonard commented on it during the 2022 earnings call: “I took a hard look at a thermal oil situation. I was looking at close to $1B investment, and it was tax advantaged. So it was a clever structure. It was a time when the sector could not get financing. And unfortunately, the oil prices ran away on me. So I was trying to be opportunistic in a sector that was incredibly beat up. So that is an example….So what are the characteristics there? Complexity. Where its a troubled situation with — circumstances and there’s a lot of complexity. I think we can compete better than the average investor, particularly when people are willing to take capital forever.” The remark on complexity reminded me of Baupost, the firm founded by legendary investor Seth Klarman, who famously bought claims on Lehman Brothers Europe following the 2008 bankruptcy. When you have hyper rational individuals, complexity is their friend.

Business Themes

types_of_motivation.jpg
  1. Decentralized Operating Groups. Its safe to say that Mark Leonard is a BIG believer in decentralized operating groups. Constellation believes in pushing as much decision making authority as possible to the leaders of the various business units. The company operates six operating groups: Volaris, Harris, Topicus (now public), Jonas, Perseus, and Vela. Leonard mentioned the organizational structure in the context of organic growth: “When most of our current Operating Group Managers ran single BU’s, they had strong organic growth businesses. As those managers gave up their original BU management position to oversee a larger Group of BU’s (i.e. became Portfolio Managers), the organic growth of their original BU’s decreased and the profitability of those BU’s increased.” As an example of this dynamic, we can look at Vencora, a Fintech subsidiary of Volaris. Vencora is managed by a portfolio manager, itself a collection of Business Units (BUs) with their own leadership. The Operating Group leaders and Portfolio Managers are incentivized based on growth and ROIC. Furthermore, Constellation mandates that at least 25% (for some executives its 75%) of incentive compensation must be used to purchase shares in the company, on the open market. These shares cannot be sold for three years. This incentive system accomplishes three goals: It keeps broad alignment toward the success of Constellation as a whole, it avoids stock dilution, and it creates a system where employees continuously own more and more of the business. Acquisitions above $20M in revenue must be approved by the head office, who is constantly receiving cash from different subsidiaries and allocating to the highest value opportunities. At varying times, the company has instituted “Keep your capital” initiatives, particularly for the Volaris and Vela operating groups. As Leonard points out in the 2015 letter: “One of the nice side effects of the “keep your capital” restriction, is that while it usually drives down ROIC, it generates higher growth, which is the other factor in the bonus formula. Acquisitions also tend to create an attractive increase in base salaries as the team ends up managing more people, capital, BUs, etc. Currently, a couple of our Operating Groups are generating very high returns without deploying much capital and we are getting to the point that we’ll ask them to keep their capital if they don’t close acceptable acquisitions or pursue acceptable Initiatives shortly.” Because bonuses are paid on ROIC, if an operating group manager sends back a ton of cash to corporate and doesn’t do a lot of new acquisitions, then its ROIC is very high and bonuses will be high. However, because Volaris and Vela are so large, it does not benefit the Head Office to continuously receive these large dividend payments and then pay high bonuses. Head Office will have a mountain of cash with out a lot of easy opportunities to deploy it. Thus the Keep your Capital initiative tamps down bonuses (by tamping down ROIC) and forces the leaders of these businesses to search out productive ways to deploy capital. As a result, more internal growth initiatives are likely to be funded, when acquisitions remain scarce, thereby increasing organic growth. It also pushes BUs and Portfolio Managers to seek out acquisitions to use up some of the capital. Overall, the organizational structure gives extreme authority to individuals and operates with large and strong incentives toward M&A and ROIC.

  2. Selling Constellation. We all know about the epic “what would have happened” deals. A few that come to mind, Oracle buying TikTok US, Microsoft buying Yahoo for $55B, Yahoo acquiring Facebook, Facebook acquiring Snapchat, AT&T acquiring T-Mobile for $39B, JetBlue/Spirt, Ryanair/Aer Lingus. There are tons. Would you believe that Constellation was up for sale at one point? On April 4th 2011, the Constellation board announced that it was considering alternatives for the company. The company was $630m of revenue and $116m of Adj. EBITDA, growing revenue 44% year over year. Today, Constellation is $8.4B of revenue, with $1.16B of FCFA2S, growing revenue at 27% year over year. At the time, Leonard lamented: “I’m proud of the company that our employees and shareholders have built, and will be more than a little sad if it is sold.” To me, this is a critically important non-event to investigate. It goes to show that any company can prematurely cap its compounding. Today, Constellation is perhaps the most revered software company with the most beloved, mysterious genius leader. Imagine if Constellation had been bought by Oracle or another large software company? Where would Mark Leonard be today? Would we have the behemoth that exists today? After the process was concluded with no sale, Leonard discussed the importance of managing one’s own stock price. “I used to maintain that if we concentrated on fundamentals, then our stock price would take care of itself. The events of the last year have forced me to re-think that contention. I'm coming around to the belief that if our stock price strays too far (either high or low) from intrinsic value, then the business may suffer: Too low, and we may end up with the barbarians at the gate; too high, and we may lose previously loyal shareholders and shareholder-employees to more attractive opportunities.” Many technology CEOs could learn from Leonard, preserving an optimistic tone when the company is struggling or the market is punishing the company, and a pessimistic tone when the company is massively over-achieving, like COVID.

  3. Metrics. Leonard loves thinking about and building custom metrics. As he stated in the Q4’2007 letter, “Our favorite single metric for measuring our corporate performance is the sum of ROIC and Organic Net Revenue Growth (“ROIC+OGr”).” However, he is constantly tinkering and thinking about the best and most interesting measures. He generally focuses on three types of metrics: growth, profitability, and returns. For growth, his preferred measure is organic growth. He also believes net maintenance growth is correlated with the value of the business. “We believe that Net Maintenance Revenue is one of the best indicators of the intrinsic value of a software company and that the operating profitability of a low growth software business should correlate tightly to Net Maintenance Revenues.” I believe this correlation is driven by maintenance revenue’s high profitability and association with high EBITA levels (Operating income + amortization from intangibles). For profitability metrics, Leonard for a long time preferred Adj. Net Income (ANI) or EBITA. “ One of the areas where generally accepted accounting principles (“GAAP”) do a poor job of reflecting economic reality, is with goodwill and intangibles accounting. As managers we are at least partly to blame in that we tend to ignore these “expenses”, focusing on EBITA or EBITDA or “Adjusted” Net Income (which excludes Amortisation). The implicit assumption when you ignore Amortisation, is that the economic life of the asset is perpetual. In many instances (for our business) that assumption is correct.” He floated the idea of using free cash flow per share, but it suffers from volatility depending on working capital payments and doesn’t adjust for minority interest payments. Adj. Net Income does both of these things but doesn’t capture the actual cash into the business. In Q3’2019, Leonard adopted a new metric called Free Cash Flow Available to Shareholders (FCFA2S): “We calculate FCFA2S by taking net cash flow from operating activities per IFRS, subtracting the amounts that we spend on fixed assets and on servicing the capital we have sourced from other stakeholders (e.g. debt providers, lease providers, minority shareholders), and then adding interest and dividends earned on investments. The remaining FCFA2S is the uncommitted cashflow available to CSI's shareholders if we made no further acquisitions, nor repaid our other capital-providing stakeholders.” FCFA2S achieves a few happy mediums: 1) Similar to ANI, it is net of the cost of servicing capital (interest, dividends, lease payments) 2) It captures changes in working capital, while ANI does not 3) It reflects cash taxes as opposed to current taxes deducted from pre-tax income (this gets at a much more confusing discussion on deferred tax assets and the difference between book taxes and cash taxes) 4) When comparing FCFA2S to CFO, it tends to be closer than comparing ANI to reported net income. For return metrics, Leonard prefers ROIC (ANI/Average Invested Capital). In the 2015 letter, he laid out the challenge of this metric. First, ROIC can be infinity if a company grows large while reducing its working capital (common in software), effectively lowering the purchase price to zero. Infinity ROIC is a problem because bonuses are paid on ROIC. He contrasts ROIC with IRR but notes its drawbacks, that IRR does not indicate the hold period nor size of the investments. As is said at investing firms, “You can’t eat IRR.” In the 2017 letter, he discussed Incremental return on incremental invested capital ((ANI1 - ANI0)/(IC1-ICo)), but noted its volatility and challenge with handling share issuances / repurchases. Share issuances would increase IC, without an increase in ANI. When discussing high performance conglomerates (HPCs), he discusses EBITA Return (EBITA/Average Total Capital). He notes that: “ROIC is the return on the shareholders’ investment and EBITA Return is the return on all capital. In the former, financial leverage plays a role. In the latter only the operating efficiency with which all net assets are used is reflected, irrespective of whether those assets are financed with debt or shareholders’ investment.” This is similar to P/E vs. EV/EBITDA multiples, where P/E multiples should be used to value market capitalization (i.e. Price) while EV/EBITDA should be used to value the entirety of the business as it relates to debt and equityholders. Mark Leonard is a man of metrics, we will keep watching to see what he comes up with next! In this spirit, I will try to offer a metric for fast-growing software companies, where ROIC is effectively meaningless because negative working capital dynamics in software produce negative invested capital. Furthermore, faster growing companies generally spend ahead of growth and lose money so ANI, FCF, EBITA are all lower than they should be. If you believe the value of these businesses is closely related to revenue, you could use S&M efficiency, or net new ARR / S&M spend. While a helpful measure, many companies don’t disclose ARR. Furthermore, this doesn’t incorporate perhaps the most expensive investing cost, developing products. It also does not incorporate gross margins, which can vary between 50-90% for software companies. One metric you could use is incremental gross margin / (incremental S&M, R&D costs). Here the challenge would be the years it takes to develop products and GTM distribution. To get around this, you could use a cumulative number for R&D/S&M costs. You could also use future gross margin dollars and offset them, similar to the magic number. So our metric is 3 year + incremental gross margin / cumulative S&M and R&D costs. Not a great metric but it can’t hurt to try!

    Dig Deeper

  • Mark Leonard on the Harris Computer Group Podcast (2020)

  • Constellation Software Inc. -Annual General Meeting 2023

  • Mark Leonard: The Best Capital Allocator You’ve Never Heard Of

  • The Moments That Made Mark Miller

  • Topicus: Constellation Software 2.0

tags: Mark Leonard, Constellation Software, CSI, CSU, Harris, Topicus, Lumine, AppFolio, Thrasio, ROIC, FCF, EBITA, Mark Miller, Harris Computer, Volaris, SaaS, AWS, Zeckhauser, Clayton Christensen, IBM, Black Knight, ICE, Seth Klarman, Lehman, Jonas, Perseus, Vela, Vencora, FCFA2S, AT&T, T-Mobile
categories: Non-Fiction
 

October 2020 - Working in Public: The Making and Maintenance of Open Source Software by Nadia Eghbal

This month we covered Nadia Eghbal’s instant classic about open-source software. Open-source software has been around since the late seventies but only recently it has gained significant public and business attention.

Tech Themes

The four types of open source communities described in Working in Public

The four types of open source communities described in Working in Public

  1. Misunderstood Communities. Open source is frequently viewed as an overwhelmingly positive force for good - taking software and making it free for everyone to use. Many think of open source as community-driven, where everyone participates and contributes to making the software better. The theory is that so many eyeballs and contributors to the software improves security, improves reliability, and increases distribution. In reality, open-source communities take the shape of the “90-9-1” rule and act more like social media than you could think. According to Wikipedia, the "90–9–1” rule states that for websites where users can both create and edit content, 1% of people create content, 9% edit or modify that content, and 90% view the content without contributing. To show how this applies to open source communities, Eghbal cites a study by North Carolina State Researchers: “One study found that in more than 85% of open source projects the research examined on Github, less than 5% of developers were responsible for 95% of code and social interactions.” These creators, contributors, and maintainers are developer influencers: “Each of these developers commands a large audience of people who follow them personally; they have the attention of thousands of developers.” Unlike Instagram and Twitch influencers, who often actively try to build their audiences, open-source developer influencers sometimes find the attention off-putting - they simply published something to help others and suddenly found themselves with actual influence. The challenging truth of open source is that core contributors and maintainers give significant amounts of their time and attention to their communities - often spending hours at a time responding to pull requests (requests for changes / new features) on Github. Evan Czaplicki’s insightful talk entitled “The Hard Parts of Open Source,” speaks to this challenging dynamic. Evan created the open-source project, Elm, a functional programming language that compiles Javascript, because he wanted to make functional programming more accessible to developers. As one of its core maintainers, he has repeatedly been hit with requests of “Why don’t you just…” from non-contributing developers angrily asking why a feature wasn’t included in the latest release. As fastlane creator, Felix Krause put it, “The bigger your project becomes, the harder it is to keep the innovation you had in the beginning of your project. Suddenly you have to consider hundreds of different use cases…Once you pass a few thousand active users, you’ll notice that helping your users takes more time than actually working on your project. People submit all kinds of issues, most of them aren’t actually issues, but feature requests or questions.” When you use open-source software, remember who is contributing and maintaining it - and the days and years poured into the project for the sole goal of increasing its utility for the masses.

  2. Git it? Git was created by Linus Torvalds in 2005. We talked about Torvalds last month, who also created the most famous open-source operating system, Linux. Git was born in response to a skirmish with Larry McAvoy, the head of proprietary tool BitKeeper, over the potential misuse of his product. Torvalds went on vacation for a week and hammered out the most dominant version control system today - git. Version control systems allow developers to work simultaneously on projects, committing any changes to a centralized branch of code. It also allows for any changes to be rolled back to earlier versions which can be enormously helpful if a bug is found in the main branch. Git ushered in a new wave of version control, but the open-source version was somewhat difficult to use for the untrained developer. Enter Github and GitLab - two companies built around the idea of making the git version control system easier for developers to use. Github came first, in 2007, offering a platform to host and share projects. The Github platform was free, but not open source - developers couldn’t build onto their hosting platform - only use it. GitLab started in 2014 to offer an alternative, fully-open sourced platform that allowed individuals to self-host a Github-like tracking program, providing improved security and control. Because of Github’s first mover advantage, however, it has become the dominant platform upon which developers build: “Github is still by far the dominant market player: while it’s hard to find public numbers on GitLab’s adoption, its website claims more than 100,000 organizations use its product, whereas GitHub claims more than 2.9 million organizations.” Developers find GitHub incredibly easy to use, creating an enormous wave of open source projects and code-sharing. The company added 10 million new users in 2019 alone - bringing the total to over 40 million worldwide. This growth prompted Microsoft to buy GitHub in 2018 for $7.5B. We are in the early stages of this development explosion, and it will be interesting to see how increased code accessibility changes the world over the next ten years.

  3. Developing and Maintaining an Ecosystem Forever. Open source communities are unique and complex - with different user and contributor dynamics. Eghbal tries to segment the different types of open source communities into four buckets - federations, clubs, stadiums, and toys - characterized below in the two by two matrix - based on contributor growth and user growth. Federations are the pinnacle of open source software development - many contributors and many users, creating a vibrant ecosystem of innovative development. Clubs represent more niche and focused communities, including vertical-specific tools like astronomy package, Astropy. Stadiums are highly centralized but large communities - this typically means only a few contributors but a significant user base. It is up to these core contributors to lead the ecosystem as opposed to decentralized federations that have so many contributors they can go in all directions. Lastly, there are toys, which have low user growth and low contributor growth but may actually be very useful projects. Interestingly, projects can shift in and out of these community types as they become more or less relevant. For example, developers from Yahoo open-sourced their Hadoop project based on Google’s File System and Map Reduce papers. The initial project slowly became huge, moving from a stadium to a federation, and formed subprojects around it, like Apache Spark. What’s interesting, is that projects mature and change, and code can remain in production for a number of years after the project’s day in the spotlight is gone. According to Eghbal, “Some of the oldest code ever written is still running in production today. Fortran, which was first developed in 1957 at IBM, is still widely used in aerospace, weather forecasting, and other computational industries.” These ecosystems can exist forever, but the costs of these ecosystems (creation, distribution, and maintenance) are often hidden, especially the maintenance aspect. The cost of creation and distribution has dropped significantly in the past ten years - with many of the world’s developers all working in the same ecosystem on GitHub - but it has also increased the total cost of maintenance, and that maintenance cost can be significant. Bootstrap co-creator Jacob Thornton likens maintenance costs to caring for an old dog: “I’ve created endlessly more and more projects that have now turned [from puppies] into dogs. Almost every project I release will get 2,000, 3,000 watchers, which is enough to have this guilt, which is essentially like ‘I need to maintain this, I need to take care of this dog.” Communities change from toys to clubs to stadiums to federations but they may also change back as new tools are developed. Old projects still need to be maintained and that code and maintenance comes down to committed developers.

Business Themes

1_c7udbm7fJtdkZEE6tl1mWQ.png
  1. Revenue Model Matching. One of the earliest code-hosting platforms was SourceForge, a company founded in 1999. The Company pioneered the idea of code-hosting - letting developers publish their code for easy download. It became famous for letting open-source developers use the platform free of charge. SourceForge was created by VA Software, an internet bubble darling that saw its stock price decimated when the bubble finally burst. The challenge with scaling SourceForge was a revenue model mismatch - VA Software made money with paid advertising, which allowed it to offer its tools to developers for free, but meant its revenue model was highly variable. When the company went public, it was still a small and unproven business, posting $17M in revenue and $31M in costs. The revenue model mismatch is starting to rear its head again, with traditional software as a service (SaaS) recurring subscription models catching some heat. Many cloud service and API companies are pricing by usage rather than a fixed, high margin subscription fee. This is the classic electric utility model - you only pay for what you use. Snowflake CEO Frank Slootman (who formerly ran SaaS pioneer ServiceNow) commented: “I also did not like SaaS that much as a business model, felt it not equitable for customers.” Snowflake instead charges based on credits which pay for usage. The issue with usage-based billing has traditionally been price transparency, which can be obfuscated with customer credit systems and incalculable pricing, like Amazon Web Services. This revenue model mismatch was just one problem for SourceForge. As git became the dominant version control system, SourceForge was reluctant to support it - opting for its traditional tools instead. Pricing norms change, and new technology comes out every day, it’s imperative that businesses have a strong grasp of the value they provide to their customers and align their revenue model with customers, so a fair trade-off is created.

  2. Open Core Model. There has been enormous growth in open source businesses in the past few years, which typically operate on an open core model. The open core model means the Company offers a free, normally feature limited, version of its software and also a proprietary, enterprise version with additional features. Developers might adopt the free version but hit usage limits or feature constraints, causing them to purchase the paid version. The open-source “core” is often just that - freely available for anyone to download and modify; the core's actual source code is normally published on GitHub, and developers can fork the project or do whatever they wish with that open core. The commercial product is normally closed source and not available for modification, providing the business a product. Joseph Jacks, who runs Open Source Software (OSS) Capital, an investment firm focused on open source, displays four types of open core business model (pictured above). The business models differ based on how much of the software is open source. Github, interestingly, employs the “thick” model of being mostly proprietary, with only 10% of its software truly open-sourced. Its funny that the site that hosts and facilitates the most open source development is proprietary. Jacks nails the most important question in the open core model: “How much stays open vs. How much stays closed?” The consequences can be dire to a business - open source too much and all of a sudden other companies can quickly recreate your tool. Many DevOps tools have experienced the perils of open source, with some companies losing control of the project it was supposed to facilitate. On the flip side, keeping more of the software closed source goes against the open-source ethos, which can be viewed as organizations selling out. The continuous delivery pipeline project Jenkins has struggled to satiate its growing user base, leading to the CEO of the Jenkins company, CloudBees, posting the blog post entitled, “Shifting Gears”: “But at the same time, the incremental, autonomous nature of our community made us demonstrably unable to solve certain kinds of problems. And after 10+ years, these unsolved problems are getting more pronounced, and they are taking a toll — segments of users correctly feel that the community doesn’t get them, because we have shown an inability to address some of their greatest difficulties in using Jenkins. And I know some of those problems, such as service instability, matter to all of us.” Striking this balance is incredibly tough, especially in a world of competing projects and finite development time and money in a commercial setting. Furthermore, large companies like AWS are taking open core tools like Elastic and MongoDB and recreating them in proprietary fashions (Elasticsearch Service and DocumentDB) prompting company CEO’s to appropriately lash out. Commercializing open source software is a never-ending battle against proprietary players and yourself.

  3. Compensation for Open Source. Eghabl characterizes two types of funders of open-source - institutions (companies, governments, universities) and individuals (usually developers who are direct users). Companies like to fund improved code quality, influence, and access to core projects. The largest groups of contributors to open source projects are mainly corporations like Microsoft, Google, Red Hat, IBM, and Intel. These corporations are big enough and profitable enough to hire individuals and allow them to strike a comfortable balance between time spent on commercial software and time spent on open source. This also functions as a marketing expense for the big corporations; big companies like having influencer developers on payroll to get the company’s name out into the ecosystem. Evan You, who authored Vue.js, a javascript framework described company backed open-source projects: “The thing about company-backed open-source projects is that in a lot of cases… they want to make it sort of an open standard for a certain industry, or sometimes they simply open-source it to serve as some sort of publicity improvement to help with recruiting… If this project no longer serves that purpose, then most companies will probably just cut it, or (in other terms) just give it to the community and let the community drive it.” In contrast to company-funded projects, developer-funded projects are often donation based. With the rise of online tools for encouraging payments like Stripe and Patreon, more and more funding is being directed to individual open source developers. Unfortunately though, it is still hard for many open source developers to pursue open source on individual contributions, especially if they work on multiple projects at the same time. Open source developer Sindre Sorhus explains: “It’s a lot harder to attract company sponsors when you maintain a lot of projects of varying sizes instead of just one large popular project like Babel, even if many of those projects are the backbone of the Node.js ecosystem.” Whether working in a company or as an individual developer, building and maintaining open source software takes significant time and effort and rarely leads to significant monetary compensation.

Dig Deeper

  • List of Commercial Open Source Software Businesses by OSS Capital

  • How to Build an Open Source Business by Peter Levine (General Partner at Andreessen Horowitz)

  • The Mind Behind Linux (a talk by Linus Torvalds)

  • What is open source - a blog post by Red Hat

  • Why Open Source is Hard by PHP Developer Jose Diaz Gonzalez

  • The Complicated Economy of Open Source

tags: Github, Gitlab, Google, Twitch, Instagram, E;, Elm, Javascript, Open Source, Git, Linus Torvalds, Linux, Microsoft, MapReduce, IBM, Fortran, Node, Vue, SourceForge, VA Software, Snowflake, Frank Slootman, ServiceNow, SaaS, AWS, DevOps, CloudBees, Jenkins, Intel, Red Hat, batch2
categories: Non-Fiction
 

February 2019 - Cloud: Seven Clear Business Models by Timothy Chou

While this book is relatively old for internet standards, it illuminates the early transition to SaaS (Software as a Service) from traditional software license and maintenance models. Timothy Chou, current Head of IoT at the Alchemist Accelerator, former Head of On Demand Applications at Oracle, and a lecturer at Stanford, details seven different business models for selling software and the pros/cons of each.

Tech Themes

  1. The rise of SaaS. Software-as-a-Service (SaaS) is an application that can be accessed through a web browser and is managed and hosted by a third-party (likely a public cloud - Google, Microsoft, or AWS). Let’s flash back to the 90’s, a time when software was sold in shrink-wrapped boxes as perpetual licenses. What this meant was you owned whatever version of the software you purchased, in perpetuity. Most of the time you would pay a maintenance cost (normally 20% of the overall license value) to receive basic upkeep services to the software and get minor bugs fixed. However, when the new version 2.0 came out, you would have to pay another big license fee, re-install the software and go through the hassle of upgrading all existing systems. On the backs of increased internet adoption, SaaS allowed companies to deliver a standard product, over the internet, typically at lower price point to end users. This meant smaller companies like salesforce (at the time) could compete with giants like Siebel Systems (acquired by Oracle for $5.85Bn in 2005) because companies could now purchase the software in an on-demand, by-user fashion without going to the store, at a much lower price point.

  2. How cloud empowers SaaS. As an extension, standardization of product means you can aptly define the necessary computing resources - thereby also standardizing your costs. At the same time that SaaS was gaining momentum, the three mega public cloud players emerged, starting with Amazon (in 2006), then Google and eventually Microsoft. This allowed companies to host software in the cloud and not on their own servers (infrastructure that was hard to manage internally). So instead of racking (pun intended) up costs with an internal infrastructure team managing complex hardware - you could offload your workloads to the cloud. Infrastructure as a service (IaaS) was born. Because SaaS is delivered over the internet at lower prices, the cloud became an integral part of scaling SaaS businesses. As the number of users grew on your SaaS platform, you simply purchased more computing space on the cloud to handle those additional users. Instead of spending big amounts of money on complex infrastructural costs/decisions, a company could now focus entirely on its product and go-to-market strategy, enabling it to reach scale much more quickly.

  3. The titans of enterprise software. Software has absolutely changed in the last 20 years and will likely continue to evolve as more specialized products and services become available. That being said, the perennial software acquirers will continue to be perennial software acquirers. At the beginning of his book, Chou highlights fifteen companies that had gone public since 1999: Concur (IPO: 1999, acquired by SAP for $8.3B in 2014), Webex (IPO: 2002, acquired by Cisco in for $3.2B in 2007), Kintera (IPO: 2003, acquired by Blackbaud for $46M in 2008), Salesforce.com (IPO: 2004), RightNow Technologies (IPO: 2004, acquired by Oracle for $1.5B in 2011), Websidestory (IPO: 2004, acquired by Omniture in 2008 for $394M), Kenexa (IPO: 2005, acquired by IBM for $1.3B in 2012), Taleo (IPO: 2005, acquired for $1.9B by Oracle in 2012), DealerTrack (IPO 2005, acquired by Cox Automotive in 2015 for $4.0B), Vocus (IPO: 2005, acquired by GTCR in 2014 for $446M), Omniture (IPO: 2006, acquired by Adobe for $1.8B in 2009), Constant Contact (IPO: 2007, acquired by Endurance International for $1B in 2015), SuccessFactors (IPO: 2007, acquired by SAP for $3.4B in 2011), NetSuite (IPO 2007: acquired by Oracle for $9.3B in 2016) and Opentable (IPO: 2009, acquired by Priceline for $2.6B in 2015). Oracle, IBM, Cisco and SAP have been some of the most active serial acquirers in tech history and this trend is only continuing. Interestingly enough, Salesforce.com is now in a similar position. What it shows is that if you can come to dominate a horizontal application - CRM (salesforce), ERP (SAP/Oracle), or Infrastructure (Google/Amazon/Microsoft) you can build a massive moat that allows you to become the serial acquirer in that space. You then have first and highest dibs at every target in your industry because you can underwrite an acquisition to the highest strategic multiple. Look for these acquirers to continue to make big deals when it can further lock in their market dominant position especially when you see their core business slow.

    Business Themes

Here we see the “Cash Gap” in the subscription model - customer acquisition expenses are incurred upfront but are recouped over time.

Here we see the “Cash Gap” in the subscription model - customer acquisition expenses are incurred upfront but are recouped over time.

  1. The misaligned incentives of traditional license/maintenance model. Software was traditionally sold as perpetual licenses, where a user could access that version of the software forever. Because users were paying to use something forever, the typical price point was very high for any given enterprise software license. This meant that large software upgrades were made at the the most senior levels of management and were large investments from a dollars and time perspective. On top of that initial license came the 20% support costs paid annually to receive patch updates. At the software vendor, this structure created interesting incentives. First, product updates were usually focused on break-fix and not new, “game-changing” upgrades because supporting multiple, separate versions of the software (especially, pre-IaaS) was incredibly costly. This slowed the pace of innovation at those large software providers (turning them into serial acquirers). Second, the sales team became focused on selling customers on new releases directly after they signed the initial deal. This happened because once you made that initial purchase, you owned that version forever; what better way to get more money off of you than introduce a new feature and re-sell you the whole system again. Salespeople were also incredibly focused on closing deals in a certain quarter because any single deal could make or break not only their quarterly sales quota, but also the Company’s revenue targets. If one big deal slipped from Q4 to Q1 the following year, a Company may have to report lower growth numbers to the stock market driving the stock price down. Third, once you made the initial purchase, the software vendor would direct all problems and product inquiries to customer support who were typically overburdened by requests. Additionally, the maintenance/support costs were built into the initial contract so you may end up contractually obligated to pay for support for a product that you don’t like and cannot change. The Company viewed it as: “You’ve already purchased the software, so why should I waste time ensuring you have a great experience with it - unless you are looking to buy the next version, I’m going to spend my time selling to new leads.” These incentives limited product changes/upgrades, focused salespeople completely on new leads, and hurt customer experience, all at the benefit of the Company over the user.

  2. What are CAC and LTV? CAC or customer acquisition costs are key to understand for any type of software business. As HubSpot and distinguished SaaS investor, David Skok notes, its typically measured as, “the entire cost of sales and marketing over a given period, including salaries and other headcount related expenses, and divide it by the number of customers that you acquired in that period.” Once the software sales model shifted from license/maintenance to SaaS, instead of hard-to-predict, big new license sales, companies started to receive monthly recurring payments. Enterprise software contracts are typically year-long, which means that once a customer signs the Company will know exactly how much revenue it should plan to receive over the coming year. Furthermore, with recurring subscriptions, as long as the customer was happy, the Company could be reasonably assured that customer would renew. This idea led to the concept of Lifetime Value of a customer or LTV. LTV is the total amount of revenue a customer will pay the Company until it churns or cancels the subscription. The logic followed that if you could acquire a customer (CAC) for less than the lifetime value of the customer (LTV), over time you would make money on that individual customer. Typically, investors view a 3:1 LTV to CAC ratio as viable for a healthy SaaS company.

Dig Deeper

  • Bill Gates 1995 memo on the state of early internet competition: The Internet Tidal Wave

  • Andy Jassey on how Amazon Web Services got started

  • Why CAC can be a Startup Killer?

  • How CAC is different for different types of software

  • Basic SaaS Economics by David Skok

tags: Cloud Computing, SaaS, License, Maintenance, Business Models, software, Salesforce, SAP, Oracle, Cisco, IaaS, batch2
categories: Non-Fiction
 

About Contact Us | Recommend a Book Disclaimer