Developer Basic Income?

Reading the recent posts here, what about this “Developer Basic Income (DBI)” service:

  • open-source project author signs up for DBI
    • they can elect to enforce a consuming repository owner to pay $1/month (license terms), or have it optional (donation)
  • repository owners pay $1/month (or more at their own discretion) to DBI, this gives them access to the entire DBI portfolio (repos that mandate DBI payments)
  • each $1/month to DBI is split evenly between the maintainers of all open-source dependencies of that consumer, no popularity perks, to a max of the latest international poverty line amount (in 2015, it was $1.90/day) with surplus trickling into later distribution - if everyone is meeting the threshold, then the calculation is repeated in an additive manner
  • payees can elect to have their leadboard standing public, as well as their payout amount public - this offers virtue advertisement to corporations and individuals
  • payouts will be public for transparency - no ebegging if you are bringing in the moolah - for the people by the people - and provides public accountability, such as what we are meant to have in the treasury and in the public sector
  • this conceptually shifts open-source developers into public servants, and compensates them as such through the private sector

This allows activity perks to a limit to incentivise and reward the elite, which combined with the limit will in term help rise the tides of the long tail that would otherwise be left behind. The low threshold is because escaping the poverty line is a big deal, whereas say a $75k/year happiness salary is just another tesla a year for a silicon valley employee, so the lower the threshold the more people that can eat and not die and join in collaboration with the one tesla a year drivers.

To be determined/discussed:

  • Perhaps the github org/user of consuming repositories, should be paying $1/month for each unique maintainer across all their repos, or $1/user or $1/org-member
  • An alternative to the international poverty line amount would be using a developer’s localised international poverty amount - this would allow me finally to afford to live in my citizen country of Australia
  • Perhaps project authors can opt-out of receiving the income, such that salary earners can flow their would be DBI earnings onto someone whose absolute earnings are below their poverty line
  • The poverty line cap would work around most pareto issues, we could do the same for the NPM database, where we rank npm authors by their cumulative package install count then limit them by poverty line cap with honesty based opt-out.
  • repeats on the international poverty line with honesty based opt-outs, with optional license requirement, seems the best combo imho, as it maintains the spirit of the project, and only pays those better off once the worst off contributors are better

Formulas fleshed out here:

Benefits fleshed out here:

Remaining todos fleshed out here:

Please consider me shooting holes into your idea as friendly debugging.

  1. Wouldn’t the authors of popular projects avoid that platform because they can probably get their own fees/donations without the platform? The only projects that would benefit from such a platform would be the ones too unpopular to stand on their own.
  2. You’d need to handle the fraudulent practice of creating a bunch of tiny, mostly useless libraries in order to get extra slices of the economic pie.
  3. I think the threshold might be too low. Whatever the payout is, it should probably be an amount the expected audience (i.e. FOSS software devs) would appreciate. Since most FOSS devs are not poor people in the global south, giving them enough money to escape the international poverty line might feel like the platform doesn’t give them much.

No worries. The earlier the criticism, the smaller the compass errors during exploration.

Platform need not be mandated by their license, it can be independent from their own monetisation as just a shoutout in their README.

Yeah, I think just syncing with a package manager database would not be sufficient as that captures pings more than actual usage. The rankings should be done by analysing the dependencies within repos of payees.

The focus then should be increasing the size of a pie, to increase the slices we get. Each repetition of the international poverty line payouts increases the pie size, increasing the slice size.

Some economic calculations will need to happen here to find the right price - perhaps $10/org-member is better. There also needs to be a financial jeopardy and hardship escape hatches, as we don’t want someone living below their poverty line paying more than they receive in income.

As a nitpick, global south is fairly accurate, but not entirely. A little magic of raspberry pis, discarded phones, and learning equality can go a long way.

For payouts, I’m thinking the following profile information could establish who gets payed out on which payout repetition tier:

  • What is your country or countries of residence?
  • What is your estimated yearly income and holdings from all sources?

Then we make some calculations from that. I’ve thought of doing a slider from say financial jeopardy/hardship/emaciation/impoverishment to economic classes, but that just complicates things more so.

I wonder if there is datasets that universities, open-source researchers, and the research departments of say github and npm (aka microsoft) have on this that I could get access to and a grant to test the economics beforehand - such that I can tweak the exemptions and the subscription price to find something most viable.

