Skip to main content

Open approaches

Open Approaches

warning

This is an early draft and isn't yet up to our standard. You can contribute improvements.

Definition & Summary: Making something open -- be it open source software, open standards, open data, or open APIs -- to remove barriers to adoption and accelerate the evolution of that component . In short, using openness as a tool to drive an activity toward commodity or utility faster.

Detailed Explanation: By open-sourcing or freely sharing a technology/practice, you encourage many others to build on it, collaborate, and drive its improvement. The purpose is to increase its adoption and commoditize it (which can commoditize someone else's advantage, or create a stable base for you to build higher-order systems). Key principles: eliminate proprietary friction -- e.g. cost, licensing, or integration hurdles -- so more users and contributors come on board . This often leads to network effects of development (many eyes improving the product) and competition shifting to new differentiators above the open layer. Many open approach strategies originate from wanting to undercut an incumbent or set a de facto standard.

Real-World Examples:

  • Historical: In 1998, Netscape open-sourced its browser (creating Mozilla) as an open approach to challenge Microsoft's dominance. The hope was that by being open, it would rally the community and other companies, accelerating innovation in browsers and eroding Microsoft's proprietary hold. Indeed, this eventually led to Firefox and a more standards-driven web (though Netscape itself didn't survive, the strategy influenced the market).

  • Historical: Google's Android OS -- Google made Android open source (mostly). This removed barriers for phone manufacturers to adopt it (no licensing fee, customizable) . The result: Android's evolution and adoption accelerated rapidly, dominating smartphone market share. Google's play was to commoditize smartphone OS (a layer where Apple's iOS was proprietary) and benefit from services and ads on top. Open approaches succeeded in making Android the standard smartphone platform globally, supported by many competitors collaborating in the Open Handset Alliance.

  • Contemporary: Open data initiatives, like when governments or companies open data sets (e.g., GPS, weather data). By releasing these openly, they accelerated development of entire industries (e.g., Google Maps and the broader geolocation services industry thrived on open GPS data). A company might open its platform data to spur complementary innovations, knowing a richer ecosystem will circle back value (like more users or improved algorithms).

When to Use / When to Avoid:

  • Use when: A component is utility-like and not your core differentiator, and you benefit from it becoming widely adopted and standard . Especially use if a rival's proprietary hold on that component is hindering you -- by open-sourcing an alternative, you undercut their advantage. Also effective to build ecosystems quickly (developers flock to open platforms).

  • Avoid when: The component is your core profit center with no alternative revenue model -- opening it would directly cut off income. Also avoid if you cannot afford to support an open community (open projects need maintenance and leadership, otherwise they stagnate). If openness won't actually attract contributors or users, it may not achieve anything (not everything thrives just by being open).

Common Pitfalls:

  • No clear monetization: You open something but don't have a plan to make money elsewhere. E.g., open sourcing a software but not capitalizing on services or higher-level offerings can hurt revenue.

  • Community misalignment: The project could fork or drift in a direction not aligned with your strategy if you don't manage community well. You risk losing control (which might be intended, but if you rely on it for something, that's an issue).

  • Competitor benefit: Ironically, competitors can also freely use what you opened. If they are better positioned to monetize it, you essentially did them a favor. For instance, some accuse that open-sourcing certain tech allowed cloud giants to benefit more than the originators.

Related Strategies: Open Approaches often go hand-in-hand with Ecosystem plays like Co-creation (inviting others to build on your open platform). It's also a form of Undermining Barriers to Entry (making a technology free removes a barrier). Embrace and Extend is the inverse approach (competitor might embrace your open tech then extend it).

Further Reading & References:

  • Wardley, S. -- "Whether source or data or practice, making something open reduces barriers to adoption..." . Describes how open approaches drive collaboration and evolution.

  • Linux Foundation case studies -- e.g., "IBM's $1B investment in Linux" , showing how a major firm used open source to accelerate a technology (Linux) for strategic benefit (services/hardware sales).