What is discussed less often is how teams responsible for widely used systems can introduce these tools carefully. This post looks at how our team is approaching AI-assisted development, and what we want to get right before we move further.

At the Eclipse Foundation, we maintain infrastructure used by a large and distributed open source community. The Eclipse ecosystem includes more than 400 open source projects and over 15,000 contributors worldwide.

Our team builds and maintains several of the applications that support that ecosystem, including the Open VSX Registry, the Eclipse Marketplace, contributor agreement tooling, and services used by many active open source projects.

Our team is small relative to the scope of what we support, and the systems we build must remain reliable, secure, and maintainable over the long term.

We are beginning to introduce AI-assisted development practices across the team, starting with a small set of controlled experiments. Here is how we are approaching it.

Starting with the right question

The question we kept coming back to was not "how do we use AI?" but "how do we use AI responsibly, given the nature of what we build?"

Mistakes in our systems do not just affect our organisation. They can affect many projects and developers who rely on the services we provide. That kind of reach means we need to be particularly deliberate when introducing new development practices.

That context shapes how we approach this work. Before discussing tools or workflows, we spent time defining the guardrails that will guide how we begin.

Isolated environments for agentic workflows

Part of our exploration includes experimenting with agentic workflows — systems where AI can generate code, execute commands, and interact with development tools.

That naturally raises a practical question: where should those agents run?

Our starting principle is that AI agents should operate in isolated environments. In practice, this means containerised sandboxes.

Projects and platforms like Docker AI Sandboxes, nono.sh, Daytona, and Modal are beginning to formalise this pattern. They provide controlled environments where AI-generated code can run and experiment without access to production environments.

The reasoning is straightforward. Agents capable of executing commands or interacting with systems need clear boundaries. Not because the tools are uniquely unsafe, but because containment is standard engineering discipline for any automated system that can execute commands. Any automated system introduced into a workflow should begin with limited access and well-defined boundaries.

Running agents inside isolated environments such as Docker AI Sandboxes allows them to write code, run tests, and experiment in a reproducible environment without direct access to sensitive infrastructure.

As part of this approach, agents will not have access to production credentials or other sensitive information, and they will not run inside our internal networks. If something behaves unexpectedly, the impact remains limited and recoverable.

This is not a new mindset for us. The same discipline we apply to dependency management, deployment pipelines, and access control applies here as well. AI tooling does not get a special exception simply because it is new.

Where AI can help first

Our goal is not to automate judgement. It is to reduce friction in work that is largely mechanical, repetitive, or easy to postpone.

The clearest opportunities we see today include:

• Rapid prototyping and technical discovery: Using AI for "architectural spikes" — building quick prototypes to validate a concept or explore a new technology. This helps us understand the "shape" of a solution and identify technical blockers early, so that when we move to production we do so with a clearer, research-backed roadmap.

• Test generation for well-defined functions: Writing unit tests for stable, well-scoped code is repetitive work that often falls behind. AI-assisted generation can help accelerate this when done in a controlled environment.

• Documentation drafts: Keeping documentation up to date is an ongoing challenge for a small team. Generating a first draft from code or issue descriptions, followed by human review and editing, fits naturally into our workflow.

• Scaffolding and boilerplate: Creating the initial structure for new services, migration scripts, or API endpoints often involves repetitive setup work. Reducing that friction can make development faster without sacrificing quality.

• Technical debt and modernisation work: Like many small teams, we still run legacy applications and services that need attention but are easy to postpone when day-to-day operational work takes priority. AI-assisted development may help us make more consistent progress on refactoring, code cleanup, migrations, and other modernisation work that too often gets pushed aside.

• Website maintenance, redesigns, and framework migrations: Our team also maintains websites such as eclipse.org and many working group sites. Work such as template updates, redesigns, framework migrations, accessibility improvements, and content restructuring often involves repetitive implementation work that could benefit from AI-assisted workflows.

In all cases, AI-generated output must still go through the same review and validation processes we apply to any other code change. Developers remain responsible for understanding the problem being solved, reviewing the generated code, and ensuring that any changes meet our security and reliability standards.

What we expect to learn

We are approaching this work with genuine uncertainty. Some of the automation we are exploring may prove more useful than expected. Other ideas will likely reveal friction or limitations we have not yet anticipated.

What matters most is the approach: start contained, observe carefully, and expand where the benefits are clear. The goal is not to adopt AI quickly. It is to adopt it thoughtfully.

More broadly, the role of the developer is beginning to evolve. Over time, we may spend less effort writing every line of code by hand and more time reviewing, validating, testing, approving, and iterating on generated output to improve the systems we operate.

For teams maintaining shared infrastructure, that shift does not make engineering judgement less important. If anything, it makes it more important — which is exactly why we want to be deliberate about how we begin.

In a previous post, I shared an update on strengthening supply-chain security in the Open VSX Registry, including the introduction of pre-publish checks for extensions. This post focuses on the operational side of the same goal: ensuring the Registry remains resilient and sustainable as usage continues to grow.

The Open VSX Registry is free to use, but not free to operate

Operating a global extension registry requires sustained investment in:

• Compute and storage to serve and index extensions at scale
• Bandwidth to deliver downloads and metadata worldwide
• Security to protect users, publishers, and the service itself
• Staff to operate, monitor, secure, and support the Registry

These costs scale directly with usage.

AI-driven usage is scaling faster than ever

Demand on the Open VSX Registry is increasing rapidly, and AI-enabled development is accelerating that trend. A single developer can now orchestrate dozens of agents and automated workflows, generating traffic that previously would have required entire teams. In practical terms, that can mean the equivalent load of twenty or more traditional users, with direct impact on compute, bandwidth, storage, security capacity, and operational oversight.

This is not unique to the Open VSX Registry. It is an industry-wide challenge. Stewards of public package registries such as Maven Central, PyPI, crates.io, and Packagist have recently raised the same sustainability concerns in a joint statement on sustainable stewardship. Mike Milinkovich, Executive Director of the Eclipse Foundation, echoed that message in his post on aligning responsibility with usage.

As reliance on shared open infrastructure grows, sustaining it becomes a collective responsibility across the ecosystem.

Open VSX is critical, and often invisible, infrastructure

Many developers and organisations may not realise how often they rely on the Open VSX Registry. It provides the extension infrastructure behind a growing number of modern developer platforms and tools, including Amazon’s Kiro, Cursor, Google Antigravity, Windsurf, VSCodium, IBM’s Project Bob, Trae, Ona (formerly Gitpod), and others.

If you use one of these tools, you use the Open VSX Registry.

The Open VSX Registry remains a neutral, vendor-independent public service, operated in the open and governed by the Eclipse Foundation for the benefit of the entire ecosystem.

For developers, the expectation is simple: Open VSX should remain fast, stable, secure, and dependable as the ecosystem grows.

As more platforms and automated systems rely on the Registry, continuous machine-driven traffic can place sustained load on shared infrastructure. Without clear operational guardrails, that can affect performance and availability for everyone.

A practical step for sustainable and reliable operations

Usage has shifted from primarily human-driven access to continuous automation driven by CI systems, cloud-based tooling, and AI-enabled workflows. That shift requires operational controls that scale predictably.

Rate limiting provides a structured way to manage high-volume automated traffic while preserving the performance developers expect. It also ensures that operational decisions are based on real usage patterns and that expectations for large-scale consumption are clear and transparent.