It’s possible you missed this important piece of information, which is the correct analysis IMO:

For me, it’s V. important who these ‘others’ are though. What I mean is: ‘not all others are our enemies’. Personally, my preference is not to quibble with other small producers, colleagues, private citizens, nonprofts, governments and civic institutions sharing my work with each other either commercially or for kicks.

AS DHH puts it variously in his battle with Apple, (and I am paraphrasing here), it’s monopoly power at scale that is the most harmful phenomenon… no matter where you stand politically or ethically, everyone seems to agree that monopoly is the problem and so if you use a licensing regime that does nothing to constrain monopoly power, either by allowing large scale private ownership (proprietary), large corporate freeriding (permissive), or by allowing large corporate interference (copyleft) then that regime will be against everyone’s interests.

With regards to payouts, the point I was trying to make is that it sounds like that model would prioritize the poorer participants, which would imply that those better off would be OK with making less so that some stranger potentially makes more.

Given that it seems a similar dynamic has created the problem of lack of support for FOSS (i.e. the dynamic of not wanting to pay because the benefits of support are distributed across N users, but my personal benefit is only 1/N), I’m not sure this model would appeal to a lot of FOSS devs, who may want to get payed themselves, but aren’t necessarily looking for a charity to help a bunch of 3rd-world strangers.

That could be specially problematic due to the issue of equality of pay.
If I’m a middle-class american and I make a very popular JS framework, why should most of the income into the platform brought by my specific project then be redistributed to a bunch of little libraries made by brazilian devs that have nowhere near the same use as my JS framework?

I’m not particularly sure what the critique of DBI was…

Re the freeloader problem, that is conquered by leverage, by disincentivising freeloading and incentivising participation. This scales all the way from people, to communities, to companies, to philanthropy, to nations, to empires. Permissive licensing voids any leverage, unless done as part of a monopolisation strategy by a commercial entity. FLOSS has maintained leverage via GPL and confidential lawsuits, with hard disincentives via licensing. (Dis)incentives need not be purely business, but can also be social, major ones are the shared and viral conceptions of shame and virtue, which impact culture, be it national or community/company specific. This is where behavioural economics matches with economy, and into anthropology. It’s not to say money is not a superior motivator, but there are many motivators which superiority is varied.

Re the monopolisation problem. DBI challenges monopolies hold of wage slavery through passive income for public service, which is sovereignty over one’s labor capital.

Re DHH. I’ve had a private email correspondence with DHH last year, which at my own discretion I believe can be summarised by this paraphrase “companies monetise scarcity (even via artificial scarcity) to expand virtuous empires against enemies, open-source is a donation to the commons, stop expecting compensation, be stoic bruh”.

If the concern is about adoptability of such an initiative, can I get clear concerns that wouldn’t be overcome by marketing.

Payouts are ranked first by usage, thresholded by income, so there is still a meritocratic and performance reward to it.

Those with residues of capital are not at a crossroad of sustainability, many work on open-source as part of their salary, or as a donation of effort afforded to them by their salary, or as a larger effort to build a standard business model from. Linus, Feross, and Sindre, are those that I believe can be placed in this category. It’s what I advocated for, before I realised it doesn’t scale to everyone, only the fortunate.

This is not a complaint about good fortune, well done and respects to the fortunate, its just a concern about those of poor fortune - such as equal merit or contribution, but without compensating opportunity through things as simple as locality or language or prejudice or affliction or the luck of draw with the same decision success rate, that pushed them below the competitive threshold and out of the fortune stampede, which can quickly compound into homelessness or excommunication from support structures, neutralising and sinking the ships of their contribution investments, as the barriers of entry, let alone barriers for successful competition get further out of reach.

DBI is not intended to be mutually exclusive. It has no incentive against monopolising benefits that the fortunate benefit from. However, it can be yet another alternative. People can pay tithe to their community, while still financing monopolising forces through purchasing movies and food and donating to streamers out of necessity or compassion. Governments can still regulate monopolies, while acknowledging their role in national economic security. People can still have rich personal lives, in addition to their 9 to 5.

