OpenList: How a Community Forked AList in 6 Months

When AList sold to an undisclosed Guizhou-based company in June 2025, the open-source community faced a trust problem. The file-listing application had become critical infrastructure for thousands of Chinese users managing fragmented cloud storage across 40+ domestic services—Aliyundrive, Baidu Netdisk, 115, Quark—most of which lack public APIs. The acquisition came with minimal transparency, triggering supply chain concerns serious enough that the community didn't just complain. They forked.

Six months later, OpenList has 21,000+ GitHub stars, packaging in Arch Linux's AUR by September, and NixOS availability by October supporting architectures from aarch64-darwin to armv5tel-linux. That's production adoption.

The Technical Problem Worth Forking

Chinese cloud storage presents a strange infrastructure challenge. Users juggle multiple services because each provider locks them into separate walled gardens, and unlike Western alternatives, these platforms rarely offer public APIs. Rclone won't help here—it's built for services with official APIs. Nextcloud solves a different problem, prioritizing privacy for self-hosted storage rather than aggregating third-party services.

AList solved this by reverse-engineering web interfaces to unify 40+ cloud storage services into a single browsable web UI. That's hard work: maintaining compatibility with constantly-changing proprietary interfaces, handling authentication flows that weren't designed for programmatic access, and doing it reliably enough that people trust it with their data.

When AList got acquired, the community didn't fork out of spite—they forked because the solution was too valuable to risk. The technical debt alone made abandoning it impractical.

Organized Action, Not Chaos

The OpenList timeline reads like a case study in deliberate community governance. The June fork wasn't just a git clone and rename. By September, the project landed in AUR, signaling that Arch maintainers considered it stable enough for user repositories. October brought NixOS packaging across six architectures, the kind of cross-platform maturity that takes real testing infrastructure.

The project shipped backward compatibility patches for AList V3 by version 4.1.0, letting existing users migrate drivers without manual reconfiguration. That's not flashy work, but it's the difference between a symbolic fork and a viable migration path. OpenList Desktop, a cross-platform GUI integrating OpenList with Rclone, launched as an official project by October—evidence that the team understood users needed more than just the core binary.

The 21,000 stars matter less as a vanity metric and more as proof that developers trusted the fork enough to switch their workflows. Major Linux distributions don't package software casually, and the three-month journey from fork to AUR suggests the maintainers moved fast without cutting corners.

What Makes a Fork Succeed

Most forks die quietly. The ones that survive share common traits: quick action before the community disperses, technical follow-through that matches the original project's quality, and transparent governance that addresses why the fork happened in the first place.

OpenList checked all three. The June timing captured momentum while developers still cared. The compatibility patches and desktop GUI proved the team could execute, not just complain. By forking over supply chain concerns rather than feature disagreements, they claimed the moral high ground without attacking the original maintainers.

For other open-source communities watching corporate acquisitions, OpenList offers a playbook: fork decisively, ship compatibility layers, get into distributions fast, and let adoption speak louder than manifestos. The Chinese cloud storage problem remains unsolved by commercial alternatives, which means OpenList now owns the solution that AList pioneered. That's how community resilience works when technical execution backs up the outrage.