The AI hype is clearly harmful

Today, I think we’d do well by distancing ourselves from the AI hype. The slop is real, and it’s now obvious that it has created massive problems, and is likely to continue to do so. I don’t want to associate myself with something this damaging. Do you?

Shallow ethics

The issues are many.

For one, AI is fundamentally hostile against anyone contributing to the digital commons, by the fact that AI companies are massively freeloading on published source code, articles, images and any other creative content, without any thought of license constraints or contributing back. If AI companies, for example, were funding the open source ecosystems they are DOS’ing, or paying the artist they are copying, the situation might be marginally better. They’re not. This means the training material these companies are misappropriating should lead to their models being considered ethically tainted.

Next, we have to remember that these models are “grown” on whatever data is fed to them. If this input contains bias, lies inaccuracies or omissions, then the resulting model will reflect this. Garbage in, garbage out.

And even worse, the resulting model is opaque by design. Any rules, corrections, filters or other efforts to compensate for “weaknesses”, are under the full control of the entity growing the model. This puts a massive amount of leverage into their hands; they can color, censor or emphasize any political, social, cultural or even religious agenda they wish! The only choice we have is to accept the models as they are delivered, or to try to polish these turds so that they are a little better for some narrow use-cases. But at the core, it is still a turd.

Lock-in economics

And then there’s the economic aspect. Let’s keep in mind that there are massive investments in AI companies (in the order of 100’s of Bln USD announced), all of which is expected to turn a profit at some point.

We know how expensive it is to train a model, and how error prone it’s inferred output is, and even if some of this can be compensated by massively increasing the energy costs (e.g. by “agentifying” their products or adding manual rules to catch the worst output), these expenses WILL ultimately be put on the end-user. This is where the Return on Investment is extracted.

How this happens is not a secret:

  1. Create a product and hype it up.
  2. Get as many customers into a “lock-in” situation, where the cost of migration is as large as possible.
  3. When you have enough locked-in customers, start increasing the price.

The problem with this picture is that we know that the initial investments have been insane, and are scheduled to increase. We know that enormous amounts of the costs of these models have been externalized.

(e.g. in the form or excessive use of water and fossil fuels needed to power these systems, or the societal damage that happens when people are replaced by LLMs, or the opportunity cost IT students pay when they realize they won’t find any work in the field they studied for, or the lost business for artists, or wasted time spent on compensating or second-guessing output that one is unsure includes any hallucinations).

We also know who is going to pay in the end – the users and businesses who decide to go “all-in”. At some point, these people will have to ask themselves:

How much am I – or my customers – willing to pay for this slop?

– Random Hapless Rube

Hostile rhetorics

AI proponents also tend to use cheap rhetoric to convince other to buy into their message. Why is that necessary? Pushing a panic-like FOMO messages onto unsuspecting techno-optimists is cruel and unnecessary. There’s no need for manipulative language like “Embrace it or get out“. People with good intentions don’t have to resort to hostile language like this!

The AI hype is clearly cruel, irrational and ignorant of the real consequences it creates, and therefore needs to be shut down, or at minimum, put AI on pause.

This particular lemon is NOT worth the squeeze.

If we continue to encourage this insanity, we’re complicit in the waste of resources, attention, life and humanity. THIS IS NOT OKAY.

Favorite resources

Here are some of the resources I’ve used to learn more.

Podcasts

Long form audio or books

Fun & Animation

Further resources

Open Source components you depend on are not “third-party components”

Third party

– adj. relating to a person or group besides the two primarily involved in a situation

“third-party suppliers”

Encyclopedia.com

When using the term “third-party”, we usually refer to someone who is not part of an agreement, but who may still be influencing (or be influenced by) this agreement. When this party is an Open Source project you depend on directly, I propose we use term “second-party.” Here’s why.

Looking at third-party software suppliers, they often have a few qualities that are common between them.

  1. The first and second party may not be free to use this component without triggering terms in the contractual agreement (e.g. there may be terms governing how many individual users are allowed to use the component, leading to an increase in fees if this increases.)
  2. The first and second party may be allowed to learn or introspect the third party component in non-invasive ways, such as reading any supplied documentation, or through basic use of the component. But this usually disallows more intrusive tools and methods used to figure out how a component preforms – like reverse-engineering, de-compiling or instrumentation. Source code is usually not available for inspection.
  3. The first and second party may not permanently fix, improve or make other non-trivial changes to the third party component, beyond basic configuration – even if source code has been made available.
  4. The first and second party may not share any changes made to the third party component.

This list is looks quite a lot like the four freedoms of the Free Software Definition, doesn’t it? It is.