Rate limits aren’t entirely new. Like most public infrastructure services, the Open VSX Registry has long had baseline protections in place to prevent sustained high-volume usage from degrading performance for everyone. What’s changing now is that we’re moving from a one-size-fits-all approach to defined tiers that more accurately reflect different usage patterns. This allows us to keep the Registry stable and responsive for developers and open source projects, while providing a clear, supported path for sustained at-scale consumption.

For individual developers and open source projects, day-to-day workflows remain unchanged. Publishing extensions, searching the registry, and installing tools will continue to work as they always have for typical usage.

A measured, transparent rollout

Rate limiting will be introduced incrementally, with an emphasis on platform health and operational stability.

The initial phase focuses on visibility and observation before any limits are adjusted. This includes improved insight into traffic patterns for registered consumers, baseline protections for anonymous high-volume usage, and a monitoring period before any limits are adjusted.

This work is being done in the open so the community can follow what is changing and why. Progress and discussion are tracked publicly in the Open VSX deployment issue:
https://github.com/EclipseFdn/open-vsx.org/issues/5970

What this means for the community

The goal is to keep the Open VSX Registry reliable and fair as it scales, while minimizing impact on normal use.

For most users, nothing should feel different. Developers should see little to no impact, and publishers should not experience disruption to normal publishing workflows. Sustained, high-volume automated consumers may need to coordinate with the Registry to ensure their usage can be supported reliably over time.

Organisations that depend on the Open VSX Registry for sustained or commercial-scale usage are encouraged to get in touch. Coordinating early helps us plan capacity, maintain reliability, and support the broader ecosystem. Please contact the Open VSX Registry team at infrastructure@eclipse-foundation.org.

The intent is not restriction, but clarity in support of fairness, stability, and long-term sustainability.

Looking ahead

Automation is reshaping how developer infrastructure is consumed. Responsible rate limiting is one step toward ensuring the Open VSX Registry can continue to serve the ecosystem reliably as those patterns evolve.

We will continue to adapt based on real-world usage and community input, with the goal of keeping the Open VSX Registry a dependable shared resource for the long term.

This infrastructure supports project governance, developer tooling, and day-to-day operations across Eclipse open source projects. While much of it runs quietly in the background, it plays a critical role in the health, security, and sustainability of those projects.

We are expanding the Software Development team with two new roles. Both positions involve contributing to the design, development, and operation of services that are widely used, security-sensitive, and expected to operate reliably at scale.

Software engineer: security and detection

One of the roles is a Software Engineer position with a focus on security and detection engineering, alongside general development and operations.

This role will work on Open VSX Registry, an open source registry for VS Code extensions operated by the Eclipse Foundation. As adoption grows, maintaining the integrity and trustworthiness of the registry requires continuous analysis, detection, and operational safeguards.

In this role, you will:

• Analyse suspicious or malicious extensions and related artefacts
• Develop, test, and maintain YARA rules to detect malicious or policy-violating content
• Design, implement and contribute improvements to backend services, including new features, abuse prevention, rate-limiting, and operational safeguards

This is hands-on work that combines backend development with practical security analysis. The outcome directly improves the reliability, integrity, and operation of services that are part of the developer tooling supply chain.

For more context on this work, see my recent post on strengthening supply-chain security in Open VSX.

To apply:
https://eclipsefoundation.applytojob.com/apply/eXFgacP5SJ/Software-Engineer

Software developer: open source project tooling and services

The second role is a Software Developer position focused on improving the tools and services that support Eclipse open source projects.

This work centres on maintaining and evolving systems that our open source projects and contributors rely on every day. It includes:

• Maintaining and modernising project-facing applications such as projects.eclipse.org, built with Drupal and PHP
• Developing Python tooling to automate internal processes and improve project metrics
• Improving services written in Java or JavaScript that support project governance workflows

As with the Software Engineer role, this position involves contributing to production services. The focus is on incremental improvement, reducing technical debt, and ensuring systems remain maintainable, secure, and reliable as they evolve.

To apply:
https://eclipsefoundation.applytojob.com/apply/mvaSS7T8Ox/Software-Developer

What we are looking for

Across both roles, we are looking for people who:

• Take a pragmatic approach to problem solving
• Are comfortable working in a remote, open source environment
• Value clear documentation and thoughtful communication
• Enjoy understanding how systems work and how to improve them over time

If you are interested in working on open source infrastructure with real users and real impact, we would be happy to hear from you.

A quick note on terminology: Eclipse Open VSX is an open source project, and the Open VSX Registry is the hosted instance of that project, operated by the Eclipse Foundation. This post focuses primarily on security improvements being rolled out in the Open VSX Registry, while much of the underlying work is happening in the Open VSX project.

Up to now, the Open VSX Registry has relied primarily on post-publication response and investigation. When a bad extension is reported, we investigate and remove it. While this approach remains relevant and necessary, it does not scale as publication volume increases and threat models evolve.

To address this, we are taking a more proactive approach by adding security checks before extensions are published, rather than relying only on reports after the fact.

Why pre-publish security checks matter

Developer tooling ecosystems, including package registries and extension marketplaces, are a popular target, and we see the same types of issues repeatedly:

• Namespace impersonation designed to mislead users
• Secrets or credentials accidentally committed and published
• Malicious or misleading extensions
• Supply-chain attacks that spread quietly over time

Relying only on after-the-fact detection leaves a growing window of exposure. Pre-publish checks help narrow that window by catching the most obvious issues earlier. Similar pre-publication and monitoring approaches are increasingly standard across large extension marketplaces as developer tooling ecosystems mature.

How we’re approaching this work

To move faster and add specialized expertise, we are working alongside security consultants from Yeeth Security. These experts are helping us design and implement a new verification framework, while keeping overall direction, decision-making, and long-term stewardship firmly within the Open VSX project and the Eclipse Foundation as operators of the Open VSX Registry.

Most of this work is happening in the open. We are keeping a small set of security-sensitive details private to reduce the risk of abuse or circumvention.

What we’re building

Together, we’re introducing a new, extensible verification framework. Over time, it will enable Open VSX Registry to:

• Detect clear cases of extension name or namespace impersonation
• Flag accidentally published credentials or secrets
• Scan for known malicious patterns
• Quarantine suspicious uploads for review instead of publishing them immediately, with clear feedback provided to the publisher

If you want to follow along, the work is tracked here:
https://github.com/eclipse/openvsx/issues/1331

This framework is designed to grow with the ecosystem, so we can add new checks as threat models evolve.

A measured rollout

We’re approaching this effort with a focus on ecosystem health. The goal and intent is to raise the security floor, help publishers catch issues early, and keep the experience predictable and fair for good-faith publishers. Our current plan is to:

• Begin monitoring newly published extensions in February, without blocking publication
• Use this monitoring period to tune checks, reduce false positives, and improve feedback
• Move toward enforcement in March, once we’re confident the system behaves predictably and fairly

This staged rollout gives us room to get it right before it impacts publication flows.

What publishers and users should expect

Publishers may start seeing new messages when potential issues are detected. In most cases, these are meant to be helpful nudges, not roadblocks. We also want to thank the thousands of extension publishers who already act responsibly and help make the Open VSX Registry a trusted resource for the broader developer community. The goal is to:

