Power Dynamics, Rug Pulls, and Other Corporate Impacts on OSS Sustainability

### Overview Open source software ecosystems increasingly reflect complex power dynamics reminiscent of historical feudalism. Large cloud service providers frequently monetize open source software without contributing back proportionately, placing financial strain on the smaller companies maintaining those codebases. In response to investor and board pressure to capture revenue, several single-vendor projects have executed "rug pulls" by shifting from open source licenses to restrictive non-open source licenses. While these shifts temporarily flip power away from cloud providers, they disenfranchise outside contributors and users. In turn, affected communities and cloud providers often respond through rebellious collective action by initiating hard forks. This presentation examines the dynamics, data, and outcomes of several prominent relicensing events and their forks, providing practical guidance for evaluating open source sustainability and mitigating disruption risk.

### Key Topics - **Feudal Power Imbalances in OSS**: Cloud providers dominate usage and monetization, while commercial project stewards, outside contributors, and users navigate shifting leverage points. - **Mechanisms of Rug Pulls**: Relicensing under non-OSI licenses (e.g., SSPL, Elastic License) or shifting binaries, packages, and development behind closed doors (e.g., Perforce's actions with Puppet; Linkerd stable artifacts; Bitnami container images). - **Hard Forks as Rebellious Collective Action**: Unlike GitHub social forks used for standard contributions via pull requests, hard forks establish competing development lines (e.g., OpenSearch from Elasticsearch, OpenTofu from Terraform, and Valkey from Redis). - **Impact on Contribution and Governance**: How contributor diversity, foundation stewardship (Linux Foundation, CNCF, Apache Software Foundation, Eclipse), and contributor agreements dictate post-fork viability.

### Technical Details Using empirical research from the CHAOSS Data Science Initiative stored in Jupyter notebooks, the speaker examined contribution patterns (commits, additions, deletions, lines of code, and corporate affiliations) across primary project repositories: - **Elasticsearch to OpenSearch**: In the year before and periods after Elasticsearch relicensed to SSPL/Elastic License, Elastic employees accounted for 95%–97% of code additions and deletions, with at most three non-Elastic contributors making 10 or more commits annually. Adding AGPLv3 later did not attract significant non-employee contributors. Amazon's fork, OpenSearch, was initially dominated by internal Amazon developers before gradually shifting toward broader outside participation and moving to the Linux Foundation. - **Terraform to OpenTofu**: Prior to relicensing, HashiCorp employees made nearly all significant commits. Following relicensing, OpenTofu was established immediately under the Linux Foundation. Significant contributions came from companies like Spacelift, with developers learning the codebase rather than having migrated from the upstream core team. - **Redis to Valkey**: Unlike Elasticsearch and Terraform, Redis had a robust external contributor base prior to relicensing (e.g., contributors from Amazon, Alibaba, Tencent, Huawei, Ericsson). Following relicensing, external contributors ceased contributing five or more commits to Redis. In Valkey's first year under the Linux Foundation, 52 people across 13 companies contributed, 22 of whom were historical Redis contributors. - **Usage Proxies**: Drawing on research linking GitHub stars and forks to project usage, relicensed projects experienced temporary spikes in forks (as users saved code snapshots) followed by permanently reduced trajectory in new stars and forks. While hard forks saw post-announcement spikes, both originals and forks currently coexist in parallel, though foundation-backed forks show stronger community traction.

### Takeaways To minimize vulnerability to rug pulls and project abandonment, organizations and maintainers should heed specific indicators: - **Avoid Contributor License Agreements (CLAs)**: CLAs consolidate relicensing authority within a single corporate entity. Developer Certificates of Origin (DCOs) protect against unilateral license changes. - **Prioritize Neutral Foundations and Governance**: Projects governed by neutral foundations (Linux Foundation, CNCF, ASF) foster level playing fields. However, neutral ownership alone is insufficient if development is monopolized by a single firm (as shown when Grafana forked Cortex to create Mimir under AGPLv3). - **Evaluate Contributor Diversity and Viability**: Rely on metrics models such as CHAOSS Project Viability Models and CHAOSS Practitioner Guides to assess organizational distribution, responsiveness, and contributor sustainability. Active corporate participation and contributing upstream remain the most effective defenses against unilateral rug pulls.