DBI would be a tool for those concerned with such monopolising forces, wealth inequality, and funding maintainers whose projects have been popular but risk being pushed out and below the threshold of fortune, for a variety of afflictions.

1 Like

I think the largest difficulty here is figuring out the weighting for the payout formula, which will be tricky without real data.

For the formula, I’ve come up with the following requirements:

  1. payers should be supporting maintainers of what they use, not maintainers of software they aren’t using, as otherwise the degrees of separation from payer perception of benefits is too large to survive enculturation
  2. maintainers must receive a payment when a payer signs up, even if insignificant, as can’t rely on pure altruism - maintainers must know, that once the the most needed from their payers stack are sustained, then they too will become increasingly financially sustained - that once the pie is big enough, and everyone is no longer hungry, the excess is divided equally — in terms of fitness philosophy, this is a stark contrast to the dominant strategy in business, which is feed the most successful kin to sustain the peasantry kin, versus allocate resources to the most needy first as breadth may also be better considering competitive extermination — aka the benefits of portfolio diversification in investment lingo — the introduction of this financial tool in alternative to the existing strategies will be good balance, which improves overall fitness of the market
  3. the degree of the payment received is based upon the necessity between the maintainers of the payer
  4. this means the whole stack becomes less fragile, as one maintainer that gives up, cripples the entire stack immediately which is more common among less popular/fortunate maintainers, and the more spread between maintainers, then the less rare fragility when one uber-popular maintainer gives up and abandons a plethora of projects, not to mention that more players at the table increase competitive innovation

Essentially accomplishing the slogan:

  • Make your stack anti-fragile, by compensating the maintainers most in need first.

Which resulted in this formula below, which ensures every maintainer of a payment gets a payment that is proportional to their comparative need amongst other maintainers of the payer’s stack - if all maintainers are are located in the same location with the same incomes, then it is an even split.

for each payment received, do
   get all unique maintainers of all projects used by the payer
   total_payment_necessity_quotient = 0
   for each maintainer, do
       maintainer_location_poverty_annual_income = average between the different maintainer residence locations
       maintainer_necessity_factor = (annual_income + holdings + maintainer_payments_so_far) / maintainer_location_poverty_annual_income
       maintainer_necessity_quotient = 1 / maintainer_necessity_factor
       total_payment_necessity_quotient += maintainer_necessity_quotient
   for maintainers, do
       maintainer_payment = payment / (total_payment_necessity_quotient / maintainer_necessity_quotient)
       maintainer_payments_so_far += maintainer_payment

for all maintainers, do
  pay maintainer their maintainer_payments_so_far

The trade-off in the above is that it assumes someone living below the poverty line in Australia, is equally deserving as someone living below the poverty line in India. Which means that less Indians are emancipated overall, as impoverished Australians cost more. However, prioritising demographics over afflictions is treacherous territory, even if common in some circles, and the moral acceptance of which one has been a debate for millennium. Perhaps we can let payers decide which algorithm they wish to use, perhaps previewing the distribution of the payment between maintainers as they complete the form - with an algorithm for local wealth inequality (above), and global wealth inequality (to be done) - however I think complexity can be skipped for now - especially as such equal treatment will emancipate those below the poverty line in India quicker - so the bigger the pie, the more natural global impoverishment addressed even with the local impoverishment focus - making the issue a nothingburger.

One of the nice aspects of this, is that the two models can really compliment each other and magnify each other. One can finance the most popular maintainers via the existing monetisations options we are all familiar with, while financing the economically fragile maintainers via DBI. There is no reason why someone earning a sponsorship via github sponsors can’t then put some of that into DBI, and why people can’t put their DBI earnings into github sponsors, and why maintainers and payers can’t advertise participation in both.

I don’t see much evidence of GPL disincentiving freeloading. I see lots of evidence of GPL encouraging it. You might want to explore these observations further?

Nothing challenges monopolies other than antitrust laws and similar regulation around anti-competitive practices AFAIK.

If you mean by ‘challenge’ that DBI provides an alternative means of working without any of the customary monopolistic tendencies of capitalism, all I can say to that is, we would have to wait and see because there is nothing obvious that would prevent the kind of interference of tax authorities and corporates that bedevil novel tech platforms like this… platform cooperativism and so forth are all run under the auspices of free market fundamentals which would need to be usurped before we experience large scale progress in human flourishing.

