Complexity  ## Metadata - Author: [[Emily Omier]] - Full Title: Complexity - Category: #articles - Document Note: --- tags: - #open-source - #product-management - #complexity Author: Emily Omier Source: Article/Website Reference: https://www.emilyomier.com/blog/complexity date created: 2025-08-23 00:00 --- # Title: Managing Complexity in an Open Source Company ## Table of Contents: - 🔗 🧭 Overview: Why open source adds complexity (#-overview-why-open-source-adds-complexity) - 🔗 🧩 Project vs Product: Roles and differences (#-project-vs-product-roles-and-differences) - 🔗 🎯 Audiences, Outcomes, and Pain Points (#-audiences-outcomes-and-pain-points) - 🔗 🛣️ Triggers, Journeys, and Conversion (#-triggers-journeys-and-conversion) - 🔗 🏷️ Positioning and Market Category (#-positioning-and-market-category) - 🔗 💎 Differentiated Value of the Commercial Product (#-differentiated-value-of-the-commercial-product) - 🔗 🧑‍🤝‍🧑 Company-wide Alignment and Communication (#-company-wide-alignment-and-communication) - 🔗 🧠 Strategic Framework and Business Impact (#-strategic-framework-and-business-impact) - 🔗 🗒️ Notes (#-️-notes) - 🔗 🗣️ Paraphrase (#-️-paraphrase) - 🔗 📰 Newsletter (#-newsletter) - 🔗 ✅ Action Items (#-action-items) - 🔗 🧪 Hypotheses (#-hypotheses) - 🔗 📊 Methodology (#-methodology) - 🔗 ❓ Questions (#-questions) - 🔗 🔮 Future Research (#-future-research) - 🔗 💡 Implications (#-implications) - 🔗 🧠 Learning Styles Assessment (#-learning-styles-assessment) - 🔗 📊 Accessibility Assessment (#-accessibility-assessment) - 🔗 🌍 DEIB Assessment (#-deib-diversity-equity-inclusion-and-belonging-assessment) - 🔗 ✅ Logical validity (#-logical-validity) - 🔗 🔍 DARVO Analysis Prompt (#-darvo-analysis-prompt) - 🔗 🔍 SEO Evaluation (#-seo-evaluation) - 🔗 🎯 Conclusion (#-conclusion) ### References: Include a list of sources consulted and cited in the article. - Primary source: Emily Omier, “Complexity,” published 2023-11-13: https://www.emilyomier.com/blog/complexity ## 📝 Summary: The article argues that open source companies face inherent complexity when they simultaneously steward an open source project and sell a commercial product. Whether shifting from closed-source to open source, or adding a commercial layer to an existing open source project, complexity increases. Success hinges on explicitly defining and aligning: - The difference between project and product - Target audiences and expected outcomes - Pain points solved by each - Triggers to adopt the project vs triggers to become a paying customer - User journey vs customer journey - Distinct positioning/market categories - The commercial product’s differentiated value beyond the project Whole-company understanding and consistent communication across all public-facing surfaces are essential. A clear strategic framework implemented early improves control, conversion, and revenue growth. ## 📖 Main Content: The author spotlights a common pitfall in open source companies: conflating the goals, audiences, and value propositions of the open source project with those of the commercial product. This ambiguity creates friction for users, buyers, and internal teams. To counter this, teams must formally separate and document: - Project vs Product: The project builds community, adoption, and technical credibility; the product solves operational, enterprise, or scale problems that justify payment. - Audiences and Expectations: OSS users expect freedom, transparency, and self-service; buyers expect reliability, support, integrations, security, and time-to-value. - Pain Points: The project addresses learning and experimentation; the product addresses risk mitigation, compliance, scale, and TCO reduction. - Triggers: Project adoption is triggered by curiosity, evaluation, or immediate technical needs; purchasing is triggered by operational pain, cost pressure, security requirements, or executive mandates. - Journeys: OSS user journeys emphasize install, docs, community; customer journeys emphasize discovery, evaluation, procurement, onboarding, and expansion. - Positioning: Each requires its own market category and messaging; avoid muddled descriptions that blur purpose. - Differentiated Value: The commercial offer must add clear, unique value beyond the OSS—e.g., managed services, SLAs, governance, advanced features. The article concludes that a lightweight, explicit framework—taught to every team member and reflected in web copy, press, sales, docs, and product choices—keeps complexity manageable and drives better conversion and faster revenue growth. ### 🗒️ Notes - Complexity inflection points - Moving from closed-source to open source increases complexity. - Adding a commercial layer to OSS increases complexity. - Complexity arises from dual motions: community-led adoption and revenue-driven sales. - Project vs Product clarity - Define what the project is for (community value, adoption, credibility). - Define what the product is for (operational value, business outcomes). - Create separate narratives and artifacts for each. - Audience segmentation - OSS users: engineers, tinkerers, early adopters. - Buyers/customers: leadership, ops, security, compliance stakeholders. - Map expectations and success criteria for each. - Outcomes and pain points - Project outcomes: learning, quick wins, experimentation, control. - Product outcomes: reduced risk, speed, support, scale, integration. - Triggers - Project trigger: a technical need or curiosity. - Product trigger: pain at scale, compliance, SLAs, cost of ownership. - Journeys - User journey (OSS): discover → install → docs → community → contribute. - Customer journey (product): discover → evaluate → budget → security review → procurement → onboarding → renew/expand. - Positioning/market category - Craft distinct, testable positioning statements for project and product. - Avoid “OSS plus” as the only framing—clarify category and who cares. - Differentiated value of commercial product - Managed hosting, observability, governance, SSO/SAML, RBAC, policy, backups, SLAs. - Prebuilt integrations, migration tooling, analytics, multi-tenant controls. - Company-wide enablement - Everyone can explain the differences succinctly and consistently. - Reflect distinctions in website, docs, sales collateral, PR, product roadmap. - Strategic framework and impact - Implement early, ideally before launching the commercial offer. - Benefits: control, consistency, conversion, revenue velocity. ## 📖 References: - Emily Omier, “Complexity”: https://www.emilyomier.com/blog/complexity ## 🗣️ Paraphrase: - Original idea: “Whichever route you take … as soon as you’ve got an open source project that you’re serious about plus something that customers pay you money for, you’ve got a much more complex setup … Managing the relationship between project + product is critical.” - Paraphrase: No matter how you arrive at an open source business, the moment you pair a serious OSS project with a paid offer, your operating model becomes substantially more complex. The key challenge is deliberately managing how the project and the product relate. - Original idea: “Every person on your team should understand all of the above … because you want the above to come through clearly in your web copy, press releases, sales conversations, documentation, product decisions … Managing complexity … can be done … if you put the right strategic framework in place … which will translate to better conversion rates and quicker revenue growth.” - Paraphrase: This clarity can’t live only in founders’ heads—everyone must internalize it so it shows up in every external touchpoint. With a lightweight strategy applied early, you can scale this alignment, which in turn improves conversions and accelerates revenue. ## 📰 Newsletter: This week in the WordPress builderverse: Learning paths, fresh plugins, and community beats - Learn web development the sustainable way: Start with the fundamentals (HTML/CSS), layer in modern PHP for WordPress, then sprinkle JavaScript where it actually reduces friction. Pro tip: build once locally with WP-CLI and scripts, then document your steps like you’re your own future teammate. - Recent updates: Gutenberg keeps shipping UX polish; keep an eye on performance impro - Summary: Moving from a closed-source software product to an open source strategy increases complexity for both the product offering and the business. Whether a company starts as an open source company or introduces a commercial offering later, the relationship between the open source project and the commercial product is critical to manage. It is important to have a clear understanding of the target audience, the difference between user expectations and customer expectations, the pain points solved by the project and the product, the triggers for users and paying customers, the user journey versus the customer journey, and the positioning and differentiated value of the project and the commercial product. Every person on the team should understand these points and be able to explain them to stakeholders. Managing complexity is a challenge for open source companies, but putting the right strategic framework in place can help control it and lead to better conversion rates and revenue growth. - URL: https://www.emilyomier.com/blog/complexity If you’re moving from a closed-source software product (whether something the runs on-prem or a SaaS offering) to an open source strategy, you will be increasing the complexity in your product offering and for your business. If you started as an open source company, on the other hand, for you it’s the moment you introduce a commercial offering that you introduce complexity into the company. Whichever route you take to being an open source company, as soon as you’ve got an open source project that you’re serious about plus something that customers pay you money for, you’ve got a much more complex setup than your peers with closed-source startups. **Managing the relationship between project + product is critical.** You need to know: * Who the target audience is your product and your product, including complete clarity on the difference between the two; * What outcome a user of the project expects versus the outcomes expected by customers… and again, what the difference between the two is; * The difference in pain points solved by the project versus the project; * The trigger for someone to download your project and become a user, versus the trigger for someone to become a paying customer; * The user journey versus the customer journey, and how the diverge and overlap; * The positioning/market category for your project and your commercial product, ie a core description of what each is, paying special attention to how they are different; * The differentiated value of your commercial product, and how it goes above and beyond the differentiated value of your project. And it’s not just that you, as the founders, need to have this in your heads. Every person on your team should understand all of the above, and every person on your team should be able to explain all of the above points to a customer, a tech journalist, or their friend from college. Because you want the above to come through clearly in your web copy, your press releases, your sals conversations, your documentation, your product decisions and every other component of your company that’s public facing. Managing complexity is one of the core challenges of building an open source company, but it’s one that can be done relatively easily and at scale if you put the right strategic framework in place — and doing this as soon as possible after, or actually ideally in preparation for, the moment you have both open source project and commercial offering co-existing will help you both feel more in control and actually be more in control. Which will translate to better conversion rates and quicker revenue growth., Complexity, Emily Omier, 01hf4dvv8h8v8x2n5nw27akbhf.