Crafting an Open Source Product Strategy
•Télécharger en tant que PPTX, PDF•
1 j'aime•383 vues
Presentation delivered at the 2019 Open Source Strategy Forum, New York, November 2019
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (14)
Similaire à Crafting an Open Source Product Strategy
Similaire à Crafting an Open Source Product Strategy (20)
Plus de Dave Neary
Plus de Dave Neary (20)
Dernier
Dernier (20)
Crafting an Open Source Product Strategy
- 1. Crafting an Open Source Product Strategy Building a business case around open source software Dave Neary Open Source Program Office Red Hat dneary@redhat.com
- 2. RED HAT IS AN OPEN SOURCE COMPANY We build Enterprise products from Open Source projects
- 3. We should open source XWidget Why? Because… we want a community Why? Because… community is good!
- 4. What is your goal? Finding the “why”
- 5. Open Source is not a business model! Open Source is: ● A way of developing software collaboratively ● A means to reduce development cost by reusing other open source code ● A distribution mechanism that lowers cost of acquisition
- 6. Development model ● Enables collaboration with others ● Leverage talent beyond company walls, and educates potential workforce ● Lowers cost of engaging with potential partners
- 7. Distribution model ● “Free” minimizes barrier to adoption ● Allows small start-ups to “punch above their weight”
- 8. The Economics of Open Source 3 basic microeconomic principles, and how they apply to open source business models
- 9. Economics 101: Demand Curve ● As price goes down, demand increases (for most goods) ● Price includes money, time, skills, ...
- 10. Economics 101: Substitute goods ● As price of a good goes down, demand for its substitutes goes down ● Open source can be used as a competitive weapon against expensive alternatives ● Incumbents can be slow to adapt - Innovator’s Dilemma applies
- 11. Economics 101: Complementary goods ● As price for a good drops, demand for its complements goes up ● Open source business models depend on finding compelling complements
- 12. Strategic motivations to open source Understanding what you want to achieve
- 13. Strategic goals ● Increase sales of complements ○ Services, consulting ○ Other products (hardware, software, certified 3rd party software) ○ Subscriptions, ongoing support ○ Exchanging time for money (integrated solutions) ● Leverage wide adoption for adjacent goal ○ Encouraging adoption of standard ○ Drive market towards an ecosystem ○ Facilitate ecosystem engagement ○ Shared undifferentiated heavy lifting
- 14. Strategic goals (2) ● Adjacent market development ○ Seed new market segment/market education ○ “Paradigm shift” - change practices ○ Portfolio adoption - “foot in the door”
- 15. Example: Android ● Mobile operating system released as open source by Google ● Displace incumbent (Symbian) in new market (smartphone OS) ● Lower cost of ecosystem partner recruitment (hardware partners) ● Leverage large market presence for adjacent goals (advertising, application ecosystem, user data)
- 16. Example: Wordpress ● Open source blogging platform first released in 2003 ● Grow adoption in crowded market space (blogging) by reducing cost of adoption (easy installation, management, license clarity) ● Leverage adoption to grow ecosystem (extensions) ● Monetize by saving less technical users time with hosted offering (Wordpress.com)
- 17. Example: React.js ● Internally developed Javascript framework released as open source by Facebook ● Lowers cost of hiring front-end developers for Facebook applications
- 18. Defining and communicating strategy
- 19. Stakeholder identification ● Constituencies include engineering, product management, sales, support, legal, brand, security teams, … ● Identify at least one key representative from each constituency ● Growing concentric circles
- 20. “Surprise is the opposite of engagement” John Lilly, former CEO of Mozilla
- 21. Understand the Big Picture ● Start broad, work in ○ Organization ○ Product/market segment ○ Project ● Map the space ○ Competitors ○ Partners ○ Dependencies
- 22. Target audience ● Who will download and use the project? ● Who will buy the product? ● What problems do they have? ● Who do these people listen to?
- 23. Tailor a symbiotic relationship ● More precisely: mutualist ● Identify how project success feeds product success, and vice versa ● Example: “Project creates popular extension platform, and company then enters into commercial relationship with extension authors to add value to product”
- 24. Understanding and communicating strategy ● Strategy should be expressed in one sentence, explained in one page ○ Example: “RDO will dramatically grow the number of OpenStack users on the Red Hat family of operating systems, showcase Red Hat’s work in OpenStack, and create a center of gravity for OpenStack users on CentOS” ● Create a mantra ○ Example: “Demonstrating the value of a Cloud Management Platform” (ManageIQ) ● The strategy should affect action - trade-offs, budgeting decisions, feature roadmap
- 25. THANK YOU plus.google.com/+RedHat linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHatNews Copyright © 2019 Red Hat Inc.
- 26. Bonus material Mapping strategy to action, tracking progress Copyright © 2019 Red Hat Inc.
- 27. Mapping strategy to action Achieving objectives and tracking progress Copyright © 2019 Red Hat Inc.
- 28. Mapping the user journey ● Target audience ● First contact, adoption ● Engagement ● Retention This is identical to a sales funnel Copyright © 2019 Red Hat Inc.
- 29. New user experience is critical ● First time experience ○ 15 minutes to “Hello, World!” ○ Prerequisites (knowledge, hardware, software) ● New user documentation, learning paths ● Troubleshooting experience Copyright © 2019 Red Hat Inc.
- 30. Defining goals Copyright © 2019 Red Hat Inc.
- 31. Be careful what you measure Copyright © 2019 Red Hat Inc.
- 32. Pivot in changing circumstances ● Circumstances change, your strategy should be able to change too ● Unintended consequences can be threats or opportunities ● Annual gut-check, executive review Copyright © 2019 Red Hat Inc.
- 33. In summary 1. Identify key stakeholders 2. Find your “why” 3. Measure progress towards success 4. Be prepared to adapt Copyright © 2019 Red Hat Inc.
Notes de l'éditeur
- My name is Dave Neary, and today I will try to explain how to come up with, and execute on, a product strategy around an open source project.
- The first conversation around open sourcing typically goes like this. Perhaps when you ask “Why do you want to open source X?” the answer is “Because we’re Red Hat, and that’s what we do” - which is a fine answer, and it is also true, but it is insufficient in terms of understanding what you want to achieve from open sourcing. When you did deeper, often times “open source the thing” is a check-box on an engineering roadmap, it’s seen as a task rather than a process, and there really is not a clear understanding how an open source project can benefit your company’s goals.
- The creation of an open source strategy is about finding that benefit. In short, you want to understand why open sourcing this project will benefit the company. Take a second to think of a successful open source project you are aware of - why do you think the original author released the project as open source? Why did the project become successful?
- The first point I’d like to make is that “open source” itself is not a business strategy or a product strategy. When I refer to “open source business models” or “open source product strategy”, really what I’m talking about is business models or product strategies based on open source software. A lot of the same work you do for a commercial product also has to be done for open source projects - with the added difficulty that some of the business models enabled by proprietary software are not available to you. Open source is not a business model. Fundamentally, it is two things: a way to develop software collaboratively, and a way to increase the distribution and reach of your project by lowering the cost of acquisition.
- Open source is fundamentally a way to develop software. By releasing code as open source, you enable your users to participate in the project’s development. As such, it can be an excellent way to foster collaboration with ecosystem partners and produce software that fits user requirements. This can allow you to lower the cost of acquiring new ecosystem partners, by separating the technical enablement conversation from the sales and market enablement conversation. It can also allow you to have a very high quality relationship with customers, by removing organizational gatekeepers between customer and supplier, resulting in a much higher quality relationship with users of the software.
- It is also a way to lower the cost of acquisition of the software, and as a result, it can enable wider distribution of the software, with a resulting amplification of mindshare for the project. This characteristic of open source is what allows small, 50 person start-ups to become world famous and “punch above their weight” as market disruptors compared to more established competitors. Can anyone give me an example of an open source project which has enabled a small start-up to have a big impact in the industry? (spend 2 minutes gathering examples, to show that (say) MySQL can compete with Oracle, or that Wikimedia can run a world top 10 website with 430 staff)
- To explain the product strategies that make sense for open source, I’m going to develop a little bit on this, with the help of 3 very basic microeconomic principles. These 3 principles are fundamental to every open source business model. If you have ever studied economics, these will be familiar to you already.
- The first principle is the basic demand curve. All else being equal, for most goods, when you reduce the price, you will see an increase in demand. This isn’t universally true, and the change in demand will be different for different goods, but as a general principle, it holds up pretty well. In the case of open source, this is just a restatement of the distribution principle I mentioned earlier - by lowering the cost of acquisition, we maximise demand and thus maximise adoption of the project. It is worth noting that “cost” in an economic sense is not just the monetary cost of buying something, it also includes the time and effort you put into learning it, the time it takes to install, any prerequisites you might not have like hardware or skills. This will be important to remember later.
- The second principle is related to substitute goods. Substitutes are good that you can use instead of each other. They can be more or less perfect. A perfect substitute for a car might be a different make of car, while an imperfect substitute might ne public transport, a bicycle, or walking. As the price of one good goes down, demand for its substitutes will also go down, all else being equal. This makes sense - if one brand of car were suddenly free, it would instantly take market share from everyone else. This pattern is what leads to price wars between stores, as they each reduce their prices to undercut the competition, hoping to be the last one standing when the dust settles, with the ability to raise prices to a more profitable level. In the case of open source, this principle explains how open source can be an agent for market disruption. If you have a free, easy to use, unix-like operating system available to you, demand for expensive, proprietary unix systems is going to go down over time, all else being equal. MySQL disrupted the proprietary relational database market by taking a lot of low-end workloads off Oracle and others, and gradually improving to take higher end workloads too. As a result, open sourcing a piece of software can be a very effective tool to undermine a competitor, who may have a lot of inertia to change when their flagship product is threatened by an upstart.
- In the first two economic principles, we saw how open source projects can gain market share and mindshare, and undermine competitors, but we still have not talked about how to make money. For that, we come to the 3rd economic principle, which is complementary goods. Complementary goods are goods that are usually consumed together. Think of cars and tyres or gas, or cellphones and a subscription to a cellular service. The law of complementary goods says that, all else being equal, when the price of a good goes down, the demand for its complements goes up. This is why mobile service providers subsidise the cost of cellphones for people who buy 24 month monthly subscription plans, which is where operators make the real money, or why Nespresso subsidises the cost of the Nespresso coffee machines. By selling more coffee machines, they sell more capsules. You might call this the “King Gillette strategy” - Gillette famously gave away millions of razor handles to the army during World War 1, and made his money selling razor blades to the handle owners afterwards. Every successful open source business model is based on this principle. The goal is to find the complements to the software you are releasing as open source which offer a lot of value to your customer, and charging a fair price for them. As we will see later, software has many possible complements, and several of these are viable for a scalable business model. Now that we have the core microeconomic principles, creating a product strategy involves understanding how to apply them to a specific piece of software. No two projects will have identical goals, so no two projects will share exactly the same product strategy.
- After looking at underlying principles, let’s get down to it. The goal is to create a simple strategy which will apply some of these underlying principles to cause a positive effect for the company, and then identify the resourcing requirements necessary to execute on the strategy. The first step is to isolate a specific, high-level goal. To break these down roughly into 3 categories, we have strategies that leverage massive adoption to increase demand for direct complements, that depend on lowering the cost of ecosystem development, or which use adoption in one space to seed an adjacent market.
- Software has lots of direct complementary goods - the most obvious are support and professional services. Helping people use the software more effectively, or integrating it into a larger solution, is an easy way to bootstrap a company, but it comes with a downside of lower margins, which can make it hard to scale and to continue investment in a product vision. Another approach is to give away one piece of software (for example, Ansible) and sell another piece of software which adds value or makes it easier to use at a larger scale (Ansible Tower). This is a very common business model for open source start-ups, and it is an upgrade on the “open core” or “freemium” business models that were common in the last decade. You don’t even need to own the other piece of software - one of the early commercial drivers of Red Hat was demand for a certified, supported Oracle database on Linux, and Red Hat drove demand for its enterprise product by providing the fastest, best supported experience for Oracle users on Linux. Nowadays, the primary driver of Red Hat revenues is subscriptions - we give customers assurance that their operating systems will be supported over a very long time period, with feature updates and security fixes being made available very quickly. The confidence to know that you can stay on the same platform for 10 years provides peace of minds to the customer. The integration of multiple components into a packaged product, lowering the time to installation and maintenance cost, is also a good model - indeed, it was the original motivation for Linux distributions, and today many OpenStack vendors provide a similar service around the installation and lifecycle management for many individual components, brought together as a single product. The use of open source for ecosystem development, or for the alignment of the industry around a specific technology stack, is very common in the standards world. Consider how the OpenOffice.org project drove adoption of its XML document format by standardising it in OASIS. The goal of this was not to make money immediately, so much as to create an ecosystem around the file format as a counter-weight to Microsoft Office. Indeed, this resulted in Microsoft standardising its document formats with ECMA and ISO in the Office Open XML format. Another possible strategy is to use an open source implementation as a de facto standard, to drive the industry to adopt it, and then use this platform as a medium for other activities or goods and services. Consider, for example, the Android operating system from Google, which is now the number one mobile operating system. This has enabled a rich ecosystem of app vendors, in addition to providing Google with a wealth of user data which they can mine for commercial purposes. Another strategy around the creation of a de facto (or de jure) standard is to encourage an ecosystem to form and engage around the underlying technology or platform. Consider, for example, the Docker container format and the OCI standardization effort. The standardization on the container format and runtime has resulted in a massively successful ecosystem of companies competing higher up the stack on container management, and application lifecycle management. Without the success of Docker as the underlying container format, the total market for containers might still be small. By encouraging the adoption of a standard, and by growing the market as a result, the commercial market around container management is much bigger than it would otherwise have been.
- Finally, open source may be useful not for itself, but as a tool to create demand for something which the market never knew it needed. Popular new products like Puppet and Chef make it possible to deploy applications consisting of hundreds or thousands of servers, creating entire new sets of activities which never existed before, including log management, continuous delivery, and management at scale, seeding entire new commercial ecosystems of activities. It could be that your goal in open sourcing one piece of software is to increase demand for an existing product by finally giving users the ability to scale their usage. At the time of its open sourcing, one of the strategic goals of ManageIQ was to demonstrate the value of a cloud management platform - the theory being that if a cloud management platform made it easier to manage applications on a private cloud, we would increase acoption of our private cloud products.
- Let’s look at some examples. One of the most successful open source projects in the past 15 years, in terms of market impact, has been Android. When it was first released, Symbian was the king of the mobile OS space. By releasing Android as open source, Google were making a land-grab into a relatively young market, and using Android as a way to lower the cost of acquisition of new hardware partners. Once Android began to appear on handsets from multiple hardware vendors, they leveraged this market adoption to grow their app ecosystem and marketplace. The billions of Android users worldwide now give them a huge opportunity to leverage their complementary goods, namely context-specific advertising, by farming a huge amount of user data,
- When Wordpress was first released in 2003, the blogging space was new and fractured. Wordpress itself is a derivative of an earlier blogging platform calle b2. Wordpress got its big break when the market leader at the time, Movable Type, changed its license, and Wordpress was both easy to install, easy to maintain, and had a well understood open source license. The project leveraged this growth to create a massive extension and theming community, and onetization through provding Wordpress as a subscription-based hosted service for people who just want a blogging dashboard and wysiwyg editor on Wordpress.com
- Finally, let’s consider a project like ReactJS. It’s not clear how open sourcing this project helped Facebook’s core business - React was internal tooling which was not generating revenue at all. But consider that as a very popular open source JavaScript framework, there are now millions of developers familiar with the framework that Facebook uses to build their applications. This lowers their costs for training developers they hire, and allows them to benefit from the feedback and contributions of millions of developers using their framework and improving it. It also helps Facebook’s brand as an open source contributor, making it easier for them to attract talent.
- The strategy you converge on or propose will depend greatly on the project you are releasing. However, one thing that is uniformly true is that if the strategy does not have the buy-in of key stakeholders, then it is wasted effort. The defining categoristic of a good strategy is that it sticks, and that it informs individual actions. So let’s talk about how you come up with a strategy, and communicate it through an organization, in a way that gets the buy-in of all concerned.
- First, to ensure that the strategy reflects the constraints and the world-view of all, we need to be aware of them. This is a key, and often undervalued, stage of strategy development. It is vital that you identify the important constituencies, from engineering through to sales and support, to ensure their voices are heard. That does not mean getting hundreds of people in a room , but it does mean finding one person who can represent a larger constituency, and who you have confidence will bring the findings and drafts of the group back to that group for feedback and revisions. Start with a small, focussed group, and iterate. It will take 3 or 4 iterations to get to a final strategy proposal, and at each iteration, you can expand the number of people providing feedback at each iteration. Thinking of a project you are familiar with, write down the job titles of 5 key stakeholders you would include in the open sourcing process.
- I really like this quote which I have seen attributed to John Lilly, former CEO of the Mozilla Foundation. “Surprise is the opposite of engagement”. If you are getting engagement in the process, no-one should be surprised when they see the strategy proposal for the first time.
- Once you have your seed group, the process starts with understanding the state of the problem space. Start by understanding the goals of the organization as a whole, and the goals of the product teams who will be building a product on top of the open source project. Only once you understand the bigger picture does it make sense to talk about goals you want to achieve with the project, and how those feed into the overall plan. For example, Red Hat has a strong Open Hybrid Cloud strategy, with a goal to manage infrastructure and applications across bare metal, VMs, and containers, in private datacenters and public cloud. A given project may contribute to that overall strategy in any number of ways - it can be a driver of revenue, or an added functionality that makes an underlying platform more attractive, or expands the portfolio footprint for a customer. In that context, the project goals may change. Supporting a portfolio attach strategy may imply maximizing project adoption, to teach the market the value of the product. Supporting a revenue model may imply segmenting the market somehow, targeting different people in the same organization, or perhaps targeting different types of companies or verticals to spread the mindshare of the product solution. The point is, the goals you have with the product must inform your project strategy. It is also important to position your offering relative to the market - what will the effect of an open source project be on partner relationships, and how will your project be positioned relative to competing products and projects? Where in your customers’ value chain does the project sit, and what else is in their value chain that they depend on? Open sourcing a project can drive a market segment towards commoditization - which can bring about a whole range of new, higher-order activities, each of which offers possibilities in terms of project strategy. For example, the popularization of containers has enabled a market of container management platforms and tooling for container applications., Understanding the effects of open sourcing on the environment is vital to coming up with a good strategy. One method I find useful in understanding the strategic landscape around a project is Wardley Maps, popularized by Simon Wardley.
- Key to understanding the market and strategy is understanding the target audience - who will use your software? What problems does it solve, and who has those problems? How do those people find out about and adopt new technology? One characteristic of open source which can be used successfully to create a business model is that the people who download and install open source software are typically not the same people who decide to buy the products based on them. Open source adoption tends to be bottom-up, based on reduction of friction and reduced cost, while product adoption tends to be through a sales process, based on contacting influencers and budget owners at the top of the organization. The sales arguments are different, the considerations are different, and one of the keys to a successful business model is understanding these differences, and tying the benefits of open source adoption to the value of a product sale.
- More precisely, you want your open source project and the product building on it to have a mutualist symbiotic relationship. Project success should clearly feed product success, and products should add value relative to the open source project for prospective customers. It’s important to understand how the product offering helps make users of the project better, and also to understand how success for the project will create opportunity for the product. In the absence of this clear relationship, you will inevitably hit conflict when trade-offs have to be made. Resources are finite, and if this relationship is not well understood by those who make budgeting and resourcing decisions, your community project will find itself under-resourced as product marketing, customer acquisition, and revenue will take priority over growing the user and developer community.
- Similarly, when coming up with a project strategy, you first think in higher level terms - “our goal is to grow an ecosystem of extension developers on this platform, and add value to our products by having a certification program for the most useful of these extensions”. How you achieve this is secondary - perhaps, to create an attractive platform, you target massive user adoption, an easy to use extensibility framework with some sample extensions, and an investment in high-quality documentation for developing extensions and using the platform’s interfaces. In addition, you might decide to invest in a bizdev team to recruit companies individually, run training courses, etc, to seed the community of extensions. Or maybe, given the unique circumstances of the project and industry vertical, another strategy (such as recruiting one high-value partner to seed the market and focussing on adoption as a secondary consideration) will make sense. The point is, the strategy informs the tactics, but the tactics are not the strategy.
- Finally, to be successful, the project strategy must stick. In any organization, some people will leave, others will be hired into the team, and you want the strategy to guide individual actions and choices on a daily basis. As a result, if the strategy is not super simple to explain and understand, it will not stick. You should be able to explain it to anyone over a 30 second meeting at the coffee machine. For example, when we launched the RDO project, Red Hat was a prominent developer in the OpenStack community (#2 or #3 developer, IIRC), but had very low mindshare in the industry, or in the user community. OpenStack packages were available on Fedora, but were not widely adopted. We created RDO to fulfil three goals: To provide an easy-to-install OpenStack experience on CentOS and other operating systems in the Red Hat ecosystem, to provide a social center of gravity for users of OpenStack on those platforms, and to communicate the work we were doing in the OpenStack community. Another tool which can be very helpful is to distil the strategy down to a mantra, a one-line, easy to repeat phrase that makes the community’s top priority obvious. For example, the mantra for the ManageIQ community might have been “We’re demonstrating the value of a Cloud Management Platform” - at the time of its launch as open source software, the value of a single, programmable platform to see all of your virtual applications was not well understood. Cloud Management Platforms were seen as complex, legacy systems. Our goal was to have a simple installation process, with a set of common tasks that we would make super simple which would show why you might want a CMP. The goal of the mantra and the one-line summary of the strategy is two-fold - it makes the strategy easy to remember, and it informs daily decisions. When a group is discussing the relative merits of two features, you want the strategy to be front of mind for the people discussing it. A note of warning: It can be tempting to have a private strategy which is different to your publicly stated strategy - perhaps you position the community project as “the bext open source X”, while your private position is “displace competitor Y”. These private positions end up getting out, and in my opinion, it should be possible to ensure you avoid this situation by having a strategy that you are comfortable communicating publicly.
- Any questions?
- Finally, once you have a strategy, with a distilled description, backed up with a good understanding of how it supprots organization and product goals, you can move to the implementation phase. The key phase here is around budgeting for success, and measuring the right things.
- Finally, once you have a strategy, with a distilled description, backed up with a good understanding of how it supprots organization and product goals, you can move to the implementation phase. The key phase here is around budgeting for success, and measuring the right things.
- A great place to start is to consider the user’s journey from hearing about your project to becoming an active community member. The user journey covers how you reach your target audience, what your first website visit experience is like, how much time it takes a new user to get from your website front-page to having something running they can use, tracking daily activation stats to see how welly you are keeping users engaged, and tracking their community engagement with your community through mailing lists, bug tracker, wiki, and code submissions. If you come from a sales or product marketing background, this might look familiar - it is essentially the same thing as a sales funnel, and we can use many of the same tools to measure attrition rates, return visitors, and more; further, we can use this data to identify areas that need improvement. One project I heard of was losing many potential users because people visiting the main web page could not figure out how to download the software - by redesigning the front page, they increased their download rate by 20% overnight.
- In particular, to return to a point I made earlier, the new user experience is a huge part of the cost of acquiring open source software. If the prerequisites are tricky to install or configure, if your new user experience is too complicated, or if I install something only to ask myself “what next?”, the costs of using your project may end up limiting adoption - and as a result, you will miss out on a lot of the good things we hope to achieve with open source. Three areas in particular I believe in strongly: a new user should be able to see the potential of your project within 15 minutes of clicking on a download link. If it takes longer than 30 minutes to download and install the software to the point where you have a basic “Hello, World!” application running, most potential users will give up. A second area to focus on is the “what’s next?” - help people level up immediately after an install by doing something useful for themselves. It can be small, but you want to give your new user a feeling of autonomy and success. Finally, it is vitally important that open source projects install the vast majority of the time. If there are failures or common misconfiguration issues, then ideally you would make those difficult or impossible to produce (with, say, config file syntax checking), but if errors do occur, you should make sure that it is easy for someone who hits an issue to find the underlying issue and get past it, fast.
- Specific to the strategy, and in addition to the basic web analytics and “user journey” funnel measurements, it’s important to be able to distil your strategy down to one or two key metrics that you will follow closely. The goal of these metrics is to ensure that you are achieving the goals you set out to - or to raise flags early if you are not, and allow course correction. For example, in the projetc discussed earlier, perhaps number of extensions, or number of companies producing extensions, might be the key metric to follow.
- However, be careful what you measure, and be sure it maps to a result you really want to achieve. There is a great story about French Indochina in 1905 to illustrate the point. At the end of the 19th Century, the French had renovated Hanoi, and as part of the renovations, had installed a modern sewer. They had inadvertently created a great breeding ground for rats - and a few years later, the city was over-run. In 1905, Lieutenant General Paul Doumer started a program to exterminate the rats, and city workers were paid a bounty for each rat they caught. They caught tens of thousands, but barely made a dent. Doumer then had the brain-wave that if they set the general population loose on the rats, they would clear the sewers in no time. He decided to pay a smaller bounty for each rat caught and killed, but given that this would be hundreds of thousands of rats, and he didn’t want a mountain of dead rats in front of city hall, he agreed to pay the bounty on production of proof of death - and for the proof, he settled on the rat’s tail. Immediately in the streets of Hanoi, two phenomena were observed: a massive increase in rat farms in basements, and multiple sightings of tailless rats wandering the sewers. Unfortunately, this did not end well for the local population, a couple of years later there was an outbreak of bubonic plague which resulted in hundreds of deaths.
- Strategies tend to last for a few years, but the world is constantly changing around us. It’s important to be able to reach to changes over time. In fact, releasing the software can itself result in surprises, which you can see as a threat of your project getting away from you, or an opportunity to re-center the strategy on a new opportunity. Serendipity has been a power force for the creation of new industries, but it requires the person concerned to take advantage of it. Open sourcing software does create the possibility that your project will be used or adapted in ways you had not anticipated. One example is the way OpenStack has been adopted by the telecommunications industry with NFV. The OpenStack project could have consider the telco use-case as a distraction from its core mission, coming as it did with requests for features related to dataplane acceleration,hardware offload, and five 9s application availability. Instead, OpenStack vendors embraced the new opportunity, worked hard to understand the requirements of that industry, and deliver those features in a way consistent with its vision of cloud infrastructure. In general, a cadence of every 12 months to check back in with the core group of stakeholder to evaluate progress and gut-check the strategy feels about right, and gives the opportunity to adjust quickly if something new comes along.
- In conclusion: crafting a product strategy around open source requires having all of your key constituencies represented in the process so that you will have buy-in for the result, exploring in depth why open sourcing makes sense for the organization's goals, make sure you’re measuring the right things to gauge the success of your efforts, and finally, be prepared to pivot if circumstances impose it. Thank you!
- Any questions?
- If you’re interested in this topic, there is coincidentally a whole set of talks that go into different aspects of it this week. Vicky Brasseur will talk about the process for open sourcing an internal open source project, a topic I barely scratched the surface on. Leslie Hawthorn will talk about how to wed a developer community culture with the needs of a sales organization to deliver customer value, and Chris Price and Hasseb Akhtar of Ericsson will talk about some of the challenges of creating a financially sustainable open source product. Tomorrow, Jeffrey Borek and Stephen Walli of Microsoft will debate whether it even makes sense to talk about open source business models (you all know my opinion), and Robyn Bergeron will talk about how the Ansible community was designed for modularity, both to grow a developer community and to create a viable business.