ggi-castalia issueshttps://gitlab.ow2.org/ggi/ggi-castalia/-/issues2021-10-25T13:55:42Zhttps://gitlab.ow2.org/ggi/ggi-castalia/-/issues/45BOK generation script forgets 1st section unless doc starts with a white line2021-10-25T13:55:42ZPierre-Yves GibelloBOK generation script forgets 1st section unless doc starts with a white lineWhen the title of the 1st section in a document (generally "Description" section) is on the 1st line (with no white line before), the whole section is forgotten, and does not appear in the generated PDF.
Inserting a white line works, as...When the title of the 1st section in a document (generally "Description" section) is on the 1st line (with no white line before), the whole section is forgotten, and does not appear in the generated PDF.
Inserting a white line works, as a temporary workaround.https://gitlab.ow2.org/ggi/ggi-castalia/-/issues/44(Trust Goal) Run code reviews2023-05-16T13:11:15ZBoris Baldassari(Trust Goal) Run code reviews
## Description
Code review is a routine task involving manual and/or automated review of an application's source code before releasing a product or delivering a project to the customer. In the case of open-source software, code review ...
## Description
Code review is a routine task involving manual and/or automated review of an application's source code before releasing a product or delivering a project to the customer. In the case of open-source software, code review is more than just about catching errors opportunistically; it is an integrated approach to collaborative development carried out at the team level.
Code reviews should apply to code developed in-house as well as to code reused from external sources, as it improves general confidence in code and reinforces ownership. It is also an excellent way to enhance global skills and knowledge within the team and foster team collaboration.
## Opportunity Assessment
Code reviews are valuable whenever the organisation develops software or reuses external pieces of software.
While being a standard step in the software engineering process, code reviews in the context of open-source bring specific benefits such as:
* When publishing internal source code, verify adequate quality guidelines are respected.
* When contributing to an existing open source project, verify that guidelines of the targeted project are respected.
* The publicly available documentation is updated accordingly.
It is also an excellent opportunity to share and enforce some of your company legal compliance policy rules, such as:
* Never remove existing licence headers or copyrights found in reused open-source code.
* Do not copy & paste source code from Stack Overflow without prior permission from the legal team.
* Include the correct copyright line when required.
Code reviews will bring trust and confidence to code. If people are not sure about the quality or potential risks of using a software product, they should conduct peer- and code- reviews.
## Progress Assessment
The following **verification points** demonstrate progress in this Activity:
- [ ] Open source code review is recognised as a necessary step.
- [ ] Open source code reviews are planned (either regularly or at critical moments).
- [ ] A process for conducting open-source code reviews has been collectively defined and accepted.
- [ ] Open-source code reviews are a standard part of the development process.
## Recommendations
* Code review is a collective task that works better in a good collaborative environment.
* Do not hesitate to use existing tools and patterns from the open-source world, where code reviews have been a standard for years (decades).
## Resources
* [What is Code Review?](https://openpracticelibrary.com/practice/code-review/): a didactic read on code review found on Red Hat's Open Practice Library.
* [Best Practices for Code Reviews](https://www.perforce.com/blog/qac/9-best-practices-for-code-review): another interesting perspective on what code review is about.https://gitlab.ow2.org/ggi/ggi-castalia/-/issues/43(Engagement Goal) Open source procurement policy2023-05-16T13:11:15ZBoris Baldassari(Engagement Goal) Open source procurement policy
## Description
This activity is about implementing a process to select, acquire, purchase open source software and services. It is also about considering the actual cost of open source software and provisioning for it. OSS may be "free...
## Description
This activity is about implementing a process to select, acquire, purchase open source software and services. It is also about considering the actual cost of open source software and provisioning for it. OSS may be "free" at first sight, but it is not without internal and external costs such as integration, training, maintenance and support.
Such policy requires that both open source and proprietary solutions are symmetrically considered when evaluating value for money as the optimum combination of the total cost of ownership and quality. Therefore, the IT Procurement department should actively and fairly consider open source options, while at the same time ensuring proprietary solutions are considered on an equal footing in purchasing decisions.
Open source preference can be explicitly stated based on the intrinsic flexibility of the open source option when there is no significant overall cost difference between proprietary and open source solutions.
Procurement departments must understand that companies offering support for OSS typically lack the commercial resources to participate in procurement competitions, and adapt their open source procurement policies and processes accordingly.
## Opportunity Assessment
Several reasons justify the efforts to set up specific open source procurement policies:
* Supply of commercial open source software and services is growing and cannot be ignored, and requires the implementation of dedicated procurement policies and processes.
* There is a growing supply of highly competitive commercial open source business solutions for corporate information systems.
* Even after adopting a free-of-charge OSS component and integrating it into an application, internal or external resources must be provided to maintain that source code.
* Total Cost of Ownership (TCO) is often (although not necessarily) lower for FOSS solutions: no license fees to pay when purchasing/upgrading, open market for service providers, option to provide some or all of the solution yourself.
## Progress Assessment
The following **verification points** demonstrate progress in this activity:
- [ ] New call for proposals proactively request open source submissions.
- [ ] Procurement department has a way to evaluate open source vs proprietary solutions.
- [ ] A simplified procurement process for open source software and services has been implemented and documented.
- [ ] An approval process drawing from cross-functional expertise has been defined and documented.
## Recommendations
* "Be sure to tap into the expertise of your IT, DevOps, cybersecurity, risk management, and procurement teams when creating the process." (from ["5 Open Source Procurement Best Practices"](https://anchore.com/blog/5-open-source-procurement-best-practices/)).
* Competition law may require that "open source" not be specifically mentioned.
* Select technology upfront then go to RFP for customisation and support services.
## Resources
- [Decision factors for open source software procurement](http://oss-watch.ac.uk/resources/procurement-infopack): not new, but still a great read by our colleagues at OSS-watch in the UK. Check out the [slides](http://oss-watch.ac.uk/files/procurement.odp).
- [5 Open Source Procurement Best Practices](https://anchore.com/blog/5-open-source-procurement-best-practices/): a recent piece on open source procurement with useful hints.https://gitlab.ow2.org/ggi/ggi-castalia/-/issues/42(Usage Goal) Manage open source software development skills and resources2023-05-16T13:11:15ZCedric Thomas(Usage Goal) Manage open source software development skills and resources
## Description
This activity is focused on **software development** skills and resources. It includes the technologies and specific development skills of developers, as well as the overall development processes, methods and tools.
A ...
## Description
This activity is focused on **software development** skills and resources. It includes the technologies and specific development skills of developers, as well as the overall development processes, methods and tools.
A vast amount of documentation, forums and discussions stemming from the ecosystem, and public resources is available for open source technologies. In order to fully benefit from their open source approach, one has to establish a roadmap of its current assets and desired targets to set up a consistent program for development skills, methods and tools within the teams.
#### Domains of application
One needs to establish the domains where the program will be applied, and how it will improve the quality and efficiency of code and practices. As an example, the program won't have the same benefits if there is only a single developer working on open source components, or if the whole development life cycle is optimised to include open source best practices.
One needs to define the scope to be embraced for open source development: technical components, applications, modernising or creating new development. Examples of development practices that can benefit from open source are:
- Cloud administration.
- Cloud-native applications, how to innovate with these technologies.
- DevOps, Continuous Integration / Continuous Delivery.
#### Categories
* Skills and resources required to develop open source software: IP, licensing, practices.
* Skills and resources required to develop software using open source components, languages, technologies.
* Skills and resources required to use open source methods and processes.
## Opportunity Assessment
Open source tools are increasingly popular among developers. This Activity addresses the need to avoid the proliferation of heterogeneous tools within a development team. It helps define a policy in this domain. It helps optimise training and experience building. A skills inventory is used for recruitment, training and succession planning in case a key employee leaves the company.
We would need a methodology to map open source software development skills.
## Progress Assessment
The following **verification points** demonstrate progress in this Activity:
- [ ] There is a description of the open source production chain (the "software supply chain"),
- [ ] There is a plan (or a wish list) for the rationalisation of development resources,
- [ ] There is a skills inventory summarising current developers' skills, education, and experience,
- [ ] There is a training wish list and program dealing with skills gaps,
- [ ] There is a list of missing open source development best practices and a plan to apply them.
## Recommendations
- Start simple, grow the analysis and roadmap steadily.
- When recruiting, set a strong emphasis on open source skills and experience. It's always easier when people already have an open source DNA than training and coach people.
- Check training programs from software vendors and open source schools.
## Resources
More information:
* An introduction to [what is a Skills Inventory?](https://managementisajourney.com/management-toolbox-better-decision-making-with-a-skills-inventory) from Robert Tanner.
* An article about open source skills: [5 Open Source Skills to Up Your Game and Your Resume](https://sourceforge.net/blog/5-open-source-skills-game-resume/)
This activity can include technical resources and skills such as:
- **Popular languages** (such as Java, PHP, Perl, Python).
- **Open source frameworks** (Spring, AngularJS, Symfony) and testing tools.
- Agile, DevOps and open source **development methods and best practices**.
Associated activities:
* [(Culture Goal) HR perspective](https://gitlab.ow2.org/ggi/ggi-castalia/-/issues/28)https://gitlab.ow2.org/ggi/ggi-castalia/-/issues/41Please add me to the Members list :-)2021-04-28T06:12:08ZChristian PatersonPlease add me to the Members list :-)Christian PatersonChristian Patersonhttps://gitlab.ow2.org/ggi/ggi-castalia/-/issues/40(Trust Goal) Run open-source reviews2021-09-28T15:31:00ZCedric Thomas(Trust Goal) Run open-source reviews
## Description
A key element of an open-source compliance program is an **open-source review process**. It means that open-source resources and internal code are regularly audited and reviewed to assess their security and IP & licensin...
## Description
A key element of an open-source compliance program is an **open-source review process**. It means that open-source resources and internal code are regularly audited and reviewed to assess their security and IP & licensing compliance. Open-source reviews can be conducted at specific quality gates (e.g. when a 3rd-party piece of code enters the company), or be integrated into the software development process.
Reviews should cover (may involve multiple sub-reviews):
* Potential breaches of license compliance.
* Staffing: is the code maintained by staff/contractor, community, intermediary (e.g. Tidelift), no one?
* Check open CVEs against this software and its dependencies, and other security-related weaknesses caused by reusing existing open-source third-party components.
* Assess patent risks.
* Variance of the above according to localization/territory of use.
These open-source reviews explicitly refer to activities #23 and #24 and shall be a required step for all project compliance validations.
## Opportunity Assessment
Reviews are valuable inbound (when a new open source project is added to the organizational inventory) and outbound (when code is contributed upstream, sent downstream to a distribution, or shipped to a customer/market). They can be associated with the code reviewing process or set up as standalone audits.
This activity becomes essential when:
* The organization acquires or takes ownership of software assets.
* The organization releases a product or service.
* There is a known security or compliance risk identified in a piece of software.
## Progress Assessment
The following **verification points** demonstrate progress in this Activity:
- [ ] Open source review is recognized as a necessary step.
- [ ] Open source reviews are planned, either regularly or at key events (e.g. when introducing dependencies, acquiring new assets, or releasing a product).
- [ ] A process for conducting open-source reviews has been collectively defined and accepted.
## Tools
* The majority of review tasks should be carried out automatically by CI/CD. Dedicated tools and plugins exist for all major CI/CD engines.
* Check tools from activities #22 and #23.
## Recommendations
* Set up automatic checks that development teams can easily use. Try to lower the barrier to such reviews by providing easy access to a known service, either inside or outside of the organization.
* Open-source review is a collective task that works better in good collaboration.
* Open-source reviews imply assessing and understanding the various use cases of the product (public distribution, distribution to customers, internal use) and its architecture (Front-end, Back-end, SAAS, embedded, Mobile).
## Resources
* This activity was inspired by the OpenChain training curriculum [reference training slides](https://www.openchainproject.org/resources).https://gitlab.ow2.org/ggi/ggi-castalia/-/issues/39(Culture Goal) Upstream first2023-05-16T13:11:15ZCedric Thomas(Culture Goal) Upstream first
## Description
This activity is concerned with developing awareness with regard to the benefits of contributing back and enforcing the upstream first principle.
With the upstream first approach all development on an open source projec...
## Description
This activity is concerned with developing awareness with regard to the benefits of contributing back and enforcing the upstream first principle.
With the upstream first approach all development on an open source project are to be made with the level of quality and openness required to be submitted to a project's core developers and published by them.
## Opportunity Assessment
Writing code with upstream first in mind results in:
* better quality code,
* code that is ready to be submitted upstream,
* code that is merged in the core software,
* code that will be compatible with future version,
* recognition by the project community and better and more profitable cooperation.
> Upstream First is more than just "being kind". It means you have a say in the project. It means predictability. It means you are in control. It means you act rather than react. It means you understand open source. ([Maximilian Michels](https://maximilianmichels.com/2021/upstream-first/))
## Progress Assessment
The following **verification points** demonstrate progress in this Activity: Upstream first is implemented?
- [ ] Significant increase in the number of pull/merge requests submitted to third party projects.
- [ ] A list of third party projects for which upstream first must be applied has been drafted.
## Recommendations
* Identify developers with most experience at interacting with upstream developers.
* Facilitate interaction between developers and core developers (events, hackathons, etc.)
## Resources
* A clear explanation of the Upstream First principle and why it fits in the Culture Goal: https://maximilianmichels.com/2021/upstream-first/.
> Upstream First means that whenever you solve a problem in your copy of the upstream code which others could benefit from, you contribute these changes back upstream, i.e. you send a patch or open a pull request to the upstream repository.
* [What is Upstream and Downstream in Software Development?](https://reflectoring.io/upstream-downstream/) A crystal clear explanation.
* A paper by Dave Neary: [Upstream first: Building products from open source software](https://inform.tmforum.org/features-and-analysis/2017/05/upstream-first-building-products-open-source-software/).
* Explained from the Chromium OS design documents: [Upstream First] (https://www.chromium.org/chromium-os/chromiumos-design-docs/upstream-first).
* Red Hat on upstream and the advantages of [upstream first](https://www.redhat.com/en/blog/what-open-source-upstream).https://gitlab.ow2.org/ggi/ggi-castalia/-/issues/38test2021-04-28T06:14:13ZNicolas Toussainttesthttps://gitlab.ow2.org/ggi/ggi-castalia/-/issues/37(Strategy Goal) Open source enabling digital transformation2022-08-04T13:54:17ZCedric Thomas(Strategy Goal) Open source enabling digital transformation
## Description
> "Digital Transformation is the adoption of digital technology to transform services or businesses, through replacing non-digital or manual processes with digital processes or replacing older digital technology with new...
## Description
> "Digital Transformation is the adoption of digital technology to transform services or businesses, through replacing non-digital or manual processes with digital processes or replacing older digital technology with newer digital technology." (Wikipedia)
When the most advanced organisations in Digital Transformation jointly drive change through their Business, IT and Finance to anchor digital in the way, they reconsider:
- Business model: value chain with ecosystems, as a service, SaaS.
- Finance: opex/capex, people, outsourcing.
- IT: innovation, legacy/asset modernization.
Open source is at the heart of digital transformation:
- Technologies, Agile practices, product management.
- People: collaboration, open communication, development/decision cycle.
- Business models: try & buy, open innovation.
In terms of competitiveness, the most visible processes are probably the processes that directly impact the customer experience. And we have to recognize that the big players, as well as start-up companies, by delivering totally unprecedented customer experience, drastically changed customer expectations.
Customer experience as well as all the other processes within a company entirely depend on IT. Every company has to transform its IT, this is what the digital transformation is about. Companies that have not done it yet, have now to achieve their digital transformation as fast as possible, otherwise the risk is that they could be wiped out of the market. Digital Transformation is a condition for survival. Since the stakes are so high, a company cannot entirely leave the digital transformation to a supplier. Every company has to get hands on with its IT, which means that every company has to get hands on with open source software because there is no IT without open source software.
Expected benefits of the digital transformation include:
* Simplify, automate core processes, make them real-time.
* Enable fast responses to competitive changes.
* Take advantage of Artificial intelligence and big data.
## Opportunity Assessment
Digital transformation could be managed by:
* Segment of the IT : Production IT, Business Support IT (CRM, billing, procurement…), Support IT (HR, Finance, accounting...), Big Data.
* Type of technology or process supporting the IT: Infrastructure (cloud), Artificial Intelligence, Processes (Make-or-Buy, DevSecOps, SaaS).
Injecting open source in a particular segment or technology of your IT reveals that you want to get hands on in this segment or technology, because you assessed that this particular segment or technology of your IT is important for the competitiveness of your company.
It is important to assess the position of your company compared not only with your competitors, but also with other industries, and key players in terms of customer experience and market solutions.
## Progress Assessment
1. Level 1: Situation assessment
* I have identified:
- the segments of IT that are important for the competitiveness of my company, and
- the open source technologies required to develop applications is these segments.
And I have thus decided:
- on which segments I want to manage in-house the development of projects, and
- on which open source technologies I need to build in-house expertise.
2. Level 2: Engagement
* On some selected open source technologies used within the company, several developers have been trained and are recognized as valuable contributors by the open source community.
In some selected segments, projects based upon open source technologies have been launched.
3. Level 3: Generalization
* For all projects, an open source alternative is systematically being investigated during the inception stage of the project. To make it easier for the project team to study such open source alternative, a central budget, and a central team of architects, hosted in the IT Department, is dedicated to providing assistance to the projects.
**KPIs**:
* KPI 1. Ratio for which an open source alternative was investigated: (Number of projects / Total number of projects).
* KPI 2. Ratio for which the open source alternative was chosen: (Number of projects / Total number of projects).
## Recommendations
Beyond the headline, Digital Transformation is a mindset that involves some fundamental changes, and this should also (or even mainly) come from the top-level layers of the organisation. Management shall promote initiatives, new ideas, manage risks, and potentially update existing procedures to make them fit new concepts.
Passion is a huge factor of success. One of the means developed by key players in the field is to set up open spaces for new ideas, where people can submit, and freely work on, their ideas about digital transformation. Management should encourage such initiatives.
## Resources
* [Eclipse Foundation: Enabling Digital Transformation in Europe Through Global Open Source Collaboration](https://outreach.eclipse.foundation/hubfs/EuropeanOpenSourceWhitePaper-June2021.pdf).
* [Europe: Open source software strategy](https://ec.europa.eu/info/departments/informatics/open-source-software-strategy_en#opensourcesoftwarestrategy).
* [Europe: Open source software strategy 2020-2023](https://ec.europa.eu/info/sites/default/files/en_ec_open_source_strategy_2020-2023.pdf).https://gitlab.ow2.org/ggi/ggi-castalia/-/issues/36(Strategy Goal) Open source enabling innovation2022-08-04T13:54:16ZCedric Thomas(Strategy Goal) Open source enabling innovation
## Description
> Innovation is the practical implementation of ideas that result in the introduction of new goods or services or improvement in offering goods or services.
>
> &mdash; <cite>Schumpeter, Joseph A.</cite>
Open source can...
## Description
> Innovation is the practical implementation of ideas that result in the introduction of new goods or services or improvement in offering goods or services.
>
> — <cite>Schumpeter, Joseph A.</cite>
Open source can be a key factor for innovation through diversity, collaboration and a fluent exchange of ideas. People from different backgrounds and domains may have different perspectives and provide new, improved or even disruptive answers to known problems. One can enable innovation by listening to different views and actively promoting open collaboration on projects and topics.
Similarly, participating in the elaboration and implementation of open standards is a great promoter of good practices and ideas to improve the company's daily work. It also allows the entity to drive and influence innovation to where and what it needs, and enhances its global visibility and reputation.
Through innovation, open source makes it possible not only to transform the goods or services that your company markets, but also to create or modify the whole ecosystem in which your company wants to thrive.
As an example, by releasing Android as open source, Google is inviting hundreds of thousands of companies to build up their own services based upon this open source technology. Google is thus creating a whole ecosystem from which all participants could benefit. Of course, very few companies are powerful enough to create an ecosystem by their own decision. But there are many examples of alliances between companies to create such an ecosystem.
## Opportunity Assessment
It is important to assess the position of your company compared with its competitors and its partners and customers because it would often be risky for a company to drift too far away from the standards and technologies used by its customers, partners and competitors. Innovation obviously means being different, but what differs should not represent too large a scope; otherwise, your company would not benefit from the software developments made by the other companies of the ecosystem and from the business momentum the ecosystem provides.
## Progress Assessment
The following **verification points** demonstrate progress in this activity:
- [ ] The technologies -- and open source communities that develop them -- that have an impact on the business have been identified.
- [ ] The progress and publications of these open source communities are monitored -- I am even aware of their strategy before the releases are made public.
- [ ] Employees of the organisation are members of (some of) these open source communities and influence their roadmaps and technical choices by contributing lines of codes and participating in the governance bodies of these communities.
## Recommendations
Out of all the technologies that are necessary to run your business, you should identify:
* the technologies that could be the same as your competitors,
* the technologies that should be specific to your company.
Stay up-to-date on emerging technologies. Open source has been driving innovation for the last decade, and many day-to-day powerful tools come from there (think of Docker, Kubernetes, Apache Big Data projects, or Linux). No need to know everything about everything, but one should know enough of the state of the art to identify interesting new trends.
Allow, and encourage, people to submit innovative ideas, and to bring them forward. If possible, spend resources on these initiatives and make them grow. Rely on people's passion and will to create and foster emerging ideas and trends.
## Resources
* [4 innovations we owe to open source](https://www.techrepublic.com/article/4-innovations-we-owe-to-open-source/).
* [The Innovations of Open Source](https://dirkriehle.com/publications/2019-selected/the-innovations-of-open-source/), from Professor Dirk Riehle.
* [Open source technology, enabling innovation](https://www.raconteur.net/technology/cloud/open-source-technology/).
* [Can Open Source Innovation Work in the Enterprise?](https://www.threefivetwo.com/blog/can-open-source-innovation-work-in-the-enterprise).
* [Europe: Open source software strategy](https://ec.europa.eu/info/departments/informatics/open-source-software-strategy_en#opensourcesoftwarestrategy).
* [Europe: Open source software strategy 2020-2023](https://ec.europa.eu/info/sites/default/files/en_ec_open_source_strategy_2020-2023.pdf).https://gitlab.ow2.org/ggi/ggi-castalia/-/issues/35(Strategy Goal) Open source and digital sovereignty2022-08-04T13:54:16ZCedric Thomas(Strategy Goal) Open source and digital sovereignty
## Description
Digital sovereignty can be defined as the
> “Ability and opportunity of individuals and institutions to execute their role(s) in the digital world independently, intentionally and safely.”
> &mdash; Competence Centre fo...
## Description
Digital sovereignty can be defined as the
> “Ability and opportunity of individuals and institutions to execute their role(s) in the digital world independently, intentionally and safely.”
> — Competence Centre for Public IT, Germany
In order to properly conduct its business, any entity has to rely on some other partners, services, products and tools. Reviewing the ties and constraints of these dependencies enable the organisation to assess and control its dependence towards external factors, thus improving its autonomy and resilience.
As an example, vendor lock-in is a strong factor of dependence that may impede the organisation's processes and added value and as such, it should be avoided. Open source is one of the ways of out this lock. Open source plays a significant role in digital sovereignty, allowing a greater choice between solutions, providers and integrators, and greater control over IT roadmaps.
It should be noted that digital sovereignty is not a trust issue: we obviously need to trust our partners and providers, but the relationship gets even better when it's based on mutual consent and recognition, rather than forced contracts and strains.
Here are some advantages of a better digital sovereignty:
* Improve the ability of the organisation to make its own choices without constraints.
* Improve the resilience of the company regarding external actors and factors.
* Improve negotiating position when dealing with partners and service providers.
## Opportunity Assessment
* How difficult/expensive is it to move away from a solution?
* Could the solution providers impose unwanted conditions on their service (e.g. license change, contracts updates)?
* Could the solution providers unilaterally increase their prices, simply because we do not have a choice?
## Progress Assessment
The following **verification points** demonstrate progress in this Activity:
- [ ] There is an assessment of critical dependencies for the organisation's providers and partners.
- [ ] There is a backup plan for these identified dependencies.
- [ ] There is a stated requirement for digital sovereignty when new solutions are investigated.
## Recommendations
* Identify key dependency risks from service providers and 3rd party entities.
* Maintain a list of open-source alternatives to critical services.
* Add a requirement when selecting new tools and services used within the entity, stating the need for digital sovereignty.
## Resources
* [A Primer on Digital Sovereignty & Open Source: part I](https://www.opensourcerers.org/2021/08/09/a-promer-on-digital-sovereignty/) and [A Primer on Digital Sovereignty & Open Source: part II](https://www.opensourcerers.org/2021/08/16/a-primer-on-digital-sovereignty-open-source/), from the Open-Sourcerers website.
* An excellent superuser.openstack.org article on [The Role of Open Source in Digital Sovereignty](https://superuser.openstack.org/articles/the-role-of-open-source-in-digital-sovereignty-openinfra-live-recap/). Here is a short extract:
> Digital Sovereignty is a key concern for the 21st century, especially for Europe. Open source has a major role to play in enabling digital sovereignty, by allowing everyone to access the necessary technology, but also by providing the governance transparency and interoperability necessary for those solutions to succeed.
* The European Union's take on digital sovereignty, from the [Open Source Observatory (OSOR)](https://joinup.ec.europa.eu/collection/open-source-observatory-osor): Open Source, digital sovereignty and interoperability: The Berlin Declaration.
* The UNICEF's position on [Open Source for Digital Sovereignty](https://www.unicef.org/innovation/stories/open-source-digital-sovereignty).https://gitlab.ow2.org/ggi/ggi-castalia/-/issues/34(Strategy Goal) C-Level awareness2022-08-04T13:54:16ZCedric Thomas(Strategy Goal) C-Level awareness
## Description
The open source initiative of the organisation will yield its strategic benefits only if it is enforced at its highest levels by integrating the open source DNA into the company's strategy and internal working. Such comm...
## Description
The open source initiative of the organisation will yield its strategic benefits only if it is enforced at its highest levels by integrating the open source DNA into the company's strategy and internal working. Such commitment cannot happen if higher-level executives and top management are not themselves a part of it. The training and open source mindset must also be extended to those who shape the policies, decisions and overall strategy, both inside and outside the company.
This commitment ensures that practical improvements, mindset changes and new initiatives are met with consistent, benevolent and sustainable support from the hierarchy, bringing in more fervent participation from workers. It shapes how external actors see the organisation, bringing in reputational and ecosystem benefits. It is also a means to establish the initiative and its benefits in the mid and long term.
## Opportunity Assessment
This activity becomes essential if/when:
* The organisation has set global goals relevant to open source management, but struggles to achieve them. It is unlikely that the initiative can achieve anything without good knowledge and a clear commitment from higher-level executives.
* The initiative has already started and is making progress, but the higher levels of the hierarchy do not follow it up properly.
Hopefully, it should become evident that anything but ad hoc usage of open source requires a consistent and well-thought approach, given the range of teams and cultural change it can bring.
## Progress Assessment
The following **verification points** demonstrate progress in this Activity:
- [ ] There is a mandated governance office/officer empowered to set a uniform open source strategy across the company and ensure that the scope is clear.
- [ ] There is a clear, binding commitment from the hierarchy to the OSS strategy.
- [ ] There is transparent communication by the hierarchy about its commitment to the program.
- [ ] The hierarchy is available to discuss open source software. It can be solicited and challenged on its promises.
- [ ] There is an appropriate budget and funding for the initiative.
## Recommendations
Examples of actions associated with this activity include:
* Conduct training to demystify OSS to C-level management.
* Obtain explicit, practical endorsement for OSS usage and strategy.
* Explicitly mention and endorse the OSS program in internal communications.
* Explicitly mention and endorse the OSS program in public communications.
Open source is a _strategic enabler_ that embarks _enterprise culture_. What does this mean?
* Open source can be leveraged as a mechanism to disrupt suppliers and reduce software acquisition costs.
* Should open source come under the purview of _Software Asset Managers_ or _purchasing departments_?
* Open source licenses enshrine the freedoms that deliver the benefits of open source, but they also carry _obligations_. If not met appropriately, responsibilities can create legal, commercial and image risks to an organisation.
* Will license conditions grant visibility into areas of code that should remain confidential?
* Will it impact my organisation's patent portfolio?
* How should project teams be trained and supported on this subject?
* Contributing back to external open source projects is where the biggest value of open source lies.
* How should my company encourage (and track) this?
* How should developers use GitHub, GitLab, Slack, Discord, Telegram, or any of the other tools open source projects habitually use?
* Can open source impact the company's HR policies?
* Of course, it's not all about contributing back, what about my own open source projects?
* Am I ready to do _open_ innovation?
* How will my projects manage _incoming_ contributions?
* Should I spend the effort to nurture a community for a given project?
* How should I lead the community, what role should community members have?
* Am I ready to cede roadmap decisions to a community?
* Can open source be a valuable tool to reduce silo-isation between company teams?
* Do I need to handle open source transfer from one company entity to another?https://gitlab.ow2.org/ggi/ggi-castalia/-/issues/33(Engagement Goal) Engage with open source vendors2023-05-16T13:11:15ZCedric Thomas(Engagement Goal) Engage with open source vendors
## Description
Secure contracts with open source vendors that provide software critical to you. Companies and entities that produce open source software need to thrive to provide maintenance and development of new features. Their speci...
## Description
Secure contracts with open source vendors that provide software critical to you. Companies and entities that produce open source software need to thrive to provide maintenance and development of new features. Their specific expertise is required on the project, and the community of users relies on their continued business and contributions.
Engaging with open source vendors takes several forms:
* Subscribing support plans.
* Contracting local service companies.
* Sponsoring developments.
* Paying for commercial licence.
This activity implies considering open source projects as fully-featured products worth paying for, much like any proprietary products -- although usually far less expensive.
## Opportunity Assessment
The objective of this activity is to ensure professional support of open source software used in the organisation. It has several benefits:
* Continuity of service through timely bug fixes.
* Service performance through optimised installation.
* Clarification of the legal/commercial status of the software used.
* Access to early information.
* Stable budget forecast.
The cost is obviously that of the support plans selected. Another cost might be to depart from bulk outsourcing to large systems integrators in favour of fine-grained contracting with expert SMEs.
## Progress Assessment
The following **verification points** demonstrate progress in this activity:
- [ ] Open source used in the organisation is backed by commercial support.
- [ ] Support plans for some open source have been contracted.
- [ ] Cost of open source support plans is a legitimate entry in the IT budget.
## Recommendations
* Whenever possible, find local expert SMEs.
* Beware of large systems integrators reselling third-party expertise (reselling support plans that expert open source SMEs actually provide).
## Resources
A couple of links illustrating the commercial reality of open source software:
* [An investor's view of the community to business evolution of open source projects](https://a16z.com/2019/10/04/commercializing-open-source/).
* [A quick read to understand commercial open source](https://www.webiny.com/blog/what-is-commercial-open-source).https://gitlab.ow2.org/ggi/ggi-castalia/-/issues/32(Engagement Goal) Publicly asserting use of open source2021-09-08T10:50:29ZCedric Thomas(Engagement Goal) Publicly asserting use of open source
## Description
_Please provide a description of the activity._
* Providing success stories
* Presenting at events
## Opportunity Assessment
_Why it is relevant to undertake this activity, What needs it addresses. What are the efforts...
## Description
_Please provide a description of the activity._
* Providing success stories
* Presenting at events
## Opportunity Assessment
_Why it is relevant to undertake this activity, What needs it addresses. What are the efforts expected. How much will it cost? What resources do we need? What RoI can be gained?_
* Benefits include HR attractiveness, innovator reputation
## Progress Assessment
_Question: How can I assess if the activity is acquired? How will progress be measured. What are the objectives? What are the KPIs? Suggest verification point._
>Add KPI description here
## Tools
_Technologies, tools and products concerned by this activity._
>List tools relevant or concerned by the activity here
## Recommendations
_Hints and best practices. Collected from GGI participants._
>Add recommendations here
## Resources
_Links to resources in the Resource Center_
>Add links to resources herehttps://gitlab.ow2.org/ggi/ggi-castalia/-/issues/31(Engagement Goal) Publicly assert use of open source2023-05-16T13:11:15ZCedric Thomas(Engagement Goal) Publicly assert use of open source
## Description
This Activity is about acknowledging the use of OSS in an information system, in applications and in new products.
* Providing success stories.
* Presenting at events.
* Funding participation to events.
## Opportunity ...
## Description
This Activity is about acknowledging the use of OSS in an information system, in applications and in new products.
* Providing success stories.
* Presenting at events.
* Funding participation to events.
## Opportunity Assessment
It is now generally accepted that most information systems run on OSS, and that new applications are for the most part made by reusing OSS.
The main benefit of this activity is to create a level playing field between OSS and proprietary software, to make sure OSS is paid equal attention to and managed just as professionally as proprietary software.
A side benefit is that it greatly helps raise the profile of the OSS ecosystem and, since OSS users are identified as "innovators" it also enhances the attractiveness of the organisation.
## Progress Assessment
The following **verification points** demonstrate progress in this activity:
- [ ] Commercial open source vendors are granted authorization to use organisation's name as customer reference.
- [ ] Contributors are allowed to do so and express themselves under the organisation's name.
- [ ] Use of OSS is openly mentioned in the IT department annual report.
- [ ] There is no obstacle to the organisation explaining their use of OSS in the media (interviews, OSS and industry event, etc.).
## Recommendations
* The objective of this activity is not for the organisation to become an OSS activism body, but to make sure there is no obstacle to the public recognising its use of OSS.
## Resources
* Example of [CERN](https://superuser.openstack.org/articles/cern-openstack-update/) publicly asserting their use of OpenStackhttps://gitlab.ow2.org/ggi/ggi-castalia/-/issues/30(Engagement Goal) Support open source communities2023-05-16T13:11:15ZCedric Thomas(Engagement Goal) Support open source communities
## Description
This activity is about engaging with institutional representatives of the open source world.
It is achieved through:
* Joining OSS foundations (including the financial cost of membership).
* Supporting, advocating foun...
## Description
This activity is about engaging with institutional representatives of the open source world.
It is achieved through:
* Joining OSS foundations (including the financial cost of membership).
* Supporting, advocating foundations activities.
This activity involves allocating the development and IT teams some time and budget to participate in open source communities.
## Opportunity Assessment
Open source communities are at the forefront of the evolution of the open source ecosystem. Engaging with open source communities has several advantages:
* it helps keep informed and up to date,
* it enhances the profile of the organisation,
* membership comes with benefits,
* it provides additional structure and motivation to the open source IT team.
Costs include:
* membership fees,
* personnel time and some travel budget allocated to participate in community activities,
* monitoring of IP commitment.
## Progress Assessment
The following **verification points** demonstrate progress in this Activity:
- [ ] The organisation is a signed member of an open source foundation.
- [ ] The organisation participates in the governance.
- [ ] Software developed by the organisation is submitted to / has been added to the code base of a foundation.
- [ ] Membership is acknowledged on the websites of both the organisation and the community.
- [ ] Performed cost/benefit assessment of the membership.
- [ ] A contact point for the community has been appointed.
## Recommendations
* Join a community compatible with your size and resources, i.e., a community that can hear your voice and where you can be a recognized contributor.
## Resources
* Check out this [useful page](https://www.linuxfoundation.org/tools/participating-in-open-source-communities/) from the Linux Foundation on the why and how to join an open source community.https://gitlab.ow2.org/ggi/ggi-castalia/-/issues/29(Engagement Goal) Engage with open source projects2023-05-16T13:11:15ZCedric Thomas(Engagement Goal) Engage with open source projects
## Description
This activity is about committing significant contributions to some OSS projects that are important to you. Contributions are scaled up and committed at the organisation level (not personal level as in #26). They can tak...
## Description
This activity is about committing significant contributions to some OSS projects that are important to you. Contributions are scaled up and committed at the organisation level (not personal level as in #26). They can take several forms, from direct funding to resources allocation (e.g. people, servers, infrastructure, communication, etc.), as long as they benefit the project or ecosystem sustainably and efficiently.
This activity is a follow-up on activity #26 and brings open source projects' contributions to the level of the organisation, making them more visible, powerful, and beneficial. In this activity, the contributions are supposed to bring a substantial, long-term improvement to the OSS project: e.g., a developer or team who develops a much-wanted new feature, infrastructure assets, servers for a new service, take-over of the maintenance of a widely used branch.
The idea is to set aside a percentage of resources to sponsor open source developers that write and maintain libraries or projects that we use.
This activity implies to have a mapping of open source software used, and an evaluation of their criticality to decide which one to support.
## Opportunity Assessment
> If every company using open source contributed at least a little, we would have a healthy ecosystem. https://news.ycombinator.com/item?id=25432248
Supporting projects helps ensure their sustainability and provides access to information, even maybe help influence and prioritize some developments (although this should not be the main reason for supporting projects).
Potential benefits of this activity: ensuring bug reports are prioritized and developments are integrated into the stable version.
Possible costs associated with the activity: committing time to projects, cash commitment.
## Progress Assessment
The following **verification points** demonstrate progress in this activity:
- [ ] Beneficiary project identified.
- [ ] Support option decided, such as direct monetary contribution or code contribution.
- [ ] Task leader appointed.
- [ ] Some contribution has happened.
- [ ] Result of contribution has been evaluated.
Verification points borrowed from OpenChain [self certification](https://certification.openchainproject.org/) questionnaire:
- [ ] We have a policy for contribution to open source projects on behalf of the organisation.
- [ ] We have a documented procedure governing open source contributions.
- [ ] We have a documented procedure for making all Software Staff aware of the open source contribution policy.
## Tools
Some organisations offer mechanisms for funding open source projects (it could be convenient if your target project is in their portfolios).
* [Open Collective](https://opencollective.com/).
* [Software Freedom Conservancy](https://sfconservancy.org/).
* [Tidelift](https://tidelift.com/).
## Recommendations
* Concentrate on projects that are critical for the organisation: these are the projects you most want to help with your contributions.
* Target community projects.
* This activity requires a minimum familiarity with a target project.
## Resources
* [How to support open source projects now](https://sourceforge.net/blog/support-open-source-projects-now/): A short page with ideas on funding open source projects.
* [Sustain OSS: a space for conversations about sustaining open source](https://sustainoss.org)https://gitlab.ow2.org/ggi/ggi-castalia/-/issues/28(Culture Goal) HR perspective2023-05-16T13:11:15ZCedric Thomas(Culture Goal) HR perspective
## Description
Switching to open source culture has deep HR impacts:
* **New processes and contracts**: Contracts have to be adapted to allow and promote external contributions. This includes IP and licensing issues for work done with...
## Description
Switching to open source culture has deep HR impacts:
* **New processes and contracts**: Contracts have to be adapted to allow and promote external contributions. This includes IP and licensing issues for work done within the company, but also the ability for the employee or contractor to have their own projects.
* **Different types of people**: People working with open source often have different incentives and mindsets than with pure proprietary, corporate people. Processes and mindsets need to adapt to this community reputation-oriented paradigm, in order to attract new types of talent and retain them along.
* **Career development**: need to offer a career path that nurtures and values employees for their technical and soft skills as well as the competencies expected by your organisation (collaboration to drive community efforts, communication to act as spokesperson for your company, etc.). By all means, HR has a key role in enabling open source as a cultural goal.
**Workforce**
For a developer who has been working on the same proprietary solution for a long time, switching to open source may seem quite a change, and require adaptation. But for most developers, open source software only brings benefits.
Developers getting out of school or university today have all always been working on open source. Within a company, the large majority of developers are using open source languages and importing open source libraries or snippets every day. It is indeed much easier to paste lines of open source code in a program than to trigger the internal sourcing process, which escalates through multiple validations through the management line.
Open source makes the job of the developer more interesting because with open source, a developer is always on the lookout to find out what their peers outside the company have been inventing, and therefore remains on the cutting edge of the technology.
For an organisation, there needs to be an HR strategy to 1/ skill or re-skill the existing workforce 2/ reflect and position the company on hiring new talents hence what is the attractiveness of the company when it comes to open source.
> Getting people with a good FLOSS mindset, who already understand the code, and know how to work well with others is wonderful. The alternative of evangelizing / training / interning is worth doing but more expensive & time consuming.
>
> — <cite>OSS Software Vendor CEO</cite>
This illustrates that hiring people with open source DNA is an acceleration path to consider in HR strategy.
#### Processes
- Establish or revisit job descriptions (technical skills, soft skills, competencies and experiences)
- Training programs: self-training, formal training, management coaching, peer mapping, communities
- Establish or revisit career path: competencies, key results/impact and career steps
## Opportunity Assessment
1. Frame development practices: the problem is probably not so much to spur developers to use more open source, but rather to make sure that they use it safely, in compliance with the licensing terms of each open source technology, and without abandoning traditional security checks (open source lines of code could contain malicious codes),
2. Revisit collaboration practices: with development practices, the opportunity is to extend the agility and collaboration to other lines of business in your organisation. Inner sourcing is often used to foster these behaviours, though this might be half of the way to open source culture,
3. Organisation's culture: in the end, this is all about your organisation's culture: open source can be the flagship for values such as openness, collaboration, ethics, sustainability.
## Progress Assessment
The following **verification points** demonstrate progress in this Activity:
- [ ] Training is available for presenting both the benefits and the constraints (Intellectual Property licensing terms compliance) related to open source.
- [ ] Every developer, every architect, every project leader (or Product Owner/Business Owner), understands the benefits and the constraints (Intellectual Property licensing terms compliance) related to open source.
- [ ] Developers are encouraged to contribute to open source communities, and take responsibility for them, and could receive adequate training to do it.
- [ ] Skills and competencies are reflected in organisation job descriptions and career steps.
- [ ] The experience that developers acquired in open source (contributions to open source communities, participation in the internal compliance process, external spoke persons for the company...) is taken into account in the HR evaluation process.
## Tools
* Skills matrix.
* Public training programs (ex. open source school).
* Sourcing: GitHub, GitLab, LinkedIn, Meetups, Epitech, Epita ...
* Contract templates (Loyalty clause).
* Job descriptions (templates) & career steps (templates).
## Recommendations
Most of the time nowadays, developers already know some open source principles and are willing to work with, and on, open source software. However, there are still a few actions that the management should take:
* Preference for OSS experience in hiring, even though the job for which the developer is being hired only relates to proprietary technology. Chances are, with the digital transformation, that the developer will someday have to work on open source.
* OSS training program: Every developer, every architect, every project leader (or Product Owner/Business Owner), should have access to training resources (videos or face-to-face training) that present the benefits of open source and also the constraints in terms of Intellectual Property and licensing compliance.
* Training should be made available for developers who want to contribute to open source communities and be part of the governance bodies of these communities (Linux certifications).
* Recognition in the HR personal assessment processes of the contribution of the employee (developer or architect) to open source related topics such as contributions to open source communities and compliance with Intellectual Property licensing terms. Most topics are shared and fit into technical career paths, whereas some might or should be specific.
* Best kept secret and company posture: need to address the communication aspects (how core this is to your organisation that it might be reflected in your annual report), how does it impact your communication posture (an open source contributor could be a spoke person for your company including press contacts).
## Resources
* Regarding the ability of people to speak outside the company during events, please see Activity 31: "(Engagement Goal) Publicly asserting the use of open source".https://gitlab.ow2.org/ggi/ggi-castalia/-/issues/27(Culture Goal) Belong to the open source community2023-05-16T13:11:15ZCedric Thomas(Culture Goal) Belong to the open source community
## Description
This activity is about developing among developers a feeling of belonging to the greater open source community. As with every community, people and entities have to participate and contribute back to the whole. It reinfo...
## Description
This activity is about developing among developers a feeling of belonging to the greater open source community. As with every community, people and entities have to participate and contribute back to the whole. It reinforces the links between practitioners and brings sustainability and activity to the ecosystem. On a more technical side, it allows choosing the priorities and roadmap of projects, improves the level of general knowledge and technical awareness.
This activity covers the following:
* **Identify events** worth attending. Connecting people, learning about new technologies and building a network are key factors to get the full benefits of open-source.
* Consider **foundation memberships**. Open-source foundations and organizations are a key component of the open-source ecosystem. They provide technical and organizational resources to projects, and are a good neutral place for sponsors to discuss common issues and solutions, or work on standards.
* Watch **working groups**. Working groups are neutral collaborative workspace where experts interact on a specific domain like IoT, modelling or science. They are a very efficient and cost-effective mechanism to tackle common, albeit domain-specific concerns together.
* **Budget participation**. At the end of the journey, money is the enabler. Plan required expenses, allow people paid time for these activities, anticipate next moves, so the program doesn't have to stop after a few months short of funding.
## Opportunity Assessment
Open source works best when done in relation with the open source community at large. It facilitates bug fixing, solution sharing, etc.
It is also a good way for companies to show their support to open-source values. Communicating about the company's involvement is important both for the company's reputation and for the open-source ecosystem.
## Progress Assessment
The following **verification points** demonstrate progress in this Activity:
- [ ] A list of events people could attend is drafted.
- [ ] There is a monitoring of public talks given by team members.
- [ ] People can submit events participation requests.
- [ ] People can submit projects for sponsorship.
## Recommendations
* Survey people to get to know what events they like or would be the most beneficial for their work.
* Set up in-house communications (newsletter, resource centre, invitations…) so people know about the initiatives and can participate.
* Make sure that these initiatives can benefit various types of people (developers, administrators, support…), not only C-level executives.
## Resources
* [What motivates a developer to contribute to open source software?](https://clearcode.cc/blog/why-developers-contribute-open-source-software/) An article by Michael Sweeney on clearcode.cc.
* [Why companies contribute to open source](https://blogs.vmware.com/opensource/2020/12/01/why-companies-contribute-to-open-source/) An article by Velichka Atanasova from VMWare.
* [Why your employees should be contributing to open source](https://www.cloudbees.com/blog/why-your-employees-should-be-contributing-to-open-source/) A good read by Robert Kowalski from CloudBees.
* [7 ways your company can support open source](https://www.infoworld.com/article/2612259/7-ways-your-company-can-support-open-source.html) An article from Simon Phipps for InfoWorld.
* [Events: the life force of open source](https://www.redhat.com/en/blog/events-life-force-open-source) An article by Donna Benjamin from RedHat.https://gitlab.ow2.org/ggi/ggi-castalia/-/issues/26(Culture Goal) Contribute to open source projects2022-08-04T13:54:12ZCedric Thomas(Culture Goal) Contribute to open source projects
## Description
Contributing to open source projects that are freely used is one of the key principles of good governance. The point is to avoid being a simple passive consumer and give back to the projects. When people add a feature or...
## Description
Contributing to open source projects that are freely used is one of the key principles of good governance. The point is to avoid being a simple passive consumer and give back to the projects. When people add a feature or fix a bug for their own purpose, they should make it generic enough to contribute to the project. Developers must be allowed time for contributions.
This activity covers the following scope:
* Working with upstream open source projects.
* Reporting bugs and feature requests.
* Contributing code and bug fixes.
* Participating in community mailing lists.
* Sharing experience.
## Opportunity Assessment
The main benefits of this activity are:
* It increases the general knowledge and commitment to open source within the company, as people start contributing and get involved in open source projects. They get a feeling of public utility and improve their personal reputation.
* The company increases its visibility and reputation as contributions make their way through the contributed project. This shows that the company is actually involved in open source, contributes back, and promotes fairness and transparency.
## Progress Assessment
The following **verification points** demonstrate progress in this Activity:
- [ ] There is a clear and official path for people willing to contribute.
- [ ] Developers are encouraged to contribute back to open source projects they use.
- [ ] A process is in place to ensure legal compliance and security of contributions by developers.
* KPI: Volume of external contributions (code, mailing lists, issues..) by individual, team, or entity.
## Tools
It may be useful to follow contributions, both to keep track of what is contributed and to be able to communicate on the company's effort. Dashboards and activity tracking software can be used for this purpose. Check:
* Bitergia's [GrimoireLab](https://chaoss.github.io/grimoirelab/)
* [Alambic](https://alambic.io)
* [ScanCode](https://scancode-toolkit.readthedocs.io)
## Recommendations
Encourage people within the entity to contribute to external projects, by:
* Allowing them time to write generic, well-tested bug fixes and features, and to contribute them back to the community.
* Providing training to people about contributing back to open source communities. This is both about technical skills (improve your team's knowledge) and community (belonging to the open source communities, code of conduct, etc.).
* Provide training on legal, IP, technical issues, and set up a contact within the company to help with these topics if people have doubts.
* Provide incentives for published work.
* Note that contributions from the company/entity will reflect its code quality and involvement, so make sure your development team provides code that is good enough.
## Resources
* The [CHAOSS](https://chaoss.community/) initiative from the Linux Foundation has some tools and pointers about how to track contributions in development.