Those are the recommendations for Free Software communities from the FOSSA project.
Deliverable 5: General Assessment of the European Institutions and FOSS Communities Code Governance Models
In the governance models.
4.1.Roles & Responsibilities
Recommendations for European Institutions
- ensure that all the roles and responsibilities, whether technical or business-related are clearly defined and documented.
- ensure the existence of a Steering Committee/Board of Directors charter document.
Recommendations for FOSS Communities
- ensure the existence of a Steering Committee/Board of Director charter document
- clearly define all the business-related roles and responsibilities(legal area, marketing area, etc.), for all FOSS communities, with emphasis in those that can directly impact the sustainability of the community, like marketing and sponsorship
4.2. Support
Recommendations for European Institutions
- keep the project documentation up to date at all times so as to help end-users and system administrators
4.3 Decision Making
Recommendations for European Institutions
- be aligned with the road map and business objectives, for all projects;
- document the decision making process, following the guidelines provided in section 3.2.1 of the Governance Model
- comply with the approved decision making process.
4.4.Software Governance
Recommendations for European Institutions
- share the code among the projects;
- define software requirements, and classify them according to their nature, i.e. business, functional, technical; have a formal and defined compliance process for software contribution.
Recommendations for FOSS Communities
- define software requirements, and classify them according to their nature, i.e. business, functional, technical.
4.5 Budget
Recommendations for European Institutions
- have a realistic annual budget;
- ensure the funding resources allocation for the whole project lifecycle;
- engage project owners to ensure budget provision for the years ahead.
Recommendations for FOSS Communities
- have a realistic annual budget.
Funding model
Recommendations for European Institutions
- set up a win-win approach for funding open sources projects which are critical for the sustainability of the EUI projects or even beneficial for the society.
Recommendations for FOSS Communities
- diversify funding approaches to engage the major number of sponsors and users willing to use the services, products or extra features;
- create alliances with public and private organisations for resources sharing;
- offer value-added services such as support, training and consulting.
Deliverable 7: Comparative Study
4.1. Project Management
FOSS communities should:
- Use a formal methodology based on PMBOK, depending on their possibilities.
- Promote project management contributions in the community
Software Development Methodology
European Institutions should use
"SecDevOps", to optimise the implementation of security throughout the entire software development life cycle
FOSS communities should use
"SecDevOps" practice, according to their resources, to optimise the implementation of security throughout the entire software development life cycle.
- Agile-based methodologies,according to their resources, so as to make software development more efficient.
- Further measures to cover pending tasks without assigned executors, such as automatic assignment of pending tasks or rewarding the execution of pending tasks among others.
4.3. Software Security Definition
European Institutions and FOSS communities should
- Consider security requirements regardless of whether the software is used internally or installed locally.
4.4. Software Testing
European Institutions should
- Test security regularly for all projects, during the software development life cycle of the project.
- Conduct software security reviews regularly for all projects.
- Foster security awareness, by providing secure development guidelines, and analysing the results of security code reviews.
FOSS communities should
- Increase security expertise in all communities, to perform security tests.
- Conduct all possible security tests for FOSS such as Black box, White box testing, etc.
- Make the test validation process more formal, using standard methodologies such as ITIL
4.5. Release Management
European Institutions should
- Include security in project road maps.
- Include security tests as release requirements for all projects.
FOSS communities should
- Have test environments, if possible
- Implement security testing.
4.6. Inspection and Code Review
European Institutions should
- Make the code review process more formal, for all projects.
- Involve security experts in all projects to inspect the code.
- Promote security awareness in all of the projects.
FOSS communities should
- Conduct a specific security review for each contribution, if possible
4.7. Application Authentication and Authorisation
FOSS communities and European Institutions should
- Use a common module or a common mechanism for authentication, avoiding custom solutions, if applicable.
- If possible, use common models of authorisation, being role-based a good example. Privileges should be easy to change for any set of users.
4.8. Incident Management
European Institutions should
- Find a substitute tool for notifying issues (bugs or vulnerabilities) in the European Institutions’ software.
- Notify end users about issues (bugs or vulnerabilities), for all projects.
- Prepare adequate incident response plans for all projects, trying to avoid shutting down running software.
- Have special, standardised processes for major incidents. It is advisable to have common formal institutional processes so as to face major issues effectively, managed by a special team.
4.9. Problem Management
European Institutions should
- Have a special process for solving critical problems, for all projects.
- Always follow organisations that provide best practices with regard to secure coding, like OWASP, for all projects.
- Consider providing an institutional problem solving plan for all of their projects so as to be efficient.
- Take advantage of their resources and involve their providers in problem detection and problem remediation processes. Also check CERT́s’ information, especially CERT-EU. This should be done for all of theprojects
- Always check vulnerability repositories of software used in the projects and its dependencies, for all projects.
- Consider the usage of bug hunting platforms to find software problems
FOSS communities should
- Always inform vulnerability repositories of FOSS problems, for all communities.
- Always follow organisations that provide best practices about secure coding, like OWASP. For all FOSS communities.
- Always check vulnerability repositories of software used in the projects and its dependencies, for all communities.
- If possible, make use of bug hunting platforms to detect problems in the software
4.10.Licensing
European Institutions should
- Consider what part of their software can be shared (i.e. correctly licensed) so as to join efforts in common necessities, among projects and the European society.
- Before using a FOSS, review the respective license and comply with it.
- Analyse the consequences of using software under some Open Source licenses, as there might be obligations resulting from its usage, e.g. the new software and all related components has to be shared and this might impact the European Institutions Intellectual Property Rights.
FOSS communities should
- Use a common license according to community strategic objectives. Review that contributions are license-compatible.
- Engage the advice of some type of legal support group within or outside of the community
- Dedicate people to watch for the license adherence.