Wayne Beaton's blog

The Eclipse Foundation Development Process (EDP) describes a release as anything that is distributed for adoption outside of the committers of a project (effectively, if you stamp something with a version number and tell the general audience to download it, it’s a release). Appropriately labeled nightly, integration, and milestone builds...

Scientific progress goes “boink”? – Hobbes The Eclipse Foundation Specification Process (EFSP) provides a framework and governance model for developers engaged in the process of developing specifications. Specification: A specification is a collection of related artifacts. The EFSP defines a specification as a “collection of Application Programming Interface (API) definitions...

The Eclipse Foundation community awards are back for 2021! The Eclipse Foundation has a vibrant community of many dedicated individuals, who deserve to be recognized for their contributions. To recognize our community members, we will be presenting awards for Top Committer, Top Newcomer Evangelist, Top Contributor, and Lifetime Achievement at...

Dropping barriers to open up opportunities for contribution is a critical activity for Eclipse open source projects. Ideally, Eclipse open source project teams should be actively soliciting contribution, growing participation in the project, and otherwise being good open source citizens. Minimally, though, Eclipse project teams must engage in practices that...

Intellectual property management is important for Eclipse projects. As a committer, you are our first line of defense when it comes to identifying and mitigating intellectual property issues. Over the past year or so, you’ve likely heard and seen rumblings of some of the innovations that we’ve been making in...

The Eclipse Foundation has a policy regarding the resolution and responsible disclosure of identified vulnerabilities. The short version is that this is one of the rare areas where open source transparency and openness ideals may be curtailed for a period of time while a vulnerability is addressed privately; but that...

The Eclipse Foundation is a Common Vulnerabilities and Exposures (CVE) Numbering Authority. Eclipse project committers can use the tools that best suit their needs to remediate their vulnerability, provided that–when disclosed–related issues are tracked via the official (open and transparent) project issue tracker. To the extent possible, tools used to...

Good news! Contributor Matt Booth has created a Maven plugin for the Eclipse Dash License Tool. The first step is to clone the repository and run the build: $ git clone git@github.com:eclipse-dash/dash-licenses.git $ cd dash-licenses $ mvn clean install This will install the plugin into your local Maven cache. With...

Originally posted on August 2, 2017 For many open source organisations, open means the same thing as transparent: open as in open book. At the Eclipse Foundation, we regard being transparent as the practice of making sure that the community can see and understand what the project is doing; and...

The hard parts of contributing to an Eclipse open source project are the same hard parts that you’ll have with any open source project. You need to find an open source project to contribute to, identify and connect with the communication channels, learn enough about the code base to make...