This still doesn't make UBI relevant to this discussion. It's already fairly trivial for a talented SWE to make UBI-level income working 10 hours a week by picking up software contracts here and there. Eng already have access to the levels of income that UBI would provide, with plenty of time left over to dedicate to open source, and yet this path is relatively untrodden.
Plenty of engineers (myself included) already leverage the flexibility and surplus pay of the industry to opt out of the "40 years of 40 hours" ratrace. But they do so to varying degrees, and evidently aren't spending enough of that surplus on OSS to fix the problem we're discussing.
I don't see what UBI would materially contribute to this dynamic.
If picking up software contracts here and there is consistent enough for you to count on then it's either already a full time job or the end result of years of networking and experience.
UBI would let people devoted to a subject pursue only that.
Sure, I'm not suggesting that it's as easy or as comprehensive as UBI, of which I'm a strong and longtime supporter.
I'm saying that the existence of this weaker alternative is illuminating: there's a non-trivial subset of the population for whom this is an option, including many OSS maintainers, and they don't seem especially jazzed about the idea of making an income that's 10% of what their skills could bring in.
Personally speaking I wouldn't see that as an alternative. Just doing a little above-the-table consulting work comes with periodic obligations. Why make a fraction of your income to still deal with the distractions?
I think you could just ask retired people who volunteer about the subject and get a good take on it.
> It's already fairly trivial for a talented SWE to make UBI-level income working 10 hours a week by picking up software contracts here and there.
What about less talented ones that can still contribute, but need to work 20 hours a week? Or 30 hours a week? Or gasp 40 hours a week?
> Eng already have access to the levels of income that UBI would provide, with plenty of time left over
No. There isn't plenty of time left over. Moreover, why wouldn't I want to work on something full time, and not in my "left over time"?
> Plenty of engineers
Which means: not even the majority of engineers.
> I don't see what UBI would materially contribute to this dynamic.
"I don't see how giving all engineers, and not some percent of engineers, the option to pursue projects they like would materially contribute to this dynamic".
This is a textbook Gish gallop, so I'll avoid the trap of responding point-by-point and address all the irrelevance and inaccuracy of your comment simultaneously.
The premise I responded to was that UBI was the only way to free up OSS maintainers, and that they wouldn't care about the lost hundreds of thousands of income if their basic needs were met. My point was that if this was the case, you would already see the low-hours-per-week strategy in place as a non-trivial factor in OSS funding. And yet you don't, because the foundational assumption is incorrect.
Also note that 10 hours a week is hyper-conservative. The population of people maintaining OSS projects are more than capable of pulling eg $70/hr for contracts[1], especially at the low volumes we're talking about. To reach UBI levels of income at this rate would require _1.5 hrs/wk_ of work, or 6 hrs per MONTH. This allows you to drop the required talent level pretty low, despite already pulling from a population that's selected for "ability to maintain a useful OSS project".
[1] also very conservative: I wouldn't be surprised if a median estimate came closer to $150/hr for your average OSS maintainer
> This is a textbook Gish gallop, so I'll avoid the trap of responding point-by-point
And this is textbook avoiding an answer
> My point was that if this was the case, you would already see the low-hours-per-week strategy in place as a non-trivial factor in OSS funding.
Yes, and your point is based on the flawed premise that there are many engineers who can do that.
> The population of people maintaining OSS projects are more than capable of pulling eg $70/hr for contracts[1], especially at the low volumes we're talking about.
And you pulled this estimation out of which crevice?
> To reach UBI levels of income at this rate would require _1.5 hrs/wk_ of work, or 6 hrs per MONTH.
Ah yes. Because there are plenty of jobs which will gladly pay you for 6 hours of work a month.
I'm not sure if we have misaligned expectations of how much income a reasonable UBI is likely to provide, or of how much income you can make contracting.
The range of incomes I've seen from UBI proposals range from 10-20k/yr, with the high end generally applying to people with 2+ children. This is partially constrained by political reality, but politics aren't the only thing putting an implicit ceiling on the amount of UBI (as a reductio ad absurdum, consider why we wouldn't just give everyone $500k a year and all just retire onto our yachts).
Taking the midpoint, $15k pa means $1250/month, which means you'd need to make _$30/hr_ on software contracts to match UBI. You don't think it's plausible to fill the pipe with a 10-hr week of contracts over $30? Bear in mind that this means you'd need 3 hours a week or _12 hours a month_ with a more realistic (yet still quite conservative) income estimate of $100/hr, and that the type of person who's currently maintaining an OSS project is already increasing the quality of the talent/income potential distribution.
Sure it's _plausible_. I even used to think that kind of thing was _possible_, long ago.
But I've come to the conclusion since that it's virtually impossible to "scale down" your income like that. And that you can't actually choose to accept lower pay to obtain more options (in software anyway), contrary to highly plausible economic theories.
Do you have any real world evidence other than that it sounds plausible?
I don't think I currently do, but that's sort of my point: people don't want to do this, for reasons ranging from the income left on the table to the type of work not being fulfilling.
Note that both of these are handled by the premise, which was that OSS maintainers would be materially unblocked to focus on OSS by a UBI-level income. This assumes that there are a non-trivial amount of OSS maintainers that don't care about the couple hundred thousand dollars they're forgoing, and that they have at least 30 hours of their week filled with fulfilling work.
Tangentially, I match the motivations you're asking about, but not the exact implementation. I spent the early half of my 20s with a far higher income than I wanted, and definitely didn't (and don't) enjoy working 40 hours a week. Given how motivated I am by intellectual challenge, I came to the realization that it was damnably hard to find a job that would give me a suitable intellectual challenge but not require me to be full-time. I "solved" this by interleaving 2-3 years of working with 1-2 years of travel/personal development a couple of times during my 20s.
That’s probably how most people do that. I have to admit that programming less than full-time was hard for me, because I tended to go flat out. And then burn out, LOL.
Only if you're incapable of making basic inferences and uncomfortable with thinking about distributions and error bars instead of forcing everything into artificial certainty.
If, like many people, you need things shoved into an imaginary concrete, low-dimensional, binary box: "the type of person maintaining an OSS project can trivially make >$30/hr[1] on 10 hrs of contract work a week". If you still think this is too subjective to infer anything from, enjoy your onanistic "nobody can ever really know anything maaaan" perspective, but it's not really relevant to this conversation.
[1] See another comment of mine in this thread for back-of-the-envelope math
Plenty of engineers (myself included) already leverage the flexibility and surplus pay of the industry to opt out of the "40 years of 40 hours" ratrace. But they do so to varying degrees, and evidently aren't spending enough of that surplus on OSS to fix the problem we're discussing.
I don't see what UBI would materially contribute to this dynamic.