Services for Start-Up Businesses

From a business perspective, there are two broad categories for interacting with Open Source software: as a user/consumer and as a participant/purveyor. It is possible (and not uncommon) to be both.

Depending on the Open Source maturity of your organization, you may already know where you are in that continuum, and even where you want to get to. Or you may still be learning and adapting approaches, and aren’t settled on your what, how, and why for interacting with Open Source software and communities.

Image is a colorization of an old black and white photo. Three figures that appear to be men by their period dress are leaning into the act of pushing up a section of a wall that seems to be about one meter wide by three meters tall and at least five centimeters thick (three feet by nine feet by two inches thick.) The wall section is on the ground on the right, aligned with the in-place section of wall to the left of the new section. To the right of the section being risen the background of trees and other workers beyond the open wall is visible, but soon to be blocked by the rising wall.

Below are simplified examples of what might be services in a statement of work for these different types of businesses.

  • If your business is going to develop Open Source software as part of it’s product line:
    • Assessment of how your R&D, marketing, sales, and support are affected by the different ways to approach Open Source software development:
      • A look at the strengths and weaknesses of your approach
      • A meaningful comparison with other approaches (e.g. Company-driven roadmap, collaborative roadmap, Open Core, multi-org collaboration, etc.)
      • What are the realistic returns and the resource costs to get results from different approaches.
      • The more you put into this process with us, the more details can be achieved. But a broad understanding may be all the guidance you need. This is something we’ll understand more from the pre-proposal discussion.
    • Roadmap of potential and likely rewards from making a commitment to achieve and maintain a sufficient Open Source organizational maturity level.
      • Identity and strategy for the initial waypoints with higher risk on that roadmap, requiring pre-planning and careful navigating to get through.
      • For example, how you respond to a future security breach of a service based on your Open Source software affects how other members of the Open Source developer ecosystem interact with you.
    • A community architecture plan that can fit and grow with your business.
      • For example, an early focus on role diversity in your Open Source communities can help strengthen ties between your Open community and your various business functions such as marketing, support, and operations.
    • Business plan development, including:
      • For a modular portion of an organization, for example to spin-up a new line of business, product, or service that involves using, participating, or creating Open Source software.
      • For a new organization starting up, such as providing a managed service based Open Source software that might be a mix of house-made and freely available Open Source components, with some gaps filled by e.g. PagerDuty.
      • For an organization, enterprise, or government looking to re-envision itself as Open by nature.
        • Depending on the scope, this could be a team or department all the way up to a state or national governmental component.
        • This is less about a product approach and more about how an organization sees itself and chooses or prefers to act and behave.
  • If your business intends to bundle one or more pieces of Open Source software in part of it’s product line (such as pre-installing such software on a hardware appliance, or bundling common programming libraries with non-Open Source software):
    • Community interaction planning and support within your license compliance and software supply chain processes.
    • Risk and rewards analysis on participating or contributing back to Open Source software.
    • Analysis of how you can use systems and practices internally that mimic or borrow from external Open systems and practices.
      • Especially where such Inner Source practices may be the only way to blend the community’s tools and processes with internal business processes.
  • If your business plan does or may include participating or contributing in some way to one or more Open Source software projects (including ones you create):
    • Setting business plan vision and mission parameters around Open Source involvement.
    • Collaboration to create your organization’s Open Source participation guidelines.
      • Including establishing your process for obtaining and maintaining ongoing alignment to the guidelines.
    • Shaping your business plan around the possibilities and constraints of Open Source software.
    • For business modules and line of business Open Source software and services:
      • Strategy and planning, from concept to business or service start-up.
      • User and contributor advocacy planning and delivery for new and established Open Source-based business modules.
      • Ongoing coaching and refresher training for leadership at all levels (package-of-sessions or retainer-based options available.)
    • Development and delivery of training of senior leadership, managers, and individual contributors on different aspects of Open Source participation.
      • For example, a VP of Software may participate on a governing board of a foundation or project, a Product Manager may have a seat on the technical steering committee that sets future roadmaps, and a technical writer may have product documentation to understand and develop.
Scroll to Top