I almost overlooked this, and then when I didn’t, I almost dismissed this as Yet Another Linux Distro with a custom skin. But no, there’s novelty and exploration in here. There’s attempt to venture off the local maximum. This is a breath of fresh air.
Always remember that open-source is an author’s gift to the world, and the author doesn’t owe anything to anyone. Thus, if you need a feature that for whatever reason can’t or won’t go upstream, forking is just about the only viable option. Fingers crossed!
If "taking part in a huge ecosystem in a foundational role" means 'other people choosing to use your FOSS software', and I can't think of what else it would mean, then no, you have no obligation to do any of that.
FOSS means the right to use and fork. That's all it means. That's all it ever meant. Any social expectations beyond that live entirely in your imagination.
There is simply no responsibility an OSS maintainer has. They can choose to be responsible, but no one can force them. Eventually OSS licensing is THE solution at heart to solve this problem. Maintainers go rogue? Fork and move on.
But surprise, who is going to fork AND maintain? Filling in all the demands from the community, for potentially no benefit?
No one can force him to take the responsibility, just like no one can force anyone else to.
Right, frustration about the no strings attached sentiment for OSS devs. Of course you've no obligations for support or maintenance, but with increasing exposure responsibility grows as de facto ever more projects, people, softwares depend on you.
This doesn't come over night and this is a spectrum and a choice. From purely personal side project over exotic Debian package to friggin httpx with 15k Github stars and 100 million downloads a week the 46th most downloaded PyPI package!
If this shall work reasonably in any way, hou have to step up. Take money (as they do, https://github.com/sponsors/encode), search fellow maintainers or cede involvement - even if only temporarily.
I feel there should be support from the ecosystem to help with that. OpenJS Foundation seems doing great: https://openjsf.org/projects. The Python Software Foundation could not only host PyPI but offer assistance for the most important packages.
>> Of course you've no obligations for support or maintenance, but with increasing exposure responsibility grows as de facto ever more projects, people, softwares depend on you.
This is an oxymoron. Either you have obligations, or you don't. There's no such thing as having "no obligations" but also "growing responsibility".
I don't understand how you can possibly conclude that just because you've chosen to become dependent on some FOSS library, they owe you anything. You don't get to somehow impose obligations on other people by your choices. They get none of your profits, but they're somehow responsible to you for your business risks? Nonsense.
It is a condition of your use of the code that you've accepted its license, and FOSS licenses are CRYSTAL CLEAR (ALL CAPS) on what obligations or responsibilities the authors have towards you - none whatsoever. Your use of the software is contingent on your acceptance of that license.
If that lack of warranty poses an unacceptable business risk to you, go buy support. Pay a dev to fix the issues you're having, rather than inventing some fictitious responsibility they have to you to do it for free.
Yeah. Previous poster points out sources how a maintainer could get resources (money, support, etc). Maintainers may be exhausted or overwhelmed by the (imposed) responsibility / work. Actively acquiring those resources would just push that over the edge.
There is also the possibility that a maintainer simply doesn't care about what the community wants, it's his baby and he can do what he wants.
Forking a project is built-in by licensing. A lot of complaints, but those complainers don't fork. Why is that? Yeah right.
Side Note: Transferring projects to foundations etc with funding may be a solution for projects that are highly depended on and require active, reliable maintenance. They wont work well for innovation or experimentation. Just saying they are just a part of the equation and not the sole solution.
No. Even if it’s a central piece of infrastructure, any and all maintainership effort is still a token of good will of the maintainer – and needs to be appreciated, rather than expected.
If you need stronger guarantees, pay someone to deliver them.
A (hypothetical) professional propriety project at same scale would probably feed a handful of people, with much less stress. FOSS version is zero cash and exaggerated community demands. Dream job.
Counterpoint: in December, a Polish MP [0] has vibe-coded an interpreter [1] of a 1959 Polish programming language, feeding it the available documentation. _That,_ at least, is unlikely to have appeared in the model’s training data.
Not exactly a counterpoint, since nobody argued that LLMs can not produce "original" code from specs at all - just that this particular exercise was not clean room.
(although for SAKO [1], it's an average 1960 programming language, just with keywords in Polish, so it's certainly almost trivial for an LLM to produce an interpreter, since construction via analogy is the bread and butter of LLMs. Also, such interpreters tend to have an order of magnitude less complexity than emulators.)
It’s ironic that the very site in question, despite claiming XHTML compliance, is served as text/html instead of application/xhtml+xml, so the browser will never parse it as XML.
To quote [0]:
> All those “Valid XHTML 1.0!” links on the web are really saying “Invalid HTML 4.01!”.
Although the article is 20 years old now, so these days it’s actually HTML5.
Edit: Checked the other member sites. Only two are served as application/xhtml+xml.
That HTML5 was used in marketing doesn't make the technical term disappear. HTML5 is a bit more precise than HTML, it refers to the living standard that's currently in use, as opposed to HTML 4.01 and the previous versions of HTML.
It's not a technical term. Nowhere in the current HTML standard will you find a versioning of HTML. That's why it's now called a "living standard". You will never find a HTML6 or higher. That note you found is to help with any confusion.
You might be right, but we don't know yet. Microsoft said that for Windows 10.
You might also be right that the current Living Standard specification doesn't really call it HTML5, but you'll find many people writing HTML for a living say HTML5 to refer to it, and telling them that HTML5 doesn't exist doesn't really help and is a bit wrong too if you have a descriptive approach to languages.
The next version of html should be able to do all the http verbs -- get, put, patch, post, delete online, reactively without having to use a form.
There has to be a way to figure this out, even if it requires a transition period. The best time to plant a tree was twenty years ago, the second best time is now. These things belong in the core HTML standards, not a js library you need to include in your code.
Oh that and better controls and better defaults but I guess that is something individual web browsers can implement on their own?
> Although Microsoft claimed Windows 10 would be the last Windows version, eventually a new major release, Windows 11, was announced in 2021.
Where does the misconception come from? Do you know where I could read about it?
edit: it seems you are right, a dev said Windows 10 was the "last version of Windows" which was true but was interpreted as being an absolute statement when he really probably meant "at this time".
Yes, Jerry Nixon claimed something like that (he's not just a dev though). But Microsoft never confirmed that, so it's just a statement by one person.
The Wikipedia quote is problematic, because it doesn't reference any sources for their claim. Whoever the author of that paragraph, it's journalistically bad practice not providing any sources to that claim.
Yeah, we can find quotes from various articles on the web and I did between writing my comment and my edit (I was on the phone, I didn't bother citing them here).
Wikipedia articles should source everything indeed, it's not that it's bad practice, it's against the idea of Wikipedia not to.
Telling them HTML5 does exist does even more harm cause it doesn't exist. Telling them it does exist is entirely wrong and is even a false statement, is misleading and causes confusion.
I am right and I gave you the proof. Understanding what one means when mentioning HTML5 has nothing to do with technically understanding that there is no HTML5 standard.
Let's just say that I don't think the truths you are pushing are as absolute as you seem to think, and I think they are a reflect of how you view the world more than anything.
And that by correcting people that mention HTML5, you will probably just annoy people without achieving anything worth it. That would be true even if you are absolutely correct.
It's peak "well, actually", with the twist it might not even actually be.
That's not the truth, just my opinion, and I appreciate that you might not agree.
Note that OP didn't mention "The HTML5 Standard", they mentioned "HTML5".
I would rather be correct and annoy people than be wrong. It's fascinating to me today to see so many people allow "good enough" over correctness. It's a disaster waiting to happen.
For example, people get annoyed when I tell them not to put closing slashes on void HTML elements. They reply that it doesn't matter because it's in the standard that it's allowed so it's perfect HTML. What they don't bother to understand, despite my pointing to online documentation, is that placing closing slashes on some elements can cause harm and that no HTML standard tells you to put one there or has ever required it. Yet they argue with me anyway. Much like you argue with me about this. And that's when I stop.
At this point, closing slashes for void elements is coding style, exactly like white space we use for indentation. You can't be right because this is in opinion territory. Exactly like whether one should put semicolons or not in JavaScript when you have automatic semicolon insertion. Some people have strong opinions on the matter. Putting them has drawbacks, and not putting them too, and in both cases, readability and clarity, which is subjective, is a factor.
You are right that it has drawbacks and that it can bite. OTOH, people using closing slashes usually also quote all their attributes and will virtually never be bitten by this.
But people have backgrounds and habits, there's culture around a language like HTML, and these backgrounds are cultures have been shaped by XHTML.
Whether to put or not to put the slash is a healthy conversation to have and there are valid points for both, but if you are arguing like you are doing here for HTML5, considering "they don't bother to understand", you'll lose your arguments and people will find you annoying.
Some people feel bad about not closing br with a slash because it kinda feels like unmatched parentheses, or old malformed HTML from the 90's. That's not reasonable, but for the better or the worse, you can't just ignore this.
Some people sometimes write XML, and when they switch to HTML, their XML habits are there, and following habits especially when they are mostly harmless is efficient.
Some people write polyglot (X)HTML for some reason, and there the slash is needed.
There are reasons to put the slash, like there are reasons not to write it, and you can't just impose your truths like this.
- since the slash doesn't have any meaning in HTML, if you don't quote your attributes, you are at risk that your slash is attached to the value or your unquoted attribute: <br class=myclass/> ← uh oh, class = "myclass/"!
You can test this by visiting the following URL, and inspecting the content: data:text/html,<br class=myclass/>
Now guess what happens to the unquoted src attribute of the img tag followed by an unspaced stray slash… OTOH, you don't need to not quote the src attribute…
- it can give a false sense of correctness, one can reasonably consider that the closing effect of the slash is pure illusion and even potentially confusing.
For backward compatibility, a stray slash at the end of the start tag is ignored, not considered as an attribute that doesn't have a value, so there's argument to be made that it's still part of the syntax. You'll never have any issue if you always put a space before the slash (which most people who put the slashes do because of a silly bug in a browser that has not been relevant for a long time), or if you quote all your attributes.
I don't understand why they haven't decided to make the HTML5 parser parse <br class=myclass/> like <br class=myclass> but I guess it is what it is.
Your argument is bad, and you should feel, if not bad, then at least very silly. There is an HTML5 standard.
It was developed by browser makers with input from the community, published by WHATWG, and begrudgingly accepted by W3C in 2014. That's a fact. The HTML5 Recommendation exists.
That those people went on to continue to develop the standards further, as standards bodies are wont to do, and that they call their current work the "Living Standard" doesn't erase that fact, any more than the W3C's publication of the third edition of the PNG standard last summer means that earlier editions "don't exist".
Please point to any current edition of the HTML standard that is titled HTML5 published by WHATWG or the W3C. You can't. It's impossible. You can only point to past, out-of-date, no longer maintained publications. We're talking current standards. Not old ones.
This is either the dumbest thing I've heard all day, or the most dishonest thing. It's not even a good attempt at sleight of hand.
> Please point to any current edition of the HTML standard that is titled HTML5 published by WHATWG or the W3C. You can't. It's impossible.
No shit.
It's impossible because the current edition is very obviously not HTML5. Nor is it HTML 4.01. Or 2.0. It's the WHATWG's "Living Standard" that you very well know exists and have referenced by name in this thread.
If you want to make an argument for the non-existence of HTML6, then fine; you're making a sound, totally defensible argument that no such thing exists. (A strawman, because nobody here—besides you—actually mentioned HTML6, but a verifiably true fact nonetheless.)
But it makes for totally asinine argument for the claim that "There is no HTML5" and that it "doesn't exist". You'll take the W3C's stamp of approval? Great, it's right there—available for review now just as it was an hour ago, or at any other time after October 2014. This is an incontrovertible fact. Feel free to actually engage with this or any of the other facts you have been confronted with, rather than setting unsatisfiable goals like asking for the "current edition" that is "titled HTML5".
> Telling them HTML5 does exist does even more harm cause it doesn't exist. Telling them it does exist is entirely wrong and is even a false statement
> there is no HTML5 standard
Source: Literally all you, here, in this thread.
If you want to switch gears now and try rewrite the record and say that, actually, what you're really saying and have said all along is that HTML5 is no longer the latest Recommendation, go jump off a bridge.
You took things out of context. You aren't following along to what I replied to. The person I replied to said, "...so these days it's actually HTML5." And, in response to "these days", I said there is no HTML5. Which is true and you agree with.
So did the other guy. Thanks to you all for your support for web standards.
Basic truth: if you can't manage to accurately summarize your counterparty's position in a statement that ends with "you agree with <x>" and have that person agree that that's their position rather than feeling compelled to call you out as an intellectually dishonest sack of shit, then they don't actually agree with you, it's more than likely to be an accurate charge against you, and you should knock it off immediately.
> I said there is no HTML5. Which is true and you agree with.
Don't move the goalposts and take this as an opportunity to learn from the feedback you are receiving from several people here. Perhaps learn to be more accurate in what you say and if you fail to be accurate (which happens to everyone, we are all humans), admit it gracefully, and move on.
> Please point to any current edition of the HTML standard that is titled HTML5 published by WHATWG or the W3C.
But who said anything about "current edition"? Only you did. The fact that the current edition is not HTML 5 does not mean that the HTML 5 standard has stopped existing!
The poster I replied to did. You're like the other guy who jumped into a thread without following the context. Technical people know better than to do that. But I'm not here to teach people how to follow a thread. Please don't reply. I'm done here
> You're like the other guy who jumped into a thread without following the context. Technical people know better than to do that. But I'm not here to teach people how to follow a thread.
Can you stop being so antagonistic already? I have been following this whole thread since afternoon. We both began commenting on this post at about the same time. I regret to say that I have wasted my whole afternoon and evening on this thread. So regrettably I have been following the context very closely actually.
Most of your subsequent comments make sense but they also keep moving the goalpost which is frustrating. I mean it is easy to be correct if you constantly keep moving the goalpost. But we must go back to where this nuisance began. It began at https://news.ycombinator.com/item?id=46743683 when you said:
> There is no HTML5.
Do you admit that your orginal claim "There is no HTML5." was incorrect? If you don't admit that do you also think HTML 4.01 standard has stopped existing? What about C89? Has that also stopped existing? Just because there are newer standards and living standards, it doesn't mean that the old standards have stopped existing.
One of the annoying things about having a living standard is that it is difficult to implement a conforming version as additional updates means that you are no longer conforming.
Versioned standards allow you to know that you are compliant to that version of the specification, and track the changes between versions -- i.e. what additional functionality do I need to implement.
With "living standards" you need to track the date/commit you last checked and do a manual diff to work out what has changed.
reply