Appnet Laravel Package

Product Decisions This Supports

• Legacy migration / decommissioning planning: This package exists only as a read-only subtree split of SocialiteProviders/Providers for App.net (ADN). Its primary PM value is as a reference artifact — it tells you whether any historical auth flow in your codebase ever depended on ADN, and what a clean removal looks like.
• OAuth provider pattern literacy: Use it as a worked example when deciding build vs. buy for a new Socialite provider. It shows the minimal contract (provider class, getAuthUrl, getTokenUrl, getUserByToken, scopes, user mapping) you’d replicate for a live network.
• Not a roadmap input: With 0 stars, 0 dependents, and a release history that amounts to a single PHP 8 compatibility bump, this should not appear on any feature roadmap, integration backlog, or provider wishlist. There is no adoption decision to make — only a retirement decision if it is already vendored.
• Risk / surface-area reduction: If the dependency is present in composer.json or a lockfile, the PM decision is to remove it. Carrying an unmaintained provider for a defunct network is pure attack surface and audit noise with zero user value. The 4.1.0 PHP 8 bump means it is installable on modern runtimes — which makes silent lockfile persistence more likely, not the package more valuable.
• Portfolio hygiene for the SocialiteProviders org: The broader takeaway for a PM evaluating that ecosystem is that the monorepo (SocialiteProviders/Providers) is the real product; individual split repos with zero dependents are packaging artifacts, not independently supportable components. Evaluate the monorepo, never the split.

When to Consider This Package

Consider it only in these narrow cases:

• Archival or historical research: You are auditing whether an old Laravel app ever supported App.net login, or reconstructing how a 2014–2016-era social login stack was assembled.
• Template for a new provider: You want a small, real-world Socialite provider skeleton to copy while building a provider for a live service. Read it, don’t require it.
• Dependency forensics: You inherited a project and need to identify what pulled this in and confirm it is safe to drop.

Look elsewhere — decisively — when:

• You need working authentication. App.net shut down in 2017. The OAuth endpoints this provider targets no longer resolve, so there is no functional path even if you wanted it.
• You need maintenance, security response, or support. The only recent signal is a one-line "Support PHP 8" release; the package remains a read-only split with zero dependents and no issue triage on this repo. Runtime compatibility is not maintenance — no security response, no SLA, no roadmap.
• You are evaluating the SocialiteProviders ecosystem for production. Go to SocialiteProviders/Providers and check the specific provider’s dependents, release cadence, and whether the upstream network is still operating.
• You need a maintained auth dependency for a live third party. Prefer first-party/framework-supported drivers or a provider with meaningful dependent counts and recent releases.

Adoption criteria summary: this fails every standard gate — network viability (dead), maintenance (a single PHP 8 compatibility bump over a multi-year gap is not maintenance), ecosystem signal (0/0), and support model (read-only split). Treat it as remove-on-sight, not evaluate-for-adoption.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, unmaintained integration for App.net, a social network that shut down in 2017. It has no users, no dependents, and its only recent activity is a minor compatibility update so it can still install on newer PHP versions — no new capability, no security program, no support commitment. There is no business case to adopt it and no capability it can deliver. If it appears anywhere in our codebase, the correct action is to remove it as routine dependency hygiene — a low-effort cleanup that reduces security and audit exposure with zero impact on customers.

For engineering leadership: Do not add this package. The 4.1.0 "Support PHP 8" release is a compatibility patch, not a revival — it removes a blocking install error but changes nothing about the dead upstream service, zero dependents, or absence of maintenance. That makes it slightly more likely to sit unnoticed in a lockfile, so treat the release as a prompt to sweep for the dependency rather than a reason to keep it. If present, schedule removal and replace any lingering ADN login path with an explicit, user-facing deprecation if (and only if) telemetry shows real usage — highly unlikely given the network has been offline for years. Redirect any genuine "add a social login provider" request to the SocialiteProviders/Providers monorepo, and gate that request on three checks: the upstream service is live, the provider has recent releases, and it has non-trivial dependent counts.

For the team (framing): The artifact is useful as a ~100-line reference for what a Socialite provider must implement, and as a reminder that split repos are distribution mechanics, not products. Judge the parent library, not the shard. A PHP 8 compatibility bump on a dead provider is the textbook example of maintenance theater — green CI, no product.