• Catch accidental mistakes early
• Make expectations clearer
• Reduce the likelihood that risky content reaches users

Human review will remain part of the process, especially for edge cases. We will also continue to provide clear remediation guidance in our wikis and project documentation.

For users, the outcome is straightforward. Pre-publish checks reduce the likelihood that obviously malicious or unsafe extensions make it into the ecosystem, which increases confidence in the Open VSX Registry as shared infrastructure.

Security is ongoing work

Security isn’t a one-and-done project. It evolves alongside the ecosystem it protects. We see this work as ongoing, and we’ll continue to share what we’re doing, why we’re doing it, and what we learn along the way.

Looking ahead

Strengthening supply-chain security is a shared responsibility. As the Open VSX Registry continues to grow, investing in proactive safeguards is essential to protecting both publishers and users.

These changes are an important step forward, and part of a longer journey. We’ll keep iterating, learning from real-world use, and adapting as the ecosystem evolves. Community feedback plays a critical role in that process, and we encourage publishers and users to share their experiences as this work rolls out.

We would also like to thank Alpha-Omega for supporting this work, and for their broader support of the Eclipse Foundation’s security initiatives.

Our goal is simple: to keep the Open VSX Registry a resource developers can depend on with confidence.

Growing with the ecosystem

The security work outlined above is part of a broader effort to scale the Open VSX Registry responsibly as adoption continues to grow. That includes investing not just in tooling and processes, but in the people doing the work.

We’re actively expanding the Open VSX team, including roles focused on security, platform engineering, and ecosystem stewardship. If you’re interested in helping build and protect critical open source infrastructure, you can find our current openings on the Eclipse Foundation careers page!

Starting June 11, 2025, we will begin sending email reminders before a standalone ECA is set to expire. For those who need to take action, the email will have a subject line of "Action Required: Your Eclipse Contributor Agreement (ECA) is Expiring Soon" and will contain a link to renew the agreement.

If you are an Eclipse committer who has signed an Individual Committer Agreement (ICA), or an employee of a member organization that has signed the Member Company Committer Agreement (MCCA), you do not need to renew the standalone ECA, as both agreements already include it. If you are covered by one of these agreements, an expiring standalone ECA will not affect your ability to contribute. In this case, you will receive a separate informational email with the subject: "No Action Required: Your Eclipse Contributor Agreement (ECA) is Expiring Soon" to confirm your status.

For those covered only by a standalone ECA, if it expires, you won't be allowed to contribute to open source projects at Eclipse until you sign it again. Specifically:

• You will no longer be able to submit a merge request to an Eclipse project repositories hosted on Eclipse Foundation GitLab.
• Your commits included in a GitHub Pull Request will fail our automated ECA validation check.

If this happens, you can always restore your ability to contribute by visiting https://accounts.eclipse.org/user/eca and signing the ECA. Your contributor status will be restored once the new agreement is processed, which may take 5 to 15 minutes for our system caches to update.

For any questions or feedback, please join the discussion on our HelpDesk issue.

We looked through our access logs for the past few months and confirmed that the only requests were from the security researcher and the Eclipse Foundation staff who verified the report.

Background

The incident was introduced by the Drupal core JSON:API module being enabled in production without recommended field access restrictions. This module exposes data such as user entities and fields based on Drupal’s default permissions. While email addresses were not visible, other custom fields were publicly accessible for some users and staff:

• City
• Province/State
• Country
• Matrix ID

We did not intend for this information to be publicly accessible by this module. While we do ask our committers to provide their full postal address, that additional information is not stored in Drupal and was not exposed.

Timeline of Events

• January 19, 2025: Endpoint became accessible after going live with our Drupal 10 migration of accounts.eclipse.org
• March 26, 2025 (08:16 AM EDT): Received initial security report from ethical security researcher in the security@eclipse.org inbox.
• April 3, 2025 (11:08 AM EDT): Security Team confirmed the issue, and notified the WebDev team.
• April 3, 2025 (12:39 PM EDT): Endpoint was disabled.

Resolution and Next Steps

To resolve the issue and prevent similar incidents in the future, we have:

• Disabled Drupal's JSON:API module from accounts.eclipse.org
• Installed and configured the Field Permissions module to enforce field-level access control.
• Initiated a full audit of all our Drupal-based sites to ensure the JSON:API module is disabled and the Field Permissions module is enabled and properly configured.

We remain committed to continuously strengthening our security practices and protecting user data. We would like to thank security researcher Gaurang Maheta for promptly reporting this issue. If you have any questions or concerns, please contact us at privacy@eclipse.org or security@eclipse.org.

To ensure a smooth transition, we’ve scheduled a maintenance window on January 19, 2025, from 02:00 am CET to 06:30 pm CET, during which accounts.eclipse.org will be in read-only mode.

During this period, users will be able to log in and access other Eclipse Foundation websites, such as projects.eclipse.org, gitlab.eclipse.org, and marketplace.eclipse.org. However, some functionality, such as the profile edit form and the create an account form will be temporarily disabled to prevent data loss while we migrate your profile data to a new database.

We’re excited about this migration and hope it will provide a better user experience for all. If you have any feedback or encounter issues, please visit our dedicated issue, which includes details on how to access the staging environment to preview the changes and how to share feedback with us!

Why Are We Dropping Gravatar?

• Improved Privacy: Moving away from Gravatar reduces reliance on external services, giving users greater control over their profile pictures and personal data.
• Inconsistent Profile Pictures: Users have experienced issues in the past with their profile pictures displaying inconsistently across some sites due to syncing problems between Gravatar and our internal systems. This update ensures a more consistent experience.
• Lack of Support with Drupal 10: The Gravatar integration module used with Drupal 7 is not compatible with Drupal 10, and maintaining support would require significant effort.

What Does This Mean for You?

To address these issues, we've introduced a new profile picture endpoint that ensures a consistent solution for displaying profile pictures across supported sites. This endpoint will show either the user's uploaded picture or our default silhouette if no picture is available. This update also aligns with our goal to minimise personal data that we need to sync across our various web properties.

To display a community member's profile picture on your project website, simply replace [:eclipse_username] with the user's Eclipse username and use that URL as the href value in your image tag:

https://accounts.eclipse.org/user/[:eclipse_username]/picture

For example, my picture is available here (my Eclipse username is "cguindon"):
https://accounts.eclipse.org/user/cguindon/picture

The content of that image URL will automatically change if the user uploads a new picture or removes it in the future. If you display profile pictures on your project website, this new endpoint eliminates the need for you to sync profile pictures as-well!

Important: Some of our services, such as GitLab, manage profile pictures independently and do not use this new endpoint. This change will not affect your picture on GitLab. To update your GitLab profile picture, visit your Eclipse GitLab Edit Profile page.

If you currently use Gravatar for your profile picture, it will no longer be displayed on sites like accounts.eclipse.org, projects.eclipse.org, blogs.eclipse.org, marketplace.eclipse.org, and newsroom.eclipse.org. To ensure your profile has a picture, please upload an Eclipse profile picture now in your account.

A service refers to any system or service hosted, funded, or supported by the Eclipse Foundation, including domains, subdomains, servers, Project and Industry Collaboration websites, sandboxes, website analytics, and third-party tools (e.g., Survey Monkey, Google Analytics, Netlify).