When you (as the first party) decide to use an open source component, you are accepting a license agreement offered by the component author or owner. When you do, they (in a sense) become the second party in a new relationship, where the terms of the agreement are laid out in this license, and with this, you gain privileged access to the Open Source component in ways that you – by definition – will never get from an agreement with a non-Open-Source component supplier. Privileged access and rights as laid out in the Free Software Definition.

And from the component author’s perspective, they (your second party) are still likely to appreciate your well-reasoned contributions that rainy day when you eventually decide to do contribute. You may be using their software in ways that exposes it to new situations which may lead to experiences to learn from and later used to improve the code you both depend on.

But while most users of Open Source components don’t exercise the rights afforded by the licenses they accept, they still retain these rights. They are still allowed to inspect, fix and share their improvements at any time, without asking for permission. And this privilege will still be there on that rainy day when you really need it.

Suppliers, colleagues or volunteers?

From the Open Source developer’s perspective, it may look different. You are maybe one of hundreds or thousands of users, but your constructive feedback and support is still appreciated. You are also a second-party to them, Both of you care about the long-term sustainability and success of the same project. The difference is one of scale – you may be second-party to hundreds of projects. They may have one or two orders of magnitude more.

So for second-party relationships to work at this scale, we should remind ourselves that constructive relationships like these, should be treated as an ongoing, long-term, low-frequency activity.

When tending long-term relationships with where good communication is important, it helps that we use the appropriate terms. If you treat your colleague the same way you treat a stranger, you’ll eventually find that this colleague becomes a stranger – this can be troublesome that day you need them the most!

So when an Open Source author says they are not your supplier – take the hint! If you depend on them, they are something closer to a colleague, or partner. If they have a bad day, you may be affected in ways similar to when a colleague has a bad day – If a colleague struggles with burnout, would you treat them as a “third party”?

Second-party

To remind ourselves that we’re in a low-frequency long-term relationship, let’s adopt terms like “second-party component”, developed in a “second-party project” with help from “second-party developers”. This is especially important when referring to people and projects we depend on directly. Even the term “second-party suppliers” could be used if you are paying for this privilege.

And while low-cost reminders like “thank you” or “I need you” are just as necessary in Open Source relationships as they are at work and at home, we can also keep an eye out for our second-party colleagues. If you have resources the second party needs to stay around in the long term – make sure to support them before it’s too late! You can even turn your second-party projects into your second-party suppliers with communication, collaboration and funding.

After all, when you depend on them, you might as well rely on them.

A Vocabulary for a Post-CRA Open Source Age

With the EU Cyber Resilience Act (CRA) arriving in 2024, software in general is – for the first time – about to be legislated.

This means any business who wishes to place software on the EU market will have to comply to new cybersecurity demands, and by implication this will affect tens of thousands of Open Source authors and maintainers indirectly.

A couple of ramifications are safe to expect.

  1. Businesses are now required (after a risk assessment) to have a full overview of what their software is and is composed of – including their Open Source transitive dependencies – “all the way down” – in order to ensure they have no vulnerable components in use.
  2. With well over 80% of software in use depending on Open Source ecosystems, authors, developers and maintainers, FOSS communities should expect to get a level of scrutiny much greater than before, and expect to make available whatever metadata that their downstream users are obliged to have.
  3. Most businesses will (eventually, hopefully) realize that they depend on components and people that are in need of their support.

With this in mind, I would like to propose the adoption of an updated vocabulary to use in this new reality. This is for helping management of these businesses make informed decisions that are both beneficial for the continued sustainability of their commercial activity, and likewise for the Open Source projects, authors and communities their business depends on.

A New Open Source Vocabulary

Invest on Return (not Return on Invest)

The idea that a business should get a “Return on Investment” (ROI), is completely backwards when it come to Open Source software. Companies depending on Open Source components already have their return by the fact that they are already using these components in their value-chain, and therefore already depending on these projects.

Instead, think of FOSS funding as an investment in the continued well-being of these projects, just as much as it is sensible in investing in the continuation of any profit-bringing venture. The business is already benefiting from the Return, and the next step is to Invest in the reliability of this source of income – Invest on Return (IOR).

Source: Conversation with Chad Whitacre on the SustainOSS podcast episode 213 (starting at 13m58s).

Open Source Sustainability

Open Source Sustainability is about ensuring the continued responsiveness of component project authors, so they both are available and capable to fix bugs and respond to vulnerabilities as the world proceeds. If a project owner is burned out or alone (or worse!), this situation directly impacts the risk landscape of their downstream users, and should therefore be mitigated. A recent example of this can be found in the revelations of social engineering leading to the 2024 xz-utils hack.

To mitigate this, downstream users should make Open Source Sustainability a part of their operating budgets and costs.

Open Source Bystander Effect

