| id | title |
|---|---|
element-details |
OSMM Element Details |
- Attributes
- No goals, objectives, or corporate alignment for open source activities
- No awareness of the benefits or potential risks of open source
- Implications
- Lack of awareness can expose to potential risks of open source or not harnessing complete benefits
- Activities
- Identify a cross- functional working group to launch an open source initiative to get trained on the basics and best practices around open source then work on discovering the use, risks, and benefits of open source at the organization
- Engage outside experts (legal, consulting, etc.) to advise on open source policy and strategy
- Hire open source experience internally
- Assign someone to own development of open source strategy
- Attributes
- An open source strategy exists
- There are no resources dedicated to open source management or strategy
- Open source strategy communicated only to select teams
- Implications
- Awareness initiates conversations and learning opportunities
- Activities
- Dedicate resource(s) to open source management and strategy
- Attributes
- Open source benefits considered during organizational strategy discussions
- Open source strategy communicated only to technical teams
- Implications
- Organization begins realizing innovation and productivity benefits of open source
- OSPO coordinates and communicates the efforts of stakeholders across the organization
- Activities
- Start formulating an open source strategy that aims at achieving specific corporate business objectives across multiple dimensions
- Identify the right resources to involve in the open source OSPO creation to ensure alignment with all the strategic dimensions of the organization
- Attributes
- Open source is an element of strategic plans and goals
- Open source strategy has elements (goals, metrics) that are tied to corporate strategic objectives
- Implications
- Evolution of OSPO to support the organization's strategic needs
- Open source solutions considered first before proprietary
- OSPO grows to touch and impact more and more of the organization service lines and business units
- Activities
- Finalize a comprehensive open source strategy aligned with corporate strategic business objectives
- Expand Open Source Program Office to include full representation of stakeholders in all relevant service lines, functions, and business units of the organization
- Attributes
- OSPO representation in executive strategy discussions
- Implications
- Increased open source contributions lead to influence in strategically important projects
- Brand and recruitment begin realizing impact of releasing open source projects
- Activities
- Continue investing resources to reinforce the role of the OSPO and alignment of open source strategy with strategic corporate objectives
- Attributes
- Management is unaware of open source use in the organization
- No institutional awareness of the role of and need for an OSPO, or its benefits
- No knowledge of the organization's open source supply chain
- Implications
- Lack of knowledge of the organization's open source supply chain can obscure vulnerabilities
- Not leveraging open source community diversity leads to uncontrolled, and sub- optimal innovation
- Activities
- Identify areas that could help generate initial push for open source engagement for management
- Attributes
- Management is aware of open source use in the organization but does not yet understand the benefits
- Management aware of OSPO but reluctant to establish one
- Executive management sees open source mostly as a nuisance that needs to be controlled
- Executive management doesn’t see or realize the strategic implications of open source
- Implications
- Skeptic management may formulate restrictive open source policies
- Activities
- Educate management on principles of open source, and key benefits that can be derived from its use
- Educate management on principles of open source, and key benefits that can be derived from its use
- Attributes
- Management (executive) is starting to understand the benefits of open source, but is usually focused on cost savings
- Limited resources devoted to measuring ROI of open source
- Implications
- Initial forays into implementing a basic OSPO
- Since it is often difficult to really measure the ROI of migrating to open source, management may be underwhelmed by the actual perceived benefits of open source activities
- Activities
- Leadership conversations about the ROI of investing in resources to support open source and how it can help achieve strategic objectives
- Attributes
- Management realizes that open source strategy can be used to achieve corporate objectives
- Open source strategy communicated to most of the departments
- Corporate talent acquisition/retention strategy leverage open source activities
- Implications
- There are a few points of alignment between open source activities and corporate objectives, already going beyond cost benefits. This allows some form of measurement
- Activities
- Identify all dimensions of corporate objectives that can be matched to aligned open source strategy elements
- Attributes
- Open source measurably contributes to critical company goals and strategy
- Open source strategy communicated to the entire organization
- Implications
- Objectives and metrics of the open source strategy and activities are increasingly aligned with objectives and metrics of the organization, ensuring that it is easier to validate the benefits of the open source activities for the organization
- Activities
- Continue ensuring and increasing the alignment of open source activities with corporate objectives
- Attributes
- No organizational engagement in communities, maybe some individual engagement
- Lack of policies/structures enabling individual developers to engage with communities
- Lack of positive returns like developer recruitment, retention and upskilling
- Activities
- Explore which communities make sense for the organization to get associated with
- Attributes
- Community and ecosystem engagement made complex due to controls
- The organization becomes aware that individuals are contributing
- Implications
- Usually, no significant nor beneficial community and ecosystem engagement at this stage
- Activities
- Educate management on principles of open source, and key benefits that can be derived from its use.
- Impart developer training to engage with communities
- Identify all the corporate benefits that can be achieved through open source community and ecosystem engagement, integrate those into open source strategy, as well as policies, processes
- Attributes
- No strategic plan for engaging with communities and ecosystem;
- Employees are encouraged to participate in open source projects, but activities may not be coordinated
- Organization part of industry foundations but without realizing its benefits
- No open source community manager function
- Community engagement thwarted by legal
- Implications
- Engaging with communities is hindered by legal, making it hard to realize significant benefits
- Lack of coordinated open source activities results in disorganized development and/or slow progress
- Activities
- Work with legal, marketing, and corporate strategy to educate on key benefits of open source community engagements, and identify a few benefits to target, as well as how to achieve them
- Attributes
- Governance programs created and implemented that support community and ecosystem engagement; benefits are identified for such engagements, and specific benefits targeted
- Engineering management, line of business management, and developers are engaging with the ecosystem
- Engagement (as mentioned in previous point) is measured and employees may be rewarded for contribution to open source projects
- Open source community manager function exists but is probably not a dedicated role
- Implications
- With governance programs and engagement policies in place, employees feel facilitated for community and ecosystem engagement
- Measurement and reward for engagement servers as motivator
- Lack of dedicated community manager function affects a directional leadership for community engagement initiatives
- Activities
- Identify all the corporate benefits that can be achieved through open source community and ecosystem engagement, integrate those into open source strategy, as well as policies, processes
- Attributes
- Any and all corporate benefits that can be supported or driven through open source community engagement are identified
- The organization encourages contributors to announce themselves as their employees when contributing to corporate projects, third party projects, or their own code
- The community engagement model is integrated into the open source strategy
- A Dedicated open source community manager exists
- Benefits are tracked and measured from the open source activities that support them
- Developers may achieve committer or maintainer status in projects
- Implications
- Engagement with communities of open source projects used by the organization, and those defined as strategic is the rule
- Engagement with communities is tracked and measured, with goals and objectives tied to corporate business objectives
- Policies, processes, and tools are in place to make engagement with the ecosystem simple, efficient, and measurable
- Activities
- Continue identifying possible corporate benefits of engaging with existing or newly selected communities and foundations
- Attributes
- Each team follows its own development process and does not disclose plans or actions outside its team (siloed development)
- Source code of a program is seen only by the team of developers working on it
- Management does not subscribe to InnerSource principles and a culture of collaboration is nonexistent
- Implications
- Code reuse doesn’t exist or is minimal; efforts wasted in duplicate work
- Lack of proper documentation and weakness in code remains hidden from other teams; technical debt can mount
- Opportunities to hone skill-set beyond project requirement is difficult
- Activities
- Individuals and teams give visibility to their plans or products to multiple stakeholders within an organization before they are started (shared roadmap)
- Make internal source code repositories visible and discoverable to other teams within the organization
- Encourage team members to collaborate with other teams
- Attributes
- People outside the team can look at the code but their involvement is limited
- No formal tools, processes, or guidelines exist for collaboration within teams
- Management is aware of InnerSource but is hesitant to deploy it
- Lack of a culture for bottom up feedback
- Implications
- Social and political issues arise frequently due to the absence of a defined framework regarding the involvement of other teams
- Testing and quality control tend to be less robust (compared to managed InnerSource)
- Activities
- Facilitate contribution to projects outside of one’s team through rewards, recognition, providing time for it and so on
- Add detailed descriptions of projects in internal repositories to enable developers from other teams to discover and use them
- Develop and implement basic policies and tools to collaborate
- Leaders in the organization need to become open to feedback and create an environment where people feel safe providing it
- Learn the best practices of InnerSource and evangelize them within and outside of the company
- Attributes
- Members from other teams contribute to the source code and have a say in the project roadmap;
- Codes developed are modular
- Codes developed have extensive documentation to facilitate collaboration from diverse stakeholders
- Initial versions of tools and processes like a central source- code repository/version control systems, mailing lists, etc. are in place
- Middle management is still hesitant to let their team members collaborate, with outside teams,
- Implications
- Time- to- market and quality for a product can be improved with more experts reviewing code
- With less support from the immediate manager, contributions from members outside the team are limited
- Activities
- Standardize tools and processes for collaboration across teams
- Collectively document shared visions and agreements like mission statements and codes of conduct, make them easily accessible, and reference them often
- Build strong executive sponsorship for InnerSource projects and an incentive structure for middle managers to promote InnerSource
- Attributes
- Standardized collaboration tools and processes exist throughout the organization
- Standard metrics and processes are established to reward collaborations outside the developers' teams; depending on merit, someone from outside the team can be elevated as a project leader
- An InnerSource Officer role oversees governance and support, including processes, education, etc., and is the first formal step in defining the IS vision and roadmap
- Implications
- Beta testing phase is shortened and hence the product release is expedited
- More engaged contributors mean more functional and secure code
- Dilution of dependency on a single resource/team helps manage risks hampering continuous development
- Activities
- Identify InnerSource as an important component of the internal strategy of a company
- Participate in industry and peer InnerSource groups
- Attributes
- InnerSource is of strategic importance and is viewed as a crucial way of working by the top management
- Cross- functional teams are common, and their activities are known broadly to the organization and the outside world; teams actively seek help, mentor, and recruit new contributors from the entire org
- Organization promotes best practices for working together
- Implications
- Allows a company to leverage the work of all its employees, eliminate duplicate work, and innovate continuously
- Activities
- Continue exploring and adopting best practices in InnerSource from other organizations
- Attributes
- There are no tools or processes to manage the open source component lifecycle
- Implications
- Risk associated with the proliferation of open source components, with multiple versions in the organization is totally unmanaged
- Activities
- Educate IT on open source component life cycle management tools, processes, and benefits
- Attributes
- IT teams are aware of possible or existing issues around component lifecycle management, but no structured approach.
- Implications
- Risks associated with the proliferation of open source components, with multiple versions in the organization are still mostly unmanaged
- Activities
- Start planning open source component lifecycle processes and select automation tools
- Attributes
- Open source components of some critical internal projects are properly managed from ingestion through EOL
- Implications
- A risk- based approach to open source components (including risk profile, and risk management tools, processes…) is in place but does not fully cover the overall application landscape
- Activities
- Specify a process to define open source component management
- Specify a process to define open source component issue tracking/handling and
- Develop training programs
- Attributes
- There is a process defining how open source components are managed from ingestion to EOL
- Such process is applied across almost all internal teams and projects
- There is an automated process to track issues, fixes, versions, and compatibility requirements for each third- party/OSS component
- Implications
- There are now processes in place, and implementation is being rolled out.
- Risks are understood and mitigated to some degree, but no individual ownership is in place for each component.
- Activities
- Define owners for each open source component in production, with associated responsibilities for its lifecycle management.
- Attributes
- The organization has named owners for each open source component in the production
- Processes for managing the open source lifecycle are fully in place
- Training program exists
- Implications
- Open source component lifecycle is managed to support the organizational structure, model, dynamics, and empowers IT to be as efficient as possible
- Activities
- Continue evolving existing process, manage the removal of components from the current list, adjust processes to changing landscape, tools, and context
- Attributes
- No enterprise risk management (ERM) process management aligned to OSS risk activities
- No OSS risk appetite management;
- No OSS performance management
- No OSS business resiliency and sustainability management
- Implications
- The absence of RM best practice processes to identify, assess, evaluate, mitigate & monitor OSS risks
- Ineffective clarification process of the gap between potential and actual OSS risk
- Inadequate execution of OSS visions and strategy; lack of risk- based approach to business continuity, operational planning, and sustainability activities
- Activities
- Adopt an ERM methodology & well- managed OSS RM process throughout business decisions;
- Utilize a risk- based methodology for OSS management
- Well- evaluated processes of risk- reward trade- offs and defining OSS risk accountability & risk tolerance
- Adequate planning, communication, & measuring core enterprise OSS goals with a risk- based process
- Attributes
- Some OSS RM processes (risk appetite, performance, business resiliency, sustainability management) are repeatable, but process discipline is not existent;
- Basic processes for performance management of the OSS RM processes
- Understanding the importance of defining OSS risk appetite
- Minimal OSS RM process for business resiliency and sustainability management
- Implications
- Uncovering major OSS risks to the overall organizational ecosystem; OSS risk appetite is unclear
- No OSS value delivery and only informal documentation
- Separated and disconnected recovery plan in case of incidents
- Activities
- Defining OSS risk ownership, risk indicators, and risk measurements; a clear definition of OSS risk appetite, risk tolerance, and risk strategy
- Define OSS KPI selection process and documentation and reporting process
- To record OSS business and IT assets and to perform BIAs & RA, establishing an incident management
- Attributes
- OSS RM processes have evolved into a steady- state & now effective & repeatable; OSS operational processes have evolved into a steady- state and are now effective and repeatable
- The amount and type of OSS risk appetite defined and documented
- A set of OSS performance management defined and documented
- Implications
- Some unpredictable OSS risk events
- Unmeasurable of any potential OSS risk events
- An inconsistent approach towards adopting an aligned OSS performance management architecture
- Lack of full crisis management activities as part of the overall RM strategy
- Activities
- Evaluate & categorize each identified risk process; establish and select a clear- cut KPI targets
- Evaluate & categorize each identified risk amount and type and develop a risk mitigation plan
- Establish and define a central crisis management team with a clear reporting guideline
- Attributes
- Somewhat systematic approach exists & some achievements of the defined attributes
- Standardized controls with periodic testing for effective design & operation with reporting capabilities
- An integrated performance management in OSS RM processes; integrating resilience and sustainability with services and internal OSS RM processes and activities
- Implications
- Lack of a measurable losses of quality or deviations from specifications; limited support controls
- Analyzing the availability of internal process management controls
- Resilience risks are regularly identified and evaluated
- Activities
- Activities are designed & executed to build a better connection between OSS RM & business; partial automation in the processes
- Full alignment of internal process management controls with OSS RM strategy
- Defining incident types, ownership, standard response procedures that aligned with OSS RM processes
- Attributes
- The evidence of a complete & systematic approach exists & full achievements of the defined attributes; an integrated internal control framework with real time monitoring by management
- Fully evaluated and integrated performance management in OSS RM processes
- Optimized business recovery with fully developed resilient strategy that is aligned with OSS RM
- Implications
- OSS RM focus is optimized on continually improving process performance and improvements
- Fully support controls; fully evaluated and support performance management system
- Quick adaptability, innovative resiliency and well threat response measures
- Activities
- OSS RM processes are continually optimized and balanced by business context & risk priorities; fully automation in the processes
- Continuous improvements, monitoring, and reporting
- Crisis management, resilient strategy, and business continuity are fully optimized and aligned with OSS RM
- Attributes
- Few, if any, compliance control processes and no validation of existing controls;
- No compliance data collected to provide to auditors
- No collaboration between internal stakeholders around compliance and controls; Lack of connectivity between released components in control testing regime that impacts compliance
- Little institutional knowledge of OSS compliance requirements
- Implications
- Multiple risk vectors (IP, legal, security, brand) due to potential unmanaged code publication, licensing, security, quality issues, and more
- Lack of collaboration can lead to gaps in security that may cause vulnerabilities and failure to meet compliance requirements
- Lack of compliance- focused activities
- Activities
- Seek external 3rd party expert education for key stakeholders in legal, compliance, risk and CISO
- Allocate resources for development and implementation of control testing
- Attributes
- Insufficient controls (e.g., Risk Assessment, Communication Plan, Legal or Organization compliance policies, Effective Monitoring, …) and control testing regime
- Marginal evidence collection; Minimal collaboration between internal stakeholders
- Restrictive policies to control the use of and contribution to open source
- Implications
- Inadequate understanding of compliance requirements
- Restrictive policies slow development and innovation internally
- Developers create workarounds for policies, putting company at increased risk
- Activities
- Establish policy and process documentation processes
- Promote and train policy and process internally
- Educate developers on copyright, licensing, and security and the potential risks for these that can occur with open source
- Attributes
- A compliance program is in place and being scaled across the enterprise
- Some processes for testing controls
- Policies and processes of collaboration between internal stakeholders established; policies facilitate use of open source
- Implications
- Lack of efficient processes
- Control testing isn’t systematic and there is not a predefined standard that’s applied to the tests
- Activities
- Expand the scope of the compliance program and ensure all relevant stakeholders are involved: legal, procurement, risk, compliance, security, OSPO
- Continue stakeholders’ education
- Attributes
- A compliance program facilitating the use of open source is standardized and streamlined
- A full set of controls testing processes in place; A full evidence collection process defined
- Collaboration between internal stakeholders works well; Policies enable some contribution to open source projects and communities
- Implications
- A mature compliance program is in place giving leadership confidence that open source is being governed effectively; OSS compliance is embedded into many business processes
- Audit requirements are given all necessary documentation
- Everyone understands their responsibilities
- Activities
- Continue working on operational processes standardization and streamlining; All processes and control testing guidelines to be defined and implemented
- Evidence adheres to the stated policies
- Compliance and risk conversation must be held at all levels of the organization
- Attributes
- There is an effective use of tooling and automation throughout the risk and compliance program
- Full evidence collection process defined and implemented
- Ongoing collaboration between internal stakeholders
- Policies encourage strategic contribution to and publication of open source
- Implications
- Products and are fully tested, secured and compliant by design
- Streamlined communication process
- Activities
- Proactively think about new regulations
- Engage and promote compliance program publicly
- Automate the testing of controls as much as possible; add active and continuous auditing
- Attributes
- No open source security policy available
- No automated tooling to identify OSS security issues
- Implications
- Absence of security procedures and guidelines to identify, assess and remediate security issues associated with open source software
- Activities
- Define open source security policies
- Train security teams on open source
- Attributes
- Have a basic security policy that may not be sufficient for managing the potential risks of open source software
- Generic security assessment methodology that is effort- intensive and not scalable
- Implications
- Security assessments of open source software components are random; Increase in security risks of open source applications
- Limited ability to track and manage security issues with changes in open source software
- Limited visibility on open source assets which in turn raises security risks within the organization
- Activities
- Define security procedures and guidelines to consume open source software
- Define a security assessment mechanism to track and manage security issues with changes in open source software.
- Define mechanisms to track all open source assets and evaluate their security posture at planned intervals
- Attributes
- Well defined open source security policy and guidelines to differentiate open source software in terms of security posture; visibility into all open source assets
- Vulnerability management system aligned to open source security vectors; automated security assessment mechanism for open source security
- Security training for teams working on open source software
- Implications
- Availability of remediation measures to address security issues for open source software before consuming them
- Visibility on security stature of all open source assets
- Vulnerability management system provides easy access to identified security issues and their remediation measures for all team members working on open source projects
- Activities
- Define security controls for open source community participation
- Define customized security sandbox environments for open source community contributions to align development security practices and automation with required security controls defined by an organization, government or other entity.
- Define security audits to check for security compliance
- Attributes
- Defined security controls for all open source initiatives – both inbound and outbound
- Conduct periodic security threat assessment
- Conduct security audit on patch compliances across all open source assets
- Monitoring of customized security sandbox environments for open source community initiatives
- Organization performs vulnerability and penetration tests on systems and software but not on a regular basis
- Implications
- Visibility on security stature of all open source community initiatives
- Ability to consume and contribute secured open source software for internal and external community initiatives
- Ability to limit the impact to the business from open source security issues as a result of quick community identification and remediation
- Activities
- Define security governance model and controls for contribution to external open source community initiatives
- Develop an automated mechanism to assess open source software for external contribution; Develop and contribute open source security utilities for community consumption
- Review and refine security remediation measures to address changing security threats
- Attributes
- Security dashboard on all open source community initiatives; security gated controls for release of open source software to external community initiatives
- Open source security utilities to strengthen security of open source community initiatives; organization performs vulnerability and penetration tests on systems and software through automation in SDLC process and at regularly scheduled intervals
- Publications of security assessment reports and remediation measures to enhance security levels of community initiatives
- Implications
- Changing security threats tracked across all open source assets as well as contributions effectively
- Security compliance achieved for all external contributions to community initiatives
- Improve the security posture of external community initiatives
- Activities
- Review and refine security governance models as well as controls to align with changing security threats
- Collaborate on implementing security controls in external community initiatives thus enabling easier adoption of open source software among organizations and institutions
- Attributes
- No defined process for procuring open source software (e.g., uncontrolled downloads by individuals)
- No automation or tooling for managing the open source software/components present in the organization (source code analysis, license validation, updating repositories, etc.…)
- No awareness of open source component lifecycle maintenance
- Implications
- Increased risk exposure due to unmanaged open source
- Increased support and maintenance costs
- Activities
- Evaluate, pilot some initial simple rules and processes for consuming open source
- Attributes
- Initial controls in place. They mostly appear as hurdles that frustrate internal users of open source and slow down ingestion of open source
- Implications
- Use of open source is likely to be hindered by initial controls in place.
- Activities
- Educate management and security and ops teams on principles of open source, and key benefits that can be derived from its use.
- Attributes
- Development processes incorporate open source; organization utilizes some commercially supported open source
- Tools are present to manage and track ingested open source components
- Community accessible open source repository (organization- owned and managed GitHub, or other…)
- Open source training programs in place
- Implications
- There is a point of contact for open source in legal and possibly other teams to manage open source activities
- Activities
- Expand the scope of the tools and processes to support the developer community in their open source activities
- Attributes
- There are governance programs and tools to support developers in their use of, and contribution to, open source
- Development teams use a modern version control system
- Implications
- Tools to support developers are there to allow use and contribution in specific projects for specific benefits
- Comprehensive training programs put in place and enforced for all employees participating in open source activities
- Activities
- Continuing expending the scope and training of the tools and processes to support the developer community in their open source activities
- Attributes
- There are effective processes and tools in place that allow developers to leverage open source fully
- Organization has a multi- tiered open source support model including corporate developers, 3rd party support and commercial open source licenses/subscriptions
- Implications
- Tools are in place, and cover all or most of the areas of open source activities that developers engage in.
- Multiple strategic organization benefits are now targeted, realized and tracked
- Activities
- Continue expanding, or ensuring tooling to empower developers to engage in their open source activities
- Attributes
- Open source code is downloaded without any kind of process or control
- No knowledge of what open source is running inside the organization
- Implications
- Potential security and licensing compliance risk
- No economy of scale for support or shadow IT
- Activities
- Create initial controls to minimize risk
- Begin to support developers with education around potential licensing, compliance, and security risks
- Attributes
- Initial controls typically defined by legal to reduce or block the ingestion of open source code
- Implications
- Open source is used, but not efficiently
- Developers may be able to download open source but will be frustrated by initial controls
- No coherence between different teams on open source management, leading to suboptimal risk management.
- Controls may block developers from downloading code, leading to creation of workarounds
- Activities
- Evolve open source consumption controls into policies, processes, and automation
- Ensure the open source governance encourages and eases consumption of open source while meeting risk management requirements
- Train all relevant stakeholders on open source best practices
- Attributes
- There are initial processes and policies for downloading and using open source
- Processes aren’t standardized across the organization
- Implications
- There may be several versions of the same piece of code across multiple groups within the organization, increasing the risk of missed security patches or other security vulnerabilities and increasing support costs
- Activities
- Standardize open source consumption policies, tools, and processes across the organization
- Offer more advanced training programs
- Attributes
- Open source components are standardized across the organization and there is a formal selection process
- The organization has an approved list of open source projects that require no additional approval
- The organization has an internally- published documentation about its open source consumption policies and procedures
- Implications
- Benefits of using open source are acknowledge across the organization
- Using open source is normalized across the organization
- Component standardization is occurring
- Activities
- Create an internal project or component owners’ model and communities of practice around core open source components
- Set goals and metrics for consumption of open source
- Create training and open source- specific career growth programs
- Attributes
- The organization is becoming open source first, evaluating open source before proprietary software in the acquisitions process
- There are defined goals and metrics for the consumption of OSS
- Open source consumed across the organization through multiple channels with component owners
- Implications
- Multiple benefits of consuming open source identified and measured
- The organization should be seeing increased developer retention and productivity
- Support costs optimized
- Activities
- Establish an ongoing open source technologies evaluation process
- Attributes
- No contribution in any structured way. Employees might contribute on their own time, from their own accounts, or even on company time but nothing is measured
- Implications
- No tracking, no controlling means a high risk of potential IP leaks and no benefits can be identified.
- Activities
- Educate management on possible benefits of contributing to open source projects
- Attributes
- Developers aware of contribution procedure within organization but with very few contributions and no internal review
- Restrictive controls put in place by legal
- Implications
- Controls prevent or hinder contribution to existing open source projects creating possible frustration among developers, possibly leading to workforce attrition.
- Activities
- Educate legal and other key stakeholders so that policies can be put in place to secure without restricting contribution to open source
- Attributes
- Developers contribute code to existing open source projects but with internal reviews first
- Developers are starting to contribute with external communities but in an unplanned manner
- Management understands that there is value to contributing to open source communities
- Implications
- Management is starting to see some benefits of contributing to open source but not necessarily leveraging them
- Activities
- Encourage contributing fixes to existing open source packages used internally
- Consider joining a foundation or community related to key open source packages used internally
- Attributes
- Developers are empowered to contribute to open source projects in use in use by the company
- There are designated contributors to target projects; there are objectives set for achieving maintainer/committer status in target projects
- Participation in foundations aligned with the software used internally has started
- Implications
- Contributing is becoming simpler, there are more and more developers contributing
- Management realizes that contributing generates benefits and provides resources to support contributing
- Activities
- Identify strategic communities and foundations to contribute to and provide support and training
- Open contributing to any employee that desires to do it, and encourage that
- Attributes
- Developers are strongly encouraged to contribute to open source projects and gets rewarded.
- There are objectives set for achieving maintainer/committer status in target projects
- Implications
- Contributors are recognized for their contributions and for the benefits they provide to the organization
- Open source powers open innovation and encourages inter- organizational collaboration
- Activities
- Keep monitoring the open source ecosystem and internal use of open source to identify more projects to contribute to
- Encourage contribution to personal projects as well
- Provide advanced training; provide a rewards program including attending industry events
- Attributes
- No code is published as open source by the organization
- No policy for releasing open source
- Implications
- Missing out on thought leadership and development efficiency.
- Activities
- Educate management on possible benefits of publishing internally developed software as open source.
- Attributes
- Policy is not well defined for releasing to open source
- Code is published as open source by the organization in a very limited and ad- hoc manner
- Implications
- If anything ends up published, it is most likely unsanctioned and a risk for the organization
- Activities
- Educate management on possible benefits of publishing internally developed software as open source.
- Attributes
- Code is published as open source by the organization often but without any structured process or guidelines
- Neither management nor communications understand the value of publishing open source software
- Implications
- No benefits from any kind of publication of software
- Legal is actively preventing all publication through strong controls making it impractical
- Activities
- Educate and prepare legal so that they understand the benefits of, and allow the publication of, internally developed code as open source
- Attributes
- There are initial projects to publish internal software as open source. Although it may be challenging as it requires strong internal advocacy, both with legal and management
- Marketing is aware of published open source projects but not necessarily participating
- The organization has a preferred list of licenses to use when open- sourcing software
- Implications
- Little to no recognition for the publication of any software as open source, Publication of software is seen as a risk and done reluctantly under strong pressure from OSPO and internal developers
- Activities
- Measure the impact of first publications of software and map it to identified business benefits to encourage more publication
- Attributes
- The organization has a comprehensive open sourcing plan with goals and objectives and GTM plans
- Several internal projects are published as open source; management measures KPIs on open source publication
- The organization has a roadmap for publishing multiple projects as open source
- Marketing activities are organized around published open source code
- Implications
- Open source publication is now seen as a strong, visible element of the organization’s open source activities
- Open source publication is leveraged at multiple levels (innovation, marketing, talent acquisition and retention, even feature development) by the organization
- Activities
- Drive more publication of internal software development
- Contribute these projects to open source foundations
- Participate at events around these publications