OpenEoX to Standardize End-of-Life (EOL) and End-of-Support (EOS) Information

That EoX logo though.<p>Every organization or committee that designs a logo should be legally required to have at least one teenager on the board to prevent accidental goatse or other inadvertent blunders.

Htm. So, how does this compare, and&#x2F;or is different from <a href="https:&#x2F;&#x2F;endoflife.date" rel="nofollow">https:&#x2F;&#x2F;endoflife.date</a>?

I think it will take a while for people to realize this effort looked great, but wasn&#x27;t the right approach. Or no silver bullet, at least.<p>The presentation with a simple diagram that combines this data with an sbom to yield &quot;information&quot; gives me navel gazing vibes of UML being <i>the future of coding</i>.<p>Just as <i>architecture</i> didn&#x27;t equate to well designed and maintainable software, I fear this initiative won&#x27;t fix horribly outdated and vulnerable deployments. Software life cycle, deprecation, abandonment, supply chains are mostly a process problem, standards and technology won&#x27;t fix that.

How does this relate to the OWASP&#x2F;Ecma Common Lifecycle Enumeration Specification (<a href="https:&#x2F;&#x2F;tc54.org&#x2F;cle&#x2F;" rel="nofollow">https:&#x2F;&#x2F;tc54.org&#x2F;cle&#x2F;</a>)?

In my experience, many software projects become abandoned and no notice is given. I don&#x27;t see how this standard helps in such cases.

JEDEC has long maintained an EOL&#x2F;EOS standard for semiconductors. This was a big part of a previous PM gig. Sounds boring, and it was. But having a process kept us out of serious hot water.

An SBOM-like approach to EOL&#x2F;EOS issues is on the way.