If you are Service Operator, we ask that you review this new policy and ensure your service is in adherence to it.

What’s New?

1. Clearer Privacy and Security Guidelines
   The updated policy clarifies the responsibilities of service operators in managing personal information (PI) and ensuring compliance with global privacy regulations. This includes but not limited to:

   • Ensuring proper anonymisation of PI (e.g., IP anonymisation in Google Analytics) and deleting it when no longer needed.
   • Completing a Data Protection Impact Assessment (DPIA) to document how PI is collected, retained, and deleted.
   • Promptly reporting security breaches to the Eclipse Foundation’s Security Team at security@eclipse-foundation.org, with details on the nature and scope of the breach.

2. Dedicated GitLab Project for Reporting
   To simplify the reporting and approval processes, we’ve created a GitLab project that service operators must use to:

   • Submit a Usage Report notifying and seeking approval from the Eclipse Foundation regarding their PI collection activities.
   • Request a Client ID and Secret for those who wish to implement the Eclipse Foundation OpenID Connect service to enable secure logins with Eclipse accounts.

3. New Analytics Platforms and Content Embedding Restrictions
   The policy now includes two new supported website analytics platforms and a list of approved domains for embedding external content. The use of any other services or domains requires explicit consent from the Eclipse Foundation, which can be requested by contacting privacy@eclipse.org.

Action Required

If you operate a service that collects Personal Information (e.g., usernames, email addresses, or other user-identifiable data), you must:

• Submit a Usage Report to inform us of your activities.
• For new services, you must now obtain formal approval via an issue before starting any data collection.

Note: This step is not required for service operators maintaining project websites that do not collect Personal Information or use any website analytics platform.

We are committed to supporting our community in meeting the highest standards for privacy, security, and transparency. For more details, please review the updated policy and don’t hesitate to contact us at privacy@eclipse.org if you have any questions!

The Eclipse User Storage Service (USS) API was created in 2015 to enable Eclipse projects to store and retrieve user data and preferences from our servers. Complementing this is the Eclipse User Storage Service SDK which offers a user-friendly Java library tailored for Eclipse RCP-based applications to simplify the integration with Eclipse USS API by managing the authentication and login processes.

Despite their past utility, the usage of this service has been steadily declining, and the costs associated with maintaining it are increasing.

Our current plan is to remove the Eclipse USS SDK from SimRel before the release of Eclipse IDE 2025-03 and to shut down the API service by 2 July 2025.

We appreciate your understanding and cooperation as we navigate these changes. If you have any questions or require further assistance, please don't hesitate to reach out via our helpdesk issue #4696.

References

• Deprecate the Eclipse User Storage Service (USS) by 2 July 2025.
• Eclipse User Storage Service SDK project
• Eclipse USS OpenAPI Docs
• Eclipsepedia: Eclipse USS
• Eclipse Oomph
• Eclipse MarketPlace Client

Our decision to extend support until 2024 is strategic. Based on our website analytics, a small but significant 3% of our user base is still utilizing IE 11. It's important to remember that IE 11 is a legacy browser that is no longer supported by Microsoft, posing increased security risks. We believe this timeline will provide ample opportunity for users to transition to modern, more secure browsers while allowing us to align our technical roadmap.

What Does This Mean for You?

For those still using IE 11, we strongly urge you to transition to a modern browser before January 1, 2024. Popular alternatives include Microsoft Edge, Google Chrome, and Mozilla Firefox, all of which offer a more secure and efficient browsing experience.

We understand that this is a significant change, and we want to hear from you. If you have any concerns or objections, please participate in our discussion.

While we aim to be as inclusive as possible in terms of browser support, technological advancements necessitate this inevitable shift. We believe that by giving our community advance notice, we're ensuring a smoother transition for everyone involved.

To provide some context, we're migrating a total of six key websites:

• projects.eclipse.org: The Eclipse Project Management Infrastructure (PMI) consolidates project management activities into a single consistent location and experience.
• accounts.eclipse.org: The Eclipse Account website is where our users go to manage their profiles and sign essential agreements, like the Eclipse Contributor Agreement (ECA) and the Eclipse Individual Committer Agreement (ICA).
• blogs.eclipse.org: Our official blogging platform for Foundation staff.
• newsroom.eclipse.org: The Eclipse Newsroom is our content management system for news, events, newsletters, and valuable resources like case studies, market reports, and whitepapers.
• marketplace.eclipse.org: The Eclipse Marketplace empowers users to discover solutions that enhance their Eclipse IDE.
• eclipse.org/downloads/packages: The Eclipse Packaging website is our platform for managing the publication of download links for the Eclipse Installer and Eclipse IDE Packages on our websites.

The Progress So Far

We’ve made substantial progress this year with our migration efforts. The team successfully completed the migration of Eclipse Blogs and Eclipse Newsroom. We are also in the final stages of development with the Eclipse Marketplace, which is currently scheduled for a production release on October 25, 2023. Next year, we'll focus our attention on completing the migration of our more substantial sites, such as Eclipse PMI, Eclipse Accounts, and Eclipse Packaging.

More Than a Simple Migration: Decoupling Drupal APIs With Quarkus

This initiative isn't just about moving from one version of Drupal to another. Simultaneously, we're undertaking the task of decoupling essential APIs from Drupal in the hope that future migration or upgrade won’t impact as many core services at the same time. For this purpose, we've chosen Quarkus as our preferred platform. In Q3 2023, the team successfully migrated the GitHub ECA Validation Service and the Open-VSX Publisher Agreement Service from Drupal to Quarkus. In Q4 2023, we're planning to continue down that path and deploy a Quarkus implementation of several critical APIs such as:

• Account Profile API: This API offers user information, covering ECA status and profile details like bios.
• User Deletion API: This API monitors user deletion requests ensuring the right to be forgotten.
• Committer Paperwork API: This API keeps tabs on the status of ongoing committer paperwork records.
• Eclipse USS: The Eclipse User Storage Service (USS) allows Eclipse projects to store user-specific project information on our servers.

Conclusion: A Forward-Looking Transition

Our migration journey from Drupal 7 to Drupal 9, with plans for Drupal 10, represents our commitment to providing a secure, efficient, and user-friendly online experience for our community. We are excited about the possibilities this migration will unlock for us, advancing us toward a more modern web stack.

Finally, I'd like to take this moment to highlight that this project is a monumental team effort, thanks to the exceptional contributions of Eric Poirier and Théodore Biadala, our Drupal developers; Martin Lowe and Zachary Sabourin, our Java developers implementing the API decoupling objective; and Frederic Gurr, whose support has been instrumental in deploying our new apps on the Eclipse Infrastructure.

As we prepare to go live with this new version, we're turning to you, our valued community, to assist us with the testing. Our goal is to ensure that the new Drupal 9 implementation of the Eclipse Marketplace website delivers the quality and functionalities we all have come to rely on. To this end, while this new implementation does make some updates in functionality and other enhancements, it largely is a migration of the existing marketplace functionality.

You can access the staging instance at https://marketplace-staging-d9.eclipse.org.

Areas Up for Testing:

1. MarketPlace Client (MPC) in Eclipse IDE: Our new API implementation and the revamped favorite management system are up for review. For detailed steps on how to configure your Eclipse IDE to query our staging server, please refer to the Marketplace REST API Documentation.
2. Editing and Content Management Features: For extension maintainers, we've introduced a mobile-responsive theme and made several content management improvements.
3. Search Performance and Accuracy: It's vital to ensure the revamped search mechanism operates with efficiency and accuracy.
4. General Website Features: Explore the site and confirm all the familiar features are functioning seamlessly.