Wage slavery is still relevant to public service, if you agree with the interpretation of governance structures being the handmaiden of whatever economic system is customary. From a Marxian perspective government bureaucracy is ‘unproductive labor’ which is not strictly speaking sovereignty over one’s labor.

The concern about adoptability that wouldn’t be overcome by marketing would be the position of the platform within the current economic system, which to produce substantial results in terms of human and environmental welfare would have to wither away prior to systems like this having any significant influence.

If you market an exchange platform for developers under the current system you will be merely amplifying it’s capitalistic potential to future capitalists AFAICT.

Hmmm… it doesn’t seem to me that you have integrated @kemitchell excellent observation that the problem is not on the contribution side but on the benefit side?

If the locus of your attention is on getting the implementation details attractive, the above identified problem is unsolved,and the very elegant and succinct way it has been articulated previously has been ignored?

It seems the disagreement here is between subjective differences in what one values as a considerable solution, and perhaps the terminology around it, as forgive my lack of comprehension but I am unsure a complete and atomic overthrow of the capitalist system is a viable option, let alone the only one.

Do you have a list of implementable proposals that you are onboard with and why, such that I can put myself in your comparable shoes and see the path forward within your value system.

I do not understand the criticism of omission of benefit, as several examples of benefits and leverage for payer and maintainer have been provided. However, probably my fault at the scattered explanations of benefits so far. So let me try again!

Benefit to payer from traditional sponsorship:

  • payments to sustain the continued growth of the most popular projects in their stack, by funding the monopolisation of the most popular maintainers

  • advertising benefits

  • influence over roadmap via perks if the maintainer implements and offers them

  • exclusive access perks if the maintainer implements and offers them

  • necessity if the maintainer mandates it, which avoidance incurs the cost of competition

Benefit to payer from DBI:

  • payments to sustain the most fragile projects in the stack, due to risk of burnout from neglected maintainers suffering financial hardship

  • advertising benefits

  • influence over roadmap perks if the maintainer implements and offers them

  • exclusive access perks if the maintainer implements and offers them

  • necessity if the maintainer mandates it, which avoidance incurs the cost of competition

Benefit to maintainer from traditional sponsorship:

  • significant income if you have crossed the popularity threshold via significant time and marketing investments

  • bloody ocean competitive, economic incentive to eliminate competition as repetition and capitalisation of brand exposure increases payout

Benefit to maintainer from DBI:

  • significant income if you need it, proportional to how many payers you onboard and how your peers are doing based on necessity

  • collaborative instead of competitive, no economic incentive to eliminate competition, the more peers will bring more payers which brings a bigger pie which brings bigger slices

  • no need to waste time with artificial scarcity perks and popularity investments to try and break the threshold needed for sponsorship in order to not starve

Both payment models can work together and address different ends of the stack fragility and sustainability concerns.

1 Like

It seems the disagreement here is between subjective differences in what one values as a considerable solution…

I think my counterpoints are objective, not subjective simply because anyone can see the phenomena I have observed, e.g. GPL as an amplifying instrument for capital, not an inhibitor, success of European Union in punishing silicon valley monopolies etc. As is the point of @kemitchell that implementation details don’t matter, if you haven’t identified the problem you are trying to fix. None of these counterpoints requires an ‘atomic overthrow of the capitalist system’, they are merely counterpoints to your proposal. My point about the withering away of capital is a banal one… simply put… if the current system continues to fail us all in the way it does, I don’t see how a failing system can prevail without ideological support since nature has an unfailing tendency to overcome ideology.

The sorts of implementable proposals that I am onboard with are strong labour rights, shared ownership of resources and fair distribution. These can be achieved through democratic policy implementation. There may be others but I think these are the most salient to this thread?

I do not understand the criticism of omission of benefit, as several examples of benefits and leverage for payer and maintainer have been provided.

Okay, so the important point is that any system looking to fix a market failure like the freerider problem needs to have features that produce the desired results.

In the case of ‘Free’ and ‘Open’ licensing models, there are benefits accruing to people who are not obliged to contribute. This is only trivially addressed with copyleft because benefits mainly accrue from reuse, not from ability to tinker - simply put - most FOSS is simply run in an unmodified state… so to fix that licenses like GPL would have to bind Freedom 0 to a requirement to contribute in some other way… like paying to run the software.

