We're seeing a trend of free (as in beer) resources being discontinued, or altered, with very little time provided to allow projects to react. This causes pain for OSS projects that use and depend on these services. The trend is certainly not new, and although there's certainly a case for the you-get-what-you-pay-for mantra, it's clear that relying on a single-vendor, third-party "free" resource is not without its risks.
Two recent cases come to mind:
Dockerhub pull rate limits. With about 2 months of notice, projects around the globe scrambled to fix release engineering processes to accommodate the upcoming limits.
JFrog terminating BinTray and others. With just under three months to react, projects who depend on these services need to find a new home for their binary distributions.
When relying on single-vendor services, or single-vendor open-source projects, or single-vendor anything for that matter, your assurance that you're not relying on a ticking time bomb is nil. At the Eclipse Foundation, we don't depend on a single vendor. In fact, we shy away from solutions that include the words Proprietary, Vendor, Closed and Licensed. A quick search for "eclipse vendor neutral" will provide dozens of examples.
The Eclipse Foundation does rely on some vendor products - GitLab and GitHub, for instance. We do need to strike a logical and reasonable balance between Vendor Neutrality and Ease of Use. We do, however, ensure two things:
The underlying data model is Open. In both those examples, the data is Git, and Git is not proprietary technology.
That we have a Plan B, should the vendor suddely change the playing field. We actively back up Eclipse project repositories that are on GitHub. The backup is a plain git clone.
Vendor Neutrality, along with those two strategies for dealing with vendor products and services, allow the Foundation to ensure project services are maintained with minimal risk or potential disruption from a single third party.