“ISO obstructs adoption of standards by paywalling them”
twitter.com
twitter.com
One common workaround is to go to "the Estonian site" which offers the same, English version of standards for a much lower price [2]. Being a bit cynical, I would say that Estonia prioritises open information much more highly than.. other developed countries. I created a price comparison on my website [3].
But: The core problem of standards being openly available is still not solved. Why is this not possible? For me, standards are very comparable to the law: A large number of people should comply with it. For that, they must be openly available to everyone. Everything else doesn't make sense. Is that unreasonable?
[1] https://www.iso.org/standard/38421.html [2] https://www.evs.ee/en/ [3] https://openregulatory.com/accessing-standards/
Healthcare startups are one place that shouldn't really have a practical problem with this - the cost of standards is a drop in the bucket compared to your overall cost of regulatory/quality implementation, filing, etc. Sure, it stings a bit to hand out a few thousand for pdfs but it isn't going to affect your business plan. If you don't have a plan to pay for all of this this you are already dead in the water.
I'm all for streamlining the implementation but a lot of it is just about implementing solid engineering practices. Note, I'm absolutely not saying you should insist on bloated slow processes, this definitely isn't required.
I also think it would be great if we could fund the ISO a different way and make all the standards freely available. It's just not going to make any real difference to your ability to execute as a healthcare startup.
How will they even know what their business plan is without knowing what standard they will be providing?
Last time I checked in Australia, compliance with pay-for-access standards was required in many laws. It is outrageous, because it means you don't even know what you are legally required to do without paying some corporation money.
To add humour to the situation, I think that corporation got bought out by the Chinese at some point. Can't swear to that, I forget what is handled by SAI Global v. Standards Austarlia.
Anyhow the whole situation is a black stain on the idea of equal access to the law.
If you head into something like healthcare without any idea of what you need to do, you are begging for trouble. By the time you are buying any standards, you know which ones you need and how they fit in with everything else. Any real business plan will have researched this enough to get a ballpark. This is table stakes stuff.
You can research it all yourself in a few days and get a reasonable idea. If your team is all inexperienced you should probably spend a few consulting hours on guidance.
If you have anything like a real plan for a company, this is peanuts. If you don't, you do not need any of this stuff yet.
and that is what created the current situation.
Laws should be freely (as in free beer) available. Laws should not be tucked away behind a paywall or behind "case law" or behind "international standards" that the layperson can't access without a fee. No fees. That's what taxes are for.
Are there no drafts available for most standards? For C++ the draft is often as good as the standard, and anybody can access the drafts. Is there nothing similar in other areas?
I guess maybe you can just ‘hope’ you comply and let the inspection figure it out if they ever show up.
Yes, the short-term financial implications (cost of standards) are minor compared to cost of employees and consultants (source: I am a consultant). However, non-free standards have a gazillion second-order effects which tend to get overlooked:
- Potential founders (think YC) can't "just quickly browse a standard" to see whether they'd want to build a startup in that area.
- Individuals not affiliated to a company won't purchase them for themselves (too expensive) and therefore are excluded from contributing.
- People can't write blog posts which freely cite passages from a standard --> Less public information on how to actually implement a standard in a company.
- People can't make presentations (slides) with passages from a standard --> A lot of paraphrasing and beating around the bush, making presentations more useless.
Imagine, for a second, the following thought experiment: Open source software on GitHub would be behind a similar paywall, say, 50 EUR per software package. You could make your argument again: Compared to engineering salaries, that's a minor amount. Sure. But the second-order effects are gigantic, essentially killing the open source ecosystem because individuals (like a random person from a third-world country) are entirely cut off and barred from contributing.
Or, like: Would DHH have written rails if access to Ruby would have cost 50 EUR?
To be a bit US specific (this varies worldwide); the FDA publishes a ton of information on what their expectations are. You absolutely should be reading their guidance documents, filing process, etc. That gets you past the "is this something we should do" phase.
You'll likely get to the point you have a conformance plan for 13485 or similar, at which point you have a real project committed so the small fraction cost thing applies.
The most impactful healthcare standards aren't about "here's how you build a device", they are about "here's how you build an organization capable of building, shipping, and supporting a device".
Once you've got your head around that, you're off and running. On the R&D side of things, there is actually little bureaucracy for it's own sake, mostly it's about implementing good engineering practices in a traceable way.
I guess my response is to your "Healthcare startups are struggling with this" is that I know a lot of healthcare startups, and they struggle with a lot of things, but this typically isn't one of them.
To me ISO-8601 not being freely available is obviously counterproductive. ISO 13485 or 60601 not being freely available is more "well, not optimal but doesn't make much difference"
I remember buying my first ISO document (INCITS/ISO/IEC 14882-2003) for $30 in like 2005 or something, back when I was still writing code. I thought I would become a better C++ programmer, armed with the standard, but turns out it didn't help me at all (reading books/writing code helped more). I did become a better standards-lawyer though! :D
- You need to purchase multiple standards (at least 4).
- In theory, you need to purchase a multi-user license if more than one person should be allowed to read the pdf in your company (hint: nobody purchases the multi-user license).
- Every few years, new versions of the standards are released which you have to purchase.
- Sometimes, you just purchase standards to realise that they're not applicable to your company.
- The industry is riddled with shadiness: A German standards web shop offers a "standards flatrate" for a "great price" of e.g. 750 EUR for 10 standards. [1]
- Getting off-topic, but more related shadiness: Your purchased PDFs are watermarked with your company name and full name of purchaser (!) in the footer of each page to prevent sharing.
[1] https://www.beuth.de/de/regelwerke/normen-flatrates-im-ueber...
And in case of standards in computing, like ISO 8601 - a lot of them are of interest to open source developers. If they could access them for free, they could make their code compliant. Software companies use a lot of open source, and often whether or not a product follows some standard somewhere is entirely dependent on whether the OSS component it uses follows the standard.
How does the law treat this differently from a book? You can buy a book and then give or sell it to whomever you wish without any restrictions... how is this different?
Then there's also another side to digital distribution, especially in entertainment — if you bought a (heavily DRM'ed) video game, or a movie, or a book, or something else, online, it's tied to your account. You can't lend whatever it is you bought to a friend like you absolutely could the same exact thing on a physical medium. You can't resell it either. You also rely on the mercy of the seller to not pull your access to the thing. Yet, even though it lacks this basic trait of a physical medium, sellers treat digital and physical as mostly the same thing.
And those prices look reasonable compared to drug database license costs.
And the real killer is meaningful use certification.
The whole field seems engineered to prevent competition.
So while ISO costs are unjustifiable, they’re a pittance compared to other compliance costs that most in the field will encounter.
Source: work for a medical billing company, have had to deal with this garbage before.
It is. After all it is not in the interests of anyone who is established in the field to make competition easy.
I was once tangentially involved with an app that was basically a weight tracker. It was supposed to be a simple, reliable solutions for doctors to prescribe their patients, that allowed doctors to export data, and did not have annoying ads.
Since doctors were supposed to prescribe the app, it had to be certified as a medical device. It was fortunately a self-certification process.
But still the certification process was 10x more expensive than just the app development.
The problem is that not every medical "startup" has multiple full time employees and millions in funding. Some are just a single doctor with a simple idea, and for them a few thousand dollar here and a few thousand dollar there quickly add up. The standards aren't their only expense.
Copyright might restrict reposting parts, but nothing (except perhaps license agreements) restricts public discussion.
You can see this by the fact that Wikipedia has complete details of the ISO date standard (as referenced in the parent tweet Tim replied to).
And nobody's doing that.
Most people aren't going to quote much anyway, which means the people who don't know what's referenced can't understand it because they have no context. Which brings us back to square one, you can't meaningfully discuss the content in public.
You absolutely can, trivially as the huge number of discussions or the ISO date format on StackOverflow show: https://stackoverflow.com/search?q=ISO+Date
There are lots of issues with locked down standards. But copyright means they can't be publicly discussed is factually incorrect.
(Also fair use means it's fine to quote enough context for a meaningful discussion anyway)
Fair Use exception in the US, and I think that would be covered by Fair Dealing in the UK and similar countries.
For instance, the C++ specification is registered as an ISO standard, which means you have to either rely on free drafts, or pay for it...
But getting funding through finances for 'a few hundred EUR' in a largish company could be nearly impossible. It's not a thing that can go into your yearly budget and it's not attached to any project. You'll have to pay out of your own pocket for that.
These codes are often produced by a single organization, "International Code Council", a non-profit somewhat analagous to ISO, which I believe sells them to governmental jurisidictions which adopt them as law, sometimes with some customizations or "choose A or B" choices.
One of the parties to the lawsuits involved happens to be a Y Combinator funded company, "UpCodes".
https://archinect.com/news/article/150195411/supreme-court-r...
https://www.constructiondive.com/news/construction-code-purv...
https://techcrunch.com/2020/11/16/a-court-decision-in-favor-...
In the US, if there are any cases where an ISO code is mentioned in law as legally binding in some way, it's possible someone could try to challenge the ability to keep from sharing the relevant standard text freely. It's not exactly the same situation, but this supreme court decision provides a possible path anyway.
Same problem in Australia with the AS/NZS standards. I've been having problems with my whiteset plaster, which is like a liquid applied white plaster surface used on almost every home here in Western Australia. Mine was done incorrectly, I had to purchase two different $250 standards to understand how it was done wrong, how it should behave, how it was tested, in order to file a complaint. It may not surprise you part of the reason it was applied incorrectly is because not every trade has a copy of said standard.
And then even once you purchase it, it's a "one user" watermarked PDF you're supposed to only have 1 copy of and there's lots of harsh warnings about that, so even those that have it and scared to run around with it.
It's a crazy situation. Because this is legislated stuff for building. As a consumer it's very expensive to inform yourself on these things. If you wanted to inform yourself on all aspects of a build it would get expensive fast.
It's also difficult for me to publish and discuss this information in the public domain to help other consumers having the same problem, as the limits of how much text I can "copy" appears technically set at 0 even though it's standard to "reference" it. But it's very easy to mis-interpret the standard if you don't read things in context.
If the standards are effectively government legislated they either need to be government funded (this makes total sense to me) or the price needs to be much more token, 10 dollars, with much less draconian access. But at that price the government may as well fund it anyway.
Somewhat off-topic, but I've never quite understood the American tendency to call something the "International X" when the US is only the country of any significance involved in it.
(It may be technically true that a handful of small countries have adopted the US building code – such as Bermuda or Western Samoa. But that doesn't change its status as an essentially American code. The US is the only major economy to use it, and non-US entities have very minimal, if any, input on its contents. And a few small countries might have adopted the US building code even if it was called "US" rather than "International".)
If anything the American tendency is to restrict interest to the US.
Realistically it’s more probable that the group started out with a goal of world-wide adoption of the standards they produced and failed to get traction outside the USA sphere of influence.
"the principles that guide the Court’s analysis seem relatively clear. The law is in the public domain, and the public must be afforded free access to it. SeePRO, 140 S.Ct. at1507. That a law references a privately-authored, copyrighted work does not necessarily make that work “the law,” such that the public needs free access to the work. CCC, 44 F.3d at 74. However, a privately-authored work may “become the law” upon substantial government adoption in limited circumstances, based on considerations including (1) whether the private author intended or encouraged the work’s adoption into law; (2) whether the work comprehensively governs public conduct, such that it resembles a “law of general applicability”; (3) whether the work expressly regulates a broad area of private endeavor;(4) whether the work provides penalties or sanctions for violation of its contents; and (5) whether the alleged infringer has published and identified the work as part of the law, rather than the copyrighted material underlying the law."
The Supreme Court ruled in Georgia vs public.resource.org, which was very much not about building codes. P.R.Org actually does have another ongoing lawsuit that is similar to UpCode's: American Society for Testing and Materials et al. v. Public.Resource.Org
The UpCode ruling was at the district court level, and merely cited the ruling from Georgia vs public.resource.org.
Until we get at least appellate level decisions on the copyrightability of enacted codes, I'm unlikely to feel satisfied.
No, it didn't. It ruled that the State of Georgia couldn't claim copyright on officially-annotated legal codes. Your sources note this and speculate about how it might impact a different ongoing dispute about privately-copyrighted building codes owned by the ICC that are often referenced in, and thereby given force of, law (and the TC one of discusses it having an effect on a non-terminal ruling in the case (a motion to dismiss which was denied, allowing the case to move forward but not resolving it.)
No, it really isn't if they are serious, or even if they plan on being serious in the future.
If you are shipping anything classified as a device, regulatory & QA work will typically involve multiple full time hires and/or equivalent consulting help by the time you file. Things are a bit leaner in SAAS only world, but still significant.
Also startups: We can't afford a hundred dollar PDF uwu.
SO the latest version of the English-language version of ISO 8601-1 would be encoded as
urn:iso:std:iso:8601:-1:en
It was a shock for people doing internet (which in 1990s based on us gov std will be obsoleted and all moved to iso/osi). Or in my job doing EDI. It is just crazy. We want to do us gov standard and world standard. But can’t.
Let us temporarily use this lousy Ethernet, to be obsolete internet ... can’t use sna we all know and decnet (iso ?) is too buggy.
At least this ftp, email, telnet seems work. It needs at least 2 working sample before the standard is a ietf paper. And you can at least download the paper to learn what is it.
Good luck we are in 1990s. We never did a migration from the temporary internetworking thing call internet to the grand great hall of iso/osi. Just hope health care do not repeat the same mistake. Only open available standard could work if you have more than 1 parties.
[1] https://www.nist.gov/standardsgov/accessing-standards-incorp...
And to top it off most of these licenses under which you buy them only allow for a single digital copy (one person).
But when it gets to dozens/hundreds, plus requiring vendors to have their own copies, it quickly multiplies into a massive burden. And that's not even getting into the open source issues.
Not to mention the fact that you might not know if you NEED the ISO until after you've already bought it.
And when you read the standards, they reference other standards. Eventually you have to build a graph of standards to which you must comply, each one costing hundreds of Euros. It's a complete racket.
The worst thing is that the standards themselves tend to be written by 3rd party organisations with an interest in that domain, so they have a strong incentive to make the standard match with whatever they're doing. So not only does a new startup have to spend months reading hugely expensive dry safety standards, you also have to build something which is essentially a worse version of the incumbents.
Mine was done incorrectly, I had to purchase two different $250 standards to understand how it was done wrong, how it should behave, how it was tested, in order to file a complaint. It may not surprise you part of the reason it was applied incorrectly is because not every trade has a copy of said standard.
And then even once you purchase it, it's a "one user" watermarked PDF you're supposed to only have 1 copy of and there's lots of harsh warnings about that, so even those that have it and scared to run around with it.
It's a crazy situation. Because this is legislated stuff for building. As a consumer it's very expensive to inform yourself on these things. If you wanted to inform yourself on all aspects of a build it would get expensive fast.
It's also difficult for me to publish and discuss this information in the public domain to help other consumers having the same problem, as the limits of how much text I can "copy" appears technically set at 0 even though it's standard to "reference" it. But it's very easy to mis-interpret the standard if you don't read things in context.
If the standards are effectively government legislated they either need to be government funded (this makes total sense to me) or the price needs to be much more token, 10 dollars, with much less draconian access. But at that price the government may as well fund it anyway.
Related anecdote: years ago I worked a semiconductor company, which was working with a competitor to standardize the sensor/camera component for the OpenMAX [1] multimedia framework (like GStreamer).
We wanted a unified component that output a finished image (because our hardware was capable for that), but the competitor wanted modular components that produced/consumed pieces transferred to memory (because their HW was more limited).
I think the final standard followed theirs, much to our chagrin.
That way you might explore which standards are necessary and buy them if need-be.
edit: Obviously I would advocate for open and free standards.
Tim Sweeney correctly observes this, then continues to talk about "millions of hobbyist programmers". I do not believe that ISO targets, or even has any remote interest, in this market.
ISO is comprised of nation-state members who will inevitably mandate ISO standards as part of legal compliance. Various stakeholders actually participate in standardization efforts and thus also both already know the standard and are able to push it through. All of these categories (government, industries in highly regulated sectors and large stakeholders) have large amounts of capital. The amount of money required to fund a purchase of an ISO standard barely even factors in on a balance sheet.
Hobbyist programmers arguably make a lot of open source software that builds the foundation for today's and tomorrow's platforms. However, when the big bulldozers from the previous paragraph roll in, hobbyist programmers give way to highly paid employees of these giants; be it by merging a patch or be it by being worked around with a greenfield project or fork.
On the other hand, ISO has an incentive in charging money for their standards because this adds perceived value: If something is freely available, it is easier to dismiss it as a non-serious effort when debating whether it is worth to bind personnel for participation in the standards committees; the standards come across as valueless, worthless.
Looking at this vector of interests of the various parties involved, I see little reason for this state of affairs to improve.
ISO's argument is compelling but we see other standards organizations taking different approaches and more or less still finding success.
[1] http://www.unicode.org/versions/Unicode13.0.0/ [2] https://home.unicode.org/membership/why-join/
I learned a lot doing this project, and I would never have been able to do it without free access to the standard. So I think Tim is right to recognise the value open standards provide to hobbyist programmers.
ECMAScript is nowadays amusing because the ISO standard for it is literally a single page document… that normatively references the ECMA published document.
Though, I think that ISO can be fully funded by the national standards bodies on an annual basis just like OASIS is funder by companies and not charge for PDFs.
Unicode is a standard for encoding characters. ISO is an organisation that _creates_ standards for just about anything.
Unicode became a standard as a result of beating other competing standardisations. ISO declares that whatever they came up with is the standard, no competition required. Hence the effectiveness of the business model.
They probably don't. And, maybe that made sense decades ago when it was more true (though this has never been completely true) that serious software came out of big industry with up-front allocation of resources, whereas what any hobbyist programmers were working on was something else entirely. Today, much serious software is built by informal networks of developers who don't necessarily share an organizational affiliation even if some of them have institutional sponsors. And a lot of it evolves fluidly, without mandated standards as institutional requirements, so if developers can't get a standard freely to assess it for fitness, they simply won't consider it at all. Thet’ll either ignore it entirely, or approximate the behavior of some other piece of software that implements (perhaps not faithfully) functionality from the standard relevant to the needs of the new project (maybe making alterations to suit the different use case, without reference to the inaccessible standard, which may have a solution for the new projects problem that the project used as a model didn't need.)
ISO/ANSI/etc. model of selling standards documents to fund the standards maintenance organization introduces friction for even “serious software” in that environment, whereas the models used by the IETF, ECMA, W3C, etc., that funded standards work without relying on selling standards docs does not.
Now, of course, there's an easy workaround; if you want technology to be used, and multiple standards organizations make standards in the field, don't submit it (at least not exclusively) to the paid-access organizations. But you've also got to get, e.g., governments onboard so that they don't adopt paid-access standards into law.
"Hobbyist programmers" in this context includes "pre-revenue startup founders" and "open source project maintainers". Those people need to have access to standards and shutting them out only serves as a barrier to the industries their applications could disrupt.
I've contributed a few patches to rustc, shipped multiple C++ projects, and even technically submitted a patch to LLVM. I've got a copy of the C++03 standard... but even I haven't rushed out to empty my pocketbook for C++11, C++14, C++17, and C++20, despite using them.
As you point out those are legal requirements, and a small/middle size company would need to know them before entering a field or hitting some legally bound clients. The paying upfront makes it difficult to do pure discovery to even know how hard are the requirements to implement.
I saw that at a small company where we could have been interested in applying for a standard, as a nice to have to bring more business. But the cost of paying for the doc, go through it to then perhaps realize it’s not worth it, brought enough friction that it was delayed to oblivion.
It's ridiculously hard to find this data. Sure, there are lists floating out there on the 'net, but many of them are incomplete, outdated, or borked in various ways.
I eventually ended up writing a script to extract it from the Maxmind GeoDB files, which was the best source I could find.
I think I spent half a day on this on total: trying to find a good list, examining the lists I found and discovering they weren't good, I wrote a script to extract this from another source (some US gov't agency, I forgot which) only to discover there were problems with that data as well (it dropped diacritics IIRC), etc.
This is the simplest possible ISO standard, and a 10-minute job ballooned to this. In hindsight it almost would have been better to just pay the €200 or whatever it is, but bugger if I'm going to shell out that kind of money for a fairly small hobby project.
I did end up paying for the standard (which doesn't even give you the data in a programmatically accessible format! I had to write a pdf extractor). Thankfully there are public lists by visa, mastercard and stripe which also contain private ranges, so my published code shares not just the iso standard but also the matching entries in the other lists.
https://github.com/jleclanche/python-iso18245
https://github.com/jleclanche/python-iso18245/tree/master/is...
ISO does have a browsable website[1] and you can get the data from there, which is the best "official" source I know of, but it's not easy to extract the list from there. It's probably better to shell out the €80 (less than the €200 I remembered) to just buy the damn PDF than spend a day writing a script to extract the data from there, but I'm kinda poor at the moment, so... :-/ Also no idea if that buys me updates as well (being outdated is a big problem with many of the lists I found, turns out countries change, who knew).
Wikipedia also has pages for them[2], but again, I'm not sure how accurate/complete/updated this is.
[1]: https://www.iso.org/obp/ui/#search (click "country codes", no permalink).
The trend of innovation is increasingly becoming grassroots-driven.
In part, that's because our fundamental research advancement has stagnated, i.e., the nation states can no longer steadily produces ground breaking tech that leaves the industry to adopt. As a result the adopt of standards become more relevant to SMBs and individuals.
On the other hand, Internet has driven down the knowledge acquisition cost to probably bare minimal. I.e., modern days, one who has good understanding of English can learn pretty much any highest-level of knowledge almost for free. The SMBs and individuals are becoming more and more sophisticated, making them gradually become competent to be involved in the standardization process.
In short, ISO's practice is fine looking from a perspective of 10 years ago, but it's now wrong.
Please qualify this, I call bs. I acutally think its harder and harder to innovate now a days and we need large companies to innovate because scale is now the battle for any product that makes an impact.
If its a "trend" then you must have historical data that displays the change and im sure you have a hard definition for "innovation" and "grassroots". This is basically a flippant comment that Im not even sure you feel strongly about but it sounds nice.
> down the knowledge acquisition cost to probably bare minimal
you dont understand how important experience is. Books have been around for centuries, all this knowledge was not much more difficult to get decades ago but you still have people cant perform surgery from reading a book or create a rocket ship. Knowledge is about 10% of the solution to any problem.
>individuals are becoming more and more sophisticated
Complicated yes, sophisticated no. Look at music, you think this is a sophisticated society???
I completely disagree. As a hobbyist programmer I want to improve myself so that I can sell my skills to international standards. It's more difficult to do that when standards have to be bought before I can even determine how hard it would be to learn and adapt to it.
The parent wasn't saying that millions of hobbyist programmers don't care about standards. The point is that millions of hobbyist programmers DO care about standards. But ISO doesn't care about the milions of hobbyist programmers and therefore paywalls standards.
But whenever the topic of standards comes up, someone immediately mentions the high price of the standards, and I think only some of the developers actually have a copy of the SQL standards.
That said, it really shouldn't be this way.
But the money you pay to the standards doesn't go to the creators, it goes to the organization to make them available. (I've contributed to ANSI standards).
This removes any commercial incentives that may result in regulatory capture - a big issue in some areas - and should (if implemented properly) drive investment in strategically sensible areas.
The profit that most national/international standards bodies just about covers costs, but none of these bodies are particularly expensive to operate in the grand scheme of things. Some already get partial funding from govts. Full funding is clearly the sensible model.
And this is exactly the perverse conflict of interest. In those cases, the authors have no interest in actually attracting independent implementations that adopt the specification. The specification is a formality to bolster the credibility of their product or technology. The authors don't want some outside team to read this and actually build something on their own; they want that team to buy their [chip/component/patent license/product/service] that implements this.
It's not a solo endeavor. The coauthors and stakeholders tend to be complicit in this game, often as peers in the oligopoly.
When a spec author actually wants their specification to be independently implemented, you can tell. They don't make it exclusively for purchase in the dusty basement of the bureaucracy superstore. They put out guides, conformance tests, reference implementations, examples, and tooling.
And those materials often do exist for ISO standards... but as expensive, proprietary kits from one of the spec authors, only available to customers who buy their [chip/component/patent license/product/service]. That's part of the business plan. Why write a clear spec and give it away for free when you could be selling one of the only conformant implementations of your Public Standard™?
Meanwhile, Oracle out here laughing their way to the bank.
The C++ standard is pretty different and an interesting example here, traditionally there were portions of the standard that weren't really accessible and that, in part, contributed to different compilers not being called out on differences of opinion along with the ability to have differences of opinion not being called out by experts since they didn't have access to the standards to see where those contradictions lay.
In the modern world the C++ standard is what I think ISO should aim for with all their standards, it is widely available and heavily discussed and that feedback has allowed the standard to grow by leaps and bounds as the language has adopted things once seen as impossible (outside of Qt & boost) like foreaches and not-terrible-to-work-with lambdas.
They all learned C++ somewhere, and I doubt that most of them had access to the official ISO standard while doing it. (Yes, I'm aware of the final drafts etc)
There's a difference between “learning to use” and “implementing” (though having access to the standard is good for both, it's more critical for the latter.)
Also, regulators should (in my opinion) pay for standards to be freely available when they harmonize/adopt them for their country/countries. It is kind of insane that one as a customer can't access the rules by which products are approved without paying. It is as if laws would be hidden behind paywalls.
To be legally compliant to install cables in the UK I've got £500 of standards on my desk. We actually pay our national body circa £5k a year for access to various industry standards we need to be able to hold suppliers to account. Govts should just properly fund this stuff.
Capitalism, baby!
Of course, those with money like it this way. It's a barrier for competition and exercising your rights.
Once you start looking at barriers, such as ISO, you start noticing them everywhere. Real estate, dentistry, doctors, school teachers. You can't even cross state lines as a school teacher, or other professions. People often argue that software developers should be licensed much like engineers. Let's be thankful that's not the case. Imagine the headache of being remote and having to get licensed in multiple states!
I'm not very familiar with the situation in France, but I can offer a data point from Switzerland: The civil code is (of course) freely available online and in PDF format. A printed copy is available for CHF 15 or so¹, both from the federal press and from other publishers who might throw in an index or a keyword reference at the same price.
However, if you're actually looking to apply any of the contents, you'll want qualified explanation and references to jurisprudence alongside the legal text. Affordable commentary² on the civil code start at CHF 250 or so, and the industry standard "Basler Kommentar" to the civil code is sold as two volumes, retailing for CHF 598.- each.
¹ It's a few hundred pages; IIUC the price pretty much reflects the cost of printing, binding and logistics. Key point: Nobody is getting rich off of selling these.
² For the civil code, specifically, you'd be in luck: Some consumer advocacy organizations publish hands-on guidebooks that are significantly cheaper than the usual commentaries. So you might get by on CHF 100 or so. But these tend to not be available for other, less mainstream, laws.
My perspective on this idea is that altruism is dead when it comes to open source. Peoples work needs to be paid for. Weather its ISO or the guy creating a program using it. We are not to be slaves to the future and I dont wish that for future devs. Making a profit isnt evil but wanting others work for free is selfish. People can always make their own standards and come together across nations and do the work. But they much rather cry and call hardworking people bad.
Tim is trying to save a buck I bet.
A common claim made by the ISO C++ committee regarding criticism of the language is that these guys are volunteers working in a mostly unpaid capacity on the language, and often have to hit tight deadlines to have any shot at getting a feature into the standard, and that's true exactly because of how arcane the ISO standardization process is. It's this pseudo-antagonistic process where maybe one or two individuals are tasked to "champion" a paper in front of their peers and then everyone is supposed to pretend that there's no politics involved and that the paper gets approved entirely on its technical merit.
C++ would have been much better served from ditching that and doing what Java, Python, and Rust do, have broad community feedback and input. It's hard to imagine what beneficial features are in C++ that would not still be there had there been involvement from the broader community of game developers, embedded device developers, desktop software developers and a host of people who use the language regularly, but it's clear many clumsy and awkward features would have been eliminated, including the now 50 ways of initializing variables, broken standard library features like std::variant, the now unusable std::regex, the minefield that is std::random, the upcoming bloated and error prone std::ranges, it's no wonder many C++ development teams are skeptical of the utility of the standard library and just roll their own alternatives.
I hope no other language goes down the road of using ISO to standardize its language.
I've argued elsewhere on HN that Common Lisp died because they were closed and secretive at the exact moment they needed to go the opposite route.
https://www.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/part4/f...
Around 2004, Lisp was having a bit of a revival of sorts. Lisp was becoming trendy, various blogs and web sites were created. But the only documentation you could find was the HyperSpec. Which, as anyone that had the misfortune of reading, is awful as a reference. It's both too technical for casual software developers and not official enough for language implementers. There were two free, open source Lisps available (CMUCL, CLISP) and both were rather unloved and clunky at best.
Even Linus had a bit of trouble getting his hands on POSIX standards. Imagine Linux dying because it couldn't follow standards that Linus could not acquire.
By the mid-to-late '90s the writing was already on the wall. Perl, Python, PHP, Ruby followed no standard. It became common for the free implementation to be the standard.
Clojure arrived and largely filled the Lisp void. Racket attempted a similar movement, by renaming itself from PLT Scheme to something that removes the emphasis on any particular standard. If you want Lisp today, though, you're probably doing Clojure.
It's not dead, it just smells funny.
> not official enough for language implementers
The HyperSpec is just a different text rendering -> here as Hypertext. The content of the official Common Lisp standard document is in the HyperSpec. As a language implementor it makes no/zero/null difference reading the HyperSpec or the official standards document in PDF format.
> Which, as anyone that had the misfortune of reading
I like it and have been using a lot.
> There were two free, open source Lisps available (CMUCL, CLISP)
GCL, OpenMCL, ECLS, SBCL, ...
> Around 2004... There were two free, open source Lisps available (CMUCL, CLISP) and both were rather unloved and clunky at best.
SBCL and ECL existed and were quite usable.
The documentation was as you say, another story. There was the HyperSpec, copies of CLtL, and a number of out-of-print or hard to find books that described some kind of Lisp. It was hard to be a tyro without a guide.
> Perl, Python, PHP, Ruby followed no standard. It became common for the free implementation to be the standard.
And I mean look how well it worked with transitions to Perl 6 and Python 3.
I don't think this is fair. It is a very useful reference, and it doesn't claim to be a tutorial:
" 1.1.1 Scope and Purpose The specification set forth in this document is designed to promote the portability of Common Lisp programs among a variety of data processing systems. It is a language specification aimed at an audience of implementors and knowledgeable programmers. It is neither a tutorial nor an implementation guide."
It took a decade to add a std::string constructor...
So any tooling improvements (dependency management, build process) are not able to be made to the language. Fractured solutions harm adoption, languages with good dependency management and good build processes have one solution they push on everyone.
I think it is extremely useful, as the standard library is easily (and often) replaced. We have a difference of opinion, and that is perfectly fine, but please do realize that this doesn't mean my comment is in bad faith.
Every library has a goal, and the standard library's goal is not to serve as a industry-ready plug-in for high-performance code. Writing high-performance code in C++ is an advanced task that necessitates more control, which makes the standard library not a good fit. The model of (language) + (library) makes it easy for the end user to pick a library of their choice, for their application.
>comment presents initialization a wart in the core language.
Okay, that is one point. When people say "X sucks" or "X is horrible" there is very little a reader can gain out of that. If a person's opinion is formed by deep experience with that X, then I am interested in knowing specifics that lead to that opinion.
I understand that you intention was to get more information, but I wanted to make sure you're aware that responding to someone who is listing out their complaints with what is essentially "a bunch of people use the language productively, can you please give me information that you just went over, otherwise I am going to disregard your comment" can be interpreted as bad faith because it's a common troll/asymmetric effort tactic.
It's not obvious to me at all; in fact I'm more tempted to believe the opposite. C++ has its shortcomings, but when I (say) compare the C++ standard library against third-party libraries, I find the standard library design & implementations to be of much higher quality. They're often far more flexible and handle far more edge cases than open-source libraries do. So, while I would love for the C++ standard to be free, I think this would be more of an argument for not making it so.
And then of course there's boost [4], but people have very mixed opinions about it.
The reason a lot of developers use the standard library in C++ is because dependency management in C++ such a nightmare that many people writing a library are forced to use the standard if they want any hope of adoption even when far superior options exist. It's literally something people writing C++ libraries will advertise "Dependency free header only library!" because they know without that a lot of developers won't bother using it.
Anyways, I would be interested to know what part of the standard library you find is better than third party options.
[2] https://github.com/facebook/folly
- You've picked some of the best C++ libraries as if they're somehow representative of the ocean of C++ code that's out there, whereas I was talking more about the general landscape.
- It's hard to do an apples-to-apples comparison for a library (like Abseil) that tries to avoid replicating what's already in the standard library, so those aren't necessarily the best examples to discuss here.
That said, OK, here's one trivial example. It is a major time sink to dig these up and write self-contained examples for the sake of argument (it took me 1 hour to write this entire comment), so I hope this example can be sufficient to get my point across.
So folly has FBVector and it supports custom allocators, right? OK, so just try making a vector with a custom pointer type:
#include <vector>
// #include <folly/FBVector.h>
template<class T>
struct my_pointer
{
typedef my_pointer this_type;
typedef T element_type, value_type;
typedef ptrdiff_t difference_type;
typedef this_type pointer;
typedef value_type &reference;
bool operator!=(this_type const &other) const { return !(*this == other); }
bool operator==(this_type const &other) const { return this->p == other.p; }
difference_type operator-(this_type const &other) const { return this->p - other.p; }
explicit operator bool() const { return !!this->p; }
friend this_type operator +(difference_type n, this_type me) { return me + n; }
explicit my_pointer(T *p) : p(p) { }
my_pointer(std::nullptr_t p) : p(p) { }
my_pointer() : p() { }
reference operator *() const { return *this->p; }
template<class U> using rebind = my_pointer<T>;
this_type &operator++() { ++this->p; return *this; }
this_type &operator+=(difference_type n) { this->p += n; return *this; }
this_type &operator--() { --this->p; return *this; }
this_type &operator-=(difference_type n) { this->p -= n; return *this; }
this_type operator+(difference_type d) const { return this_type(this->p + d); }
this_type operator++(int) { this_type copy(*this); ++*this; return copy; }
this_type operator-(difference_type d) const { return this_type(this->p - d); }
this_type operator--(int) { this_type copy(*this); --*this; return copy; }
value_type *operator->() const { return this->p; }
reference operator[](difference_type d) { return this->p[d]; }
private:
T *p;
};
template<class T>
struct my_allocator
{
std::allocator<T> base;
typedef T value_type;
typedef size_t size_type;
typedef my_pointer<T> pointer;
template<class U> struct rebind { typedef my_allocator<U> other; };
pointer allocate(size_type n) { return pointer(this->base.allocate(n)); }
void deallocate(pointer p, size_type n) { return this->base.deallocate(&*p, n); }
};
namespace std
{
template<class T>
struct iterator_traits<my_pointer<T> >
{
typedef typename my_pointer<T>::pointer pointer;
typedef typename my_pointer<T>::reference reference;
typedef typename my_pointer<T>::value_type value_type;
typedef typename my_pointer<T>::difference_type difference_type;
typedef std::random_access_iterator_tag iterator_category;
};
}
int main()
{
#ifdef FOLLY_CPLUSPLUS
folly::fbvector
#else
std::vector
#endif
<int, my_allocator<int> > numbers;
numbers.push_back(1);
return 0;
}
But now try to uncomment the #include so that it uses folly and you suddenly get errors like this:
/usr/include/folly/FBVector.h:148:27: error: no viable conversion from 'folly::fbvector<int, my_allocator<int>>::Impl::pointer' (aka 'my_pointer<int>') to 'int *'
S_destroy_range(b_, e_);
/usr/include/folly/FBVector.h:365:34: note: passing argument to parameter 'first' here
static void S_destroy_range(T* first, T* last) noexcept {
What we see here is folly pretends to support custom allocators, but it cuts corners internally. (!) Which is awful not only because of the inflexibility, but because it misleads you, too. If they're introducing unfounded assumptions internally just out of sheer convenience, how am I supposed to trust the implementation? Heck, if I had implemented implicit conversions to raw pointers so that the code compiled, I might not have even discovered there's a latent bug in my program.
In contrast, in my experience, actual standard library implementations pay attention to the details and don't tend to cut corners like third party libraries do.
Now, again, keep in mind this is what we get with some of the best libraries, whereas I was talking about the general landscape, so the situation isn't even remotely this good on average.
>But who says my fancy pointers will even necessarily map 1:1 to a linear (and contiguous!) pointer space?
The standard as of C++11 does. std::vector<T> provides the member function T* data() which is required to return a pointer to the first element of a contiguous memory region spanning the entire vector:
https://en.cppreference.com/w/cpp/container/vector/data
Note that it specifically returns a T* rather than a my_pointer<T>, or what is referred to in standardese as a "fancy pointer":
https://en.cppreference.com/w/cpp/named_req/Allocator#Fancy_...
>What we see here is folly pretends to support custom allocators, but it cuts corners internally.
No such corners are cut. Folly has full support for custom allocators including fancy pointers and in this case it's giving you a compile time error for what could have been undefined behavior. That's an advantage in my book, I'll take compile time error over hard to debug memory corruption any day of the week.
Fancy pointers to T are required to be implicitly convertible to T* and while the small snippet of code you pasted doesn't make use of this requirement in GCC and clang, MSVC does make use of this requirement and you can see as per the link below that your allocator fails to work:
You'll notice the error is that std::vector is trying to convert your fancy pointer into a raw pointer in order to call _Delete_plain_internal:
>C:/data/msvc/14.28.29910/include\vector(683): error C2893: Failed to specialize function template 'void std::_Delete_plain_internal(_Alloc &,_Alloc::value_type *const ) noexcept'
Other parts of the standard that depend on this are node based containers such as std::list, std::set, and std::allocate_shared also makes use of this requirement.
The fact is that writing a standard conforming allocator that uses fancy pointers is incredibly difficult and error prone, the standard is not clear about the rules with numerous defect reports related to fancy pointers and as of today no compiler actually has full support for it:
https://quuxplusone.github.io/draft/fancy-pointers.html
The fact that you could have picked any example to prove your point about the standard library and the one you chose to produce took you a very long time to exercise what is a fringe and corner case example of a defective language feature that you do not fully understand is not a particularly convincing argument that the standard library provides the high quality implementations and APIs.
That may seem blunt and harsh, but you're in good company since I myself also don't fully understand it, and anyone who's being honest would also admit that fancy pointers in C++ are an area that quite possibly no one really truly understands.
Before jumping to the conclusion that Facebook got it wrong, they cut corners, and their code is not trustworthy over this, perhaps it might be best to pause a moment; this issue has nothing to do with Facebook and instead is merely a reflection of the sheer complexity of C++ as a language.
It disappoints me that, to this day, the best reference for pure SQL out there are the postgres docs, postgres is actually pretty good about calling out non-compliances so you can get a really good grounding of what code is likely to be cross platform compatible.
I 100% agree with Tim Sweeney's sentiment. ISO are terrible at their job.
Second informal review draft from the accepted answer: http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
Downloadable iso standards (C-f sql) http://www.iso.org/PubliclyAvailableStandards
One time it was IEEE, one of our customers was a college professor, and he was using his personal web hosting space (remember that?) To host his syllabus including a pdf of one of their standards. I tried to get a hold of him multiple times, but they kept contacting us, more aggressively than the RIAA or MPAA ever did. So I just deleted the file.
ISO 8601-2:2019 [1] is however a complete mess. It is too complex for human consumption and too ambiguous for computing uses. I argue that it should be shelved as soon as possible.
[1] https://web.archive.org/web/20171020000043/https://www.loc.g... (draft standard)
Wow, you weren't joking.
It introduces things like "?2015-?02-31" (year and month are uncertain, day is known), which may be abbreviated as "2015-02?-31". 'The character '?' (question mark) is used to mean "uncertain". The character '~' (tilde) is used to mean "approximate". The character '%’ (percent) is used to mean “both uncertain and approximate".'
There's also "1950S2" (2 significant digits, so a year between 1900 and 1999, estimated as 1950). You could also write 19XX, though that has a slightly different meaning (leaving the last two digits unspecified).
There are special "month" values to denote other divisions of a year. "2001-21" is spring of 2001, 2001-22 is summer, 2001-33 is the first quarter.
"R/20150104T083000/PM15S00/FREQ=YR;INTR=2;BYMO=1;BYDA=SU;BYHO=8,9;BYMIN=30" is a fifteen minute time interval every Sunday in January at 8:30:00 AM and 9:30:00 AM, every other year
- Sub-year groupings are not very well defined and you may want to avoid them, but if you want the basic approximate and uncertain dates you can't avoid them because they all belong to the level 1. Ideally each extension to 8601-1 should have been defined separately; they do have to be described altogether to avoid the conflict among them, but any part of the additional standard should have been optional.
- 8601-2 essentially took the whole recurring time interval mechanism from iCalendar and it is a simple textual format. Why not the same for extended date and time instead of sigils (e.g. `2021-03-09;SIG=P1M`)? Unlike 8601-1 it doesn't have an absolute requirement for usability. I can only guess but editors seem to have forgotten to harmonize different specifications.
Approximate dates, and unknown portions of dates are fairly commonplace in genealogy.
(No idea what the original author was thinking though — I wonder if the intended use cases are documented anywhere?)
When specifications needed to be printed and shipped, I understand that costs money, but electronic standards should be very low to zero cost to download.
I did find that DIN (Deutsche Institut für Normung or German Institute for Standardisation) is starting to publish some of their standards for free. https://www.din.de/en/din-and-our-partners/press/press-relea...
In the US, anything that is published by the government is supposed to be free of copyright. https://www.govinfo.gov/about/policies
And ANSI and 3GPP for all kinds of telecom.
> Hello, unfortunately, the ISO Central Secretariat does not provide free copies of standards. All ISO Publications derive from the work and contributions of ISO and ISO Members that contain intellectual property of demonstrable economic value.
> For this reason, considering the value of standards, their economic and social importance, the costs of their development and maintenance, we and all ISO Members have the interest to protect the value of ISO Publications and National Adoptions, not making them publicly available.
The ISO standard that I have the most experience with is ISO/IEC 9899:1990, aka C90. Part of the reason for that, of course, is that I had a used copy of Herbert Schildt's Annotated ANSI C Standard; it's also a considerably smaller standard than, say, SQL or C++.
I'm of mixed minds as to the value of the C standard. There is certainly value in having a standard. After sufficient study and deliberation, you can usually determine whether an input program or compiler implementation is standards conforming. When I compare the evolution of C and C++ to say, Python and Rust, I have trouble pointing to the specific value that ISO adds.
This isn't really a fair comparison, because the difference between C/C++ and Python/Rust isn't just the process, but the end result. I judge C and C++ not just by ISO's efforts, but by those of Microsoft, IBM, GNU, LLVM, etc. Python and Rust, meanwhile, ship a working reference implementation, and do a pretty good job of it. Rust has improved quite a bit six weeks at a time. C standards, meanwhile, ship closer to every decade. Even the new rapid pace of C++ is every three years.
Low-quality standards are themselves an access issue, and I think are reinforced by the paid-access rule, since that means the people reading the standards are a narrower group who is more specialized in dealing with ISO standards, who are more prone to become blind to “that’s just the way ISO standards are”.
ANSI (also paid access) standards such as the whole ASC X-12 suite widely used in industry and a portion of which is mandated federally for healthcare under HIPAA are a complete nightmare mess, too. (And it doesn't help that not only are they paid-access standards, but they often incorporate by reference literally hundreds of other, largely paid access, standards from other bodies, some of which have become obsolete and are no longer available when the standard referencing them remains mandated.)
I am currently a member of TC184/SC4 and have also been a member of TC22/SC31.
For the TC22/SC31 work I was just being paid by my employer and they provided the travel costs to meetings.
The scope of TC184/SC4 is much bigger, the core people work on it pretty much full time and get paid by industry consortia to deliver something that will meet their needs. Some parts have been written by postgraduate students who got their PhD out of the work.
If they write the text of the standard, that means ISO writes the text of the standard.
I implemented the entirety of ISO 8601 years ago (not just the most common 5% that most people are aware of) -- parsing, representation, writing, validation, and arithmetic -- and there's no way I could've guessed some of the stranger cases the standard explicitly supports, and how, without being told what they are.
I hope I never see some of the truncated and reduced precision forms in practice, since perhaps no one but the handful of people with access to the standard will be able to interpret those correctly. :)
I could agree for something like the international definition of physical quantities, where people have to do actual experiments, or travel to see equipment or even transport standard items.
But in software designs, often when you tip more resources into a project, you get a worse result. This is true for the C++ standard. Some necessary improvements occur (modules, finally, albeit incomplete with respect to build details), but as long as a large group of people meet to evaluate each others' proposals in a series of desirable resorts, the language will continue to grow in size and complexity whether or not it actually needs to. For example, adding "xvalues" to "lvalues" and "rvalues" may solve some earlier design problem in the standard library, but makes the language less understandable for users and implementers and the standards text more opaque.
Indeed, the standards language for C++ is so inscrutable one suspects that you need to be a full-time expert to fully understand it. It then becomes a career for the people involved in the standardisation. Now they have an incentive for the language to grow without bound, and the more complex and hard to understand it becomes, the better.
It's hard enough getting consistent behavior out multiple implementations of the same public standards.
Because those suckers cross-reference each other like crazy, a standard can have only a few paragraphs of useful content (and pages and pages of legaleeze and revision management around).
The bottom line is that there are and will always be costs associated with a running an organization, regardless of whether they are for or non profit. There are overhead costs associated with running a website, conferences, technical review, or collaboration tooling for example. While some revenue comes from participants and membership fees, not everything gets covered. The organization does a lot for the public good and it's unacceptable to criticize these passionate engineers that have dedicated their careers to ensuring proper standards globally.
Open standards. Open research. Open code. This is how we progress as a society. Rent seeking organizations like ISO can rot in the dirt for all I care.
At the very least, ISO could make the cost to get a copy of a standard not some arbitrary 3-digit number of Swiss Francs, but let the committees themselves have a say in this.
In my opinion, for example, it would make perfect sense to make royalty-free specs (i.e. standards that only have Type-1 declarations) available online for free, while charging 4- or 5-digit numbers for patent encumbered specs (standards with Type-2 declarations) for which those who need access to those will have to pay 7- or 8-digit numbers in royalties anyway, so it's still an insignificant extra obstacle for them.
The goal of ISO should be to promote international standardization. Its current business model is instead creating financial obstacles to adopt international standards, as well as creating financial incentives to base implementations on outdated drafts and old versions, which defeats the purpose of having processes to amend, correct and extend standards.
Other standardization organizations like IETF, W3C, ITU are capable of "making money somehow" without having to put their standards behind a paywall.
Standards are a lot like laws, except you in theory voluntarily comply with them (though not always — there are plenty of cases where compliance to ISO standards is obligatory in one way or another). It would be insane if politicians would put the laws they write behind a paywall, for sale to lawyers at 118 Swiss Francs per article, with the argument that "judges need to make money somehow". If you expect people to respect the law, the least you can do is to let them actually see the law, for free. Why would it be any different for international standards?
Heeellll no!
An international co-op, fine, but please not part of political committees such as the UN!
Sorry AN_ISO_Dude, but whatever merit someone/group has doesn't exempt them from valid criticism.
Show us the receipts, and how these standards couldn't exist without paywalls and I (we) would be a lot more sympathetic - the argument here is purely qualitative.
My company complies with HITRUST. Many of the HITRUST controls are syntheses of controls found in NIST, ISO, and other organizations.
In some cases, I want to know where a HITRUST control comes from: But since I can't look at ISO without paying, I am blocked from understanding the provenance of some HITRUST controls.
I don't like that.
Even as members of these working groups writing standards that refer out to other standards, we don't get free access to these and have to pay for them. It's crazy.
I'm really proud of the work I've done over the years helping to get these standards published, but it's really annoying that there's such a barrier of entry to people who want to use them to produce compliant equipment.
(At this point Postgres’s wire protocol is becoming the de-facto wire protocol for smaller players to make themselves compatible with, but that’s still a long ways from being able to talk to every major enterprise DBMS with the same codec-layer library, rather than needing ODBC-style codec plugins.)
You need tons and tons of people to work together on a cross-implementation standardization effort like that (including, hopefully, lots of volunteer FOSS contributors); and all those people would need to be referencing the standard constantly. It’d just be untenable if every one of them needed to pay to see the standard they were coding against.
[1]: https://standards.iso.org/ittf/PubliclyAvailableStandards/in...
long time ago there is about a guy going around the world how his book on decnet and a new networking standard call “internet” is doing. He showed a bot how hard to get hold of iso standard.
Those were the days. I thought ... or they still do not learn.
Like by making a patent covered tech a "standard" ? https://www.openbsd.org/lyrics.html#35
I tried to use ISO 1016 for writing a software design doc with some success, but it was like pulling teeth.
First, you needed multiple ISO dictionaries to find out what half the words are referring to, and even then things are ill-defined.
For example, one of the required sections in an ISO SDD is the Context, but nowhere is context defined or described.
The standards just seem like a web of academic garbage with no connection to reality.
Woe to anyone that must implement them as part of their job.
I remember when the first HTTPS spec came out, and me and everyone else were saying how hard it was to follow. And someone from Netscape came out and said the text was "intentionally terse".
I agree that the fees seem like annoying gatekeepers, and antithetical to the purpose of standards. But if we remove them, where do the economic incentives come from?
I can't find a reference to it though and it was only briefly announced during an ISO meeting. Is there someone from ISO who can back this up?
[0] https://www.iso.org/standard/80321.html
I get the impression the standardisation of Ada has been broadly successful in providing assurance of conformity, [1] but that still doesn't excuse paywalling the document.
[0] https://en.wikipedia.org/wiki/ISO/IEC_8652
[1] https://www.adaic.org/ada-resources/standards/ada-95-documen...
The core of the problem is that we somehow put a private Swiss company in charge of international standardization. Of course that company needs to make money _somehow_ to pay its staff. But that would better be done via government subsidies than via selling specs.
In a way, this reminds me a lot of academic publishing. It's not the publishers who write the papers, yet they get to paywall science.
We need open access standards, just like we need open access scientific journals.
Some are, to be certain. Especially standards where a lot of money is riding on all the adopters agreeing on compliance, so there's a certain benefit to the "money where your mouth is" aspect of the service ISO provides.
But plenty of highly influential standards are not ISO.
That's for a $50 computer with 45 millions copies sold, with Linux being the only OS supported by manufacturer. On other computers can be much worse.
By comparison, install Windows on a computer, install a GPU driver, and Media Foundation API will use the hardware to decode and encode all supported formats, no recompilation needed.
I have implemented accelerated video playback myself https://github.com/Const-me/Vrmac/tree/master/VrmacVideo and I disagree. Needed a lot of these standards, not just for containers and audio, for video decoding too.
> since open implementations exist, open source developers know how the formats function.
These formats are way more complicated than you think they are. Just because open source implementations decode/encode something doesn't mean the implementation is standard-compliant. My one certainly is not.
Note the wordings like “for some Linux users”, “restricted to AMD/Intel graphics cards”. Also check the comments, there’re many other issues, with 4k on Intel GPUs, different desktop managers, and so on.
I think if these MPEG4 standards were freely available, Linux kernel developers would come up with something better. For instance, V4L2 API portable across hardware, with a higher-level wrapper around it.
If you look at MS Media Foundation docs, you’ll see portions of the API surface (like h264-specific media type attributes, or the bit stream, or the APIs for dealing with containers) taken directly from these ISO/IEC specs.
A key spec in this pile was paywalled, so I've reverse-engineered an existing implementation instead. And guess what? The implementation I used as a reference wasn't compliant with the paywalled standard either. So now AVIF-in-the-wild is not compatible with the ISO-AVIF. Great job, ISO!
I remember sending cheques to "Global Engineering Documents" in Englewood Colorado to get printed copies of various standards back in the 1990s and hoping that would die with the advent of the Internet and the possibility of cheaply distributing information. It was understandable in the world of paper that if you wanted some obscure technical document that it was expensive. They retained the publishing model but eliminated the reason it was expensive.
It has been encouraging that people like Carl Malamud have been working at making various aspects of our laws, regulations and standards public but more work is needed.
Some of my tweets over the years on the topic of open access standards:
"I am really thrilled by sudden attention on paywalled standards. Current model hurts standardization. So how about it @SAEIntl, @IEEESA, @NMEA_org, @isostandards, @ITUstandards will you join the 21st century and move to free open access standards? Alternative is your irrelevancy." https://twitter.com/mjduigou/status/1369033695030513670
"It annoys me that the IEEE standard for publishing test results probably won't be adopted by software industry because it is behind a fricking paywall https://ieeexplore.ieee.org/document/8662798" https://twitter.com/mjduigou/status/1273718847497887744
"I don't like that @IEEESA or @SAEIntl put their standards behind paywalls. Whatever revenue this publishing model makes is grossly offset by the impairment to, you know, standardization." https://twitter.com/mjduigou/status/1308889681187221505
"How many bullshit encodings have been created since 1984 because ASN.1 wasn't a freely available standard? Not that it is perfect but SO MUCH PAIN could have been avoided if there had been community adoption. That adoption didn't happen because it was not an open access standard." https://twitter.com/mjduigou/status/1308892326098546691
"Free the codes! https://www.kickstarter.com/projects/publicresource/public-s... Only slightly worse than patent trolls are public standards behind paywalls." https://twitter.com/mjduigou/status/384767046753320962
[1] e.g. https://www.techstreet.com/standards/atis-0700036-v002?produ...
The ISO business model is creating something (standards) and then profiting from their distribution.
A better hack is to approach your local standards body. BIS in India publishes the ISO standards mostly-as-is as adopted by Indian Law/Regulations. They don’t make it easily accessible on the Internet, but it’s available if you ask them for it.
My tiny stash of climbing relevant EN safety standards only exists because of a scrappy Russian climbing community web server someone uploaded to.
Get together with Unity and open source your engines so we can drive towards a standard.
What’s actually interesting is content. Why should we developers be locked into walled gardens?
Thanks
It wasn’t his idea, and thousands of people have worked on the technologies to enable it, and he’s not even the only billionaire with a company who is working on such a thing.
For the most part I see him complaining about people impeding him, rather than just solving the problems with his own resources.
"Timothy Dean Sweeney (born 1970)[4] is an American video game programmer, businessman and conservationist, known as the founder and CEO of Epic Games and as the creator of the Unreal Engine, a game development platform."
https://en.wikipedia.org/wiki/Tim_Sweeney_%28game_developer%...
"Tune in to hear Tim Sweeney (founder and CEO, Epic Games) during his SIGGRAPH 2019 Talk, “THRIVE: Foundational Principles & Technologies for the Metaverse.” You’ll hear Sweeney posit the state of the games industry, the rise of creator-centric and social gaming, what the “metaverse” really is, and what it will take to build the medium on a larger scale."
https://blog.siggraph.org/2019/10/siggraph-spotlight-episode...