Planet JM

Tag: ai native

  • Open Source in a Post-Agentic World

    I haven’t seen so much anxiety permeating the world of technology since the dot bomb implosion of 2000-2001. And anxiety is everywhere right now. Software developers are worried about their jobs ending. Venture capitalists are wondering whether they will even be needed when 2 vibe coders can literally build complete apps in days or weeks without any funding. Startup founders are worried about building a “moat” around their business when autonomous agents can reverse-engineer and reproduce their features at blinding speed. And open source maintainers are worried about keeping their heads when autonomous agents are sending an inordinate number of pull requests, many of which are substandard and should be disregarded.

    A number of people have opined that “the end of open source is nigh”. One article from The Register highlighted one example that demosntrated how agentic development could change the face of open source forever by killing the very essence of software licensing, open source and otherwise. The choicest comments came from Bruce Perens, who declared that “the entire economics of software development are dead, gone, over, kaput!” To demonstrate the degree of change, Perens enlisted the aid of an agentic engineering platform to reverse engineer and copy an SRE platform, declaring, “I am the Harry Potter of software!” waving a magic wand and summoning a new platform into being. Dan Lorenc, co-founder and CEO of Chainguard, was a bit more circumspect in his outlook, offering that open source platforms would get much needed improvements, and that agentic engineering is great at one-shot software outcomes, but not so great at maintaining efforts that add value over time. In the end, nobody really knows, but hey, that never stopped me before! So let me offer my take, which you no doubt were awaiting with bated breath…

    No, this is not the end of open source

    Let me just cut to the chase and say that open source is not ending, not by a long shot, but open source will definitely change and may not be recognizable to those of us who grew up on hand-crafted, artisanal (organic!) source code. Licensing will almost certainly change, and the medium of exchange, source code, will undergo significant change as well, with the points of collaboration more resembling writing tutorials and language exams than software. I went through some of this in my previous posts about upcoming changes, including the potential death of source code, the inevitable changes to business models, and the increasing importance of open source platforms. There are valid concerns to be sure, and change can be difficult, especially when assymetric change affects people differently depending on where they are in a given ecosystem or point in technology lifecycle.

    How Will Open Source Change?

    I have been pretty adamant over the past few months that open source and innersource, while about to undergo significant change, would emerge as more important than ever. Ok, so what exactly will change and how? How is open source going to survive, and what will it look like?

    For one thing, we always wanted software tools to progress to the point where the developer interface was not something that required arcane and esoteric syntax, but something that more resembled human language. LLMs and agentic tools are the great enabler here. This is to be celebrated. We should be thankful that we can summon systems into being without worrying about obscure reference pointers, poorfly implemented semaphores, and race conditions. I’m making the assumption that the current crop of agentic systems are good enough to avoid those mistakes or correct them if needed.

    What this means in practice is that well-written instructions, user stories, and specifications will be the driving force of all software development. The implications of this are momentous – your philosophy and comparative literature graduates may be better at this than your friends who are well-versed in a particular language syntax. Collaborating on prompts and specifications will look much different from today’s code pull requests, but the act will be very similar: developers with different ideas will be able to script them out and try them in record time, comparing results and deciding what is the best solution. Once they’ve written and testing the specifications and program narratives, they may not need to even submit the pull requests – they’ll just have their agents to that. And who is reviewing the pull requests as submitted? Those would be other agents. The humans in the loop will be evaluating results, comparing multiple tests and determining which is the best solution. Because writing and testing code is now as easy as a simple command to multiple agents, open source collaborators will be able to run as many concurrent tests as they want, depending on their infrastructure capacity. The collaboration will still be there. The ideation will still be there. But the implementation will change.

    I have seen some developers question why we even need reusable software when agents can simply rewrite anything at will. This can get tricky, because many simple, single-maintainer libraries could be easily rewritten by an agent in the course of developing software. Given the number of single-maintainer libraries that involve burned out developers who don’t get paid for their work, this may not be a bad thing. But that doesn’t mean that maintainers will simply go away. It means that maintainers may not care about single libraries anymore, but they will be managing and maintaining tools suites, large infrastructure systems, and large platforms. Single maintainers will no longer manage just a library, they will band together and manage technology ecosystems, and agentic engineering platforms will enable them to do that more effectively than ever.

    Everything Comes at a Price

    This is not to say that everything will be peachy keen with no consequences. For one thing, our massive data center buildout will have untold environmental ramifications, and as developers, we would be remiss if we did not account for the external costs of our work. Our agentic systems also come with systemic bias that is difficult to foresee and weed out as we build interfaces meant for humans. And then there are groups of workers who will be out of a job if current trends continue. And then, of course, our new agentic systems have already been used to conduct mass surveillance and war at an industrial scale. These are just some of the societal costs that will come with our “great transformation”, but there are other, smaller scale costs as well, and those are also worth exploring.

    We have already seen open source maintainers inundated with “slop PRs” submitted by agents. Some maintainers have elected to simply close their projects to all outside pull requests. You may call them luddites or make fun of them, but I have great sympathy, because they never signed up for this. It’s clear to me that the age of personally reviewing every incoming pull request is probably drawing to a close sooner rather than later, but right now we live in a liminal period where we’ve only begun the transition. Until we work out a community standard for both submitting and receiving agentic pull requests, we’re going to be awkwardly moving forward, often blindly, as best as we can muster, feeling our way through. This will no doubt accelerate the burnout rate of open source maintainers, and some projects will likely disappear as a result, bringing about some degree of chaos to the ecosystem.

    As I like to tell my kids, everything comes at a price. There are going to be some painful transitions, and not everyone will make it through unscathed. Some people will lose their jobs and decide that this agentic world isn’t worth the trouble. Some will be energized by how quickly they can now build things. And still others will suffer from “AI exhaustion” and “AI mania”, two phenomena that we’re only just now starting to see. We still don’t quite understand the human cost of subjecting people to these tools. But I don’t really seen an alternative at the moment – the world seems to be rushing headlong towards the great agentic transformation, and I don’t see much standing in the way. My advice is to get used to it and learn as much as possible about it.

  • AI Native and the Open Source Supply Chain

    AI Native and the Open Source Supply Chain

    I recently wrote 2 essays on the subject of AI Native Automation over on the AINT blog. The gist of them is simple:

    It’s that latter point that I want to dive a bit deeper into here, but first a disclaimer:

    We have no idea what the ultimate impact of "AI" is to the world, but there are some profoundly negative ramifications that we can see today: misinformation, bigotry and bias at scale, deep fakes, rampant surveillance, obliteration of privacy, increasing carbon pollution, destruction of water reservoirs, etc. etc. It would be irresponsible not to mention this in any article about what we call today "AI". Please familiarize yourself with DAIR and it's founder, Dr. Timnit Gebru.

    When I wrote that open source ecosystems and InnerSource rules were about to become more important than ever, I meant that as a warning, not a celebration. If we want a positive outcome, we’ll have to make sure that our various code-writing agents and models subscribe to various agreed-upon rules of engagement. The good news is we now have over 25 years of practice for open source projects at scale that gives us the basis to police whatever is about come next. The bad news is that open source maintainers are already overwhelmed as it is, and they will need some serious help to address what is going to be an onslaught of “slop”. This means that 3rd party mediators will need to step up their game to help maintainers, which is a blessing and a curse. I’m glad that we have large organizations in the world to help with the non-coding aspects of legal protections, licensing, and project management. But I’m also wary of large multi-national tech companies wielding even more power over something as critical to the functioning of society as global software infrastructure.

    We already see stressors from the proliferation of code bots today: too many incoming contributions that are – to be frank – of dubious quality; new malware vectors such as “slopsquatting“; malicious data injections that turn bots into zombie bad actors; malicious bots that probe code repos for opportunities to slip in backdoors; etc – it’s an endless list, and we don’t yet even know the extent to which state-sponsored actors are going to use these new technologies to engage in malicious activity. It is a scary emerging world. On one hand, I look forward to seeing what AI Native automation can accomplish. But on the other, we don’t quite understand the game we’re now playing.

    Here are all the ways that we are ill prepared for the brave new world of AI Native:

    • Code repositories can be created, hosted, and forked by bots with no means to determine provenance
    • Artifact repositories can have new projects created by bots with software available for download before anyone knows no humans are in the loop
    • Even legitimate projects that use models are vulnerable to malicious data injections, with no reliable way to prove data origins
    • CVEs can now be created by bots, inundating projects with a multitude of false positives that can only be determined by time-consuming manual checks
    • Or, perhaps the CVE reports are legitimate, and now bots scanning for new ones can immediately find a way to exploit one (or many) of them and inject malware into an unsuspecting project

    The list goes on… I fear we’ve only scratched the surface of what lies ahead. The only way we can combat this is through the community engagement powers that we’ve built over the past 25-30 years. Some rules and behaviors will need to change, but communities have a remarkable ability to adapt, and that’s what is required. I can think of a few things that will limit the damage:

    • Public key architecture and key signing: public key signing has been around for a long time, but we still don’t have enough developers who are serious about it. We need to get very serious very quickly about the provenance of every actor in every engagement. Contributed patches can only come from someone with a verified key. Projects on package repositories can only be trusted if posted by a verified user via their public keys. Major repositories have started to do some of this, but they need to get much more aggressive about enforcing it. /me sideeyes GitHub and PyPi
    • Signed artifacts: similar to the above – every software artifact and package must have a verified signature to prove its provenance, else you should never ever use it. If implemented correctly, a verified package on pypi.org will have 2 ways to verify its authenticity: the key of the person posting it, and the signature of the artifact itself.
    • Recognize national borders: I know many folks in various open source communities don’t want to hear this, but the fact is that code that emanates from rogue states cannot be trusted. I don’t care if your best friend in Russia has been the most prolific member of your software project. You have no way of knowing if they have been compromised or blackmailed. Sorry, they cannot have write access. We can no longer ignore international politics when we “join us now and share the software”. You will not be free, hackers. I have to applaud the actions of The Linux Foundation and their legal chief, Michael Dolan. I believe this was true even before the age of AI slop, but the emergence of AI Native technologies makes it that much more critical.
    • Trust no one, Mulder: And finally, if you have a habit of pulling artifacts directly from the internet in real time for your super automated devops foo, stop that. Now. Like.. you should have already eliminated that practice, but now you really need to stop. If you don’t have a global policy for pushing all downloads through a centralized proxy repository – with the assumption that you’re checking every layer of your downloads – you are asking for trouble from the bot madness.
    • Community powered: It’s not all paranoid, bad stuff. Now is a great opportunity for tech companies, individual developers, enterprises, and software foundations to work out a community protocol that will limit the damage. All of these actors can sign on to a declaration of rules they will follow to limit the damage, quarantine known bad actors, and exchange vital information for the purpose of improving security for everyone. This is an opportunity for The Linux Foundation, Eclipse, and the Open Source Initiative to unite our communities and show some leadership.
    • Bots detecting bots: I was very hesitant to list this one, because I can feel the reactions from some people, but I do believe that we will need bots, agents, and models to help us with threat detection and mitigation.

    I have always believed in the power of communities to take positive actions for the greater good, and now is the perfect time to put that belief to the test. If we’re successful, we can actually enjoy revamped ecosystems that will be improved upon by our AI Native automation platforms. If successful, we will have safer ecosystems that can more easily detect malicious actors. We will also have successful communities that can add new tech capabilities faster than ever. In short, if we adapt appropriately, we can accelerate the innovations that open source communities have already excelled at. In a previous essay, I mentioned how the emergence of cloud computing was both a result of and an accelerant of open source software. The same is true of AI Native automation. It will inject more energy into open source ecosystems and take them places we didn’t know were possible. But what we must never forget is that not all these possibilities are good.