How Should I Submit Feedback?

Please submit your feedback via a new Gitlab issue. When sharing your experiences, include pertinent details such as the current behavior, the desired outcome, the affected URL, any specific search queries alongside expected results, and/or any other information that may be relevant.

For complete guidance, refer to the dedicated issue we've set up for this testing phase.

Facing a Glitch?

If you hit any roadblocks accessing our staging server or configuring MPC, feel free to drop a comment on our issue dedicated to this testing phase.

Your contribution ensures that our community continues to have the best tools at its disposal.

Let's make the Eclipse Marketplace a robust and seamless experience for everyone. Dive in, test, and share your feedback. Your insights can make all the difference.

As you may be aware, Google Analytics 4 is being rolled out as a replacement for Universal Analytics. While Universal Analytics is still supported at this time, Google has announced that they will stop processing new hits for all standard Universal Analytics properties on July 1, 2023.

Therefore, we strongly recommend that all projects currently using GA take some time to re-evaluate whether it is still necessary for their needs. If the data provided by GA is no longer useful or necessary, we recommend that projects remove GA from their website.

If it is determined that the data is still relevant and useful for the project, we recommend that it be migrated to Google Analytics 4 manually. Google has provided a migration guide for those who are looking to upgrade.

We believe this is the safest way for projects to confirm that all is well, as we cannot assume that the automatic GA migration will work as expected for everyone. Also, it’s the only way for projects to ensure that explicit consent has been given by the user via our cookie consent banner before enabling GA.

As a reminder, it’s possible to add our cookie consent banner to any website by adding the following code snippet in the section of each page:

<link rel="stylesheet" type="text/css" href="//www.eclipse.org/eclipse.org-common/themes/solstice/public/stylesheets/vendor/cookieconsent/cookieconsent.min.css" />
 
<script src="//www.eclipse.org/eclipse.org-common/themes/solstice/public/javascript/vendor/cookieconsent/default.min.js"></script>

A project website with GA must then ensure that the value of the eclipse_cookieconsent_status cookie is set to “allow” before loading GA on a webpage.

Additionally, we recommend that projects opt-out from letting GA make any changes to their account. This will ensure that projects have full control over their upgrade and can manage it in a way that best suits their needs.

Upgrading to GA 4 will not only provide access to new features and benefits but will also ensure that project websites are prepared for the future of Google Analytics before the end of support for Universal Analytics.

As always, we are here to support you with any questions or concerns you may have. Please do not hesitate to reach out to us via issue #2630 in our Helpdesk.

You can also find additional information and requirements around the acceptable usage of GA for Eclipse projects in our Eclipse Foundation Hosted Services Privacy and Acceptable Usage Policy.

With this update, we are moving our validation logic to our new ECA Validation API that we created for our new Gitlab instance.

We are planning to push these changes live on Wednesday, December 9 at 16:00 GMT, though there is no planned downtime associated with this update.

Our plan is to revert back to a previous version of the plugin if we detect any anomalies after deploying this change.

Please note that we are also planning to apply these changes to our GitHub ECA validation app in Q1 of 2021. You can expect more news about this in the new year!

For those interested, the code for the API and the plugin are open-source and can be seen at git-eca-rest-api and gerrit-eca-plugin.

Please use our GitHub issue to discuss any concerns you might have with this change.

In November 2019, The Eclipse IoT working group launched a campaign to promote adopters of Eclipse IoT technologies. Since then, more than 60 organizations have shown their support to various Eclipse IoT projects.

With that success in mind, we decided to build a new API service responsible for managing adopters for all our projects.

If needed, this new service will allow us to create an Adopters page for each of our working groups. This is something that we are currently working on for Eclipse Cloud Development Tools. Organizations that wishes to be listed on this new page can submit their request today by following our instructions.

On top of that, every Eclipse project can now leverage our JavaScript plugin to display logos of adopters without committing them in their website git repository.

As an example, you can check out the Eclipse Ditto website.

What Is Changing?

We are migrating logos and related metadata to a new repository. This means that adopters of Eclipse IoT technologies will be asked to submit their request to this new repository. This change is expected to occur on December 10, 2020.

We plan on updating our documentation to point new users to this new repository. If an issue is created in the wrong repository, we will simply move them to the right location.

The process is very similar with this new repository but we did make some improvements:

1. The path where we store logos is changing
2. The file format is changing from .yml to .json to reduce user errors.
3. The structure of the file was modified to make it easier for an organization to adopt multiple projects.

We expect this change to go uninterrupted to our users. The content of the Eclipse IoT Adopters page won't change and the JavaScript widget hosted on iot.eclipse.org will continue to work as is.

Please create an issue if you have any questions or concerns regarding this migreation.

How Can My Organization be Listed as Adoptor of Eclipse Technology?

The preferred way to become an adopter is with a pull-request:

1. Add a colored and a white organization logo to static/assets/images/adoptors. We expect logos to be submitted as .svg and they must be transparent. The file size should be less than 20kb since we are planning to use them for the web!
2. Update the adopter JSON file: config/adopters.json. Organizations can be easily marked as having multiple adopted projects across different working groups, no need to create separate entries for different projects or working groups!

The alternative way to become an adopter is to submit an issue with your logo and the project name that your organization has adopted.

How Can We List Adopters on Our Project Website?

We built a JavaScript plugin to make this process easier.

Usage

Include our plugin in your page:

<script src="//api.eclipse.org/adopters/assets/js/eclipsefdn.adopters.js"></script>

Load the plugin:

<script>
  eclipseFdnAdopters.getList({
    project_id: "[project_id]"
  });
</script>

Create an HTML element containing the chosen selector:

<div class="eclipsefdn-adopters"></div>

• By default, the selector's value is eclipsefdn-adopters.

Options

<script>
  eclipseFdnAdopters.getList({
    project_id: "[project_id]",
    selector: ".eclipsefdn-adopters",
    ul_classes: "list-inline",
    logo_white: false
  });
</script>

For more information, please refer our README.md.

A huge thank you to Martin Lowe for all his contributions to this project! His hard work and dedication was crucial for getting this project done on time!

To support this initiative, we needed to start making some important changes to our website. This week, we made available the first round of these changes!

1. Eclipse Membership

First off, it was essential to rethink how we convey membership information on our website. Our main goal was to organize information effectively and highlight important links such as how to contact us.

We decided to use tabs to make it easier for users to find our membership fees, our membership levels, how to become a member, and our key services.

Folks are no longuer required to navigate between multiple pages to find the information they need.

2. Eclipse Working Groups

Given that many of our new members are now interested in joining an Eclipse Working Groups, we wanted to make sure that important documents, such as the Working Group Partipation Agreement or the Working Group Charter, were easy to find.

Therefore, we thought changing the layout would help. We highlighted the Resources section to make it really visible on the page and now we have more space to grow and support additional documents in the future.

3. Eclipse Members

Finally, we simplified our Members page, we thought the page would be more interesting by offering a simple list of logos and company name by removing the short description of each member.

The Work Ahead

Our focus is now on the required content updates for Eclipse Foundation AISBL.

