In the original bylaws of the Eclipse Foundation, three distinct councils were established to govern the ecosystem: the Eclipse Requirements Council, the Eclipse Planning Council, and the Eclipse Architecture Council. At the time, the Foundation was largely centred on the Eclipse SDK (which most of the community erroneously referred to as the Eclipse IDE, but that’s another story).
The Eclipse Requirements Council authored and disseminated the roadmap, defined themes and priorities, and ensured that the interests of key ecosystem stakeholders were represented. The Eclipse Planning Council was responsible for orchestrating coordinated release plans, managing inter-project dependencies, and cross-project conflict resolution, and operationalising strategy. The Eclipse Architecture Council had a mandate to guide and influence software conventions, ensure architectural consistency, technical quality, API hygiene, and interoperability across open source projects.
Over time, the role of Eclipse Requirements Council was taken over by the Eclipse Project Management Committee (PMC) and we dissolved the Eclipse Requirements Council. With the growth in the breadth of technology areas covered by Eclipse open source projects, and the relatively narrow scope of the Eclipse Planning Council’s mandate, we removed it from the bylaws and reformed it as a committee of the Eclipse IDE Working Group.
Likewise, as the scope of the Eclipse Architecture Council’s mandate grew, we morphed it into a body responsible for guiding and influencing the software conventions, standards, and architectures used by open source projects, maintaining and revising the Eclipse Foundation Development Process (EDP), and providing expert advice to the Eclipse Management Organization (EMO), and the Eclipse Foundation’s Executive Director with regard to emerging issues in open source that have a direct impact on Eclipse developers and technology. With this change in mandate, the name no longer made sense, and the Architecture Council was rebranded as the Eclipse Technical Advisory Council (ETAC) in the December 2025 update to the Eclipse Foundation’s Bylaws.
The ETAC functions strictly in an advisory capacity, providing feedback and recommendations. The majority of this guidance is disseminated during scheduled monthly meetings, though it may also be delivered via discussions on issue trackers and other communication platforms. In contrast, the Eclipse Foundation staff is responsible for operational execution, including the formulation and administration of policies, and the development and maintenance of systems and tools supporting the community.
Composition
The strength of the ETAC lies in its composition. It is not an ivory tower; it is a democratic crossroads. It includes:
Appointed members: Appointed members are long-standing members of the Eclipse developer community who have experience that spans multiple open source projects. Candidates are nominated and voted on by the council members themselves, and appointed to the council by the Eclipse Foundation’s Executive Director. Appointed members serve a three year renewable term.
Representatives from every Project Management Committee (PMC): Representation by Project Management Committees (PMCs) ensures that the council remains deeply rooted in the practical realities of software development. As technical leaders of their respective domains PMC representatives bring practical expertise to the table, ensuring that any changes to the EDP are technically feasible and do not impose undue bureaucratic burdens on developers. Their participation ensures that the “Eclipse Way” remains a meritocracy where the needs of the developers are prioritised, protecting the agility and innovation of individual projects from being stifled by top-down administrative shifts.
Representatives from Strategic Members of the Eclipse Foundation: Strategic members provide a vital anchor for the Eclipse Foundation by bridging the gap between high-level commercial requirements and the day-to-day technical execution of open source projects. By holding seats on the ETAC, these members ensure that the EDP remains pragmatic and “business-ready,” providing the industrial-scale perspective necessary to keep the ecosystem sustainable and attractive for long-term corporate investment. Their participation creates a critical counterbalance system, where the technical focus of PMCs is harmonised with market-driven needs for security, interoperability, and professional governance.
This diversity prevents “siloing”. It ensures that when the EMO proposes a change, they hear from the people who will actually have to live with it. It turns top-down management into consensus-driven governance.
What has the ETAC ever done for us?
The EMO brings every major effort that we engage in to the ETAC for the review and to solicit feedback. The past year (2025-2026) has been incredibly busy.
These examples described below are listed in no particular order.
Artificial Intelligence
The EMO consulted with the ETAC while developing the Generative Artificial Intelligence Usage Guidelines for Eclipse Committers and supporting materials. We gathered feedback which we delivered to the Eclipse Foundation’s legal team and the Eclipse IP Advisory Committee to help us reshape and craft it into its current form.
Our consultation covered practical considerations, such as the vetting responsibilities of committers, criteria for AI disclosure, how to identify the AI assistant using de facto standards (like the Assisted-by header), and rules around utilising automation extensions or agentic tools within project repositories.
This effort resulted in updates to the Eclipse Foundation Project Handbook, along with presentations to committers delivered in Committer Office Hours sessions, and a video added to our Committer Training series. These orientation sessions emphasised governance, transparency, compliance, and verification obligations to the community.
The impact of Artificial Intelligence on our development community continues to evolve, and so it continues to be a topic of ongoing discussion, regarding how we can best support our development community (e.g., provide assistance to create an AI_POLICY document in Git repositories).
Security and Vulnerability Management
The Eclipse Security Team briefed the council regarding a requirement to build security teams and expertise within Eclipse open source projects. Having the ability to discreetly handle security vulnerability reports by a subset of the project committers may be necessary in some cases, especially when a project has a large team.
The ETAC discussed potential modifications to the EDP for formalising the notion of a Project Security Team, but determined that the process already supports designation of special teams within a project and that no modifications were necessary.
Security Reviews
The Eclipse Foundation Security Team briefed the council on a new effort to engage in Rapid Security Reviews with our open source projects. This lightweight security assessment, led by the Security Team, is designed to provide guidance and actionable recommendations to further reinforce existing security measures. In addition to these assessments, the Security Team is actively engaged with some Eclipse projects to determine what we need to provide or support in various ecosystem pipelines, helping them generate Software Bills of Materials (SBOMs), and working with the Eclipse Foundation’s SBOM Registry to warehouse these artifacts so the Security Team can quickly assess scope and implement mitigations in the event of a significant vulnerability.
The Security Team has started engaging in Rapid Security Reviews with a number of Eclipse projects. The practical process involves spending a fixed amount of time reviewing the high-level security posture of a project by evaluating a few agreed-upon source code repositories and the configuration of the parent group (GitLab) or organisation (GitHub). The primary intention is to identify key risk factors, such as projects with only one active developer or no CI.
To ensure a streamlined workflow, the process begins by asking project teams to collaboratively complete a brief questionnaire, which takes less than ten minutes and serves as a living record for tracking the review. The Security Team then sets up initial calls with the projects to introduce the review, reviews the survey answers alongside their findings to prepare a review report, and follows up with results to agree on recommended actions and timelines. We are doing our best to align these with progress reviews initiated by the EMO to try and keep the process as streamlined as possible and avoid bothering the project teams twice. This initiative remains experimental and will be continually refined as the team gains experience.
Committer Id Verification
The Security Team provided a briefing to the ETAC regarding their investigation into an optional committer identity verification feature for Eclipse open source projects. Collaborating with multiple providers, the Eclipse IT and Security Teams established a program enabling committers to voluntarily verify that their account name aligns with a government-issued identity document. Upon successful verification, a verified checkmark badge is affixed to the committer’s Eclipse Foundation account profile.
The council conducted a brief assessment regarding compatibility with open source rules of engagement, concluding unanimously that the feature is aligned.
SBOMs
When we first presented our ongoing work to help Eclipse project teams build SBOMs, the ETAC asked a frank question: are SBOMs just going to be used to put a check mark on a list, or can they be leveraged systemically to prove security and supply chain integrity?
Sometimes we end up with more questions than answers:
- Do we include information about the build environment in the SBOM?
- How do we leverage Eclipse IP data and existing workflows like the Eclipse Dash License Tool to improve the quality, accuracy, and verification of license information in SBOMs?
- Do SBOMs make sense for an individual library, JAR file, or an isolated Eclipse Platform Plug-in? Or do they really only make sense for a fully resolved “product” or standalone application where all dependency versions are explicitly known?
- What does an SBOM for a complex, modular application like the Eclipse IDE look like? Does the SBOM change when a user installs a plug-in, and if so, how is that runtime dynamic managed?
- How can the Eclipse Foundation integrate “Safety Relevance Metadata” into automotive and functional safety SBOMs to help developers distinguish between components that directly impact vehicle safety and those that do not?
The ETAC spends considerable time discussing SBOMs, an increasingly vital topic given growing regulatory demands, such as the upcoming Cyber Resilience Act (CRA) in Europe, and what services we can bring to bear to help our project teams.
To support our committers, the Eclipse Security Team is developing a set of practices, documentation, and templates that project teams can integrate into their existing release workflows. These practices leverage existing tools to create SBOMs using existing standards like CycloneDX, and encourage our project teams to provide the most complete metadata possible to ensure that those who are building solutions based on Eclipse projects can more easily generate their own SBOMs.
This work, and related discussions within the ETAC are ongoing.
Releases and the PMI
The ETAC discussed whether using the Project Management Interface (PMI) to announce project releases is required. It is not: the EDP does not require the use of a particular technology/solution for capturing release metadata. There is no requirement for committers to duplicate release information that they capture, for example in GitHub releases, in the PMI.
PMI support for describing releases was created in a time when no other means of expressing a release in a consistent manner (with access to a well-defined API) existed.
It is a point-in-time limitation that the Eclipse Foundation’s services currently use metadata provided in the PMI to disseminate information about project releases and otherwise hype projects to the community. The EMO is working on extending those services to leverage release metadata from other sources like GitHub. Track that ongoing work here.
Inclusive Naming
A brief discussion was conducted regarding the implementation of inclusive language throughout the community. For definitive guidance on this subject, project teams are referred to the resources provided by the Inclusive Naming Initiative.
The current position of the Eclipse Foundation is to encourage project teams to review these references to ensure that all terminology is welcoming and accessible.
Committer Training
The ETAC addressed an ongoing problem that new committers and new project teams are, with increasing frequency, unfamiliar with open collaboration and open source in general, and Eclipse open source project practices in particular. The EMO spends considerable effort working one-on-one with committers to help them understand their obligations.
At the EMO’s request, the ETAC discussed the potential for adding a formal committer training requirement. The EMO has produced a series of committer training videos, but wants to explore options for using a learning platform to deliver a 20-30 minute training session that touches on the important aspects of open collaboration in general, and in the context of Eclipse Foundation governance. The idea being that we use this as an opportunity to ensure that the candidates know what they’re signing up for, and what we need from them.
The ETAC debated making completion of committer training a mandatory requirement in the first-time committer workflow before status is formally granted. Members expressed concern that making training mandatory would introduce a barrier for entry along with a general distaste for mandatory training.
This topic remains open and a subject of ongoing discussion with the ETAC. The work is being tracked here.
Code Owners
We discussed whether the use of the GitHub code owners feature is consistent with the EDP.
The use of GitHub’s code owner feature is consistent with the EDP (provided there is a well defined open, transparent, and meritocratic criteria for designating code owners). Whether or not our infrastructure supports this is an ongoing matter being tracked here.
Eclipse Foundation Functional Safety Process
The EMO had the ETAC review our early drafts of the Eclipse Foundation Functional Safety Process to solicit their feedback and advice before delivering it to the Eclipse Foundation Board of Directors for approval.
Functional Safety refers to the aspect of safety that ensures a system or equipment operates correctly in response to its inputs, particularly in the presence of faults or failures. The focus of this process is to enable practices to create open source software that can be used in safety critical systems.
Additionally, there are ongoing considerations regarding how the Eclipse Foundation can integrate “Safety Relevance Metadata” into automotive and functional safety SBOMs to help developers distinguish between components that directly impact vehicle safety and those that do not.
End-of-Life
The ETAC very often engages in discussions of philosophical matters that pertain to open source and open collaboration.
The ETAC debated, for example, the notion of end of life of a development stream and what that means in open source. We discussed that the notion of an absolute end of life doesn’t really make sense, since it’s relatively easy for a project team to accept a pull request, or for the content to be forked and worked on elsewhere. The forking option may have trademark implications that we need to think about: if somebody forks an Eclipse project with the intention of providing support for that version, they cannot use the project name? (this is just how trademarks work)
Members pointed out during the conversation that we need to be careful using the word “support”. When we talk about supported versions and end-of-life, it gives a mistaken impression that the output of open source projects are “products” in a traditional sense. We have to keep in mind that the Eclipse Foundation is not a software vendor, our open source projects do not produce products in the traditional sense, and what we mean when we say “support” is very different from what an organisation that regards us as a software vendor thinks it means.
Incubation and Graduation
The EMO presented ongoing efforts to revitalise the incubation process, noting that we need to be flexible for new projects to give them space and time to properly assimilate processes and practices consistent with open collaboration in open source in general, and Eclipse practices in particular.
The new philosophy within the EMO is that “becoming an Eclipse project is a process, not an event” and our goal is to reduce friction improve a new project team’s first experience with us, and reduce the time required to create a new Eclipse open source project.
The ETAC also discussed the challenges of graduating from the incubation to the mature phase. A project should not be in incubation for any longer than is necessary, and should want to leave incubation. In positioning incubation as a time during which project teams are learning how to implement open source practices, it serves as a flag to adopters and the community that the project may not be fully implementing Eclipse practices correctly (that is, “incubation” is synonymous with “not ready for production”).
Graduating from the incubation phase to the mature phase should be regarded as a significant event. Our discussions have touched on plans to make graduation more formal with marketing support (e.g. social media outreach and, potentially, press releases).
The EMO are developing metrics to help assess project stature with regard to their adoption of collaborative processes that are consistent with the EDP. These metrics along with tools that are being developed to support them will be discussed in future meetings.
Tools for Committers
Tools provided by the EMO for committers are an ongoing topic of discussion.
The EMO recently introduced the ETAC to a new tool called Eclipse CARE that is intended to help project committers improve their alignment with the expectations of the open source community and potential adopters. Eclipse CARE is intended to replace tools like our online documentation generator to help project teams create, for example, CONTRIBUTING, SECURITY, AI_POLICY, and NOTICE files, identify missing files and content, and otherwise ensure that their Git repositories meet community expectations.
This is ongoing work that the EMO will present to the ETAC for review and feedback in a future meeting.
The Eclipse Foundation Development Process
The ETAC completed an update to the Eclipse Development Process EDP. You can review the specific changes here.
With this new iteration, the ETAC’s primary efforts focused on ensuring that the updated document aligns with the Eclipse Foundation Bylaws which were revised in late 2025. To achieve this, we have removed historical references to the Architecture Council, changed references to “Membership at Large” with “community”, and the definition of the Eclipse Management Organization (EMO).
Our secondary efforts are closely focused on aligning the process with contemporary open source practices and modern community norms.
The phrase “Frameworks and Exemplary Products” no longer reflects the wonderful diversity of technology areas being addressed by our open source projects, and has been replaced with the more inclusive term, “Eclipse Technology” (which was pulled directly from the bylaws).
New text has been added to explicitly state that the Eclipse Foundation serves as the open source steward for all Eclipse Projects, intentionally decoupled from any single, specific regulatory framework. The Eclipse Foundation acts as the open source steward for all Eclipse Projects by providing the fundamental legal framework, infrastructure, and governance required to ensure project technical integrity and regulatory compliance, while seamlessly facilitating transparent, vendor-neutral collaboration.
The core concepts surrounding project releases have been reframed. The legacy notions of integration and nightly builds, as well as milestones and release candidates, are not universal across modern workflows and are no longer strictly necessary. Releases are builds of project content that are intended to be distributed outside of the committers of a project.
The update has been approved by the Eclipse Foundation’s Board of Directors and went into effect on July 1 2026.
EMO Services and the ETAC
To ensure a continuous and robust flow of information, the ETAC regularly invites representatives from the various Eclipse Foundation service teams (IT, Projects, Marketing, Security, and Industry Collaborations) to participate in our scheduled calls. These collaborative sessions are designed to provide the council with comprehensive, first-hand briefings regarding matters of critical importance to Eclipse committers, while simultaneously inviting constructive feedback and diverse perspectives from across the ecosystem.
How do you Engage?
The EMO monitors the Help Desk to identify when committers are experiencing difficulties with open collaboration, practices, or project execution. In such instances, the EMO escalates the matter directly to the ETAC. This procedure enables the solicitation of expert feedback and counsel to effectively address emerging issues and optimise support for the development community.
Individuals may also contact their respective PMC. PMCs serve as the primary technical leaders within their designated domains; the PMC’s ETAC representative is well positioned to represent the interests of the open source projects that operate under their purview.
In the spirit of openness and transparency, use public channels (e.g., your PMC’s mailing list) whenever possible. But, if you’re in a pinch, you can contact the EMO directly via email (emo@eclipse-foundation.org).
Epilogue
The ETAC meets monthly (historically on the second Thursday of the month, but shifting to the fourth Thursday of the month starting in August 2026) to ensure our open source practices keep pace with reality and the evolving expectations of our adopter, developers, and members. These sixty-minute sessions are high-intensity feedback loops where the EMO presents initiatives and the ETAC provides the expert reality check.
The Technical Advisory Council is the quiet engine of the Eclipse Foundation ensuring that it remains more than just a host for code, but a trusted community where open source collaboration can thrive.
As we look towards the future of open source, the role of the ETAC will only become more important. In an era of increasing regulatory pressure, evolving security threats, and rapidly changing technologies, the Eclipse Foundation needs a representative body that can translate emerging best practices into practical, effective development processes.This is one of the Eclipse Foundation’s greatest strengths. The ETAC doesn’t just help shape how we build software, it helps cultivate the trusted open source ecosystem that makes sustainable software development possible