The problem is of course this creates economic asymmetries just like proprietary software that FOSS was meant to fix… I think this is called a ‘double bind’ but a better systems archetype may be more accurate… maybe it’s a ‘fix that fails’ type of thing. Whatever it is… all we need to know is the freerider problem is the problem that needs fixing, not how people contribute (the implementation details) but how to stop freeriders without destroying the generally accepted principles of the free and open culture movement.

I understand DBI offers benefits for many roles, but can you explain in a nutshell how you believe DBI fixes the freerider problem of the commons, without creating just a weakly reformed capitalistic system destined to screw people and our planet over further downstream?

Thanks for your input.

Tammy, I believe your interests would be best served by creating a new topic dedicated to your interest in the free-rider phenomena, of which we can address the actuation of DBI and other initiatives over there.

I say this because how one conceptualises which parts of a phenomena are problematic or beneficial and what can be remedies or exacerbations of the phenomena, is subjective to their value system in how they consider the phenomena. We observe reality do things, then subjectively match those observations with our subjective understanding of the limited things we have experienced so far and our orientation as a subject within reality. For instance, Rand, Marx, Ostrom, Keynes, Hayek, Schaub have all spent considerable time (decades!!!) dedicated to coming to terms with the freerider phenomena, each with different ways to conceptualise it and drawing different conclusions, while accepting and being aware of different trade offs and policies — I’ve been studying and integrating the works of each of them. We can consolidate the ideological battle of our flags in dedicated topics for our ideals and concerns, instead of marching with a flag to each varied initiative. A dedicated battlefield of ideology helps us find the objective in the subjective ideals, as figuratively, the subjects remove themselves as the subject of the battle as their blood spills in the battlefield, leaving behind bodies devoid of subject, which the remaining subjects then themselves reconsider what was worth it. What is usually claimed as objective by a subject, is just an object of their subjective desires or understanding, which is as much to do with reality as a mirror is to a person. When people believe they are making a statement about reality, they typically are actually only making the statement about their own underlying foundation of what they personally opine and consider reality to be; the same applies as much for the listener as it does the speaker, and this post by myself is no exception. We can continue this in a dedicated thread, or a call.

DBI’s benefits and approach are incompatible with your ideology, fine, however I have not heard from you how it would fail at its goals (win-win for the fortunate to make their stacks less fragile by reducing the burnout/inundation of maintainers facing financial hardship, while complimenting and leveraging existing systems), not your goals (does DBI solve the freeloader problem? are the goals of DBI honourable enough? and so on). Whether DBI can achieve its goals be it technically or motivationally is what I hope this particular thread is for.

Personally, I share many of the interests and concerns that you’ve raised, and will be happy to discuss and debate such, and which initiatives can address what, inside dedicated topics to the specific ideals; just invite my opinion on what you want my commentary for.

One of the other nice things about DBI, is that maintainers would be able to and may be willing to put a portion of their own earnings, be it from DBI or traditional sponsorship back into DBI to support the stack that they them-self used and reduce the financial hardship within their own peers, offering a trickling viral effect outwards. As I can’t contribute to the commons effectively, if my own stack is fragile, nor efficiently if the potential of my own peers is inundated.

This I can see emerging in pledges on people’s own github sponsor pages, where they’ll put say 10% of their github sponsorship revenue into DBI, and DBI could even have an option where you can elect to forward a percentage of your own DBI revenue back into your stack.

This essentially makes it easy to be an “angel donator” to each other, via DBI automatically scaling out offerings of a repose escape to those inside calamity.

The main issue that I see with DBI is that it feels like charity, and I don’t see a lot of people contributing to a charity (specially one meant to feed programmers instead of helping animals or children), unless they can get something out of the charity (like some boon to their status).

I think if DBI were to get mainstream, it would only do so by mutating into some sort of adopt-a-programmer program, with a strong tone of condescension and paternalism from the well-to-do programmers financing the struggling ones.

With that said, DBI could definitely have a place covering certain needs that other methods might not cover so well; which is why I’m OK with the idea.

Thank you for that feedback.