We created Bug 566455 - Website Updates For Eclipse Foundation AISBL to discuss these remaining changes.

One of those changes is to publish the Eclipse Foundation AISBL Membership Agreement. This is a new agreement that members will be asked to sign as of October. To simplify the signing process, we will allow our members to sign the Membership Agreement with an eSignature.

We also need to update the currency of our membership fees. Our fees will no longer be stated in USD but in Euros.

The list of remaining changes is available via the dependency tree of this project.

To learn more about the Eclipse Foundation transition to Europe, please visit eclipse.org/europe.

Yes, you got that right, the end result was -77,116 lines of code because we took the opportunity to clean up our codebase.

To kickoff this initiative, the community help us define the goals for this project:

1. Improve our information architecture:
   Led by Frédéric Desbiens, the Eclipse IoT community created a new structure for the website.
2. Contribute to the recruitment of new members and adopters:
   Adopters and Members are now top-level menu items. We also created a new “How to be Listed as an Adopter” page.
3. Ensure the website cathers to both technical and non-technical visitors:
   We made some big improvements to our Community and Resources sections. These sections cathers to both technical and non-technical users since you can find Case-Studies, Market Reports, Videos, White Papers and some additional information on how you can stay informed about what's currently going on with Eclipse IoT.
4. Drive adoption for our technologies:
   We now fetch project information from the Eclipse PMI each time we push a change to the website. Our stale project page is now a thing of the past!

In an effort to communicate our project plans with our community, we created a public GitHub project with two milestones.

Being open and transparent allows us to natually inform our communities about our efforts and we think it's a great way for us to collaborate and share tasks. As the project manager, this workflow allows me to ensure that the project is moving forward as planned.

We also created a set of brand guidelines for the Eclipse IoT Working Group. These guidelines include the brand font (Roboto), logo variations, color swatches, and acceptable logo treatments. This will help us consistently deploy the brand across different digital and print channels as well as Eclipse IoT events.

Overall, I am very happy with this new redesign! A huge thank you to Eric Poirier, Matt Joanisse, a graphic designer hired by the Foundation to work on the site, Christie Witt, Joe Speed, Frédéric Desbiens and Martin Lowe!

We are not expecting any disruption of service but it's possible that some committers may lose write access to their Eclipse project GitHub repositories during this 1 hour maintenance window.

This toolset is responsible for syncronizing Eclipse committers accross all our GitHub repositories and on top of that, this new release will start syncronizing contributors.

In this context, a contributor is a GitHub user with read access to the project GitHub repositories. This new feature will allow committers to assign issues to contributors who currently don't have write access to the repository. This feature was requested in 2015 via Bug 483563 - Allow assignment of GitHub issues to contributors.

Eclipse Committers are reponsible for maintaining a list of GitHub contributors from their project page on the Eclipse Project Management Infrastructure (PMI).

To become an Eclipse contributor on a GitHub for a project, please make sure to tell us your GitHub Username in your Eclipse account.

Adopters are organizations that voluntarily show their support for the Eclipse IoT projects they have adopted (i.e. shipping commercial products based on the projects and/or using the projects for non-commercial or internal reasons).

You can add your organization logo to our list of adopters by submitting a pull request or by creating an issue. You can attach files to an issue by dragging and dropping them in the text editor of the form.

If you plan on submitting a pull request, you will need to make the following changes to the website codebase:

1. Add a colored and a white organization logo to static/assets/images/adoptors. We expect that all submitted logos to be transparent svg.
2. Update the adopter data file: data/adopters.yml If your organization wishes to express support for multiple projects, you will need to add your organization's YAML definition to the adopters list of each of the relevant project nodes.

Your participation in this initiative will publicly show your support for open source innovation.

List Eclipse IoT adopters on an Eclipse project website

Eclipse projects can showcase the logos of their adopters on their project websites. We built a JavaScript plugin to make this process easier. If you are a project committer, here are quick instructions on how to use the eclipsefdn-adopters.js on your Eclipse project website:

Usage

Include the plugin's JS in the section of the page:

<script src="//iot.eclipse.org/assets/js/eclipsefdn.adopters.js"></script>

Load the plugin:

<script>
  eclipseFdnAdopters.getList({
    project_id: "[project_id]"
  });
</script>

Create an HTML element containing the chosen selector:

<div class="eclipsefdn-adopters"></div>

• By default, the selector's value is eclipsefdn-adopters.

Options

<script>
  eclipseFdnAdopters.getList({
    project_id: "[project_id]",
    selector: ".eclipsefdn-adopters",
    ul_classes: "list-inline",
    logo_white: false
  });
</script>

The goal of this new GitHub App is to make sure that every contributor is covered by the necessary legal agreements in order to contribute to all Eclipse Foundation Projects including specification projects.

For example, all contributors must be covered by the Eclipse Foundation Contributor Agreement (ECA) and they must include a "Signed-off-by" footer in commit messages. When contributing to an Eclipse Foundation Specification Project, contributors must be covered with version 3.0.0 or greater of the ECA.

We created a GitHub App to improve the following problems:

1. Reduce our maintenance burden by simplifying the installation process.
2. Increase our API rate limit.
3. Create a better experience for users by allowing the App to be installed on non-Eclipse project repositories such as the Eclipse IoT website and the Jakarta EE website.

Finally, we made some improvements to our “details” page. We added a “revalidate” button to allow Eclipse users to trigger a revalidation without pushing new changes to the pull-request and we added some useful links to allow users to return to GitHub or to sign the ECA.

We are planning to install our new Eclipse ECA Validation Github App to all our Eclipse Projects on GitHub this week and I am hoping that these changes will improve the way our users are contributing via Github.

If you are using our new Github App and you wish to contribute feedback, please do so on Bug 540694 - Github IP validation needs to be more robust.

The Eclipse Foundation Hosted Services Privacy and Acceptable Usage Policy will provide guidance to folks who operate a virtual server or a website hosted either directly by the Eclipse Foundation or provided via the Eclipse Foundation’s funding in support of an Eclipse Foundation open source project.

We want to ensure that all such services meet the highest standards of privacy and transparency, and to ensure that any collected data is used strictly in support of the activities of its open source projects.

There are two changes that we would like to highlight. First we have updated our position on Google Analytics (GA). Projects will now be allowed to create their own GA property, provided they agree to the conditions listed in our new policy.

Secondly we are better defining the responsibilities of the projects or committers responsible for hosting a service or website with the Eclipse Foundation.

Hosted services and Eclipse Projects can adopt this new policy by creating an issue on Eclipse Bugzilla under Community > Hosted Services Privacy and Acceptable Usage Policy where they acknowledge reading and understanding the policy.

Those who wish to store Personally Identifiable Information (PII) must create and include a Data Protection Impact Assessment (DPIA) document. The DPIA must describe what kinds of PII data will be collected and their purpose. This will have to be updated as your services evolve by uploading a new version on Eclipse Bugzilla.

If a service wishes to retain PII for longer than 1 year, they must produce a Data Retention Policy (DRP) that indicates how long they plan to keep each pieces of PII data and why they need to keep them for that long.

For the complete list of requirements & conditions, please make sure to read the Eclipse Foundation Hosted Services Privacy and Acceptable Usage Policy.

Please let us know if you have any questions or concerns regarding this new policy by sending your questions to privacy@eclipse.org.