The effect seen when everyone is waiting for someone else to make the first move (or accept a burden) to support a resource-starved Open Source project. This is a consequence of businesses having never felt the need to involve themselves (in a budgetary sense) in Open Source communities, with the predictable result that these Open Source projects and communities have become so resource-starved that many just abandon them, and thereby worsening the risk and reliability landscape for everyone. By waiting for someone else to “fix the problem” instead of showing leadership, businesses inadvertently hurt themselves through inaction.

To mitigate this, businesses and users can familiarize themselves with their own dependency tree, and look for indicators of any projects needing support. This may include financial, software development, marketing, project management, documentation or any of a number of issues. Reach out to the project owners, and have a continued discussion on how the business can help — and if repeated attempts fail, then it may be time to consider taking over or even forking the project.

Open Source Colleague

An Open Source author, developer or maintainer that the business depends on. If they have a bad week or month, and the business is in risk of consequences because of this, then the business should consider treating them as any of their regular highly competent colleagues.

If the business decides to support their Open Source Colleague in a sustainable way, they may become an Open Source Supplier. Until then, they are Open Source Volunteers, with the risks and liabilities this entails.

Open Source Supplier

An author, developer, maintainer or contributor working on an Open Source project that is financially supported in a way that is sustainable in the long-term. This is an especially useful term to use when taking into account the requirements for sustained support and updates laid out in the EU Cyber Resilience Act recitals 60-63. In this context, I mean “Supplier” and “Manufacturer” to be equivalent.

Open Source Volunteer

An author, developer, maintainer or contributor that is volunteering for an Open Source project. This work may or may not happen in a way that unsustainable in the long run.

Second-party component

A component depended on or used in a product, that is licensed with an OSI approved Open Source license. Since the company (“first-party”) has accepted the FOSS license, they are now – in a sense – associates in the further development of this component. They both gain the benefits of the license, and are subject to the obligations of it.

While the obligations are “cheap”, they still involve considerations around project health, interaction with volunteers and their long-term sustainability, and using the term “Second-Party” can help remind us to help these projects’ longevity.

Software Sustainability (Budget line item)

A budget line item dedicated to supporting the authors and projects behind components that the business depends on. This is spending money on the continued and sustainable reliability of software components that the business actually uses. This is not sponsorship, not charity and not “giving back to the community”, but rather a prudent act of self-interest, since “freeloading” (using Open Source projects without contributing to their sustainability) may expose the business to much more expensive risks.

Third-party component

A component depended on or used in a product, where the component owner does not gives all four freedoms the Open Source definition affords to the user (Use, Learn, Modify, Share), or where the component is not directly or transitively in use by the business.

Partnership (not Sponsorship)

When considering business-critical Open Source projects or ecosystems, a business would do well to treat this relationship as a partnership. For the project or ecosystem user (the business) this partnership is already beneficial, and since the business has accepted the terms of their Open Source license, they have demonstrated that they depend on the continued reliability of this project or ecosystem. Partners are not expected to be bystanders, but rather take an active role in their partner’s well-being and long-term health.

Consequently, if an Open Source developer or project (or ecosystem contributor) approaches the business for Sponsorship, they are making a mistake! The business is already a partner, and should expect to be treated accordingly.

Final words

The vocabulary proposed here is meant to help business stakeholders and decision-makers to inform themselves enough to prompt a re-evaluation of their relationships with their upstream open source component providers. The first step in this awareness-raising, is to introduce some new useful concepts that can help them see the nuances and realities of the landscape they are operating in. I hope that you, the reader, agree and decide to adopt this vocabulary in your daily dealings.

A FOSS Ecosystem Checklist for the Benefit of Maintainer Sustainability

  1. Maintainers and authors are found everywhere throughout our dependency trees. This includes the authors of the tooling others use for maintaining, building, testing, writing and running the infrastructure they depend on. Even maintainers depend on other maintainers.
  2. Maintainers’ mental health and well-being is also a dependency.
  3. So is their outlook on the sustainability of their projects, both in personal, technical, systemic and economic respects.

This means that personal, technical, systemic and economic well-being in the end are all actual and real dependencies for the businesses that rely on these people and their projects.

What can an ecosystem provide to make the lives of these maintainers easier in this regard?

Here are a few suggestions.

  1. Ensure that sustainability metadata fields (intended to be kept up-to-date by maintainers and authors) is specified and made available. These fields may include…
    • Project life-cycle status (supported, support-period end date, unsupported, replaced, discouraged, abandoned).
    • Project sustainability status (available for adoption, needs help, is available for a managed hand-off, requests funding, under custodianship).
    • And related metadata, like…
    • Links to funding services that are available or preferred.
    • Recommended alternative projects.
    • Relevant CE conformity information.
    • …or whatever else helps end users and businesses decide to support their open source colleagues and second-party component providers.
  2. Ecosystem tooling and infrastructure communicates this metadata to their downstream users and consumers.
  3. (Bonus) Up-river maintainers are invited to events that are specifically suited for their needs, free of cost, where they may learn and share new developments from and with their peers.

