Dodgy EDIDs (was: What does your OS look like?)

[Kazinsal]

You've got this backwards. When the admin sees the OS's "The monitor attached to head #2 on node #123 is a worthless pile of puss that should be replaced" message, chances are they'll replace the crusty old monitor with something that's 10 times better and the user won't even know why (but will be grateful).

I want to know where you're planning on having deployments where the IT department has the budget approval to just spend money on monitors because the OS they're using says they should.

[Brendan]

Hi,

For about 99.99% of displays that have ever existed, and 99.999% of the displays that are still actually in use, I will have the best information. For the remainder, it'd be close enough that the user probably won't even notice anyway.

If you want to continue whining; how about having a big "4+ page" whinge about my intention to not bother with ISA cards, 8-inch floppy disks, Itanium, and everything else that will be on my "never going to be supported" list that is all far more important than this?

If you're going to use that defense for not supporting old monitors, then rather than complain about ISA/floppy/Itanium, I'll just ask why it's not a good reason to avoid supporting old fixed-function graphics hardware that can just as easily be replaced with something "10 times better."

Because:

• You can still buy new hardware with fixed function graphics hardware that fits in with one of the OS's use cases (e.g. cheap little systems glued to the back of a monitor for the purpose of adding additional monitors to the LAN); and
• I can support it without breaking "zero config"; and
• It'll be easier to write native drivers for modern video cards after gaining experience from simpler fixed function video cards; and
• Fixed function graphics hardware is closer to how I think graphics hardware should designed than modern hardware is.

Note: My idea of "ideal" graphics hardware is video mode setting, "page flip on vertical sync" support, "scatter/gather" bus mastering to transfer data to/from the device, and nothing else; with completely separate/unrelated (and optional) "GPGPU" devices for things like physics, processing accountancy data, doing "photo quality" rendering for the printer driver, audio/signal processing, etc.

You've got this backwards. When the admin sees the OS's "The monitor attached to head #2 on node #123 is a worthless pile of puss that should be replaced" message, chances are they'll replace the crusty old monitor with something that's 10 times better and the user won't even know why (but will be grateful).

I want to know where you're planning on having deployments where the IT department has the budget approval to just spend money on monitors because the OS they're using says they should.

It's a distributed OS; and therefore doesn't really make sense unless you've got 3+ computers, high speed networking and enough load to justify the cost of 3+ computers and high speed networking. The main focus is businesses, where it can slash TCO (half as many computers with 2+ users per computer, near zero admin/maintenance costs, etc), and where a decent monitor costs a fraction of one employee's weekly wage.

Note that (for the purpose of "near zero admin/maintenance costs") the OS will have the ability to analyse and monitor hardware and suggest upgrades. Things like "the network connection between A and B is becoming a bottleneck and should be upgraded" and "the third hard drive in node #123 has reached it's MTBF", and "node #55 has been struggling and needs more RAM". This will be built into a maintenance utility that also says things like "the mouse on station #88 is due for scheduling cleaning" and "node #77 is due for preventative maintenance (e.g. blow the dust out of it)". Advising that a monitor should be replaced (for whatever reason, which can be "works perfectly but its native resolution is too low") is just an extension of this.

Of course there will also be smaller scale systems - e.g. a family that has a main computer in a study area, a media computer in the lounge, 3 laptops and wifi, and where the "admin" will probably be one of the parents; or maybe someone like me (who occasionally uses ~$10000 of equipment just to play one computer game by themselves, with client on one computer and server on another), where "owner = admin = user", and where the single largest reason for not buying another monitor is "running out of physical space in computer room".


Cheers,

Brendan

[Schol-R-LEA]

It's a distributed OS; and therefore doesn't really make sense unless you've got 3+ computers, high speed networking and enough load to justify the cost of 3+ computers and high speed networking. The main focus is businesses, where it can slash TCO (half as many computers with 2+ users per computer, near zero admin/maintenance costs, etc), and where a decent monitor costs a fraction of one employee's weekly wage.