Since then, we migrated our Hugo theme, Eclipsepedia, Eclipse Community Forums and a few other Drupal sites, such as the Eclipse User Profile and the Eclipse Foundation Blog to the Quicksilver look and feel!

This week, I am happy to announce an update to the Eclipse Packaging website. For those who don't know, the Eclipse Packaging website is used to publish download links for the Eclipse Installer and Eclipse Packages.

I am very proud of the work done here since the original site desperately needed some TLC. I’m hoping the new look and feel will improve the way the Eclipse IDE is downloaded by the community!

New features include:

• A website redesign based off the Quicksilver look and feel.
• The links to the Eclipse Installer, Eclipse Packages and Eclipse Developer Builds are more accessible via a new submenu beneath our breadcrumbs.
• Created a new Eclipse Installer download page page with instructions.
• Made improvements to our breadcrumb links which allow users to easily find every Eclipse release on the Eclipse Packaging site.
• The More Downloads sidebar includes links to Eclipse Packages instead of the release train landing page.
• Links to the Eclipse Installer is available in the sidebar.

Finally, this migration is also a win for the Eclipse Foundation staff. These changes to the Eclipse Packages site allow us to streamline the Eclipse Release process and no longer requires us to manually submit Gerrit patches to publish a release.

1. Go to Help > Install New Software
2. Paste the Marketplace Client update site url into the "Work with" field: http://download.eclipse.org/mpc/photon
3. Select the "EPP Marketplace Client" checkbox
4. Follow the wizard and restart your Eclipse to finish the installation.

We are working on providing an update to the Eclipse Photon release to distribute the fix through automatic updates and package downloads. In the meantime, please update manually if you are affected by this bug.

If you have any questions about this update process, please send an email to mpc-dev@eclipse.org. For more technical details, see bug 536385.

Blog post co-authored with Carsten Reckord.

I am pleased to announce a new look and feel for www.eclipse.org, codenamed Quicksilver, and a new logo for the Eclipse Foundation which Mike Milinkovich, the Executive Director of the Eclipse Foundation, has blogged about.

The main goal of the redesign is to highlight the Eclipse Foundation as more than just the IDE it started with. We want the site to reflect the fact that the Foundation now represents a collection of working groups, open source projects, vendors and individual committers all collaborating in the same space to create innovative technologies.

We hope we have the balance right, making sure it remains easy for the millions of developers who visit our site to get to their desired downloads easily and quickly.

A Quicksilver prototype is available now via our public staging server. This server is protected with basic access authentication. The username is testuser and plaintext is the password.

The main focus of this redesign was on the following pages:

• Eclipse Foundation Homepage
• Eclipse Working Groups
• Business Value
• Content pages

You can participate and contribute to this project by submitting feedback on Bug 533394 - Quicksilver: eclipse.org new look and feel.

Quicksilver is going to be available on April 19th, 2018 for www.eclipse.org only. We will continue the rollout across our broader web properties over the coming weeks.

Technology-wise, Quicksilver is an extension of Solstice. Since this is not a complete overhaul of our existing codebase, we’re expecting the transition from Solstice to Quicksilver to be fairly straightforward. Website maintainers for Eclipse projects and working groups should know that the colors are going to change but we don’t expect to break any existing Eclipse project websites.

Future plans

We plan on changing our look and feel gradually. The following tasks are going to get done after the initial release of Quicksilver:

• Drupal themes for Eclipse Marketplace, Eclipse PMI and Eclipse User Profiles
• New Hugo theme for static websites
• Mediawiki theme for Eclipsepedia
• New theme for Planet Eclipse
• Updated header and footer for Eclipse Bugzilla, Gerrit, Eclipse CI and Eclipse Git repositories
• New FUDforum theme for the Eclipse Community Forums.

A lot of work needs to get done before this becomes available but I am very proud of the work we did so far for this project.

A huge thank you to Eric Poirier, Stephanie Swart, Thabang Mashologu, and the entire Eclipse Foundation staff!

We are using Bug 526827 - Fall clean up of eclipse.org-common to track the following tasks:

• Bug 468336 - Remove support for the Nova theme in eclipse.org-common
• Bug 526824 - Remove yui from eclipse.org-common
• Bug 526825 - Remove Services_JSON from eclipse.org-common
• Bug 526826 - Remove JQuery from eclipse.org-common

I believe this "clean up" exercise is our first step towards the execution of my long term plan for migrating our code base to follow recommendations from the PHP Framework Interop Group. I will be writing about this subject in a future blog post but for now, you can take a look at Bug 496514 - PHP sites maintained by the EF should follow recommendations from the Framework Interop Group.

Bug 468336 - Remove support for the Nova theme in eclipse.org-common

During the summer of 2014, my team was responsible for implementing the redesign of www.eclipse.org via Bug 432342 - Eclipse.org Website Redesign 2014. We created a new look and feel called Solstice and since then, we've been busy migrating all of our web properties.

Today, I am happy to announce that it’s finally time to retire the Eclipse Nova theme. We are planning on removing the Nova theme from eclipse.org-common on December 5th, 2017.

The Solstice look and feel will become the default theme for all web pages that are currently being served with Nova.

This change will be affecting the following websites:

• Celebrating 10 years of Eclipse
• Agent Modeling Platform
• PEL Designer Project
• BPMN2 Modeler
• CDO
• Eclipse CDT (C/C++ Development Tooling)
• Damos
• EGF
• EMF Refactor
• Equinox
• EMF Facet
• FMC - Fundamental Modeling Concepts
• GEF3D
• Gemini
• Gemini DBAccess
• Gemini JPA
• Henshin
• Java Workflow Tooling (JWT)
• Libra
• Maven Integration for WTP
• Mangrove - SOA Modeling Framework
• Model to Model Transformation (MMT)
• Graphical Modeling Project (GMP)
• Model Development Tools (MDT)
• Marketplace Client
• OSEE: The Open System Engineering Environment
• Pulsar
• R4E
• RT
• Skalli
• SOA Platform Project
• The Spatiotemporal Epidemiological Modeler (STEM) Project
• Tigerstripe
• Tycho - Building Eclipse plug-ins with maven
• UOMo
• Vex - A Visual Editor for XML

Please use Bug 468336 - Remove support for the Nova theme in eclipse.org-common to discuss any concerns regarding this change.

I am new to the blogging world and I am really excited to kick off this new challenge with this report.

My blog posts will be on the following topics:

1. Quarterly reports on web developpement at the foundation;
2. Maintenance window calendar;
3. Web developpement tips and tricks for Eclipse projects;
4. Discussion on new features.

Here's a top-level list of items that we worked on in Q3 2017:

• Api.eclipse.org
  • Bug 516914 - Create public documentation for api.eclipse.org REST Api
  • Bug 502485 - Activity tab - Error reports from AERI
• Eclipse.org
  • Bug 519264 - Create an Eclipse Foundation webdev blog
  • Infra 2507 - Donate Campaign Plan - Fall 2017
  • Bug 521084 - Add epl-2.0 to the website
  • Bug 261658 - status.eclipse.org
• Eclipse Marketplace
  • Bug 520850 - Possible adware in marketplace plugin (Eclipse Class Decompiler)
  • Bug 501861 - Selecting a favorite on Eclipse Marketplace is slow