DBI seems to cross the paths of two distinct motivations: selfish, less fragile stack; altruistic, help your neighbour. If the marketing lacks on one, it will alienate the concerns of one crowd for the amplification of the other. I think the best and largest approach will be to maintain mutual marketing of both motivations, selfish altruism, to ensure both crowds benefit each other rather than death by infighting.

1 Like

Thank you for your input, it’s beyond the scope of this thread but I feel energized enough to write out a general sense that empirical subjectivity must not overlap actual objectivity, otherwise you end up conflating two analytical subjects concepts as both resembling ‘reality’ in a rather idiosyncratic understanding of our current scientific paradigm of which, I am a zealous fan. If you want to call that ‘ideology’ then it would require a radical subversion of what ideology generally stands for, which is an intellectual framework in excess of the demand for efficient understanding of causes. So, whereas laws of thermodynamics are not ideological, ‘spiritual flames’ and metaphorical ‘battles’ and so on are on this reading.

All in all you comix epistemic, ontological and normative positions, pretty much to suit yourself in this comment I think. That’s fine in terms of therapeutics, but it doesn’t help move the discussion along analytically.

In passing, your go-to list of economists isn’t particularly balanced IMO, you have three far right economists and one center-right, I do not know where Ostrom’s political commitments lie but she is perhaps one of the more reliable economists on matters like this since she is ideologically the most austere. You have one political economist on the far left. Just saying.

I don’t feel obliged to start a new thread on the free rider problem because I have already limited my remarks here to how your proposal is a case of a collective choice problem, and thus the freerider concern is perhaps the most relevant issue in terms of designing a worthwhile policy intervention.

I don’t think the freerider phenomenon has been conceptualized differently by the people you listed. The freerider problem is a very tightly scoped concept and for the purposes of this forum, I think it’s fair to rely on @kemitchell pithy remarks about the really hard problem about benefits accruing to people other than the contributors.

This is a problem DBI also hasn’t addressed, and for that reason alone we ought to be skeptical of it’s value to us as developers I think.

Not all my comments are ideological, sometimes I admit I do stray into moral philosophy if pushed, but generally speaking I tend to self-censor as much as I can on ethical concerns simply because I don’t find ethical justifications for copyright convincing, and thus ethical justifications for abolishing copyright or reforming it through licensing initiatives or platform novelty are unconvincing too.

If you see me waving a flag, that flag will be pinned only on one of three regions of enquiry: empirical subjects (e.g. observations), real laws (e.g. resource distribution policies) and actual objects (e.g. a computer). My interest in ideology is limited to familiarizing myself with it’s many faces and am always delighted to substitute ideological arguments for scientific ones whenever the opportunity arises.

The next paragraph I find too florid to understand in the context of software licensing/payment solutions/collective-choice policies. The only thing I can tease out is I think your philosophical position is possibly something like solipsism, in that you seem to like the idea that objective study necessarily collapses into unitary human consciousness or something… which feels to me more like an affective predisposition to the sovereignty of the individual over abstract theories about broader material conditions. If so, the prerequisites for that are a right-wing libertarian type of politics that emphasizes individual emancipation over collective struggle. That’s a choice, not an inevitability.

I think DBI’s benefits and approach are incompatible with every software developers story, no matter what their politics are simply because I don’t see it’s goals as being tied to an identified problem.

I would be delighted if this scheme proves me wrong. In the meantime I don’t think I will be involving myself with it for the simple reason I can already get well paid easily for what I do either by getting hired by a well resourced company or by just playing around in a sandbox for kicks and pushing it to a repo to see if it flies any.

I think my goals are the same as your goals, but where we differ is I think, is what we think the problem is that is getting in the way of achieving our goals. DOn’t we want to work in a relaxed way and just get paid fairly for what we do? Isn’t this the goal? My understanding is you believe the problem is in the way developers get paid, and for me there is already a great way to do that, either get a job, or get lucky and ride a unicorn.

I agree with Kyle on this one. I believe the problem is not on the contribution side, i.e. how contributors get paid, but on the benefits side… which is the huge drain on developers creativity that software licensing has yet to fix… because neither proprietary rights systems nor commons rights systems and all the tweaks and variations and hybridity inbetween the implied license of Berne and the public domain so far have met my expectations on fairness.