Traditional donation models let mega-popular packages capture 70%+ of funding, leaving critical but less-visible dependencies unsupported. A project with 150+ dependencies shouldn't send most of its donation to just one package.
This creates an unsustainable ecosystem where foundational packages that power your entire dependency tree receive minimal support, while a few highly visible packages capture disproportionate shares.
GiftOS uses a multi-factor balanced algorithm that evaluates each dependency on four dimensions:
| Factor | Weight | What it measures |
|---|---|---|
| Structural Importance | 29% | How many packages in YOUR tree depend on this |
| Ecosystem Popularity | 29% | Downloads, dependents, and GitHub stars (compressed) |
| Code Quality | 24% | Quality score, maintenance, community trust |
| Base + Version | 18% | Baseline recognition + multi-version usage |
We track which packages depend on which within your project. A utility used by 10 of your dependencies is more critical than a standalone leaf package.
A package with 100M downloads doesn't get 100x the weight of one with 1M downloads—it gets ~10x. This prevents runaway concentration.
No single factor exceeds 29% influence. A mega-popular but low-quality package won't dominate. A niche but foundational package gets fair recognition.
After scoring, all weights are normalized to sum to 100%.
Every dependency starts with 5 points, ensuring that even the smallest utility package receives meaningful representation. This reflects our belief that every open source contribution has value.
What it measures: How foundational is this package within YOUR project's dependency tree?
We count how many other packages in your tree directly depend on each package. A package like debug that's used by Express, Mocha, and 10 other packages in your tree is more critical to your project than a leaf dependency used by nothing else.
| In-tree dependents | Score |
|---|---|
| 0 (leaf package) | 5 |
| 1 package depends on it | 10 |
| 4 packages depend on it | 15 |
| 16+ packages depend on it | 25 (max) |
What it measures: How important is this package to the broader open source ecosystem?
We combine three signals:
Critical design choice: We use square root compression instead of linear scaling.
| Package | Downloads | Linear would give | Our algorithm gives |
|---|---|---|---|
| Mega-popular | 100M/week | 100x more | ~10x more |
| Moderately popular | 1M/week | 1x | 1x |
Without compression, a single mega-popular package could capture 70%+ of donations. With our approach, popular packages still receive more, but the distribution remains fair.
What it measures: Is this package well-built and actively maintained?
We use industry-standard metrics from npms.io:
| Factor | Max points | Why it matters |
|---|---|---|
| Code quality | 10 | Tests, documentation, best practices |
| Maintenance | 5 | Recent commits, issue response time |
| Popularity | 5 | Community trust signal |
What it measures: Is this package used in multiple versions across your dependency tree?
When different packages in your tree require different versions of the same dependency (e.g., lodash@4.17.21 and lodash@4.17.20), it indicates that package is deeply embedded in the ecosystem.
| Versions in tree | Bonus |
|---|---|
| 1 version | 0 |
| 2 versions | 3 |
| 3 versions | 6 |
| 4+ versions | 10 (max) |
Our scoring is designed so that no single factor can dominate:
| Factor | Max points | % of max possible |
|---|---|---|
| Base | 5 | 6% |
| Structural | 25 | 29% |
| Ecosystem | 25 | 29% |
| Quality | 20 | 24% |
| Version | 10 | 12% |
| Total | 85 | 100% |
For a typical JavaScript project with 150+ dependencies:
| Metric | Before (naive approach) | After (GiftOS algorithm) |
|---|---|---|
| Top package | ~45% | 8-12% |
| Top 5 packages | ~75% | 30-40% |
| Bottom 100 packages | ~5% | 25-35% |
We believe fair funding for open source requires both intelligent defaults and user control. Users can always:
See the calculated weights for each dependency
Learn why each package received its score
Manually modify weights before confirming donation
See how our fair distribution algorithm works with your project's dependencies.
Try It Yourself