• Eclipse Project Management Infrastructure (PMI)
  • Bug 519694 - Remove solr on projects.eclipse.org
  • Bug 469321 - Portal Shutdown plan: Transfer all portal functionality to PMI, website
• Eclipse Working Groups
  • Bug 520121 - Need a new conference website for FOSS4G NA 2018
  • Bug 514542 - Create initial website for openPASS

Api.eclipse.org

Bug 516914 - Create public documentation for api.eclipse.org REST Api

The documentation for api.eclipse.org was all over the place and we needed to fix that.

Some documentation was available on our wiki page but most of it was written in our source code and in a Google document. We decided to resolve this issue by converting our GDOC to static HTML.

After trying out SWAGGER and RAML, we decided to use API Blueprint to generate our API docs.

API Blueprint is a documentation-oriented web API description language. The API Blueprint is essentially a set of semantic assumptions laid on top of the Markdown syntax used to describe a web API. In addition to the regular Markdown syntax, API Blueprint conforms to the GitHub Flavored Markdown syntax.

If you are interested in this project, our documentation source code is available on GitHub.

Bug 502485 - Activity tab - Error reports from AERI

As of June 2015, with the Eclipse Mars simultaneous release, all Eclipse packages are shipped with the Automated Error Reporting client (called AERI).

Ever since AERI became a part of the Eclipse packages, eclipse.org has seen a steady stream of incoming error reports. Eclipse users currently send around 70,000 reports per week. That is a total of 3 million reports in the past 12 months!

This quarter, we added a new Error Reports tab for each user profile on accounts.eclipse.org. This tab allows users to review reports they submitted.

You can try it out now by log in with your Eclipse account.

Eclipse.org

Infra 2507 - Donate Campaign Plan - Fall 2017

On September 29, we launched the October Donation Campaign. The goal is to have over 1000 individual donations to the Eclipse Foundation and help support the overall community.

We implemented a new donation page that allows donors to give back using their credit card. I expect this to be useful for user's who can't or won't use Paypal or Bitpay.

We investigated a few options to incorportate credit card donations and we chose Stripe. Regarding it's implementation, we are using the Drupal Stripe module with the latest Stripe PHP API Library.

A few days before pushing this to production we noticed that the Drupal Stripe module did not support web proxies. This was a last minute oversight because our testing servers did not require us to use a web proxy to connect to Stripe's API.

I created an issue on drupal.org to enable web proxy support and I am hoping the contribute a patch to fix this very soon.

You can help support the overall Eclipse community by donating now to the Eclipse Foundation.

Bug 521084 - Add epl-2.0 to the website

On August 24, The Eclipse Foundation announced that version 2 of the Eclipse Public License (EPL v2) was approved by the Eclipse Foundation Board of Directors and the Open Source Initiative (OSI).

I was tasked by Mike Milinkovich to format the final HTML and plain text document for this new version.

I was really excited to create these digital documents that will be included in many open source projects in the future.

For more information, you can visit the Eclipse Foundation press release.

Bug 261658 - status.eclipse.org

Denis, our IT Director, built this very nifty status page and by doing so, won the award for closing the oldest bug this quarter!

The status page measures performance of various Eclipse.org services from our monitoring agent in Portland, Oregon (many thanks to OSU Open Source Lab).

If you are experiencing issues with some of our services, please take a look at our Service Status page for more information.

Marketplace

Bug 520850 - Possible adware in marketplace plugin (Eclipse Class Decompiler)

It was brought to my attention that a listing on Eclipse Marketplace, called Eclipse Class Decompiler, contained binary code that could be used for adware and could potentially download files to Eclipse workspaces.

This issue was initially reported in a blog post from a community member. After a bit of testing with Burp Suite Free Edition, I was able to confirm his findings. It was clear that this plugin included code that was not appropriate for the Eclipse users and community.

We removed the listing from Eclipse Marketplace and the Eclipse Foundation strongly suggests any Eclipse user to uninstall this plugin from their workspace.

To remove this plugin, please do the following:

1. Go to Help > About Eclipse > Installation Details
2. Select the feature(s) belonging to the entry
3. Press "Uninstall"
4. Follow the wizard

If you have any questions, please send an email to EMO.

Bug 501861 - Selecting a favorite on Eclipse Marketplace is slow

Two years ago, we decided to move Eclipse Marketplace Favorites to Eclipse USS. This move allowed the Eclipse Marketplace Client (MPC) to leverage the Eclipse User Storage Service SDK to add/remove user favorites.

The Eclipse User Storage Service SDK provides an idiomatic Java library for easy use of the USS by Eclipse RCP-based applications. The USS SDK transparently handles the authentication and login capabilities required to use the USS from an Eclipse installation.

Unfortunately, this move created a regression on our website because it required the page to reload each time a favorite was added or removed.

To speed up this action, our team decided to enable the implicit grant flow for the Marketplace API endpoint on api.eclipse.org.

The implicit grant flow is used to obtain access tokens and is optimized for public clients. These clients are typically implemented in a browser using a scripting language such as JavaScript.

This update allowed us to create a jQuery library for adding/removing favorites. This new library can add and remove favorites without a page reload each time.

You can test this new change now on the Eclipse Marketplace website.

Eclipse Project Management Infrastructure (PMI)

Bug 519694 - Remove solr on projects.eclipse.org

We've been using Apache Solr for a few years now to run the Eclipse Projects search page. The search result page was very quick to load but our users often reported issues regarding the results.

Since Solr was a service that the Eclipse IT team needed to maintain, I considered removing Solr from projects.eclipse.org and replacing it with a simple Drupal view.

It didn't take long before it was obvious that this new page did a better job at meeting the needs of our community.

This was a win/win for both the Eclipse IT team and our community. We now have a better search results page for our users and the Eclipse IT team can drop the support of Solr instances for this website.

You can try this new search page now on projects.eclipse.org.

Eclipse Working Groups

Bug 520121 - Need a new conference website for FOSS4G NA 2018

This year's FOSS4G NA conference is a collaborative effort involving OSGeo and LocationTech. The conference provides opportunities for the FOSS4G community to learn, explore, share, and collaborate on the latest ideas and information.

The conference is next year from May 14 to the 16 in St. Louis.

The FOSS4G - North America 2018 website is now available and you can follow @foss4gna on twitter or the latest news.

Bug 514542 - Create initial website for openPASS

The goal of the Eclipse OpenPASS Working Group is to support the development of advanced driver assistance systems (also known as autonomous driving systems) providing tools and adapters for standardized openly-available and vendor-neutral platforms for simulation of traffic scenarios.

Eric Poirier did a great job at building this new website using Drupal and the Eclipse Solstice look and feel.

The OpenPASS Working Group website is now available!

Summary

I am very proud of the work that my team did this quarter and I am looking forward to new and exciting projects for Q4.

I am still working on a final list of MBO's for Q4 2017 but here's a shortlist of what's on my radar:

1. Migrate our Conference platform to COD 7.x-2.x.
2. Build a new conference website for Eclipse France 2018.
3. Pursue the work done so far with Bug 469321 - Portal Shutdown plan: Transfer all portal functionality to PMI, website, etc.
4. Bug 421727 - Use mysqli extension instead.
5. Archive some EclipseCon websites to static HTML to reduce maintenance.
6. Migrate mailing list subscriptions to accounts.eclipse.org.