How GiftOS Distributes
Donations Fairly
A multi-factor balanced algorithm that ensures every maintainer receives a fair share based on their true contribution to your project
The Problem
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.
Our Solution
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 |
Key Innovations
Structural Analysis
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.
Square Root Compression
A package with 100M downloads doesn't get 100x the weight of one with 1M downloads—it gets ~10x. This prevents runaway concentration.
Balanced Scoring
No single factor exceeds 29% influence. A mega-popular but low-quality package won't dominate. A niche but foundational package gets fair recognition.
The Formula
Weight = Base + Structural + Ecosystem + Quality + Version
After scoring, all weights are normalized to sum to 100%.
1. Base Score (5 points)
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.
2. Structural Score (0-25 points)
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) |
3. Ecosystem Score (0-25 points)
What it measures: How important is this package to the broader open source ecosystem?
We combine three signals:
- Weekly downloads (30% weight): Usage across all npm projects
- Dependent packages (40% weight): How many npm packages depend on this
- GitHub stars (30% weight): Community recognition and endorsement
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.
4. Quality Score (0-20 points)
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 |
5. Version Bonus (0-10 points)
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) |
Why These Coefficients?
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% |
Results
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% |
Worked Example: 100 EUR Donation
Let's walk through how a 100 EUR donation distributes across five packages from a real-world dependency tree.
Step 1: Input Values
Each package has different characteristics — structural importance, popularity, quality, and version spread:
| Package | In-tree deps | Downloads/wk | Dependents | Stars | Quality | Maintenance | Versions |
|---|---|---|---|---|---|---|---|
| express | 12 | 30M | 50K | 60K | 0.9 | 0.85 | 1 |
| debug | 8 | 200M | 100K | 10K | 0.7 | 0.6 | 2 |
| lodash | 3 | 50M | 150K | 55K | 0.95 | 0.4 | 3 |
| ms | 0 | 150M | 80K | 3K | 0.5 | 0.3 | 1 |
| my-util | 0 | 500 | 2 | 5 | 0.2 | 0.1 | 1 |
Step 2: Score Each Factor
The algorithm calculates each factor independently using the formulas described above. Here are the intermediate scores:
| Package | Base | Structural | Ecosystem | Quality | Version | Raw Total |
|---|---|---|---|---|---|---|
| express | 5.00 | 22.32 | 10.02 | 17.75 | 0.00 | 55.09 |
| debug | 5.00 | 19.14 | 12.16 | 13.50 | 4.00 | 53.80 |
| lodash | 5.00 | 13.66 | 12.69 | 16.25 | 8.00 | 55.60 |
| ms | 5.00 | 5.00 | 11.15 | 9.00 | 0.00 | 30.15 |
| my-util | 5.00 | 5.00 | 0.06 | 3.50 | 0.00 | 13.56 |
Step 3: Normalize & Distribute
Raw scores are normalized to percentages using the largest remainder method, ensuring the total is always exactly 100.00%:
| Package | Weight | EUR Amount |
|---|---|---|
| express | 26.46% | 26.46 EUR |
| debug | 25.84% | 25.84 EUR |
| lodash | 26.71% | 26.71 EUR |
| ms | 14.48% | 14.48 EUR |
| my-util | 6.51% | 6.51 EUR |
| Total | 100.00% | 100.00 EUR |
Notice: even my-util (500 downloads, 5 stars) still receives 6.51 EUR — the base score ensures every dependency gets meaningful recognition. Meanwhile, the top package only captures 26.71% — not the 70%+ it would get with naive download-based distribution.
Transparency & Control
We believe fair funding for open source requires both intelligent defaults and user control. Users can always:
View
See the calculated weights for each dependency
Understand
Learn why each package received its score
Adjust
Manually modify weights before confirming donation
Anti-Gaming Protections
Our algorithm is designed to resist manipulation. Here's how each layer provides protection:
Square Root Compression
Inflating downloads or stars has diminishing returns. Going from 1M to 100M downloads only increases the score by ~10x, not 100x.
Your Tree, Your Weights
Structural analysis is based on YOUR dependency tree, not global metrics. Creating fake packages doesn't help unless your tree actually depends on them.
Multi-Factor Scoring
No single factor exceeds 29% influence. Gaming one dimension — like downloads — has limited impact on the overall weight.
Deterministic & Open
Same inputs always produce the same outputs. The scoring is transparent and verifiable — this page is the proof.
Ready to Try It?
See how our fair distribution algorithm works with your project's dependencies.
Try It Yourself