If IT purchasing decisions were made on anywhere near that rational a basis, that would make sense. Real-world experience, as testified in dozens of sites such as The Daily WTF (articles generally SFW, but the forum is another matter) and Not Always Working, says that this is not usually the case. Most corporate IT is run on a shoestring by managers who seem to consult tea leaves, dice, and Magic 8 Balls to decide whether to replace a given piece of hardware, and when. I've worked for companies that had MS-DOS and Windows 7 systems running side by side, companies that would rather throw customers away than fix their software products, companies whose salespeople promise the impossible (as in, would require a violation of causality to work) to their corporate customers and then fire employees who don't deliver it, companies where the CEO utters phrases like "We will test no software before it ships!" with a straight face (yes, that was one I submitted personally), and still remain in business long enough to refute the idea that private enterprise is inherently efficient and sustainable - or would, if it weren't for the fact that the IT management at government and NPO offices are invariably even worse.

[Tyler]

I love that when Brendan goes out his way to support 99.9999% of cases (for example ensuring the Physical Memory Map is thorough and correct on all computers) he is derided for supporting too much (Just use GRUB it wouks in 90% of cases, that's good enough), and when his very well thought out requirements (which probably compare to 0 requirements defined for the people arguings own operating systems) mean only supporting 99.999% of cases (though, still supporting the user with well planned hardware support databases and messages where GRUB just doesn't know it's messed up) suddenly he's not supporting enough.

I know the OSDev community isn't a single amorphous blob with a shared opinion, but I never see the other group come out of the woodwork to defend him, when he isn't facing criticism, but shrill whines that he isn't doing the same thing as the Operating Systems people already know and doesn't he know that by ignoring his well thought out requirements that he can be the same as Linux?

EDIT: "arguins -> arguings"

[Brendan]

Hi,

If IT purchasing decisions were made on anywhere near that rational a basis, that would make sense. Real-world experience, as testified in dozens of sites such as The Daily WTF (articles generally SFW, but the forum is another matter) and Not Always Working, says that this is not usually the case. Most corporate IT is run on a shoestring by managers who seem to consult tea leaves, dice, and Magic 8 Balls to decide whether to replace a given piece of hardware, and when.

What can we (as OS designers) do to solve/prevent the problem of "relatively random" purchasing decisions?

If a (distributed) OS was monitoring everything; and described exactly where the bottlenecks are, which pieces are nearing the end of their useful life, which pieces are responsible for "below average" user experience/productivity, etc; do you think the "relatively random" purchasing decisions could become much less random and much more effective?

Here we get power failures about 5 times per year. They typically last 15 minutes to an hour. About 5 years ago I bought a UPS - not a huge thing, but enough to keep my server running for about 45 minutes (and enough to keep the server up for the majority of power failures). More importantly, it's able to tell Linux to shut the server down properly when the battery is getting low and prevent file system corruption caused by unexpected power loss. It worked fine for years. I mostly forgot about it. Sadly rechargeable batteries never last forever.

The UPS itself has full self-tests, etc. An OS could've run the self-tests periodically (once per month?) and could've let me know that the UPS battery wasn't holding enough charge anymore. It could've also auto-adjusted the UPS's setting to compensate for battery condition (so the UPS still tells the computer to shut down soon enough, and still prevents file system corruption caused by unexpected power loss). Can you guess how much of this Linux does?

For the last power failure, the power went out and the UPS kicked in like normal. About 10 minutes later the server started shutting down. About 1 minute after that the UPS killed power to the server while the server was frantically pounding disks in the middle of its shut down.


Cheers,

Brendan

[Combuster]

I never see the other group come out of the woodwork to defend him, when he isn't facing criticism, but shrill whines that he isn't doing the same thing as the Operating Systems people already know and doesn't he know that by ignoring his well thought out requirements that he can be the same as Linux?

I know better than to disturb people actively practising their religion. I do regret the amount of arguments being made on the "I am right and you are wrong" basis, because that leads to very frustrated discussions.

[Brendan]

Hi,

I love that when Brendan goes out his way to support 99.9999% of cases (for example ensuring the Physical Memory Map is thorough and correct on all computers) he is derided for supporting too much (Just use GRUB it wouks in 90% of cases, that's good enough), and when his very well thought out requirements (which probably compare to 0 requirements defined for the people arguings own operating systems) mean only supporting 99.999% of cases (though, still supporting the user with well planned hardware support databases and messages where GRUB just doesn't know it's messed up) suddenly he's not supporting enough.

When people agree, there's not really much they can say.

When people disagree, it's actually a valuable service, as it helps me check that I haven't overlooked a horrible design flaw or something else I'm going to regret later. I do appreciate this; but (unfortunately) rarely say so even though I should.

When people repeatedly raise the same points, let's just say there's "diminishing returns"...


Cheers,

Brendan

[Tyler]

Hi,

I love that when Brendan goes out his way to support 99.9999% of cases (for example ensuring the Physical Memory Map is thorough and correct on all computers) he is derided for supporting too much (Just use GRUB it wouks in 90% of cases, that's good enough), and when his very well thought out requirements (which probably compare to 0 requirements defined for the people arguings own operating systems) mean only supporting 99.999% of cases (though, still supporting the user with well planned hardware support databases and messages where GRUB just doesn't know it's messed up) suddenly he's not supporting enough.

When people agree, there's not really much they can say.

When people disagree, it's actually a valuable service, as it helps me check that I haven't overlooked a horrible design flaw or something else I'm going to regret later. I do appreciate this; but (unfortunately) rarely say so even though I should.

When people repeatedly raise the same points, let's just say there's "diminishing returns"...


Cheers,

Brendan

Oh I know the value, I've learned more from your attempts to educate rdos than from any book. Just letting you know we are here I guess.

[Schol-R-LEA]

What can we (as OS designers) do to solve/prevent the problem of "relatively random" purchasing decisions?

If a (distributed) OS was monitoring everything; and described exactly where the bottlenecks are, which pieces are nearing the end of their useful life, which pieces are responsible for "below average" user experience/productivity, etc; do you think the "relatively random" purchasing decisions could become much less random and much more effective?

In some cases, it might. The problem is, in many cases, the people responsible for making such decisions have no technical background, and may be more concerned about the cost of new equipment than the cost of paying an expert to keep the older hardware running (no matter how much more that would end up costing), might make a 'brilliant deal' for the new hardware that ends up dropping a expensive pile of trash in the admins lap with no choice but to use it, might decide that they know more than the admins do, might get distracted by a passing flock of butterflies and forget to order the new hardware, etc.

All I am saying is, I agree that it would be a significant improvement, but human behavior being what it is, I know how easily that improvement could be negated by folly.

I can understand why you don't want to support a load of trash; much of what makes Windows the huge turd it is comes from trying to cover millions of edge cases, bad interactions, and odd requirements of specific customers. By rights (and good design principles), this shouldn't affect installations that don't use those facilities, but it does, to everyone's loss. The problem is, customers can be unreasonable. Very unreasonable. If you don't give them what they want, they will find someone who does, no matter how much they lose out from being so unreasonable. You can say that "well, I am better off without unreasonable customers", and perhaps you'd be right, but if you multiply that by the number of unreasonable customers you have, you will lose most of your business - and since your installed base is so small, no one else will want what you are offering, either, no matter how much better it might be.

The situation for open source in this instance is slightly better, but not much; if you don't support the users' idiocies, they will just fork the codebase and do it themselves, or else find someone who will. It trades having the edge cases causing less impact on the main codebase for loss of control over the user experience, while still getting blamed when those forks fail (and they will try to pin the blame on you, even - or especially - when the main codebase is rock solid).

I honestly have much the same view as you in this matter, but in my case my primary goal is research - while I am designing my OS as if it will catch on, I have no illusions about the chances of anyone other than me using it, and my main hope for improving things in the real world is that I might learn something new that others can build upon. All I am saying is that you need to go into this with your eyes open about the reality of how hard what you are trying to accomplish really is.

Technical superiority is the least important part of success in the software field; companies like IBM, Microsoft, and Oracle became what they are because they have marketing departments that can sell garbage to other companies even when superior options exist, and that fact isn't going to change any time soon. Without efforts like yours, the field can't advance, but in most cases, it advances not because of a superior product, but because an established product co-opts some part of the technically superior product's improvements, which is why - despite constant surface changes - real improvements in user experience and software quality are usually painfully slow to emerge, and the field goes backwards as often as it does forwards.

Every once in a while something truly revolutionary comes along - microprocessors, GUIs, mobile devices that are actually usable - which upsets the apple cart, but even then the disruption is often temporary as these corporate behemoths usually have some department inside them that is agile enough to adjust to the new situation. Even when their inanities eventually catch up with them, as happened to IBM in the 1990s, there's almost always some other company of the same mold ready to replace them.

TL;DR: go ahead and do what you think is best - since you are probably right - but don't be surprised when someone less right steals your thunder by being better at conning people than at making software

[onlyonemac]

The UPS itself has full self-tests, etc. An OS could've run the self-tests periodically (once per month?) and could've let me know that the UPS battery wasn't holding enough charge anymore. It could've also auto-adjusted the UPS's setting to compensate for battery condition (so the UPS still tells the computer to shut down soon enough, and still prevents file system corruption caused by unexpected power loss). Can you guess how much of this Linux does?

For the last power failure, the power went out and the UPS kicked in like normal. About 10 minutes later the server started shutting down. About 1 minute after that the UPS killed power to the server while the server was frantically pounding disks in the middle of its shut down.

Actually that's the UPS's fault. Linux shouldn't need to compensate for the UPS's age; the UPS should be able to say "this is how much longer you can keep running for if you keep drawing that amount of power". So that's completely the UPS's fault for telling Linux that there was enough power to keep running for 10 minutes when in fact there wasn't.

[Brendan]

Hi,

What can we (as OS designers) do to solve/prevent the problem of "relatively random" purchasing decisions?

If a (distributed) OS was monitoring everything; and described exactly where the bottlenecks are, which pieces are nearing the end of their useful life, which pieces are responsible for "below average" user experience/productivity, etc; do you think the "relatively random" purchasing decisions could become much less random and much more effective?

In some cases, it might. The problem is, in many cases, the people responsible for making such decisions have no technical background, and may be more concerned about the cost of new equipment than the cost of paying an expert to keep the older hardware running (no matter how much more that would end up costing), might make a 'brilliant deal' for the new hardware that ends up dropping a expensive pile of trash in the admins lap with no choice but to use it, might decide that they know more than the admins do, might get distracted by a passing flock of butterflies and forget to order the new hardware, etc.

Companies that are that bad tend to go bankrupt before it matters.

All I am saying is, I agree that it would be a significant improvement, but human behavior being what it is, I know how easily that improvement could be negated by folly.

When I've finished writing my OS I'll start working on other problems; like changing company practices, solving world hunger, and fixing global warming.

Note: I'm not sure these problems aren't unrelated.

I can understand why you don't want to support a load of trash; much of what makes Windows the huge turd it is comes from trying to cover millions of edge cases, bad interactions, and odd requirements of specific customers. By rights (and good design principles), this shouldn't affect installations that don't use those facilities, but it does, to everyone's loss. The problem is, customers can be unreasonable. Very unreasonable. If you don't give them what they want, they will find someone who does, no matter how much they lose out from being so unreasonable. You can say that "well, I am better off without unreasonable customers", and perhaps you'd be right, but if you multiply that by the number of unreasonable customers you have, you will lose most of your business - and since your installed base is so small, no one else will want what you are offering, either, no matter how much better it might be.

In reality, it's probably going to be many orders of magnitude worse than you imagine (at least initially). The OS can't support hardware if there's no drivers, and thousands of drivers don't just magically appear overnight. The simple solution may be to sell "hardware+software" as a single package (even if that means getting a trademark and creating "BCOS machines" in my back shed) while encouraging others to create "BCOS clones" (by combing parts from an "officially supported hardware" list); and do that for 10+ years until there's enough drivers to consider supporting generic PC systems.

I honestly have much the same view as you in this matter, but in my case my primary goal is research - while I am designing my OS as if it will catch on, I have no illusions about the chances of anyone other than me using it, and my main hope for improving things is in the real world is by learning something new that others can build upon. All I am saying is that you need to go into this with your eyes open about the reality of how hard what you are trying to accomplish really is.

"The tragedy of this life is not failure, but low aim"


Cheers,

Brendan

[Schol-R-LEA]

Meh, I did it again - I was still making changes to my post when you replied. Sorry 'bout that, chief.

Yes, you have a point there. I'll admit that I do have larger ambitions than what I said, but I've been in this field long enough to see that technical prowess often gets trumped by carpetbaggers with a smooth line of patter. Many truly brilliant ideas never see the light of day, because the people who came up with them (I'm looking at you, Ted Nelson) thought that just having a better idea was enough.

I know Ted personally, and I'll tell you this: he's even worse at follow-through than I am, and I am epically bad at it. Must be an ADHD thing, since we both have it and his is far worse than mine - the real goal of Xanadu, hypertext, etc. was to come up with a mental prosthesis that could help him cope with his crippling inability to stay on point about anything. The result was that his projects all meandered into oblivion while his best ideas were stolen, imperfectly copied, dumbed down to the point of being almost unrecognizable, and then sold to the masses in a way that negated most of their purposes.

People like Doug Engelbart don't fare much better - while some of his ideas did eventually catch on, it took over twenty years for the mouse to gain real acceptance, and that was just one of hundreds of things he invented in the 1960s, most of which still languish, forgotten despite a crying need for them. The same can be said for Alan Kay, Jef Raskin, Alexia Massalin, and dozens of others who invented a better mousetrap only to see someone else succeed by selling a shoddy knock off of it.

I guess I'm just bitter.

[onlyonemac]

The biggest joke here is that you're talking like there's any commercial value in your OS - and a very large commercial value at that. Either that or you're so good at talking "in character" that I've completely missed it.

[Brendan]

Hi,

The biggest joke here is that you're talking like there's any commercial value in your OS - and a very large commercial value at that. Either that or you're so good at talking "in character" that I've completely missed it.

There is no doubt at all that there's commercial value in my OS.

There is plenty of doubt that I can actually implement it, and get it working reliably on enough hardware with enough applications; but this has nothing at all to do with the commercial value of the finished product (and everything to do with whether or not I'll be able to deliver a finished product).

There's also something else that's harder to explain...

Imagine if I invented an efficient hover-car, and knew everyone would want one, but wasn't happy with just providing hover-cars. What if I wanted to force people to accept something they don't necessarily want, like pink cars? I could say "all hover cars must be pink or else" and refuse to sell any hover cars that are any other colour (and use patents to force other manufacturers to do the same). This would reduce the commercial value of my hover cars, but if the commercial value is enough to sustain that, then I would be able to force people to accept pink cars for no reason other than "I felt like it".

What if (hypothetically) I wasn't happy just providing an OS that's far superior to Windows/Linux (for its intended purpose); but also wanted to force people to abandon the entire existing world wide web and adopt something radically different where advertising in all its forms is banned outright and content providers are sustained via. a system of micro-payments? Not because I need to, but simply because I want to. Just think of the repercussions - Google would "love" it!

The question is; is the OS's commercial value high enough to force people into accepting something like this? For this specific (hypothetical) case, I'd expect that the answer is "No, attempting to force people to accept that would diminish the commercial value beyond the breaking point".

The next question is obvious: how much could I force on people and still get away with it?

Could I force all software to use device independence? Probably yes. Could I force people to abandon all existing programming languages? Maybe if my IDE/tools are good enough I might be able to. Can I force everything to use standardised open file formats too? Now it's starting to get a little scary...

There is plenty of doubt that I can actually implement it. If I can implement it, there is no doubt at all that there's commercial value; but then there's also a risk that I will take things too far and ruin its chance of success anyway.


Cheers,

Brendan

[Schol-R-LEA]

There is no doubt at all that there's commercial value in my OS.

I'll be honest, I'm not sure that there is commercial value (at least under any of the current sales or service models) for any software. All of the current models of funding (or not funding, in the case of many FOSS projects) software development are fundamentally unstable and broken, but I can't come up with a better one.

As I said elsewhere (warning, some of the replies in the thread have less than family-friendly language):

There are basically five (HEAHD) models of software compensation or lack there of (open-source, bespoke, bundled, off-the-shelf, and subscription), none of which really work.

Of them, the most lucrative - and ironically, least effective - models are the two-headed monster that is bundled and off-the-shelf, mainly because they give the ordinary consumer the comforting illusion that software is just a commodity like tissue paper or ice cream bars. Indeed, with bundling, most PC users are unaware that they are paying for their software at all, and most don't really grasp the difference between hardware and software - a dangerous, but highly profitable illusion fostered by the likes of Dell and Microsoft. The reason it is broken is because it means that you have to shell out for 'upgrades' again and again, to no one's benefit but the owners of the software companies, and not even them in the long run since it is an unstable model, which only remains working because of customers' ignorance and lack of alternatives.

Open-source is nearly as bad, economically, since there isn't any real profit to be had in it - that is, after all, the whole point. A model that depends on ego satisfaction and public standing replacing greed is only going to work if the developers have another source of income that doesn't interfere with their ability to work on the software. While it is a 'gift economy', as ESR puts it, the problem is that gift economics only work when the gifters are financially secure in other ways - the classic examples of gift economies all worked because the labor for basic necessities was done as an obligation to the feudal lord, leaving the upper echelons free to focus on 'what can I do for you' rather than 'what do I need to do for myself'. Gift economies are inherently parasitic on physical economies based on unpaid labor by individuals other than those involved in the gifting activity.

Bespoke development fails because most software is generic; truly specialized development is rare, and most 'custom' work is either a derivative of some existing open-source system where the incentive to improve it voluntarily is lacking, as an alternative to a proprietary system whose owners cannot or will not provide the needed functionality for the customer, or - and this is the most common reason - because the company wants something done in-house, for no better reason than because they can. While there is a fair amount of work done in bespoke software, the majority of it is redundant - it literally shouldn't be done in the first place, because there are existing options which are almost always better.

Finally, the subscription model is probably the one which will work in the long run, but it too is flawed - it really only is suited to very small applications where the majority of users are willing to pay a nominal fee, and where the user base is broad (there are thousands if not millions of users) but shallow (that is, most users are casual users and not dependent on the software for any real needs). It works very well with mobile apps and casual gaming, but not at all for larger mission-critical projects.

Unfortunately, there really aren't any new economic models of software development on the horizon, so we are all stuck with a broken system for the foreseeable future. Fnord.

Regarding the funding of FOSS through support contracts, I added:

I deliberately downplayed that aspect of it, even though it could, in principle, be a source of financial security for the OSS industry. Why? Because for every open-source project with a significant paid support service, there are tens of thousands that don't. Of course, that's partially due to Sturgeon's Law at work on an exposed base of works - probably only one OSS project in a thousand gets past setting up a repo on GitHub or Sourceforge, never mind releasing a product, and while it does not reflect on the overall value of open-source software, it does make it clear that there is a lot more ambition than actual time and motivation.

But I digress. The question was, why didn't I factor in support? Because an OSS project has to already be stable and growing in use for the support base to be viable as an income source, and it has to have either a very large user base (e.g., Canonical, Cygnus when it was a separate company) or a steep pricing structure (e.g., Red Hat, Oracle's OSS projects) to make it possible to support further development, and even when it does, only a handful of core developers are sustained. The majority of OSS development is always done by the end users, whether they are a hobbyist working on GIMP or a corporate DBA running MongoDB over a Beowulf cluster. Again, that is part of the point of open source - 'with enough eyes all bugs are shallow', etc., but it is also a weakness of it - without a critical mass, no OSS project can succeed, even if it is desperately needed by some clients.

As for whether I believe all software goes to an end-user, no, not in the sense you mean. Most OSS is tool oriented - the 'end users' are themselves OSS developers, or work as developers on bespoke software which applies an OSS tool. HOWEVER, the market for any given development tool is small and self-limiting, and more importantly, few development tools are of such scale as to be able to have a viable paid support structure, unless they are part of a larger toolchain. Indeed, binutils and the related GNU tools are virtually unique in this, mainly because Red Hat covers so many different tools that they can generate a broad base.

Customer training is probably a more viable a model of payment than support, realistically speaking, but only Red Hat and ORA have made serious efforts in that direction to the best of my knowledge. I suspect that a bias against non-technical users is at work there. However, even that can only generate enough revenue for a small core team, if that.

In any case, the biggest need is for ways to support the developers in the critical months before a large enough user base have developed. They almost invariably need to work a regular paid job elsewhere first, slowing development down, or else need to turn to vulture capital, which isn't really compatible with the OSS philosophy. Kickstarter and similar crowdfunding sites are one option, but convincing enough supporters that there is a real need for your particular software to reach your funding goal is nearly impossible.

Note that I am not denigrating OSS itself; I would be thrilled to see a viable funding strategy be developed for it. I am myself struggling to get a significant OSS project5 off the ground myself (or rather, at this stage, a subsidiary project3 needed to complete the main one), but I am far from getting even a critical mass of co-developers so far, never mind finding users who will want it when it is released. I just don't see any of those which have been tried to date being really viable for more than a handful of operations.

I repeat what I have said already: I am not critiquing OSS itself, but the pragmatics about how it is funded and operated. Ideally, it should be possible for all projects necessary for a healthy software ecosystem to have a wide enough volunteer base that the issue would never come up. That simply isn't the case, however, and most projects need at least one full-time developer and maintainer to be viable. Unless that developer is independently wealthy, they will need a source of income, and most of the time, the income models for OSS fall flat. As things are already, the majority of OSS 'funding' comes in sideways, via student grants and loans to graduate students who work on the projects as an adjunct to their thesis work, much as Linus did.

Until a new model of funding - or a way to avoid the need for it - is invented, OSS will always live in the shadow of proprietary software. I wish it were otherwise, but that's the truth.