Size of the user base

[TRS-80]

Many of these funding models sound like doing a lot of tangentially related work, as a full time job no less, just so you can do the actual work and give it away for free. In particular, this model is not appealing to kids that are inheriting this mean blue dot. Perhaps that is the biggest problem of them all.

Yes, it's a difficult and long standing problem.  I don't know the answers, but I certainly realize the potential importance of this to future development and sustainability of the entire ecosystem.  Hence my interest in the topic.

Maybe your fresh ideas can finally bring sustainability along with freedom and privacy?  Wouldn't that be nice!? 

I'm skeptical based on what you said, however.

I guess I can see that, coming from point of view of trying to appeal / "sell" to the masses.  Personally I have given up on them.  I only care about the (relatively smaller) group of users (/hackers) comprising the F/LOSS community.  For a multitude of reasons.

This is precisely why commercial efforts choose Electron, easy short term gains.

Well that's the idea behind it, and Java for cross platform, and on and on...  However native apps still always out perform, it seems like (even though hardware gets faster all the time).

As a thought experiment, and you'll have to set the ideology aside for this one, consider what would happen if the license didn't explicitly allow this, and instead focused on a potentially more important aspect: portability and privacy of the data that the software generates and interacts with. I imagine "Indie/Handmade/Free" software starting out with such guarantees over all others. It is possible that we are on a trajectory where freedom to modify the source code is less relevant than the freedom to own, move, and delete the data. Surely once we reach singularity (any day now, perhaps this century), code will transition to the realm of machines and personal data will remain personal. Perhaps we already passed the inflection point where data matters more than the computation and have failed to adjust.

Well, you replied to me about making copies, which is one of the 4 freedoms.  Then later you talk about modifying the source code which is a different one of the 4 freedoms.  So let's take each in turn.

In case of source code availability/modification (actually 2 separate freedoms), I guess I would say that how do we really know what's in there if we can't see the source code?  You would have to trust the author.

Even if the end user does not understand the source code, it is assumed that others do and it's intended as a sort of collaborative effort.

I think a lot of these ideas have been hashed out quite a lot already; I am not saying rms is perfect, but he is a smart guy and thought this all through pretty thoroughly.  In fact he has pages and pages of writings about it if you care to read them.  And the more the decades go on and the more things I see, I just think more and more that he was right all along, and foresaw quite a lot of our current societal problems around tech.

Now, if we are talking about not allowing making copies, then we are talking about something that is no longer considered Free Software by most definitions I am aware of.  Now, maybe this is the solution (at least to some of the problems you correctly identify in this thread)?

However from Free Software perspective, it is about freedom and control.  We want to have control of our software (and hardware, to the exent possible).  And it turns out, in order to have that control, you must have all 4 of the essential freedoms that rms identified.

Also, from a practical standpoint, you then could not release any software you have built on top of anything which is licensed as Free Software.  In fact the Free Software licenses are designed explicitly in that way, in order to protect the entire ecosystem (unlike "Open Source").

You'd be surprised how difficult of a task that is using modern technology. Concretely, your direct dependencies have dependencies of their own, and those indirect dependencies have dependencies, etc. Meanwhile, I still type things into a tty terminal and have to decipher a puke of text when something goes wrong. That is, essentially, still the state of the art for Software Development.

In other words, it's important to have empathy towards the shear amount of will and work that it takes to ship software.

I know you were replying to swiley here, but for my part I do have empathy.  I well realize how complex it can be.  Personally I very much aspire to learn more about Debian packaging, but just haven't had the time.

Anyway, it was from a point of empathy that I suggested further up thread that this is the packagers / distributions job, traditionally speaking.  For all the reasons you mentioned and more.