Accessibility in Wayland

Posted Jul 8, 2024 1:27 UTC (Mon) by raven667 (subscriber, #5198)
In reply to: Accessibility in Wayland by atnot
Parent article: Rosenthal: X Window System At 40

This is a wonderful and succinct summary of a serious and touchy topic, but I'm getting the feeling like the tech in Chornobyl saying "5 Roentgens, not great, not terrible" with how much mostly working but unmaintained code underpins the modern Linux system, from X11 (aside from Xwayland) to AT-SPI to all the various libraries (like XZ) and toolkits, applications and integrations (like to Google and MS service APIs). This stuff isn't in the critical path for say SteamDeck or ChromeOS, and Redhat/IBM isn't dependent on desktop revenue, so there doesn't seem to be anyone with the kind of headcount necessary and the drive to pick up these components, as long as they keep working well enough with the level of volunteer support available. As you point out though volunteers aren't beholden to contract terms mandating a certain standard, like working a11y, so the standard answer is "patches welcome" which really does not go over well with people who need these frameworks to function for the computer to function at all and this isn't a hobby for them that they can volunteer in their leisure time, it's why we have laws about this kind of thing.

I think there is probably a story here about which parts are insufficiently maintained and a lot of work trying to figure out how to find the resources to keep them maintained, when random volunteerism isn't enough, people depend on it, but there isn't a clear commercial revenue stream to tap into, or the commercial players have excelled at making their costs external and captured the value difference for themselves.

Accessibility in Wayland

Posted Jul 8, 2024 4:07 UTC (Mon) by raven667 (subscriber, #5198) [Link]

replying to myself but after writing this floated across my vision
https://infosec.exchange/@kurtseifried/112748522867243886
which was claiming the beginning of an exponential growth curve of developer burnout in FOSS projects, from a security perspective in seeing firsthand how incident response is handled in various projects.

Accessibility in Wayland

Posted Jul 8, 2024 12:19 UTC (Mon) by pizza (subscriber, #46) [Link] (20 responses)

> or the commercial players have excelled at making their costs external and captured the value difference for themselves.

This has always been the primary driver in commercial uptake of F/OSS. Believing otherwise is highly naive.

Accessibility in Wayland

Posted Jul 8, 2024 19:27 UTC (Mon) by raven667 (subscriber, #5198) [Link] (19 responses)

I don't think I'm being naive about this, its just that some commercial vendors FOSS ambitions involve maintenance and improvements on existing software to make it a useful product, eg. Valve, SteamDeck and the WINE ecosystem, or Dosbox, SCUMMVM, etc where people are selling games but need the infrastructure to work well enough they don't get support calls about it, or Linux and the Linux Foundation itself which pools efforts from many vendors who provide salaried full-time developers. I think that's different than say XZ where the maintenance is low enough that one developer can kinda/sorta do it in their spare time but there are many, many vendors who depend on it and they are all looking away and saying "not me" unless they have a drive-by patch or something, which still takes effort to review. That's taking advantage of peoples desire to be responsible and valued to avoid the long-term maintenance that doesn't directly impact their bottom line and can be ignored ... for a while, the overall system design depends on people performing heroics to keep the wheels on rather than properly accounting for cost and coming up with a mechanism to pay for it (vendor consortium like LF or taxes or whatever).

Accessibility in Wayland

Posted Jul 8, 2024 20:43 UTC (Mon) by atnot (subscriber, #124910) [Link] (18 responses)

I wasn't going to say anything because it's kind of off-topic and the statement is mostly true for the majority of companies that do read-only foss anyway. Yeah, externalizing costs is not really the whole story and doesn't explain why some corporations also contribute significantly. The other, much less talked about piece of the puzzle is that it's a way to destroy your competitors markets.

For example, if you are in the business of offering support for some server software, say a database, it may be in your interest to ensure that nobody else is making any money off of the operating system. Or if you are a games publishing platform who's lost a lot of ground to a handheld, you may want to make sure that the software components to make a competing handheld are freely available for anyone to use. Especially if the main platform your games are mostly run on is owned by another competitor. Or if you are, say, the #3 cloud provider, you may want to destroy your competitors chance to outclass you on container orchestration by releasing a free one that is so ubiquitous and capable that the market is absolutely swarming with "cloud" offerings. Or if you are the #2 GPU vendor, you may want to absolutely destroy the market for shader middlewares, APIs, Drivers, etc. You get the point.

I should say, I don't greatly mourn the loss of any of these, as a certified not-a-fan of markets as a way of organizing society. However if this was physical goods, this would be considered anticompetitive and wildly illegal in a lot of jurisdictions[1] and it has no doubt played a significant part in how monopolistic the tech industry is today. But when you're ostensibly or actually contributing something as ethereal as code to a public good, that's a lot harder to rule against.

[1] yes, I know, the US is not one of them, at least since the Chicago school ruined antitrust. but that's a different discussion.

How is destroying competitors' markets by selling at or above your marginal cost of production illegal in some jurisdictions?

Posted Jul 8, 2024 20:57 UTC (Mon) by farnz (subscriber, #17727) [Link] (11 responses)

I'd be interested to know which jurisdictions would consider it illegal to destroy a competitor's market with products sold at marginal cost or above. For physical goods, it's generally considered anti-competitive to sell goods below their marginal cost of production, but not to sell them for less than your competitors do, and the marginal cost of production of software is effectively zero.

How is destroying competitors' markets by selling at or above your marginal cost of production illegal in some jurisdictions?

Posted Jul 9, 2024 13:46 UTC (Tue) by paulj (subscriber, #341) [Link] (10 responses)

Hmm, the marginal cost of software may /tend/ _towards_ zero, but it is not zero, and will never reach zero either. In particular, it is far from zero at lower numbers of units shipped. Assuming a model where you amortise the costs over actual units shipped so far, or even a more subjective "number we reasonably could hope to ship in the next year or two" - not over some arbitrary number of "hope to ship in total in the future over the long-term life of the product".

So, in particular at the early "Destroy our competitor!" stage, the marginal cost may be _huge_ - in that kind of model.

Marginal cost of software

Posted Jul 9, 2024 14:07 UTC (Tue) by farnz (subscriber, #17727) [Link] (9 responses)

What you're describing is not the marginal cost of production, but rather the total cost of production. The marginal cost is derived by assuming that your first customer pays all of your total costs to produce their order; given that you've now paid off your up-front costs, how much does it cost you to fill a new order?

And software is weird because total cost of production is high (a lot of up-front design work), but the marginal cost of production is so close to zero as to be effectively negligible - since the marginal cost of production of a new copy is the cost of copying that software over the Internet, where the Linux source code is under 1¢ marginal cost (since that's what the cost of one more copy out of AWS S3 would be, if you stored the kernel source tarball in S3), and probably cheaper elsewhere.

Contrast that to (say) a carrot, where the marginal cost of growing one more carrot is not insignificant. You need to plant the seed, use slightly more fertilizer, pay the costs of having the harvesting machinery + people run for one extra carrot's worth of time etc. The total cost of producing a carrot would also include the cost of the field, the cost of ploughing that field and otherwise preparing it for planting, and anything else that you have to do to have a field of carrots; the marginal cost is the cost of adding one more carrot to that field.

Marginal cost of software

Posted Jul 9, 2024 14:58 UTC (Tue) by paulj (subscriber, #341) [Link] (8 responses)

Ah, sorry, yes... have my cost models mixed up. In my comment, seems I'm thinking more of an ongoing average cost model.

That said, even in the marginal cost model, there are still substantial costs in the earlier units. Cause almost universally earlier software units are shipped with substantial bugs and feature TODOs, and it's almost universal practice that there is the cost of significant engineering work to be done to ship further units - or even just to /support/ the already shipped units.

So, even in the marginal cost model, the cost of engineering labour is not a fixed cost - particularly not in the early phase of life of some software, the phase which would correspond to the "destroy the competitor by undercutting" phase of competition. I.e., the competitor being undercut could quite reasonably make the argument I make above to claim they were subject to unfair competition, even /if/ the competition law was predicated on marginal cost model.

Marginal cost of software

Posted Jul 9, 2024 15:10 UTC (Tue) by paulj (subscriber, #341) [Link] (4 responses)

Oh, and the market kind of has already priced in the 0 fixed-cost component of the prior engineering effort to create the software shipped. Software generally ships for near-0 cost these days (internet bandwidth and electricity costs), be it Free Software or evaluation versions of proprietary software. What tends to be paid for is either support and/or selling ads (even indirectly) - the ongoing support-desk and engineering headcount cost for which is distinctly non-0.

E.g., a browser you must spend significant engineering resources on to maintain so it keeps it's lead in mind and market share, so as to attract users to your search engine, so you can get advertising revenue, does not have a 0 marginal cost really, does it?

Marginal cost of software

Posted Jul 9, 2024 15:15 UTC (Tue) by farnz (subscriber, #17727) [Link] (3 responses)

The browser absolutely has a near zero marginal cost; its amortized costs, and its total costs are much higher, but none of the engineering resources you spend on it are specific to a single unit of the browser as shipped. And the marginal costs of the browser are the costs associated only with a single unit as shipped, not costs that are shared among all units shipped after the costs are spent.

You're describing either an amortized costs model or a total costs model - but anti-competitive behaviour laws tend to shy away from that historically, because the amortized costs are much harder to tease out from the outside, and when you've got a physical good, saying that it's anti-competitive to sell below a price set based on marginal cost has the advantage that it's very hard to argue with, and only protects you from anti-competitive behaviour, but not from a competitor who's simply much more efficient than you.

Marginal cost of software

Posted Jul 9, 2024 17:21 UTC (Tue) by paulj (subscriber, #341) [Link] (2 responses)

Hmm.. Well, I'll go with what you say on how these things are defined in the field of economics.

Though, is the law going to be bound by economics textbooks. If a company is spending €xM on engineering to sustain a product in the marketplace, that they're selling at a price that undercuts others, and they're unfairly subsidising that required engineering cost using other revenue streams, then anti-competition law is going to apply, surely?

I'm no expert on cross-subsidisation competition law, but I'd be a bit surprised if such law was framed strictly to marginal cost. Indeed, for software I think it's impossible to say what the exact cost is for any particular unit shipped (do you have to dive into the companies' bug tracker to figure out exactly what bugs were fixed and who suffered them; and which features were added and who were promised them - never mind you often don't know which customers would have lost patience and walked away if a bug had not been fixed or a feature not added) - as I think you say (or imply anyway). An amortised model makes much more sense for software, precisely cause of what you're arguing about the marginal model. It's much simpler, workable, and gives a more fair view. And I'd assume the injured party would stand a good chance of persuading a court use that in its analysis?

Marginal cost of software

Posted Jul 9, 2024 17:22 UTC (Tue) by paulj (subscriber, #341) [Link]

arg: "Though, is the law going to be bound to economics textbooks?"

Cross subsidy versus anti-competitive activity

Posted Jul 9, 2024 18:28 UTC (Tue) by farnz (subscriber, #17727) [Link]

The law is, indeed, not framed strictly to marginal costs; it's just that proving anti-competitive behaviour with amortized costs is extremely hard, since the competitor is under no obligation to amortize the costs in the way you want them to, and the presumption is that the amortization in the competitor's accounts is correct unless you can prove that it's incorrect.

So, for example, I might have a 2D graphics library that I use in many products, and amortize its costs mostly on the products that aren't undercutting you - it's then on you to prove that when I say a given engineering cost belongs to (say) my my native compiled application framework and not to my browser, I'm being deceptive. And that's incredibly hard to do in most legal systems, since you'd have to have a pre-existing reason (not a fishing expedition) that gives you cause to subpoena not just my accounts, but also the underlying data that justifies my decisions to amortize costs in a certain fashion.

And that's a lot of why most anti-competitive behaviour actions depend on marginal costs, rather than amortized; marginal costs can be easily deduced from the material inputs to a product plus a suitable margin to allow for the cost of production, and the only way to refute that as your cost basis is to open up your accounts and show that your actual costs are lower and why they're lower. Amortized costs depend on exactly how things like engineering time, support staff time etc are accounted to the projects involved - and any good accountant can find ways to amortize the costs to get the right outcome in a given case.

Also worth noting that amortized costs do not have to be consistent between cases; I can account the same engineering time to the browser in a case about my native compiled application framework, and to the native compiled application framework in a case about my browser, and that's OK, legally.

Marginal cost of software

Posted Jul 9, 2024 15:12 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

The engineering labour is not part of marginal costs, because it's a one-and-done situation; while it is spread out over time, it's not tied directly to the cost of producing a single unit, and only applicable to that unit.

In the marginal cost model, the cost of engineering labour is ignored - it's known to be there, but it's not part of the marginal costs; it's part of amortized costs, or total costs, but not marginal costs. And because marginal costs are relatively easy to account in physical goods (since it's basically the cost of the raw materials), most anti-competitive behaviour laws are written in terms of "selling below marginal cost plus some reasonable margin to cover other costs", not "selling below amortized cost".

Marginal cost of software

Posted Jul 9, 2024 16:04 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

>The engineering labour is not part of marginal costs, because it's a one-and-done situation; while it is spread out over time, it's not tied directly to the cost of producing a single unit, and only applicable to that unit.

But if it's an ongoing cost, it's not a capital cost, either. Maintenance *should* be paid for out of revenue, which makes it part of the marginal cost.

True the original engineering cost is an investment paid for out of capital, which is your argument.

But there's certainly a case to be had that if it's an ongoing cost, therefore should be paid for out of revenue, then it's a marginal cost that should be subject to unfair competition law.

Cheers,
Wol

Amortized costs, marginal costs, and capital costs

Posted Jul 9, 2024 16:23 UTC (Tue) by farnz (subscriber, #17727) [Link]

It's part of amortized costs and total costs, but not marginal costs. Paying for it out of revenue does not make it part of the marginal cost; if it's paid out of revenue, it's an amortized cost, but not necessarily a marginal cost. Marginal costs of production are not total costs minus capital costs; rather, they're the costs that are directly attributed to a single unit of production, and that cannot be shared with other units of production.

Unfair competition law has historically liked this as the baseline for "is this anti-competitive" (with a requirement that you charge at least some percentage more than the marginal cost of production), since unlike amortized costs (where the precise amount of engineering effort attributed to a single unit of something is an accounting decision), there's very little wiggle room - the costs of producing this one item, given that you have everything you need to produce N items, can be reduced down to the materials cost of that item for physical goods plus some percentage to reflect the amortized costs of producing the item, which makes it very simple to avoid accidentally using competition law to protect an inefficient producer from a more efficient producer.

But this is what breaks down for software - software's marginal cost is tiny (the Linux kernel's marginal cost is under 1¢ per copy), and most of the cost is amortized costs at best. Which means that competition law is basically useless in most jurisdictions, since you'd have to show that I'm paying customers to take my software to show that I'm selling below my marginal cost.

Accessibility in Wayland

Posted Jul 9, 2024 0:04 UTC (Tue) by jjs (guest, #10315) [Link] (5 responses)

Interestingly, the majority of organizations (businesses, non-profits, governmental bodies, etc.) are NOT in the software business. Which means software is a cost for them, NOT a profit. It also means that their software, since it's from somewhere else, is NOT a "secret sauce" - it's the same as their competitors are using.

However, if it's proprietary, it also means they are at the mercy of their vendor. Vendor can handle 1000 problems at a time and you're number 1010? Too bad. Vendor decides to jack up the price? Especially if there's no drop-in replacement, you're out of luck.

However, by using open source software, they can eliminate these issues. Hire an open source developer/development company to maintain the open source product X you use. Pay for bug fixes. If your vendor ups the price, you can go elsewhere. Want a feature added? Pony up the money and they'll add it (money talks).

And the odds are good you can probably set up contracts for less than the yearly licensing fees on that proprietary software. And by paying, you encourage the growth of the open source development community.

Of course, if you're cheap, you don't pay anything. And when the people maintaining that software you depend on either quit maintaining it (because they need to eat, for example), or take it in a different direction, well, you can always fork it. If you (a non-software entity) have coders. And budgeted for them.

Mind you, I'm not saying organizations are this smart. Most, I think, are on the order of the last paragraph.

Commercial support for open source

Posted Jul 9, 2024 10:37 UTC (Tue) by farnz (subscriber, #17727) [Link] (4 responses)

The difficulty is persuading people that it's worth their while sharing improvements (from trivial bug fixes through major features). Proprietary vendors can enforce sharing improvements by reserving the ability to improve the software at all, and thus being able to say "everyone gets the improvements we make, as long as they pay us".

But once you get into sharing your improvements, you face two sets of pushback:

Why should we share this fix/improvement? We paid for it, and if we share it, that takes away a tiny advantage over our competitors who don't have the same change available to them.
Why should we pay for this change, when we can wait for someone to do it for free? After all, if everyone shares their changes, we'll get it for free eventually.

Between the two, you end up with proprietary software having an advantage because organisations know that they won't get the change they want for free, but have to pay the vendor to make it happen.

Commercial support for open source

Posted Jul 9, 2024 12:28 UTC (Tue) by pizza (subscriber, #46) [Link]

> Proprietary vendors can enforce sharing improvements by reserving the ability to improve the software at all, and thus being able to say "everyone gets the improvements we make, as long as they pay us".

Or by effectively making every customer independently pay for the same improvements. [1]

[1] Which include "fixing glaring syntax errors that show the software was never even _compile tested_ before shipping it"

Commercial support for open source

Posted Jul 9, 2024 14:18 UTC (Tue) by jjs (guest, #10315) [Link] (2 responses)

Oh, I agree. See my last line. However, their thinking is ultimately against them. Having seen many companies, my experience is that the majority of their "secret sauce" - their advantage - has to do with a) their data, b) their processes, c) their policies. Many outside of the software (things like putting customers first, how they interact with customers, their process for developing their products/services, etc.). For your two items:
1. While they may think it gives them a small advantage, so does everyone else. Reality is the changes most likely are neutral in terms of competitiveness, but make life easier for their employees.
2. Yes, you'll get it free. But you run the risk of the support chain going away, because EVERYONE thinks like that.

Both of which lead back to proprietary software - which is much worse. Unless you are a huge buyer of the software, or there's a very large common thing, why should proprietary software companies do maintenance? Maintenance is a cost in software, not a profit center. The big money is on licensing - the right to use the software.

Well, I'll somewhat take that back. For most software I've seen, maintenance is a cost (they don't charge for maintenance fixes). However, I have seen companies charge for maintenance. Normally lots of money. Plus licensing fees. And you still don't get the ability to go elsewhere to get fixes if they don't respond, and you can't easily change vendor (now you need new software).

Prisoner's dilemma in paying for open source

Posted Jul 9, 2024 14:55 UTC (Tue) by farnz (subscriber, #17727) [Link] (1 responses)

You end up in a prisoner's dilemma situation; for any individual user of a piece of software, the best thing to do is to not pay for maintenance at all and just freeload on everyone else. But the best thing for everyone who uses that software is for all users to contribute a "fair" amount to maintenance, such that everyone pays for maintenance, and everyone gets maintenance.

With proprietary software, the software vendor gets to force everyone to contribute a "fair" amount to maintenance, but takes a further fee as their profit margin. Everyone therefore pays more than they would in the open source everyone co-operates world, but the maintenance happens.

With open source, there's no forcing function; if you choose to defect and not pay, the cost is that the software is worse for everyone, and the gain is that you're not paying for maintenance while still getting software that's as good as anyone else gets.

And you've got a proper prisoner's dilemma here, since, with "cooperate" meaning "contribute to maintenance", and "defect" meaning "freeload on other people's maintenance", I get the highest payoff if I defect and you cooperate (since you provide me with "free" maintenance), my next best is us both cooperating (software is better for both of us), then both defecting (software is awful, but at least it's free), and the worst is if I cooperate and you defect (I pay for maintenance, you get it for free).

Prisoner's dilemma in paying for open source

Posted Jul 9, 2024 15:58 UTC (Tue) by Wol (subscriber, #4433) [Link]

And while it may not go down well, the best solution is if a couple of companies support their own in-house improvements, hear about each other, and say "hey, why don't we form a trade association, we have a shared git server that only we have access to, and we each dedicate one full-time software guy to improving the software the way his employer wants, but all the software guys have access to - and can collaborate with - all the other software guys".

Then hopefully they'll have the sense to do an occasional "over the wall" code drop along with the message "if you depend on this software, why don't you join us?".

Cheers,
Wol