Product Decisions This Supports
- Build vs. buy vs. fork — the fork is the wrong answer. This package is a third-party fork of Google's official PHP SDK (
google/apiclient), and its own maintainer has stamped it "DO NOT USE. ITS NOT MAINTAINED." That is a rare gift: an unambiguous, first-party signal that lets you close the build-vs-buy question in one meeting rather than one sprint. Decision: adopt the officially maintained google/apiclient, not this fork.
- Dependency risk triage for any Google-integrated surface. If your roadmap includes Calendar sync, Drive file access, Gmail send/read, YouTube Data API, or Analytics reporting, this package is a concrete reminder that SDK choice is a security and support decision, not just a composer line. Each of those features inherits the SDK's OAuth token handling, transport behavior, and vulnerability response time.
- Roadmap sequencing around integration risk. A deprecated SDK effectively caps your supported PHP versions and your ability to absorb Google API deprecations (e.g., OAuth out-of-band flows, scope changes, API version sunsets). If an integration is planned for next quarter, the SDK decision must land before the feature is estimated — otherwise engineering inherits an unplanned migration mid-build.
- Vendor and maintenance review calibration. Stars (33) and this assessment's low opportunity score reflect that the ecosystem has already voted: this is a low-signal artifact. Use it as a worked example in your internal dependency policy — "maintainer-declared abandonment" is a hard fail, independent of license (Apache-2.0 and permissive licensing do not imply support).
- Use case it legitimately serves: reference material only. Reading a historical snapshot of Google SDK structure, or understanding a legacy fork's divergence when migrating an old service off it. That is a one-time engineering read, not a product dependency.
When to Consider This Package
Adopt only under narrow, non-production conditions:
- You are migrating off it. An existing service already depends on this fork; you need to keep it pinned while you port to
google/apiclient. Treat it as a bridge with a dated removal ticket.
- You need a read-only historical reference to diff against the official SDK during a migration or incident review.
- You are doing dependency-policy training and want a real example of a maintainer-declared-dead package.
Look elsewhere — specifically at the official google/apiclient — when any of the following hold, which is essentially always for new work:
- The code path touches user data, OAuth tokens, or credentials (Calendar, Gmail, Drive). An unmaintained dependency in the auth path is an audit finding waiting to happen.
- You need security advisories, PHP version support, or bug fixes on a schedule you don't control.
- You are planning rather than remediating — for greenfield integrations, there is no reason to consider a fork its own author disavows.
- Your integration is narrow in scope (e.g., one endpoint, server-to-server). In that case a thin HTTP client plus
league/oauth2-google may be lighter than any full SDK, official or not.
How to Pitch It (Stakeholders)
For executives: We evaluated a PHP library for Google API integration and are recommending against it. Its own maintainer has publicly marked it as unmaintained and instructed people not to use it. Because this library would sit in the path that handles customer data and access tokens, adopting it would create an open-ended security and support liability with zero offsetting benefit — the officially maintained equivalent from Google is available, free, and under the same permissive license. Net decision: no adoption, no added cost, no added risk. The only action is a hygiene item: confirm no existing service depends on this fork, and if one does, schedule its migration.
For engineering: Treat evert/google-api-php-client as a dead branch. Standardize on google/apiclient for any Google integration; where the surface is small, a thin HTTP client with league/oauth2-google is an acceptable alternative. If you find this package in a composer.json, that is a migration ticket, not a discussion. Add "maintainer-declared abandonment" as an explicit disqualifier in our dependency review checklist so this class of decision doesn't consume review time again.