UPSTREAM.ECLIPSE.ECLIPSE
UPSTREAM.ECLIPSE.ECLIPSE-BUILD_INSTRUCTIONS | Reviewed: ✔ | Score: 0.0
An Eclipse project publicly documents build instructions that are easily reproducible.
Supported Requests:
| Item | Summary | Score | Status |
|---|---|---|---|
| UPSTREAM.TSF.TA-RELEASES | Construction of XYZ releases is fully repeatable and the results are fully reproducible, with any exceptions documented and justified. | 0.15 | ✔ Item Reviewed ✔ Link Reviewed |
Supporting Items:
None
References:
None
The Eclipse Foundation Project Handbook (section Project Resources and Services/Builds), as well as the Eclipse Foundation Project Handbook (section Legal documentation requirements / Contributor Guide), states that (please refer to the official Eclipse document for definitive and canonical definitions):
Eclipse projects must ensure that community members can build project artifacts from source with reasonable effort, regardless of whether they use the Eclipse Foundation’s Common Build Infrastructure (CBI) or their own build systems. Projects are encouraged to use CBI but are not strictly required to do so.
To support adoption and contributions, projects should maintain a Contributor Guide (typically CONTRIBUTING.md in the repository root). This file must be concise, accessible, and include:
- Project name and description
- Links to the project website and documentation
- Eclipse Foundation Terms of Use
- Main communication channel(s)
- Canonical source repositories
- Clear build and contribution instructions (e.g., how to submit pull requests)
- Link to sign the Eclipse Contributor Agreement (ECA)
Optional additions include links to downloads and more detailed contribution documentation. Well-documented build instructions and contribution guidance ensure transparency, reduce barriers for new contributors, and strengthen the project’s community and sustainability.
Evidence for compliance might include (but is not limited to):
- README.md and CONTRIBUTING.md files in project repositories
- Developer documentation on project websites
UPSTREAM.ECLIPSE.ECLIPSE-CODE_REVIEW | Reviewed: ✔ | Score: 0.0
Any changes to an Eclipse projects always go through review, and are only merged on approval.
Supported Requests:
| Item | Summary | Score | Status |
|---|---|---|---|
| UPSTREAM.TSF.TA-METHODOLOGIES | Manual methodologies applied for XYZ by contributors, and their results, are managed according to specified objectives. | 0.12 | ✔ Item Reviewed ✔ Link Reviewed |
Supporting Items:
None
References:
None
The Eclipse Foundation Project Handbook (section Project Resources and Services) states that (please refer to the official Eclipse document for definitive and canonical definitions):
Eclipse Foundation projects must use the provided infrastructure and follow practices that ensure high-quality, auditable contributions.
Key requirements include:
- Version control and attribution: All source code must be maintained in Eclipse-managed Git repositories (GitLab or GitHub), ensuring full traceability of changes and contributor attribution.
- Code reviews: Projects are strongly encouraged to enforce peer reviews for all contributions. Changes should only be merged after review and explicit approval by another committer, ensuring code quality and shared ownership.
- Issue tracking: All bugs and feature requests must be tracked in Eclipse-managed issue trackers, with links between commits and issues to document the rationale behind changes.
- Third-party content review: Any external dependencies must be vetted for compliance with licensing and intellectual property requirements.
- Metadata and governance: Projects must keep their metadata current and use Eclipse services for builds, communication, and artifact signing, ensuring transparency and proper oversight.
By adopting peer reviews and approval-based merging, projects build trust, maintain high standards of quality, and encourage collaboration in a transparent, community-driven way.
Evidence for compliance might include (but is not limited to):
- Git commit history with author attribution
- Pull/merge request records with review history
UPSTREAM.ECLIPSE.ECLIPSE-COMMIT_RECORDS | Reviewed: ✔ | Score: 0.0
Eclipse project commit records have a consistent form, include the author and should reference the issue that they are addressing.
Supported Requests:
| Item | Summary | Score | Status |
|---|---|---|---|
| UPSTREAM.TSF.TA-METHODOLOGIES | Manual methodologies applied for XYZ by contributors, and their results, are managed according to specified objectives. | 0.12 | ✔ Item Reviewed ✔ Link Reviewed |
Supporting Items:
None
References:
None
The Eclipse Foundation Project Handbook (section Project Resources and Services / Git Commit Records) and Eclipse Foundation Project Handbook (section Community / Issues states that (please refer to the official Eclipse document for definitive and canonical definitions):
Eclipse Foundation projects must follow rules for Git commits to ensure transparency, traceability, and legal compliance.
Key requirements:
Author identity
- The Author field must include the contributor’s real legal name and a valid email address.
- The email must match the address registered with the Eclipse Foundation (case-sensitive).
- The contributor must have a signed Eclipse Contributor Agreement (ECA) on file.
Commit message structure
- Summary line (max 72 characters): A clear, self-contained description of the change. Best practice: include the bug/issue ID.
- Description: A detailed explanation of what was changed and why.
- Footer: Optional metadata, such as additional authors.
Co-authors
- Use Also-by: or Co-authored-by: entries for additional contributors, each with their real name and Eclipse-registered email address.
- All additional authors must also have signed the ECA.
Best practice
- Keep summary lines meaningful because they appear in commit listings.
- Use the description and footer for additional context and attribution.
- Link commits to relevant issue tracker entries whenever possible.
Following these rules guarantees proper attribution, legal compliance, and clear project history.
Evidence for compliance might include (but is not limited to):
- Project Commit Records
UPSTREAM.ECLIPSE.ECLIPSE-CONSTRUCTIVE_CULTURE | Reviewed: ✔ | Score: 0.0
An Eclipse project handles bug reports, discussions and decisions in a healthy, constructive and welcoming manner, and that issues raised against the project are addressed in a timely manner.
Supported Requests:
| Item | Summary | Score | Status |
|---|---|---|---|
| UPSTREAM.TSF.TA-METHODOLOGIES | Manual methodologies applied for XYZ by contributors, and their results, are managed according to specified objectives. | 0.12 | ✔ Item Reviewed ✔ Link Reviewed |
Supporting Items:
None
References:
None
The Eclipse Foundation Project Handbook (section Community) states that (please refer to the official Eclipse document for definitive and canonical definitions):
Eclipse projects are expected to actively foster a welcoming, constructive, and responsive community. All discussions, decisions, and issue tracking must take place publicly and respectfully to encourage participation, lower barriers for contributors, and grow a diverse and vibrant project ecosystem.
Key expectations for project teams:
- Welcoming communication: Maintain polite, professional, and supportive discussions in all public channels (forums, mailing lists, issue trackers). Negative or dismissive behavior is discouraged.
- Constructive issue management: Respond to all questions and reported issues promptly. Clearly distinguish between defects and feature requests, and ensure that issues are tracked and updated visibly.
- Transparency: Capture project decisions, schedules, and milestones in public forums, inviting community input.
- Responsiveness: No question or issue should remain unanswered for long; timely engagement is crucial to building trust and respect.
- Empowerment: Encourage the community to answer questions and contribute, while providing guidance or corrections politely if needed.
- Traceability: Link commits to their related issues so that discussions and decisions can be easily followed and understood.
By maintaining open, respectful communication and resolving issues efficiently, projects build credibility, attract contributors, and ensure the long-term success of their ecosystem.
Evidence for compliance might include (but is not limited to):
- Project repository, related infrastructure like discussion boards and issue trackers
UPSTREAM.ECLIPSE.ECLIPSE-CONTRIBUTION_PROCESS | Reviewed: ✔ | Score: 0.0
The contribution process for an Eclipse project is publicly documented and consistently followed.
Supported Requests:
| Item | Summary | Score | Status |
|---|---|---|---|
| UPSTREAM.TSF.TA-METHODOLOGIES | Manual methodologies applied for XYZ by contributors, and their results, are managed according to specified objectives. | 0.12 | ✔ Item Reviewed ✔ Link Reviewed |
Supporting Items:
None
References:
None
The Eclipse Foundation Project Handbook (section Legal Documentation Requirements/Contributor Guide) states that (please refer to the official Eclipse document for definitive and canonical definitions):
Eclipse projects are required to provide a clearly documented and publicly accessible contribution process to lower barriers for new contributors and support community growth. This is typically done through a CONTRIBUTING.md file placed in the root of each repository.
The contribution guide should be concise, easy to read, and include:
- Project name and brief description
- Links to the project website, documentation, and Eclipse Terms of Use
- Main communication channels for contacting the project team
- Canonical source code repositories
- Steps for setting up the development environment (sources, dependencies, tools, build instructions)
- Mechanics for contributing (e.g., GitHub pull requests or GitLab merge requests)
- Legal requirements for contributions, including the Eclipse Contributor Agreement (ECA) and Developer Certificate of Origin (DCO)
Additionally, the guide should define any project-specific contribution rules, such as code formatting, quality standards, and review processes. If different repositories follow different rules, these differences must be explicitly documented. A well-structured contribution guide ensures transparency, streamlines onboarding, and helps contributions reach the project efficiently.
Evidence for compliance might include (but is not limited to):
- File CONTRIBUTING.md or relevant information in README.md exists
- Guidelines are being followed in PRs/MRs
UPSTREAM.ECLIPSE.ECLIPSE-FORMAL_RELEASES | Reviewed: ✔ | Score: 0.0
Each release of an Eclipse project undergoes formal review and approval.
Supported Requests:
| Item | Summary | Score | Status |
|---|---|---|---|
| UPSTREAM.TSF.TA-RELEASES | Construction of XYZ releases is fully repeatable and the results are fully reproducible, with any exceptions documented and justified. | 0.15 | ✔ Item Reviewed ✔ Link Reviewed |
Supporting Items:
None
References:
None
The Eclipse Foundation Project Handbook (section Project Releases and Reviews/Releases) states that (please refer to the official Eclipse document for definitive and canonical definitions):
Releases for Eclipse projects are formal and follow an iterative process. They are categorized as:
- Major releases: Include API changes that may break downstream compatibility.
- Minor releases: Add new functionality while maintaining API compatibility.
- Service releases: Contain only bug fixes and no significant new features.
Each release cycle begins with a public plan created openly for community review and input. Development is iterative, with regular milestone builds for feedback, and concludes with a final release candidate and general availability.
Only projects in good standing — those that have completed a progress review within the past year — may issue major or minor releases. Service releases based on an official release do not require additional reviews. Throughout the release process, project teams must continuously follow the Eclipse IP Due Diligence Process to ensure proper intellectual property management, with progress reviews serving as a confirmation of ongoing compliance rather than a late-stage cleanup.
Evidence for compliance might include (but is not limited to):
- Release review documentation on eclipse.org
- PMC approval votes for releases, e.g. documented on level of release PR / MR
UPSTREAM.ECLIPSE.ECLIPSE-IP_COMPLIANCE | Reviewed: ✔ | Score: 0.0
An Eclipse project follows the Eclipse Foundation IP Policy at all times.
Supported Requests:
| Item | Summary | Score | Status |
|---|---|---|---|
| UPSTREAM.TSF.TA-INPUTS | All inputs to XYZ are assessed, to identify potential risks and issues | 0.00 | ✔ Item Reviewed ✔ Link Reviewed |
Supporting Items:
None
References:
None
The Eclipse Foundation Development Process section 6.4 states that (please refer to the official Eclipse document for definitive and canonical definitions):
Releases in Eclipse projects must strictly adhere to the Eclipse Foundation IP Policy to ensure legal compliance and maintain project quality. Any build distributed outside of the project's committers constitutes a Release and must follow the formal approval process.
Key Requirements:
- IP Policy Compliance: Before any Release, the Project Lead must confirm that all IP due diligence and approvals are complete in accordance with the Eclipse IP Policy.
- Source Linkage: Every Release artifact must be traceable to its corresponding source code.
- Release Validity: Projects can make official Releases for one year following a successful Progress or Release Review; additional reviews may be required by the project leadership.
Exceptions:
- Nightly & Integration Builds: Allowed only for developers and early adopters; no public links should encourage general use.
- Milestone & Release Candidate Builds: May be shared publicly with clear labeling and caveats (e.g. alpha, beta, RC).
- Service Releases: Maintenance updates without new features do not require a new review.
Evidence for compliance might include (but is not limited to):
- License compliance tool results
- Third-party license obligation fulfillment documentation
UPSTREAM.ECLIPSE.ECLIPSE-METADATA_CORRECTNESS | Reviewed: ✔ | Score: 0.0
Technical metadata of an Eclipse project is always correct and up to date.
Supported Requests:
| Item | Summary | Score | Status |
|---|---|---|---|
| UPSTREAM.TSF.TA-RELEASES | Construction of XYZ releases is fully repeatable and the results are fully reproducible, with any exceptions documented and justified. | 0.15 | ✔ Item Reviewed ✔ Link Reviewed |
Supporting Items:
None
References:
None
The Eclipse Foundation Project Handbook (section Project Resources and Services) states that (please refer to the official Eclipse document for definitive and canonical definitions):
Eclipse open source projects must keep their project metadata accurate and up-to-date and ensure that project information is consistent and vendor-neutral. This metadata is critical for software build, distribution, governance and legal compliance.
The Eclipse Foundation supports projects with infrastructure (e.g., Git hosting, CI/CD, artifact signing, mailing lists), security services (e.g., vulnerability reporting, security audits), intellectual property (IP) due diligence, governance support, and promotion resources. Correct project metadata ensures these services are applied properly, supports IP compliance, and enables downstream consumers to rely on accurate legal and technical information.
Failure to maintain correct project metadata can lead to IP compliance risks, governance delays (e.g., during reviews), misapplied infrastructure services, and reduced transparency for the community and adopters. Proper metadata management is therefore a core responsibility for all project teams.
Evidence for compliance might include (but is not limited to):
- Project repository, including e.g. Cargo.toml, jar index files, etc
- Project CI in some form checking/using/validating metadata
UPSTREAM.ECLIPSE.ECLIPSE-PROCESSES | Reviewed: ✔ | Score: 0.0
All Eclipse projects follow the Eclipse Foundation Development Process.
Supported Requests:
| Item | Summary | Score | Status |
|---|---|---|---|
| UPSTREAM.TSF.TA-METHODOLOGIES | Manual methodologies applied for XYZ by contributors, and their results, are managed according to specified objectives. | 0.12 | ✔ Item Reviewed ✔ Link Reviewed |
Supporting Items:
None
References:
None
The Eclipse Foundation Development Process (section Project Resources and Services) states that (please refer to the official Eclipse document for definitive and canonical definitions):
Projects that fail to perform the required behaviors will be terminated by the EMO (Eclipse Management Organization).
Evidence for compliance might include (but is not limited to):
- Eclipse Development Process compliance documentation
- Project lifecycle milestone completion records (TODO: where can these be found?)
UPSTREAM.ECLIPSE.ECLIPSE-PROJECT_README | Reviewed: ✔ | Score: 0.9
An Eclipse projects must have a README file with information about the project.
Supported Requests:
| Item | Summary | Score | Status |
|---|---|---|---|
| UPSTREAM.TSF.TA-RELEASES | Construction of XYZ releases is fully repeatable and the results are fully reproducible, with any exceptions documented and justified. | 0.15 | ✔ Item Reviewed ✔ Link Reviewed |
| UPSTREAM.TSF.TT-EXPECTATIONS | Documentation is provided, specifying what XYZ is expected to do, and what it must not do, and how this is verified. | 0.18 | ✔ Item Reviewed ✔ Link Reviewed |
Supporting Items:
| Item | Summary | Score | Status |
|---|---|---|---|
| TSFTEMPLATE-PROJECT_README | Project comes with a comprehensive README file, explaining goal, scope, and providing getting-started documentation. | 0.80 | ✔ Item Reviewed ⨯ Link Reviewed |
| TSFTEMPLATE-PROJECT_SCOPE | The tsftemplate project README file defines the scope of the project, and lays out the why and to for reaching that goal. | 1.00 | ✔ Item Reviewed ⨯ Link Reviewed |
References:
None
The Eclipse Foundation Project Handbook (section Incubation / Development) states that (please refer to the official Eclipse document for definitive and canonical definitions):
Clear and consistent documentation is essential for collaboration and community participation in Eclipse projects. Every repository must include specific files to ensure legal compliance, contributor guidance, and transparency.
Mandatory README: Explains the project purpose and provides key information for users and contributors.
Evidence for compliance might include (but is not limited to):
- README file in project repository
UPSTREAM.ECLIPSE.ECLIPSE-PROJECT_SCOPE | Reviewed: ✔ | Score: 0.0
An Eclipse project's scope and objectives are formally documented and maintained.
Supported Requests:
| Item | Summary | Score | Status |
|---|---|---|---|
| UPSTREAM.TSF.TA-BEHAVIOURS | Expected or required behaviours for XYZ are identified, specified, verified and validated based on analysis. | 0.00 | ✔ Item Reviewed ✔ Link Reviewed |
Supporting Items:
None
References:
None
The Eclipse Foundation Project Handbook (section Starting an Open Source Project at the Eclipse Foundation / Project Proposal), Eclipse Foundation Project Handbook (section Project Management Infrastructure (PMI) / Project Metadata) and Eclipse Foundation Development Process (section 4.5) states that (please refer to the official Eclipse document for definitive and canonical definitions):
A clear and realistic project scope is essential for ensuring project success at the Eclipse Foundation. It provides focus, helps the community evaluate proposals, and prevents misaligned initiatives.
Each proposal must include:
- A concise project description
- A well-defined scope
- Initial project leads and committers
Project metadata, including scope, must be kept up to date.
Evidence for compliance might include (but is not limited to):
- Project charter documents on eclipse.org
UPSTREAM.ECLIPSE.ECLIPSE-PUBLIC_CODE | Reviewed: ✔ | Score: 0.0
All source code of an Eclipse project is kept and maintained via Eclipse-managed infrastructure.
Supported Requests:
| Item | Summary | Score | Status |
|---|---|---|---|
| UPSTREAM.TSF.TA-RELEASES | Construction of XYZ releases is fully repeatable and the results are fully reproducible, with any exceptions documented and justified. | 0.15 | ✔ Item Reviewed ✔ Link Reviewed |
Supporting Items:
None
References:
None
The Eclipse Foundation Project Handbook (section Project Resources and Services/External Resources) states that (please refer to the official Eclipse document for definitive and canonical definitions):
Project teams may use external services (e.g., GitHub, DockerHub) provided they comply with Eclipse Foundation rules. All such usage must respect Eclipse branding guidelines, ensure that service terms do not conflict with project licenses or copyrights, and grant ownership rights to one or more project committers. Additionally, services must be operated in an open, transparent, meritocratic, and vendor-neutral way, with shared administrative control among a diverse subset of committers and a documented policy for managing access.
External services may be used for:
- User forum discussions (e.g., Slack)
- Builds and alternative download sources
- Container image management (e.g., DockerHub)
- Examples, presentations, blogs, and social media
Project leads must review the terms of any external service with their PMC and the EMO to ensure compliance with project licenses, the Eclipse IP Policy, and the Eclipse Foundation Development Process.
However, source code, documentation, and issue tracking must live on Eclipse-managed infrastructure.
Evidence for compliance might include (but is not limited to):
- Source code repo is part of Eclipse-managed organization
UPSTREAM.ECLIPSE.ECLIPSE-PUBLIC_RECORDS | Reviewed: ✔ | Score: 0.0
All tickets, issue discussions, bug reports and decisions of an Eclipse project are kept and made publicly accessibly via Eclipse-managed infrastructure.
Supported Requests:
| Item | Summary | Score | Status |
|---|---|---|---|
| UPSTREAM.TSF.TA-BEHAVIOURS | Expected or required behaviours for XYZ are identified, specified, verified and validated based on analysis. | 0.00 | ✔ Item Reviewed ✔ Link Reviewed |
Supporting Items:
None
References:
None
The Eclipse Foundation Project Handbook (section Project Resources and Services / External Resources), as well as the Eclipse Foundation Development Process (section 2.1) states that (please refer to the official Eclipse document for definitive and canonical definitions):
Eclipse projects must conduct all essential project activities — including source code, documentation, issue tracking, and bug reporting — on publicly accessible Eclipse Foundation infrastructure. This ensures that development is open, transparent, and inclusive. While external services (e.g., GitHub, DockerHub) may be used for auxiliary purposes such as user forums, builds, or container management, they must not replace Eclipse-managed infrastructure for core project resources.
Projects must also follow Eclipse’s key principles:
Openness: Participation is open to all under the same rules, with no exclusion of contributors or competing vendors. Transparency: Project discussions, decisions, plans, and records must be public and easy to access. Meritocracy: Responsibility and leadership are earned through contributions, recognized by the community.
External services must not impose legal terms that conflict with project licenses, must share administrative control among multiple committers, and must not create barriers for contributors. All project-related communication and decision-making should remain vendor-neutral and documented in public, ensuring that the project community can fully engage and collaborate.
Evidence for compliance might include (but is not limited to):
- Project repository, related infrastructure like discussion boards and issue trackers
The Eclipse Foundation Project Handbook defines how Eclipse Foundation projects operate.
Eclipse Project Handbook: A Comprehensive Guide to Professional Open Source Development
The Eclipse Project Handbook serves as the definitive operational guide for projects within the Eclipse ecosystem, representing a mature approach to managing large-scale, mission-critical open source development. It describes the manner in which we do open source software, providing a framework that scales from individual contributions to enterprise-grade software systems.
Structured Project Lifecycle Management:
The Handbook codifies the complete project lifecycle from inception through maintenance, establishing clear gates, reviews, and governance structures. This includes project proposal processes, committer election procedures, release management protocols, and graduation criteria that ensure projects meet enterprise-readiness standards before achieving full status.
Intellectual Property Excellence:
The documentation establishes comprehensive contributor licensing requirements, mandatory provenance reviews for all third-party components, and systematic tracking of code origins throughout the development lifecycle. Every contribution undergoes legal scrutiny to ensure clean title and compatibility with Eclipse's licensing model. This process, while more demanding than typical open source projects, provides the legal certainty that enterprises require when building mission-critical systems on open source foundations.
Community and Technical Governance:
The Handbook establishes clear roles and responsibilities for project leads, committers, and Project Management Committees (PMCs). Project leadership roles are all positions of trust and responsibility with the Eclipse community, ensuring accountability and sustainable leadership succession across hundreds of active projects.
Operational Best Practices:
Beyond governance, the Handbook provides practical guidance on development infrastructure, release engineering, community building, and technical decision-making processes. This includes standardized approaches to version control, issue tracking, continuous integration, and documentation that create consistency across the Eclipse ecosystem.
Enterprise Integration Ready:
The processes outlined in the Handbook are designed for organizations that need predictable, auditable, and legally clean open source software. The documentation addresses compliance requirements, security practices, and long-term maintenance commitments that make Eclipse projects suitable for regulated industries and critical infrastructure.
This comprehensive approach transforms ad-hoc open source development into a professional, sustainable practice that enterprises can depend on for decades-long software investments.
Eclipse Foundation Project Handbook Alignment with TSF tenets
Here's how the Eclipse Project Handbook implements and supports TSF goals:
Provenance Support (TSF Tenet 1)
Eclipse Handbook Implementation:
- Intellectual Property Framework: Eclipse has rigorous IP due diligence processes for contributions, requiring proper documentation of code origins and contributor agreements
- Contributor Tracking: All contributors must sign Eclipse Contributor Agreements (ECA) ensuring clear provenance chains
- Project Charter Requirements: Each project must document its origins, founding members, and initial scope
- License Management: Comprehensive tracking of third-party content and license compliance
- Version Control Standards: Git-based systems with full commit attribution and history
TSF Alignment: Strong - Eclipse's IP processes directly support the TSF's provenance requirements by ensuring clear documentation of software origins and contributor responsibilities.
Construction Support (TSF Tenet 2)
Eclipse Handbook Implementation:
- Build Infrastructure Standards: Common build infrastructure and CI/CD practices across projects
- Release Engineering Process: Formal procedures for creating, testing, and validating releases
- Development Environment Guidelines: Standardized tooling and development practices
- Quality Gates: Review processes that validate construction practices during project lifecycle transitions
- Reproducible Build Encouragement: Guidelines for consistent and repeatable build processes
TSF Alignment: Strong - Eclipse's emphasis on standardized build processes and release engineering directly supports TSF construction requirements.
Change Management (TSF Tenet 3)
Eclipse Handbook Implementation:
- Project Lifecycle Management: Structured development process with formal reviews at key transitions
- Eclipse Foundation Committer Training: Foundation-managed trainings for project committers, to teach community and process standards
- Release Review Process: Formal release reviews ensure changes meet quality and compatibility standards
- Eclipse Foundation Specification Process: For projects that focus on the creation and evolution of specification documents
- Version Control Policies: Standardized approaches to branching, merging, and version management
- API Evolution Guidelines: Rules for maintaining backward compatibility and managing breaking changes
- Migration Documentation: Requirements for documenting upgrade paths and compatibility considerations
TSF Alignment: Strong - Eclipse's formal review processes and lifecycle management directly address TSF change management requirements.
Expectations Documentation (TSF Tenet 4)
Eclipse Handbook Implementation:
- Project Scope Definition: Clear requirements for documenting project objectives and deliverables
- API Documentation Standards: Comprehensive documentation requirements for public interfaces
- Specification Processes: Eclipse Foundation Specification Process (EFSP) for formal technical specifications
- Quality Criteria: Defined maturity levels and graduation requirements
- Governance Documentation: Clear community processes and decision-making procedures
TSF Alignment: Strong - Eclipse's emphasis on documentation and specification processes supports TSF expectations management.
Results Verification (TSF Tenet 5)
Eclipse Handbook Implementation:
- Testing Requirements: Expectations for comprehensive test suites and quality assurance
- Community Validation: Open development model with transparent issue tracking and peer review
- Performance Metrics: Project health indicators and community engagement measurements
- Compliance Verification: Regular reviews ensure projects meet Foundation standards
- Release Validation: Review processes that verify deliverables meet stated objectives
TSF Alignment: Moderate to Strong - Eclipse's testing and review processes support results verification, though more formal metrics frameworks could strengthen alignment. This is where adopting TSF as a methodology can substantially contribute.
Key Strengths of Eclipse Handbook in Supporting TSF Goals
-
Evidence-Based Governance Eclipse's formal review processes create evidence trails that support trust decisions, aligning with TSF's evidence-based approach.
-
Structured Risk Management The project lifecycle with graduation requirements helps identify and manage risks throughout the development process.
-
Community Transparency Open development processes provide visibility into project health and decision-making, supporting trust assessment.
-
Vendor Neutrality Eclipse's governance model reduces single-vendor risks and increases trustability through community oversight.
Areas for Enhanced TSF Alignment
-
Formal Trustability Metrics While Eclipse has quality processes, more explicit trustability measurement via TSF could strengthen overall outcomes.
-
Supply Chain Security Enhanced focus on dependency management and third-party component risk assessment.
-
Automated Compliance Verification More automated validation of TSF-style assertions throughout the development lifecycle.
-
Post-Deployment Monitoring Stronger emphasis on monitoring and validating results in production environments.
Conclusion
The Eclipse Foundation Project Handbook provides a robust foundation that naturally aligns with TSF principles across all five tenets. The structured approach to IP management, development processes, change control, documentation, and quality assurance creates an environment where trustable software can be developed and maintained effectively.
The Eclipse model's emphasis on community governance, transparency, and formal processes makes it particularly well-suited for organizations seeking to implement TSF-compliant software development practices. The handbook's comprehensive coverage of project lifecycle management provides a practical framework for implementing evidence-based trust evaluation in open source software development.
UPSTREAM.ECLIPSE.ECLIPSE-SBOM_GENERATION | Reviewed: ✔ | Score: 0.0
An Eclipse projects generates Software Bill of Materials (SBOM) documentation for the software that is produced. This is optional for libraries, but mandatory for applications or standalone components.
Supported Requests:
| Item | Summary | Score | Status |
|---|---|---|---|
| UPSTREAM.TSF.TA-INPUTS | All inputs to XYZ are assessed, to identify potential risks and issues | 0.00 | ✔ Item Reviewed ✔ Link Reviewed |
Supporting Items:
None
References:
None
Eclipse Foundation Project Handbook (section Software Bill of Materials) states that (please refer to the official Eclipse document for definitive and canonical definitions):
All Eclipse open source projects are encouraged to generate Software Bills of Materials (SBOMs) for their software. SBOMs provide a comprehensive inventory of all software components and dependencies, enabling improved supply chain security, effective vulnerability management, regulatory compliance, efficient development, and faster incident response. Additional guidance and best practices are available in the Eclipse Foundation Security Handbook.
Projects should follow these core practices when generating SBOMs:
- Use standard formats: Create SBOMs in recognized formats such as SPDX or CycloneDX.
- Provide resolvable coordinates: Identify components unambiguously using formats such as Package URL (pURL) to specify namespace, name, and version.
- Identify licenses accurately: Include correct license information for project files and third-party dependencies.
- Distribute SBOMs with artifacts: Publish SBOMs alongside the corresponding build artifacts (e.g., with Maven artifacts).
- Support SBOM generation by others: Ensure clear copyright headers, SPDX-License-Identifiers, and accurate metadata to make it easy for adopters to generate their own SBOMs.
By following these practices, projects help ensure the security, compliance, and quality of their software while supporting the broader open-source ecosystem.
Evidence for compliance might include (but is not limited to):
- SBOM information e.g. as part of releases
UPSTREAM.ECLIPSE.ECLIPSE-SECURITY_POLICY | Reviewed: ✔ | Score: 1.0
An Eclipse project defines a process for handling, analysis and resolution of security issues that are reported.
Supported Requests:
| Item | Summary | Score | Status |
|---|---|---|---|
| UPSTREAM.TSF.TA-METHODOLOGIES | Manual methodologies applied for XYZ by contributors, and their results, are managed according to specified objectives. | 0.12 | ✔ Item Reviewed ✔ Link Reviewed |
Supporting Items:
| Item | Summary | Score | Status |
|---|---|---|---|
| TSFTEMPLATE-SECURITY_POLICY | The tsftemplate project defines a securits policy for handling, analysis and resolution of security issues that are reported, which is based on and references the Eclipse Foundation Security Policy. |
1.00 | ✔ Item Reviewed ⨯ Link Reviewed |
References:
None
The Eclipse Foundation Security Policy defines how Eclipse Foundation projects deal with reported security issues:
The Eclipse Foundation Security Policy represents a mature, industry-standard approach to vulnerability management that addresses the security concerns enterprises face when adopting open source software. The purpose of the Eclipse Foundation Security Policy is to set forth the general principles under which the Eclipse Foundation manages the reporting, management, discussion, and disclosure of Vulnerabilities discovered in Eclipse software, creating a framework that rivals commercial software vendors in its rigor and transparency.
Two-Tier Security Architecture:
The policy establishes a sophisticated dual-layer security structure with the Eclipse Foundation Security Team as the first line of defense: they triage reports, redirect them to the appropriate Project's Security team or the EMO team, provide assistance and guidance in the resolution. This ensures both centralized coordination and project-specific expertise, preventing security issues from falling through organizational cracks.
Systematic Vulnerability Lifecycle:
Unlike ad-hoc open source security practices, Eclipse mandates comprehensive vulnerability tracking from initial report through full disclosure. All Vulnerabilities must be resolved and All Vulnerabilities must eventually be fully disclosed to the community at large, ensuring transparency while protecting users during the resolution period.
Coordinated Disclosure Framework:
The policy supports progressive, coordinated, and quiet disclosure options depending on severity and circumstances, allowing for responsible handling of critical vulnerabilities while maintaining community transparency. This flexibility enables proper coordination with downstream users and commercial redistributors.
Accountability and Governance:
In the unlikely event that a project team does not engage in good faith to resolve a Vulnerability, a member of EMO may – at their discretion – initiate the Grievance Process, ensuring that security responsibilities are enforced rather than merely encouraged.
This comprehensive approach provides the security governance that enterprises require when building critical systems on open source foundations, matching the security practices of commercial software vendors while maintaining open source transparency principles.
UPSTREAM.ECLIPSE.ECLIPSE-SECURITY_REPORTING | Reviewed: ✔ | Score: 0.0
An Eclipse project provides information about how and where to report security issues.
Supported Requests:
| Item | Summary | Score | Status |
|---|---|---|---|
| UPSTREAM.TSF.TA-METHODOLOGIES | Manual methodologies applied for XYZ by contributors, and their results, are managed according to specified objectives. | 0.12 | ✔ Item Reviewed ✔ Link Reviewed |
Supporting Items:
None
References:
None
The Eclipse Foundation Project Handbook (section Legal documentation requirements / SECURITY File) states that (please refer to the official Eclipse document for definitive and canonical definitions):
Projects must include a SECURITY file in the root of every repository to define how security issues are handled. It should:
- Link to the Eclipse Vulnerability Reporting page.
- List supported product versions for security updates.
- Provide a communication channel for reporting vulnerabilities.
A template is available from the Eclipse Security Team but must be customized for the project.
Evidence for compliance might include (but is not limited to):
- SECURITY.md file exists
UPSTREAM.ECLIPSE.ECLIPSE-VERSION_CONTROL | Reviewed: ✔ | Score: 0.0
All changes to an Eclipse project are tracked through version control with full attribution.
Supported Requests:
| Item | Summary | Score | Status |
|---|---|---|---|
| UPSTREAM.TSF.TA-RELEASES | Construction of XYZ releases is fully repeatable and the results are fully reproducible, with any exceptions documented and justified. | 0.15 | ✔ Item Reviewed ✔ Link Reviewed |
Supporting Items:
None
References:
None
UPSTREAM.ECLIPSE.ECLIPSE-VULNERABILITY_MANAGEMENT | Reviewed: ✔ | Score: 0.0
An Eclipse project follows obligations and practices regarding the analysis and reporting and disclosure of vulnerabilities.
Supported Requests:
| Item | Summary | Score | Status |
|---|---|---|---|
| UPSTREAM.TSF.TA-METHODOLOGIES | Manual methodologies applied for XYZ by contributors, and their results, are managed according to specified objectives. | 0.12 | ✔ Item Reviewed ✔ Link Reviewed |
Supporting Items:
None
References:
None