But why?

Mostly because businesses usually don’t have the tuits to figure out this information (even if it is available). Lowering “the bar for caring” with a few metadata fields may at least increase the possibility for these businesses to make a difference for their upstream component maintainers— a possibility that for many won’t exist unless their ecosystems help by enabling the communication of project sustainability metadata.

Perl Toolchain Summit 2023 in Pictures

PTS2023 was this time in Lyon, France; Organized primarily by Philippe “BooK” Bruhat and Laurent Boivin.

This event wouldn’t be possible without it’s sponsors, Booking.com, Deriv, Grant Street Group, FastMail, cPanel, Perl Careers, MaxMind, Fastly Inc., Perl Maven, OpenCage, Perl Services, Oetiker+Partner, and Procura. Thank you!

All pictures in this gallery are ©2023, Salve J. Nilsen, CC-BY-NC-4.0. Please reach out to me on Mastodon if you consider using any of these in a commercial setting.

NIS2 and CRA – EU LAWS that may kill Open Source?

New EU laws are coming that will affect Open Source. Should we worry?

One is the NIS2 directive, which cares about the state of computer and software security in sectors that work on critical infrastructure. Another is the Computer Resilience Act, which tries to improve the security landscape around network-connected devices.

Depending on how these two directives are implemented, and how companies and communities react, this may either lead to increased funding for badly needed efforts in resource-starved Open Source communities — or — motivate affected businesses to move in the direction of software mono-cultures and away from the culture of permission-less innovation that Open Source software developers have practiced for decades.

Of course, these laws aren’t finished yet. NIS2 has to be implemented in local law, and the CRA is (as of this writing) still a work in progress. While the situation may still change, I believe there are a couple things Open Source communities can do to prepare already now.

  • Ensure supply-chain security procedures are in place and all issues resolved.
  • Create easy-to-find-and-use documentation directed at business managers that are forced to be introduced to their new Open Source colleagues.
  • Clarify project adoption and takeover procedures so the ones with a bus-factor of zero get a chance to be revived.
  • and more…

I’ve summarized some of my thoughts on this in the presentation I gave at the Perl Toolchain Summit 2023 in Lyon, France, on April 27th 2023, embedded below. (Edit: The slides from this presentation can be found under the CPAN Security Group list of presentations.)

Presentation about NIS2 and CRA at PTS2023

As a background and preparation for this talk, I and the Norwegian chapter of the Internet Society organized a fireside chat on April 22nd 2023.

In this conversation, we explored these laws (and others) both from a legal, security and Open Source perspective. The panel consisted of Simon Phipps (Director of EU Policy at the Open Source Initiative), Kaspar Rosager Ludvigsen (Lawyer and PhD candidate, working on the Cyber Resilience Act), Hans-Petter Fjeld (Senior Security Analyst at Defendable), and myself (Community activist and organizer in the Perl and Raku communities).

ISOC Norway fireside chat with Simon Phipps, Kaspar Rosager Ludvigsen, Hans-Petter Fjeld and Salve J. Nilsen

This event was graciously funded with a grant from NUUG Foundation.

If you find these topics interesting, feel free to reach out to me on Mastodon!

A FIXIT-dive into an old CPAN module

Let’s have a thought experiment. Assume there is an Open Source-licensed Perl module published on CPAN that you care about, and that hasn’t had any updates in a very long time – what are your options?

In this blog post, I’ll take a dive into this problem, and use the Geo::Postcodes::NO module as an example. As of this writing, the module version is 0.31, and it’s most recent release was in September 2006. Continue reading A FIXIT-dive into an old CPAN module

Perl’s Postmodern Metanarrative

Now and then, it’s good to remind ourselves what “There Is More Than One Way to Do It” means.

A long time ago, Larry Wall said Perl is the first postmodern programming language. I’ve thought about this – asking myself what does that even mean?

Today I think this is just a nice way of saying that Perl has no metanarrative. Let’s unpack this.

Continue reading Perl’s Postmodern Metanarrative

Let’s encrypt, by random encounter

Things seldom happen by themselves, but when they do, there is luck, help and sweat involved. — Unknown

If you ever find yourself at the Chaos Communication Congress, you may eventually snap out of your awestruck haze to realise you probably want a memento to bring home. This happened to me at last year’s event, and while I usually go for a t-shirt or a hoodie, this time I found something unexpected and much, much better!

Continue reading Let’s encrypt, by random encounter