[HN Gopher] I algorithmically donated $5000 to Open Source
___________________________________________________________________
I algorithmically donated $5000 to Open Source
Author : lorey
Score : 348 points
Date : 2024-12-03 22:45 UTC (5 days ago)
(HTM) web link (kvinogradov.com)
(TXT) w3m dump (kvinogradov.com)
| lorey wrote:
| Had to modify the title slightly to pass validation. Also "How [I
| algo...]" got removed, did not know that happens automatically.
| asicsp wrote:
| You can edit the title after submission (the automatic change
| won't trigger).
| mrbluecoat wrote:
| Great post! I wish all companies would recognize their dependency
| on open source and compensate accordingly.
| 38 wrote:
| 5000 is not that much anymore, especially in the US. would have
| been better to split into $1000 chunks instead of $200
| loloquwowndueo wrote:
| I know at least one of the maintainers in the list, I know they
| live in the US and their project is something they maintain as
| a hobby with no expectation of retribution, and I know they are
| probably ecstatic to receive a small grant.
| mikelward wrote:
| Yeah, it's not much. But the publicity and the methodology and
| the possibility of others doing the same is more impactful than
| just the financial resources the author had.
| kvinogradov wrote:
| Thanks. That's a start experiment - I am going to donate more
| using this approach in the future and hope that other people
| will join me in this non-profit initiative.
|
| While any particular donation I made to OSS maintainers is
| small, it seems important that the recipients get more
| attention and maybe will be less likely to burn out in the
| future. For instance, some of them (btw, from Nebraska!) did
| not receive anything for 18 years of contributing to OSS
| before last week: https://www.linkedin.com/feed/update/urn:li
| :activity:7269812...?
| Wilduck wrote:
| I think this is a really interesting model for providing funding
| to open source software. There's something about the "Index Fund"
| approach that is really appealing. I also think it's interesting
| that the author was both balancing "value" and "risk". I do
| wonder, if this became a more dominant strategy for providing
| funding for open source how you would deal with a couple
| potentially adverse incentives:
|
| 1. Publishing the exact formula for funding is great for
| transparency, but then leads to an incentive to game the system
| to capture funding. Doing things like breaking your project up
| into many small packages, or reducing the number of maintainers
| are not good for the ecosystem but may lead to more funding.
| Also, there starts to be an incentive to juice download numbers.
|
| 2. In general, rewarding "risk" with additional funding seems
| like it creates an adverse incentive. This seems like a really
| tricky problem, because lack of funding is a major source of
| risk. It seems like there could be a pendulum effect here if
| you're not careful. Is there a way to structure the funding so it
| encourages long term "de-risking"?
| 3abiton wrote:
| But the issue is, whatever the criterias are, they will become
| the main kpis opensource projects (at least the not-so-driven
| ones) will target for growth. Goodhart's law.
| Wilduck wrote:
| I think Goodhart's law only applies if you have fixed,
| published criteria for funding. That's why I mentioned
| transparency explicitly. I wonder if you could avoid some of
| the worst of Goodhart's law by saying something like "the
| formula changes every year, and we will publish it only after
| 5 years, but the goal is to reward value provided, and de-
| risk the ecosystem". The idea being you're explicitly trying
| to incentivize broadly valuable work rather than specific
| metrics.
|
| It's a bit like the SEO dance. Publishing the exact formula
| makes it much easier to game SEO, so instead search engines
| say stuff like "we're trying to gauge the overall quality of
| the site, we use metrics like [...] but not exclusively,
| focus on making good, responsive, accessible content above
| all else". Obviously it doesn't work perfectly and the more
| money there is, the more incentive to game the system, but it
| seems better than the alternative of publishing the exact
| ranking algorithm.
| leoc wrote:
| I think that might be the best strategy: a charity playing
| Google and being transparent about what money it
| distributes to whom, but being less transparent about the
| exact mechanism it uses to calculate the disbursement, or
| at least being ready to make arbitrary future changes at
| its discretion to the mechanism to counter gaming (as well
| as outright zapping clear offenders _ad hoc_ ). One nice
| thing about this strategy is that it could generate a
| virtuous circle: consolidate together a big enough pot of
| money from early adopters and you could start getting some
| good media coverage, which in turn might generate interest
| and donations from "normie" sources which would never have
| wanted to be in before then. Similarly and relatedly, IME
| one of the excuses for low Open Source donations from big
| US companies is "we have to monitor and audit where all
| donated money goes, and that's too much overhead".
| Centralise that work in a big, fairly well-trusted charity
| to which multiple other organisations can donate and that
| excuse is hopefully removed or partly removed. It has long
| annoyed me that the Open Source Initiative never (AFAIK)
| tried to take on this role, despite having been (at one
| time, at least) the most obvious candidate for the role.
|
| Of course, the big hazard here is "who watches the
| watchmen?" But public scrutiny plus the fact that others
| can jump in and try to take some of the same middleman role
| might help to keep that risk partly under control.
| pessimizer wrote:
| > Publishing the exact formula for funding is great for
| transparency, but then leads to an incentive to game the system
| to capture funding.
|
| I say think of it as an authorization protocol, and watch how
| people break it in order to figure out how to fix it.
| ants_everywhere wrote:
| > There's something about the "Index Fund" approach that is
| really appealing
|
| This is an approach I'm actively working on, although I haven't
| actively donated anywhere yet.
| bajabaq wrote:
| This is cool: good, reasonable methodology (I like the value x
| risk idea).
|
| Two requests: 1) could you easily add the projects to the CSV
| file (maybe one column left of the user: "projectA;projectB;...")
| 2) could you share the code (understanding that it's rough and
| lots of hand-curation)
|
| I've long given to EFF, FSF, and other projects sporadically, but
| this method seems excellent and expandable and customizable,
| maybe something like: 1) identify the packages on your machine
| (or used by your team) 2) score them 3 donate based on score
| dmacedo wrote:
| I believe this is a better approach for scale.
|
| Make it a local or company-wide identification of FOSS
| packages, and a way for those individuals, teams, and
| businesses to score them by importance or criticality (or needs
| of the FOSS project if they are aware).
| kvinogradov wrote:
| Thanks!
|
| 1) Yes. My plan is to continue iterating on this approach and
| publish more data later, including projects and some other
| inputs (PyPI, etc.)
|
| 2) Maybe. I prefer the full transparency and have planned to
| publish the code too, but some comments suggest that it might
| not be ideal. Need to think more about this.
| tlocke wrote:
| I was 18th on the list, thanks for the donation!
|
| There's also the approach to funding that looks at things from
| another angle, and says we should have a basic income, or
| negative income tax, for everyone.
| freen wrote:
| If a sufficiently large number of participants, with sufficient
| resources participate, then any open source project with
| sufficient utilization and value will receive funding.
|
| Lots of "sufficients" in there, of course.
| iandanforth wrote:
| I love the idea! Anyone here from MS/Github who could integrate
| this into Github sponsors? That way you could "Donate to Open
| Source" and see the allocation distribution without having to do
| all this work.
| bradley13 wrote:
| As soon as money is in play, greedy people will start gaming the
| system. The anonymous guy in Nebraska won't have a chance, even
| if he is interested.
|
| tl;dr: well intentioned, but it isn't gonna work.
| kassner wrote:
| Specially when GitHub gatekeeps users from accepting
| sponsorships, even if you have stuff published for over a
| decade.
| leoc wrote:
| It's a great idea; I have some similar thoughts. The looming
| problem, though, is that Goodheart's Law is likely to strike if
| this ever gets scaled up significantly.
| cbeach wrote:
| In case anyone else was wondering:
|
| Goodhart's law is an adage often stated as, "When a measure
| becomes a target, it ceases to be a good measure"
|
| https://en.wikipedia.org/wiki/Goodhart's_law
| leoc wrote:
| In concrete terms, what you would or will see, if enough
| money starts going down this track, is open-source
| contributors changing their behaviour as they seek to make
| projects "donation-optimised" and to maximise their personal
| share of donations, and likely also "donation-bait" projects
| which exist simply to game the system. But even though all
| this could get quite bad, it's still quite likely to be less
| bad than the status quo. EDIT: If you're thinking of making
| such a contribution yourself I don't think the downsides
| should deter you yet, at least unless you're lucky enough to
| have control of a truly large bag.
| TiredGuy wrote:
| On that note, the article states that it donates more to
| higher risk projects, and risk increases by OpenSSF score.
| One question I had about the article is does that mean that
| projects with more security vulns get a higher donation? If
| so, then that might become a perverse incentive to leave
| security gaps in your code.
| airstrike wrote:
| I think you can solve that by funding the dependencies you rely
| on and have them fund their dependencies and so on...
|
| A related project I recently found out about is
| https://www.drips.network/ The more I think about it, the more
| I like it.
|
| In fact, TFA says
|
| _> But how should one decide which users to sponsor and how
| much to donate to each one? It requires data on their
| importance, and I used PyPI to roughly estimate it for Python
| packages._
|
| It's better to have one of the slabs in the XKCD comic fund the
| ones immediately below it than to have users look at the whole
| thing from the outside and try to arbitrarily allocate
| importance via some metric like PyPI downloads, GitHub stars
| and whatnot
| leoc wrote:
| It's a good start, but it's vulnerable to sticky fingers,
| patronage relationships and so on if the money becomes
| serious. For example, what if a project writes internal code
| instead of having a dependency on someone else's library? Do
| they get to keep the money which would have gone to an
| external contributor, creating an incentive to pull
| everything in-house? Or do they still have to push the same
| amount of money upstream? That creates the opposite
| incentive, a bag of free money which can be directed to
| third-party libraries which purely by coincidence happen to
| be staffed by members of the downstream project and/or their
| pals.
|
| But as I said elsewhere, I'm not using this to dismiss the
| idea or assert that it can't improve things overall. The
| status quo seems to be pretty bad, so an alternative
| certainly doesn't have to be flawless to be better overall.
| swatcoder wrote:
| Worse (and very unfortunately), any kind of unmonitored/low-
| attention payment scheme that starts funneling meaningful money
| to countless small libraries turns those libraries into revenue
| streams whose ownership can be valued and sold.
|
| And when that happens, you'll quickly start to see professional
| schemers and hustlers coming in to buy them, the most
| aggressive of whom will start surreptitiously converting some
| of those projects into things like data siphons or bot shells,
| may relicense and restructure them for further monetization or
| to set up targeted lawsuits, etc
|
| It creates a whole new and dangerous incentive scheme, not
| unlike the one that's already corrupted the browser extension
| ecosystem.
|
| To avoid that from happening, people need to be actually paying
| attention to what they're paying for, when they're paying for
| it, so that they can make sure they're still getting what they
| expect. Automated/algorithmic schemes like this specifically
| avoid that.
|
| They're a great idea in theory, meant to address a real issue
| in what reward open source developers might see from popular
| work, but as you suggest, it opens a very wide and inviting
| door for trouble at scale.
| leoc wrote:
| I generally agree, though some of those specific risks
| already exist and some (like license changes) are if anything
| probably less likely if they mean giving up significant
| donation money.
| paxys wrote:
| My concern is that the value a project brings isn't always
| objectively measurable. You can try to approximate it, sure,
| using # of downloads and whatever else, but then those metrics
| can also be easily gamed if the incentives are large enough. For
| example if you applied this same logic to the npm ecosystem then
| the creator of is-odd would retire a billionaire.
|
| Regardless, donating something is always better than donating
| nothing, so kudos.
| kvinogradov wrote:
| Thanks. There is no ideal set of metrics for value, but some
| measurable ones correlate with it. The more reasonable inputs
| are accounted for, the harder it is to game the system.
|
| Regarding is-odd, it would unlikely receive a high score even
| with the current primitive version of my algorithm, as it
| already includes the package size among the "risk" set.
| IAmLiterallyAB wrote:
| One thing I want to try is looking at all the packages on a
| minimum install of a Linux distro. How many of those are just a
| dude?
| teddyh wrote:
| Title is cut off; it is missing "... via GitHub Sponsors and PyPI
| data ". My project, for instance, does not use GitHub, nor is it
| a Python library or even Python-only.
|
| I suspect that a better measurement might be based on what
| software people actually have installed, perhaps using the Debian
| Popcon data.
| mrtksn wrote:
| Ha, maybe there should be a tool that calculates your "bill"
| based on the OS stuff you are using and help you make a single
| payment that distributes it to the rightful owners. That bill
| thingy can be calculated as how much you actually used this stuff
| and how much donation they currently receive and then you pick
| how much you feel like paying thing month.
|
| Distribution can favor projects that need funding to be
| sustained. Maybe you are using niche library than only 20 other
| people are using it but you are getting great value out of it,
| then maybe it can be reasonable to be billed $100(or not a strict
| sum but high coefficient to make your donation go mostly to this
| particular library).
| kvinogradov wrote:
| There are some relevant tools for this, such as
| https://thanks.dev. While it doesn't work as a usage-based
| billing, at least it provides a way to fund all dependencies.
|
| However, the issue is that most organizations relying on OSS
| are not tech companies. They mainly have no clue about OSS
| sustainability (e.g., airports and hospitals) and are unlikely
| to ever fund their own software supply chains, unfortunately.
| That's why there should be a data-driven index to address the
| global OSS supply chain, not only any particular ones.
| hinkley wrote:
| I still think it's much more efficient to let your teams vote
| for 8 or 10 libraries, once or twice a year, send N dollars for
| every vote over <enough to make it worthwhile to track down
| donation information and cut a check> and carry over remainders
| from one vote to the next, so that everything below the cutoff
| gets some love every couple of intervals.
|
| A lot of people will vote for the obvious ones, a few people
| will vote for the underdogs and it'll come out in the wash.
|
| That also fights the common complaint here of people gaming the
| system by splitting up their libraries too much. Sindre, for
| instance, would get some money for p-limit, p-retry, and maybe
| p-queue, but not much else for his astounding menagerie of
| micro-libraries.
| treve wrote:
| One thing is a bit frustrating for me personally is that I
| have a few packages that get tons of downloads yet very
| little stars. This is because I solve a niche well. Im
| usually deep in the dependency tree, rarely as a direct
| dependency. I would definitely be ignored by this scheme.
| hinkley wrote:
| I don't know what the solution to that is. I think you'd
| still get a few votes. I think it's unlikely for library
| authors to pass some of their donations down to the
| libraries they depend on.
|
| Foundations should probably be doing some of this work.
| Maybe government as well. National Science Foundation did
| it for a bit, partly because of Al Gore, but that is also
| how we ended up with the current model of everything being
| free either until it isn't, or until you become the produce
| (advertising, user tracking).
| Wilsoniumite wrote:
| I feel like there is a big risk here, which others have already
| mentioned, but in fact this risk has already been realized w.r.t
| npm packages.https://news.ycombinator.com/item?id=41178258
| kvinogradov wrote:
| While some mistakes are probably inevitable (like it happened
| with Tea protocol), sourcing a wide range of metrics from
| multiple sources, fixing bugs and building reasonable
| guardrails can prevent them from repeating.
|
| For instance, given that my algo-donating aims to support the
| global OSS supply chain (not to distribute any crypto tokens
| like Tea did), it could potentially even focus only only "old"
| repos. They carry higher maintenance-related risks, but it will
| take years to distort such target area for donations.
| lorenzleutgeb wrote:
| Comparing to index funds is neat. What Flattr.com offered was to
| set a monthly budget and then not allocate according to an index
| but according to your preferences (value per flatter = monthly
| budget divided by number of flatters).
|
| Flattr is no more. But I could see that work out for open source
| projects: Allocate a fixed monetary amount per unit of time you
| want to donate. Record "intent to donate" during that period.
| This could be done via a browser extension or a CLI. At the end
| of one period, distribute.
| joshdavham wrote:
| I think someone should also donate to the person who created that
| open source meme.
| kvinogradov wrote:
| It does not seem that Randall Munroe (xkcd) accepts public
| donations, but he recently released his own book, which can be
| bought at https://xkcd.com/what-if. I've just ordered.
| kibwen wrote:
| _> Value increases with # total downloads and LTM downloads on
| PyPI._
|
| While I applaud the OP for the initiative, if this ever takes off
| it will cause people to exploit the system in the following ways:
|
| 1. Hammer the package registries with fake downloads, which will
| increase the financial burden on the registries both in terms of
| increased resource usage and in employing countermeasures to stop
| bad actors.
|
| 2. People spamming the repositories of popular packages with PRs
| that just so happen to add a dependency on their own personal
| package, so that they can pick up transitive downloads. This
| increases the burden on package authors who will need to spend
| time rejecting all of these.
|
| So this approach carries the risk of possibly making things even
| worse for OSS maintainers.
|
| If a metric can be gamed, and there is a financial incentive to
| game it, it will be gamed. I coin this the "this is why we can't
| have nice things" law.
| tempodox wrote:
| Exactly, and Goodhart's law drives the nails in the coffin.
|
| https://en.wikipedia.org/wiki/Goodhart%27s_law
| ddulaney wrote:
| The mechanism is kinda like the Spotify fake songs case:
| https://www.justice.gov/usao-sdny/pr/north-carolina-musician...
|
| In the same way, there was a fixed pot of money available split
| up by popularity, so making thousands of songs and streaming
| them as much as possible with bot accounts is profitable, even
| though each bot account cost a few dollars per month.
|
| Here, the bots you use to juice your numbers don't even need a
| subscription fee!
| reaperman wrote:
| Which is why spotify should pay a percentage of MY
| subscription fee to only the artists that I listen to. My
| money shouldn't go to Taylor Swift if I don't listen to
| Taylor Swift.
|
| That would eliminate direct financial payment from botting.
| But botting could still affect trending or "related"
| recommendations for indirect financial boost.
| suzumer wrote:
| The issue there is that the listens from people who listen
| to less music would be worth more than the listens from
| people who listen to more music.
| imtringued wrote:
| That's not an issue. That's the entire point. You track
| listens per account and if you're only listening to a
| single niche musician, all your money (not someone
| else's) goes to that musician.
|
| The real mystery is why it should work any differently,
| because the cross subsidy seemingly creates a perverse
| profit incentive for bots to scalp off some of that cross
| subsidy. The economics are broken. This is socialism for
| the rich and popular.
| knutzui wrote:
| A fixed monthly subscription amount with unlimited usage
| will always carry this deficiency. A solution that
| addresses this would be usage-based pricing.
| imtringued wrote:
| I find that court case very off putting, since it was Spotify
| that stole the royalties, because the same mechanic applies
| to simply being popular. When will someone sue Taylor Swift
| for stealing royalties?
|
| Also, since they didn't change the economics, they have done
| nothing to prevent this from happening again. Any economist
| that sees that he can earn $12 from a $11 payment would keep
| doing this until the risk adjusted return is equal to the
| interest rate. Ironically this will remain profitable until
| the cross subsidy is gone. I.e. there is an incentive to use
| the bots to boost real musicians who lose out from not being
| the recipient of the cross subsidy.
| TuringTest wrote:
| _> While I applaud the OP for the initiative, if this ever
| takes off it will cause people to exploit the system in the
| following ways_
|
| It's true that the metrics used in this story could lead to
| being exploited. But the value of the initiative is not in the
| specific method used to donate, but in the idea of finding
| worthy yet non-obvious projects to donate and in leading by
| example.
|
| If the initiative catches on, the community can find better,
| harder-to-exploit methods to find deserving targets, as for
| example it has happend with NGOs. This idea could create a
| healthy ecosystem that supports FLOSS software, just like the
| idea of a stock exchange supported the emergence of public
| traded corporations in the XVIII and XIX centuries.
| kiba wrote:
| If everyone use their own idiosyncratic algorithm for
| choosing OSS to donate to, it's going to be awfully hard to
| exploit.
| gleenn wrote:
| There are probably only so many obvious metrics from which
| to pick and you wouldn't have to game them all, just pick
| the easiest ones and keep grinding. Fraudsters are usually
| motivated and not that dumb.
| kvinogradov wrote:
| Exactly! The idea is to use available data for evaluating the
| value and risk of OSS and then allocate donations accordingly
| to the wide algo-based systemic index, not to a narrow set of
| manually picked projects (usually large or popular ones).
|
| The current algorithm is far from being perfect (it's an MVP)
| and will never be, but with more measurable inputs and after
| multiple iterations with the help of the community, it can
| lead to an analogue of "S&P500" for OSS, that's worth using
| for donating to reduce the risk of the global OSS supply
| chain we all rely on.
|
| As with publicly traded companies, having a decentralized set
| of private donors with skin in the game helps a lot to
| efficiently evolve the approach and make it harder to exploit
| in the future. And on the contrary, I would not trust an
| algorithm created and maintained by some state-owned or
| simply very large institution.
| lacker wrote:
| Even an index fund has some human-curated criteria for what
| to include, though, right? The S&P 500 isn't open to just
| anyone. So it seems totally legitimate to have it be not
| completely algorithmic.
|
| If there were an "Open 500" that was trying to be like the
| open equivalent to the S&P 500, I would happily donate to
| it. Right now I do GitHub sponsors but it feels kind of
| random.
|
| You just don't want to include projects like React or
| TypeScript that are operated by a for-profit company - they
| don't need our donations. You want it to be, this money is
| actually going to an organization that will invest it in
| software quality.
| bee_rider wrote:
| Rather than trying to donate to the most popular packages,
| people could try to donate to the packages they use, and then
| their dependencies (it would be nicer, though, if repos had a
| way for packages to list their dependencies and automatically
| propagate donations they received down--which would be a usable
| by the top level packages but, eh, you have to trust people at
| some point).
| Pooge wrote:
| Makes me think of the "cobra effect", like the Great Hanoi Rat
| Massacre.[1]
|
| Set arbitrary metrics like download count -> bad actors make
| bots to download their package -> they profit while the
| registry suffers from very heavy load.
|
| [1]: https://en.wikipedia.org/wiki/Great_Hanoi_Rat_Massacre
| sesm wrote:
| 2 is already happening, I have seen this multiple times.
| uncomplexity_ wrote:
| sweet sweet human nature.
| igor47 wrote:
| Does anyone know of a non profit that routes money directly to
| open source projects? I'm wondering what's the best way to
| support open source via 501c3 dollars
| jvanderbot wrote:
| I think someone should make an ETF that donates 1-2% of profits
| to the open source packages that the companies use. Tie profit
| directly to payback to the community.
|
| Undisclosed use would be a bad idea - your package could be
| receiving free funding!
| jillyboel wrote:
| Must be nice to have $5k to burn. Probably means you have too
| much money.
| Nimishg14 wrote:
| The guy is a GP at a VC so I think this spend goes from their
| marketing budget.
| kvinogradov wrote:
| This spending comes from my personal pocket and does not even
| create any tax relief. I just think that Open Source is
| important and want to efficiently support it.
| yu3zhou4 wrote:
| I tried to fix software funding - I think people can sell
| licenses to their software, we can introduce new licenses that
| allow free usage for individuals and nonprofits and charge the
| companies. I am the worst marketer/seller ever and failed with
| getting the publicity. I still think that's a worthwhile idea and
| have all the source code for this platform
| bruce511 wrote:
| >> we can introduce new licenses that allow free usage for
| individuals and nonprofits and charge the companies
|
| You definitely can use such a license for your project. That's
| trivial to do.
|
| However, of course, that would not be an OSS compatible
| license.
|
| I'm as big a fan of OSS as the next guy. I'm also a fan of
| eating. I sell my work (as source code) with a proprietary
| license. That's how I "solved" the problem, at least for me.
|
| Ideologically I'd love for it to be open source. But there's no
| sustainable way of capturing that value. So rather than not-do-
| it I chose to charge for it instead. (Shrug).
| hartator wrote:
| Great initiative!
|
| Yeah, doing open source is very unthankful even outside of that
| money consideration. I have a 5k+ star GitHub project for like 9
| years, 200-300 bug requests via GitHub/personal email, and maybe
| I got maybe 1 genuine thanks email without a request.
| kvinogradov wrote:
| Hey HN community, thanks a lot for your great feedback and
| actionable critique!
|
| It was a simple MVP for personal OSS donations, and I have many
| considerations on how to evolve it and especially to prevent it
| from becoming a victim of Goodhart's Law at scale. Some of them:
|
| 1) Value and Risk scores shall include more metrics:
| dependencies, known funding, time since the last dev activity,
| active contributors, etc. A wider set of connected but relatively
| independent metrics is harder to fake. Also, it will help to
| exclude edge cases -- for instance, I auto-donated to Pydantic
| (it's a great OSS), but such support is unlikely needed as they
| have raised $12.5M Series A from Sequoia this year.
|
| 2) Algorithmic does not mean automatic. While I see a strict,
| measurable, and ideally fully transparent methodology crucial for
| donating, it does not mean that all inputs shall be automatically
| generated. For instance, in the stock ETF world, one can
| generally rely on such metrics as "annual financials" for trading
| because they are annually audited (although it does not prevent
| fraud in 100% of cases). In the OSS world, data from trusted
| ecosystem actors can also be part of the equation.
|
| 3) Many guardrails are possible: limited budget per project,
| manual checks of top repos with the most anomalous changes in
| metrics. Also, if we target the sustainable maintenance of OSS
| the world relies on (I do!), then new projects (1-2 years) will
| unlikely get high scores - that adds another protection layer.
|
| Given the interest in this topic, I am going to continue
| developing this algorithm further and expand it to other
| ecosystems (e.g. JS/TS and Rust). Your feedback here is very
| valuable to me, and those who would like to help make the algo
| better or donate through it are invited to the newly created
| gist:
|
| https://gist.github.com/vinogradovkonst/27921217d25390f1bf5e...
| mudkipdev wrote:
| Great idea, I also think it'd be interesting to systematically
| donate to the projects with the lowest bus factor (or as that
| one XKCD describes it: "the project that a random person in
| Nebraska has been maintaining since 2005")
| kvinogradov wrote:
| Yes, that would be a very useful risk metric! Assuming access
| only to public APIs (GitHub, package managers, etc.), how
| would you define the bus factor in terms of data? I am
| thinking about # unique contributors over the last X years.
|
| It's funny that the experiment uncovered exactly such a case:
| a person from Nebraska got my donation as the first income
| from his open source contributions over the last 18 years and
| shared this on Linkedin:
|
| https://www.linkedin.com/feed/update/urn:li:activity:7269812.
| ..
| theendisney wrote:
| Building something for fun with others seems underrated outside
| software. I sometimes look with jelousy at pictures of amish barn
| raising. Who benefits is rather different tho.
| gauss233 wrote:
| Open-source maintainers are the base that holds the entire
| industry! It is such a nice noble and generous act, I honestly
| wouldn't dedicate my skills and time to work in something that is
| not going to help me to pay the bills. (pretty selfish, I know
| xD). it's great to have you guys around!
| NelsonMinar wrote:
| This reminds me of when Redhat went public in the late 90s and
| did a generous thing with the friends and family round for the
| IPO. They included every open source contributor they could find
| in the Redhat sources. Including me, a grad student at the time.
| I made a few thousand dollars flipping the stock which probably
| doubled my salary for the year. (My contribution was an early
| HTML mode for emacs.) It was a really nice gesture.
|
| Reddit did something similar last year in their IPO. I'd love to
| read an article on how people benefitted from it.
| kinderjaje wrote:
| I wanted to see if chatGPT will be able to understand the meaning
| of this comic, and i think it did.
|
| *Gpt message:*
|
| This comic humorously highlights a critical issue in the tech
| world: the dependency of massive modern digital infrastructure on
| small, often overlooked, and underfunded components maintained by
| individual contributors. The large stack in the illustration
| represents the complex and sprawling "modern digital
| infrastructure," while the tiny piece at the bottom, maintained
| by a "random person in Nebraska," symbolizes open-source software
| or obscure tools that are crucial for the functioning of this
| entire system.
|
| The key message is that large systems often rely on foundational
| work done by unsung heroes who may not receive the recognition,
| support, or resources they deserve, despite the critical nature
| of their contributions. This comic resonates particularly with
| the tech community, where dependencies on small open-source
| projects are common.
| kinderjaje wrote:
| By the way, a lot of money goes to open-source projects via
| donations in exchange for an SEO backlink. A lot of stuff going
| down there.
| LtWorf wrote:
| Oh what a coincidence. I wrote pypular
| (https://codeberg.org/ltworf/pypular) to artificially increase
| download counts on PyPI (talked about it at a MiniDebConf).
|
| I was claiming that there are important incentives to play this
| sort of games.
|
| Seems OP proved me right!
| xk3 wrote:
| Wow! I was surprised to see myself on the list. Sure enough, I
| see a donation and it will take 90 days to pay out the first
| time.
|
| Interesting project
___________________________________________________________________
(page generated 2024-12-08 23:01 UTC)