Blog

Change Agents in Large Organizations
“Everybody has plans until they get hit the first time.” — Mike Tyson

An economist was once asked, “If you were stranded on a desert island, how would you survive?” The economist pondered this great question for some time and then proudly ventured his answer: “Assume a perfect world…” — old joke about economists

I am not known for my love of business or management books; quite the opposite, actually. When I try to articulate why, it generally comes down to boredom and a decided lack of enthusiasm for the subject. It’s not that I don’t appreciate the appeal of business topics or the act of conducting it. Far from it. It’s more that there’s an utter futility to the idea that we can do it better. I led off this post with the 2 quotes above to illustrate my reasoning. They seem to come from very different points of view, and yet they are in my mind very much related:
- Business books are not reflective of lived experiences or real world incentives, just like the economist in the above example, and…
- They’re hopelessly naive and unable to account for what happens the first time a practitioner gets “punched in the face” (not literally, of course, or at least not usually)
Both quotes illustrate the difficulty of putting a plan into action, either because you didn’t account for resistance (Mike Tyson) or the realities of the real world constraints (the economist). I dislike business books for the same reason I dislike management consultants, strategists, market analysts, pundits, and any other pointy-haired expert who tries to tell me how to do my job better: because their words prove to be almost useless against the realities of functioning, much less thriving, in a real-life bureaucratic system. With that in mind, I’m now going to do what I probably never should: give advice on how to be a change agent in large bureaucratic organizations. Given what I wrote above, you could be forgiven for asking, “Why?” The answer is rather simple: despite all my experience which tells me I should really know better, at the end of the day, I naively follow an insatiable desire to drive change. Knowing better or not, it doesn’t stop me from trying. The act of futile resistance against the borg is buried deep, deep inside my psyche. It’s terminal, I’m afraid.

Never, Ever be a Change Agent

The first thing to know about being a change agent is to not be one. Just don’t do it. No one is ever going to congratulate you on your futility or give you an award for repeatedly beating your head against countless walls. Just don’t. The best that can happen is that somebody else advances themselves based on your ideas, picks up the pieces after you’ve been beaten to a pulp, and then gets the accolades. The worst that can happen is that nobody every listens to you at all and you toil away in silence and isolation, walled off from doing any real damage. Note that getting fired is not the worst outcome. In fact, it’s a great way to confirm you were on to something and extricate yourself from a terrible situation, preventing you from expending energy on fruitless efforts that nobody will acknowledge. Getting fired is a merciful end. Futilely trudging along with no end in sight? Now that’s inhumane torture.

To successfully make changes in an organization, think very carefully about who you need to convince and bring along for the ride: your upper management. That’s right, the very people who have benefited from the existing systems. Remind me, what is their incentive for changing? Their interest goes only as far as their incentives. To be a successful change agent, you have to convince them that change is in their interest, and that’s a pretty high bar. To be successful, your leaders have to be in such a position that they see an urgent need for change that will benefit the organization – but also simultaneously benefit them. The stars have to be aligned just so, and you will need to take extra care to spot the right opportunities. I cannot emphasize this point enough: the stars do not tend to align except in particular circumstances. You have to learn to be very adept at spotting those particular circumstances. As I said, most of the time it’s not worth it.

For the remainder of this post, I’m going to assume that you are disregarding my hard-earned, well-considered advice and have chosen to proceed on this adventure in masochism.

Ok, Fine. You’re a Change Agent. Now What?

The first thing to know about large organizations is that they never fail. Where most change agents go wrong is they erroneously assume that organizations are failing. If you are asking the question, “why is this organization failing?” know that you are asking precisely the wrong question. Organizations behave exactly as they are designed, and one thing they are designed to do is to resist change. When you zoom out and consider the possible outcomes of an organization’s lifecycle, this is not a bad thing. A long-lived organization will need to be able to survive the whims and myopia of misguided leaders as well as the ups and downs of its industry and market. Resistance to change is a design feature, not a bug. Organizations are so good at self-perpetuation that they are quite adept at identifying and neutralizing potential threats, ie. people that want to change things. How this happens depends on the environment, from putting you on projects that keep you tied up (and away from the things management cares about) to just flushing you out entirely if you prove too meddlesome.

This is why I get annoyed with most attempts to affect change: they assume that organizations need to be better, and they assume that their pet project is a way to do that. Thus we have movements like Agile and DevOps, which started off as a means to change organizations and eventually were subsumed by the beast, becoming tools that organizations use to perpetuate their existence without actually changing anything. The authors of the Agile manifesto wanted to change how technology worked in organizations, but what they actually did was give large organizations the language they needed to perpetuate the same incentive structures and bureaucracy they always had. DevOps was going to put Agile methodology into practice and empower (whatever that means) technologists to take a larger stake in the business. I’m pretty sure CIOs are still laughing about that one. In the meantime, we still get design by committee, the inability to make decisions, and endless red tape to prevent change from actually happening. Again, this isn’t necessarily bad from the perspective of a business built to last; it’s just really annoying if you expect things to move after you push. My advice: adjust your expectations.

Incentives and Human Behavior

The reason most change initiatives fail is because they don’t account for the reality of incentives and the influence of human behavior. Large organizations have evolved intricate systems of carrots and sticks to reward certain behaviors and punish or at least discourage behaviors deemed impolitic. Want to know why teams don’t collaborate across organizations? Because they’re not rewarded for doing so. Why do leaders’ edicts get ignored? Because teams are incentivized to stay the course and not switch abruptly.

Agile failed in its original intent because it naively assumed that incentives would be aligned with faster development and delivery of technology. What it failed to calculate was that any change in a complex system would incur a premium cost or tax for the change. Any change to a legacy system with complex operations will have unknown consequences and therefore unknown costs. The whole point of running a business effectively is to be able predict P&L with some accuracy. Changes to legacy systems incur necessary risk, which disincentivizes organizations from adopting them at scale. Thus agile morphs from accelerated development and delivery to a different type of bureaucracy that served the same purpose as the old one: preventing change. Except now it uses fancy words like “scrums”, “standups”, and “story points”. As Charles Munger put it, “show me the incentives, and I’ll show you the outcome.” If the avoidance of risk is incentivized and rewarded, then practitioners in your organization will adopt that as their guiding principle. If your employees get promoted for finishing their pet projects and not for collaborating across the organization, guess what they will choose to do with their time?

It’s this naive disregard of humanity that dooms so many change initiatives. Not everyone wants to adopt your particular changes, and there may be valid reasons for that. Not everyone wants to be part of an initiative that forever changes an organization. Some people just want to draw a paycheck and go home. To them, change represents risk to their future employment. Any change initiative has to acknowledge one universal aspect of humanity: to most people, change is scary. Newsflash: some people don’t tie their identities to their jobs. I envy them, honestly. And still others aren’t motivated to change their organization. They are just fine with the way things are.

Parasite-Host Analogy

And how do organizations prevent change? By engaging in what I call the “host immune response.” If you’re familiar with germ theory and disease pathology you know that most organisms have evolved the means to prevent external threats from causing too much harm. Mammals produce mucous, which surrounds viruses and bacteria in slimy goo to prepare for expulsion from the body, preventing these organisms from multiplying internally and causing damage to organs. Or the host will wall off an intruder, not eradicating or expelling it, just allowing it to exist where it can’t do any damage, like a cyst. Or an open source community.

Within this host immune response and parasite analogy, there lies the secret to potential success: symbiosis. If you recall your high school biology textbook (and really, who doesn’t?) you’ll recall that symbiosis is the result of 2 species developing a mutually beneficial relationship. Nature provides numerous examples or parasitic relationships evolving into symbiosis: some barnacle species and whales; some intestinal worms and mammals; etc, etc. In this analogy, you the change agent are the parasite, and the organization you work for is the host. The trick is for the parasite to evade getting ejected from the host. To do that, the parasite has to be visible enough for its benefits to be felt, but not so visible as to inflame the host. It’s quite the trick to pull off. To put this into more practical terms, don’t announce yourself too loudly, and get in the habit of showing, not telling.

Oh dear… I’ve now shifted into the mode of giving you a ray of hope. I’m terribly sorry. I fear that my terminal case of unbridled optimism has now reared its ugly head. Fine. Even though it’s probably pointless and a lost cause, and you’re only signing up for more pain, there are some things you can do to improve your chances of success from 0% to… 0.5%?

Show, Don’t Tell

There are few things large organizations detest more than a loud, barking dog. The surest route to failure is to raise the expectations of everyone around you. This is a thing that happens when you talk about your vision and plant the seeds of hope.

Stop. Talking.

Open source projects serve as a great point of reference here. Sure, many large open source projects undergo some amount of planning, usually in the form of a backlog of features they want to implement. Most well-run, large open source projects have a set of procedures and guidelines for how to propose new features and then present them to the core team as well as the community-at-large. Generally speaking, they do not write reams of text in the form of product requirements documents. They will look at personas and segmentation. They will create diagrams that show workflows. But generally speaking, they lead with code. Documentation and diagrams tend to happen after the fact. Yes, they will write or contribute to specifications, especially if their project requires in-depth integration or collaboration with another project, but the emphasis is on releasing code and building out the project. Open source projects serve as my point of reference, so imagine my surprise when I started working in large organizations and discovered that most of them do precisely the opposite. They write tomes of text about what they are thinking of building and what they wish to build, before they ever start to actually build it. This runs counter to everything I’ve learned working in open source communities. Given my above points about not changing too much too quickly, what is a change agent to do?

Prototype. Bootstrap. Iterate.

Open Source innovation tells us that the secret to success is to lead with the code. You want to lead change? Don’t wait for something to be perfect. Do your work in the open. Show your work transparently. Iterate rapidly and demonstrate continuously. Others will want to create the PRDs, the architectural documents, the white papers, and the other endless reams of text that no one will ever read. Let them. It’s a necessary step – remember, your job is to not trigger the host immune response. You can do that by letting the usual processes continue. What you are going to do is make sure that the plans being written out are represented in the code in a form that’s accessible to your target audience as quickly as possible, and that you get it in front of your target audience as soon as it’s available. Without a working representation of what is being proposed, your vision is wishful thinking and vaporware.

The reasons are simple: if you expend your time and energy building up expectations for something that doesn’t exist yet, you risk letting the imaginations of your customers and stakeholders run wild. By limiting your interactions to demonstrations of what exists, the conversation remains grounded in reality. If you continuously present a grand vision of “the future” you will set the stage for allowing perfect to be the enemy of good. Your customers will have a moving target in their minds that you will never be able to satisfy. By building up expectations and attempting to meet them, you are setting the stage for failure. But with continuous iteration, you help to prevent expectations from exceeding what you are capable of delivering. There’s also the added benefit of showing continuous progress.

Borrowing from the open source playbook is a smart way to lead change in an organization, and it doesn’t necessarily need to be limited to code or software. Continuous iteration of a product or service being delivered can apply to documentation, process design, or anything that requires multi-stage delivery. By being transparent with your customers and stakeholders and bringing them with you on the journey, you give them an ownership stake in the process. This ownership stake can incentivize them to collaborate more deeply, moving beyond customer into becoming a full-fledged partner. This continuous iteration and engagement builds trust, which helps prevent the host from treating you like a parasite and walling you off.

Remember, most people and organizations don’t like change. It scares them. By progressing iteratively, your changesets become more manageable as well as palatable and acceptable. This is the way to make your changes seem almost unnoticeable, under the radar, and yet very effective, ultimately arriving at your desired outcome.

Prototype. Bootstrap. Iterate.
January 1, 2026
The New Open Source Playbook – Platforms Part Deux

(This is the 2nd post in a series. Part 1 is here)

I was all set to make this 2nd post about open core and innovation on the edge, and then I realized that I should probably explore the concept of “lift” in a bit more detail. Specifically, if you’re looking for your platform strategy to give your technology products lift, what does that mean exactly? This goes back to the idea that a rising tide lifts all boats. If you think of a rising tide as a growing community of users or developers, and the boat is your particular software project, then you want a startegy where your project benefits from a larger community. A dynamic, growing community will be able to support several “boats” – products, projects, platforms, et al. A good example of this is the Kubernetes community, which is the flagship project of the Cloud Native Computing Foundation (CNCF).

How Do We Generate Lift?

There are 2 basic types of lift you will be looking for – user lift, or getting more people ot adopt your platform, and developer lift, where more developers are contributing to your platform. The former gets more people familiar with your particular technology, providing the basis for potential future customers, and the latter allows you to reduce your engineering cost and potentially benefit from new ideas that you didn’t think of. This means that the community or ecosystem you align with depends on the goals for your platform. If you want more users, that is a very different community strategy from wanting more collaborators. Many startups conflate these strategies, which means they don’t always get the results they’re looking for.

Let’s assume that you have a potential platform that is categorized in the same cloud native space as Kubernetes. And let’s assume that you’ve determined that the best strategy to maximize your impact is to open source your platform. Does that mean you should put your project in the CNCF? It depends! Let’s assume that your product will target infosec professionals, and you want to get feedback on usage patterns for common security use cases. In that case, the Kubernetes or CNCF communities may not be the best fit. If you want security professionals getting familiar with and adopting your platform, you may want to consider security-focused communities, such as those that have formed around SBOM, compliance, and scanning projects. Or perhaps you do want to see how devops or cloud computing professionals would use your platform to improve their security risk, in which case Kubernetes or CNCF make sense. Your target audience will determine what community is the best fit.

Another scenario: let’s assume that your platform is adjacent to Kubernetes and you think it’s a good candidate for collaboration with multiple entities with a vested interest in your project’s success. In that case, you need developers with working knowledge of Kubernetes architecture, and the Kubernetes community is definitely where you want your project to be incubated. It’s not always so straightforward, however. If you’re primarily looking for developers who will extend your platform, making use of your interfaces and APIs, then perhaps it doesn’t matter if they have working knowledge of Kubernetes. Maybe in this case, you would do well to understand developer use cases and which vertical markets or industries your platform appeals to, and then follow a different community trail. Platform-community fit for your developer strategy is a more nuanced decision than product-market fit. The former is much more multi-dimensional than the latter.

If you have decided that developers are key to your platform strategy, you have to decide what kind of developers you’re looking for: those that will *extend* your platform; those that will contribute to your core platform; or those that will use or embed your platform. That will determine the type of lift you need and what community(ies) to align with.

One more example: You’re creating a platform that you believe will transform the cybersecurity industry, and you want developers that will use and extend your platform. You may at first be attracted to security-focused communities, but then you discover a curious thing: cyber security professionals don’t seem fond of your platform and haven’t adopted it at the scale you expect or need. Does this mean your platform sucks? Not always – it could be that these professionals are highly opinionated and have already made up their minds about desired platforms to base their efforts on. However, it turns out that your platform helps enterprise developers be more secure. Furthermore, you notice that within your enterprise developer community, there is overlap with the PyTorch community, which is not cyber security focused. This could be an opportunity to pivot on your adoption strategy and go where your community is leading: PyTorch. Perhaps that is a more ideal destination for community alignment purposes. Before deciding, however, you can do some testing within the PyTorch community before making a final decision.

Learn From My Example: Hyperic

Hyperic was a systems management monitoring tool. These days we would put it in the “observability” category, but that term didn’t exist at the time (2006). The Hyperic platform was great for monitoring Java applications. It was open core, so we focused on adoption by enterprise developers and not contributions. We thought we had a great execution strategy to build a global user base that would use Hyperic as the basis for all of their general purpose application monitoring needs. From a community strategy perspective, we wanted Hyperic to be ubiquitous, used in every data center where applications were deployed and managed. We had a great tag line, too: “All Systems Go”. But there was a problem: although Hyperic could be used to monitor any compute instance, it really shined when used with Java appliations. Focusing on general systems management put us in the same bucket, product-wise, as other general use systems management tools, none of which were able to differentiate each other. If we had decided to place more of our community focus on Java developers, we could have ignored all of the general purpose monitoring and focused on delivering great value for our core audience: Java development communities. Our platform-community fit wasn’t aligned properly, and as a result, we did not get the lift we were expecting. This meant that our sales team had to work harder to find opportunities and put a drag on our revenue and overall momentum. Lesson learned…

When attempting a platform execution strategy, and you’re going the open source route, platform-community fit is paramount. Without it, you won’t get the lift you’re expecting. You can always change up your community alignment strategy later, but it’s obviously better if you get it right the first time.

December 30, 2025
The New Open Source Playbook
(This is the first in a series)

For the last few years, the world of commercial open source has been largely dormant, with few startup companies making a splash with new open source products. Or if companies did make a splash it was for the wrong reasons, see eg. Hashicorp’s Terraform rugpull. It got to the point that Jeff Geerling declared that “Corporate Open Source is Dead“, and honestly, I would have agreed with him. It seemed that the age of startups pushing new open source projects and building a business around them was a thing of the past. To be clear, I always thought that it was naive to think that you could simply charge money for a rebuild of open source software, but that fact that startups were always trying showed that there was momentum behind the idea of using open source to build a business.

And then a funny thing happened – a whole lot of new energy (and money) started flowing into new nascent companies looking to make a mark in… stop me if you’ve heard this one… generative AI. Or to put it in other words, some combination of agents built on LLMs that attempted to solve some automation problem, usually in the category of software development or delivery. It turns out that when there’s lots of competition for users, especially when those users are themselves developers, that a solid open source strategy can make the difference between surviving and thriving. In light of this newfound enthusiasm for open source and startups, I thought I’d write a handy guide for startups looking to incorporate open source startegy into their developer go to market playbook. Except in this version, I will incorporate nuances specific to our emerging agentic world.

To start down this path, I recommend that startup founders look at 3 layers of open source go to market strategy: platform ecosystem (stuff you co-develop), open core (stuff you give away but keep IP), and product focus (stuff you only allow paying customers to use). That last category, product focus, can be on-prem, cloud hosted, or SaaS services – it won’t matter, ultimately. Remember, this is about how to create compelling products that people will pay for, helping you establish a business. There are ways to use open source principles that can help you reach that goal, but proceed carefully. You can derail your product strategy by making the wrong choices.

Foundation: the Platform Ecosystem Play

When thinking about open source strategy, many founders thought they could release open source code and get other developers to work on their code for free as a new model of outsourcing. This almost never works as the startup founders imagined. What does end up happening is that a startup releases open source code and their target audience happily uses the code for free, often not contributing back, causing a number of startups to question why they went down the open source path to begin with. Don’t be like them.

The way to think of this is within the concept of engineering economics. What is the most efficient means to produce the foundational parts of your software?
- If the answer is by basing your platform on existing open source projects, then you figure out how to do that while protecting your intellectual property. This usually means focusing on communities and projects under the auspices of a neutral 3rd party, such as the Eclipse or Linux Foundation.
- If the answer is by creating a new open source platform that you expect to attract significant interest from other technology entities, then you test product-market fit with prospective collaborators and organizations with a vested interest in your project. Note: this is a risky strategy requiring a thoughtful approach and ruthless honesty about your prospects. The most successful examples of this, such as Kubernetes, showed strong demand from the outset and their creation was a result of market pull, not a push.
- If the answer is that you don’t need external developers contributing to your core platform, but you do need end users and data on product-market fit, then you look into either an open core approach, or you create a free product that gives the platform away for free but not necessarily under an open source license. This is usually for the cases where you need developers to use or embed your product, but you don’t need them contributing directly. This is the “innovation on the edge” approach.
- Or, if the answer is that you’ll make better progress by going it alone, then you do that and you don’t give it a 2nd thought. The goal is to use the most efficient means to produce your platform or foundational software, not score points on hacker news.
Many startups through the years have been tripped up by this step, misguidedly believing that their foundational software was so great that once they released it, thousands of developers would step over each other to contribute to a project.

In the world of LLMs and generative AI, there is an additional consideration: do you absolutely need the latest models from Google, OpenAI, or elsewhere, or can you get by with slightly older models less constrained by usage restrictions? Can you use your own training and weights with off-the-shelf open source models? If you’re building a product that relies on agentic workflows, you’ll have to consider end user needs and preferences, but you’ll also have to protect yourself from downstream usage contraints, which could hit you if you reach certain thresholds of popularity. When starting out, I wholeheartedly recommend having as few constraints as possible, opting for open source models whenever possible, but also giving your end users the choice if they have existing accounts with larger providers. This is where it helps to have a platform approach that helps you address product-ecosystem fit as early as possible. If you can build momentum while architecting your platform around open source models and model orchestration tools, your would-be platform contributors will let you know that early on. Having an open source platform approach will help you guide your development in the right direction. Building your platform or product foundation around an existing open source project will be even more insightful, because that community will likely already have established AI preferences, helping make the decision for you.

To summarize, find the ecosystem that best fits your goals and product plans and try to build your platform strategy within a community in that ecosystem, preferably on an existing project; barring that, create your own open source platform but maintain close proximity to adjacent communities and ecosystems, looking for lift from common users that will help determine platform-ecosystem fit; or build an open core platform, preferably with a set of potential users from an existing community or ecosystem who will innovate on the edge, using your APIs and interfaces; if none of those apply, build your own free-to-use proprietary platfrom but maintain a line-of-sight to platform-ecosystem fit. No matter how you choose to build or shape a platform, you will need actual users to provide lift for your overall product strategy. You can get that lift from core contributors, innovators on the edge, or adoption from your target audience, or some combination of these. How you do that depends on your needs and the expectations of your target audience.

Up Next: open core on the edge and free products.
December 30, 2025
Open Source is About to Undergo Substantial Change
…And Most Open Source Communities Aren’t Ready

It’s probably gauche to talk about “AI” by now. AI this… AI that… and most of the time, what we’re really talking about is predictive text machines, aka LLMs. But today I want to talk about what I see happening in the open source world, and how I see things changing in the not too distant future, and how much of that will be shaped by these predictive text machines, aka… LLMs. The agentic world is growing very quickly, and even if the large LLMs are starting to plateau, the LLM-backed services are still accelerating in their product growth for the simple reason that developers are figuring out how to add rules engines and orchestration platforms to build out targeted vertical services (think tools for reading radiology and MRI scans, for example). A great analogy from computing history for this shift from LLMs to agentic “SLMs” is the shift in emphasis from the single CPU for defining compute power to the emergence of multi-core CPUs along with faster RAM, NVMe, larger onboard caches, and of course, GPUs. When we think about compute power today, we don’t refer to the chip speed, which is a far cry from the late 90’s and early 2000s. Believe it or not, kids, there was a time when many people thought that Moore’s law applied to the clock speed on a CPU.

For some time now, source code has been of little value. There’s so much of it. Nobody buys source code. I’ve made this point before in a series of posts on the subject. 20 years ago, I noted how internet collaboration was driving down the price of software because of the ubiquity of source code and the ability to collaborate beyond geographic borders. This trend, which has been unceasing now for 25+ years, has hit an inflection point and accelerating beyond the previous rate. This is, of course, because of the oncoming train that is AI, or more specifically, agentic LLM-based systems that are starting to write more and more of our source code. Before I get into the full ramifications of What This Means for Open Source ^(tm) let me review the 2 previous transformative eras in tech that played a pivotal role in bringing us to this point: open source and cloud.

Open Source Accelerated the Speed of Development

A long, long time ago, software vendors had long release cycles, and customers had no choice but to wait 1-2 years, or longer depending on the industry, for the long cycle of dev, test, and release to complete. And then a funny thing happened: more people got online and suddenly created a flurry of core tools, libraries, and systems that gave application developers the ultimate freedom to create whatever they wanted without interference from gate-keepers. I cannot over-emphasize the impact this had on software vendors. At first, it involved a tradeoff: vendors were happy to use the free tools and development platforms, because they saw a way to gain a market edge and deliver faster. At the same time, startups also saw an opportunity to capitalize on this development and quickly create companies that could compete with incumbents. In the late 90s, this meant grabbing as much cash as possible from investors in the hopes of having an IPO. All of this meant that for every advance software vendors embraced from the open source world, they were also effectively writing checks that future competitors would cash, which required that established vendors release even more quickly, lather, rinse, repeat, and find vertical markets where they could build moats.

Cloud accelerated the speed of delivery

If open source accelerated the speed of development, the emergence of what became “cloud technologies” enabled the delivery of software at a speed and scale previously thought to be impossible. Several smart companies in the mid-2000s saw this development and started to enact plans that would capitalize on the trend to outsource computing infrastructure. The companies most famous for leading the charge were Amazon, which created AWS in 2006, Netflix, which embraced AWS at an early stage, Google, which created Borg, the predecessor to Kubernetes, and Salesforce, which created it’s cloud-based PaaS, Force.com, in 2009. Where open source gave small growing companies a chance to compete, cloud did the same, but also at a price. Established software vendors started moving to cloud-based systems that allowed them to deliver solutions to customers more quickly, and startups embraced cloud because they could avoid capital expenditures for data center maintenance. Concurrently, open source software continued to develop at a fast pace for the simple reason that it enabled the fast development of technologies that powered cloud delivery. Similar to open source, the emergence of cloud led directly to faster release cycles and increasing competition. Unlike open source, however, cloud computing allowed established cloud companies to build out hegemonic systems designed to exact higher rental fees over time, pulling customers deeper into dependencies that are increasingly difficult to unravel. Software vendors that thought open source developers were the architects of their demise in the early 2000s hadn’t yet met Amazon.

All of these developments and faster release cycles led to a lot more source code being written and shared, with GitHub.com emerging as the preferred source code management system for open source communities. (Pour one out for Sourceforge.net, which should have captured this market but didn’t.) Sometimes this led companies to think that maybe their business wasn’t cut out for this world of source code sharing, so they began a retrenchment from their open source commitments. I predicted that this retrenchment would have little impact on their viability as a business, and I was right. If only they had asked me, but I digress…

All of this brings us to our present moment where source code is less valuable than ever. And in a world of deprectiating value for something, how do we ensure that the rules of engagement remain fair for all parties?

Sorry Doubters: AI Will Change Everything

If open source accelerated development and cloud accelerated delivery, then AI is accelerating both, simultaneously. Code generation tools are accelerating the total growth of source code; code generation tools are accelerating the ongoing trend of blending the boundary between hardware and software; and code generation tools are (potentially) creating automated systems that deliver solutions more quickly. That last one has not yet been realized, but with the continuing growth of agentic workflows, orchestrators, and rules engines, I would bet my last investment dollar on that trend realizing its potential sooner rather than later.

What does this portend? I think it means we will need to craft new methods of managing and governing all of this source code. I think it means that rules of collaboration are going to change to reflect shifting definitions of openness and fairness in collaboration. I think it means that previously staid industries (read: semiconductors) are facing increasing pressure in the form of power consumption. speed of data flow, and increasingly virtualized capabilities that have always lived close to the silicon. And I think a whole lot of SaaS and cloud native vendors are about to understand what it means to lose your “moat”. The rise of agentic systems is going to push new boundaries and flip entire industries on their heads. But for the purpose of this essay, I’m going to focus on what it means for rules of collaboration.

What is the Definition of Open Source?

For many years, the definition of open source has been housed and governed by the Open Source Initiative (OSI). Written in the post-cold war era of open borders and free trade, it’s a document very much of its time. In the intervening years, much has happened. Open source proliferation happened, and many licenses were approved by the OSI as meeting the requirements of the Open Source Definition (OSD). State-sponsored malware has happened, sometimes inflicting damage on the perceived safety of open source software. Cloud happened, and many open source projects were used in the creation of “cloud-native” technologies. And now LLM-based agentic systems are happening. I mention all of this to ask, in what context is it appropriate to consider changes in the OSI?

One of the reasons open source governance proved to be so popular is that it paved the way for innovation. Allow me to quote my own definition of innovation:

Innovation cannot be sought out and achieved. It’s like happiness. It has to be achieved by laying the foundation and establishing the rules that enable it to flourish.

In open source communities and ecosystems, every stakeholder has a seat at the table, whether they are individuals, companies, governments, or any other body with a vested interest. That is the secret of its success. When you read the 10 tenets of the OSD, it boils down to “Establishing the rules of collaboration that ensure fairness for all participants.” Basically, it’s about establishing and defending the rights of stakeholders, namely the ability to modify and distribute derivative works. In the traditional world of source code, this is pretty straightforward. Software is distributed. Software has a license. Users are held to the requirements of that license. We already saw the first cracks in this system when cloud computing emerged, because the act of distributing… sorry “conveying” software changed significantly when I used software distributed over a network. And the idea of derivative works was formed at a time when software was compiled with shared library binaries (.so and .dll) that were pulled directly into a software build. Those ideas have become more quaint over time, and the original ideas of the OSD have become increasingly exploitable over the years. What use is a software license when we don’t technically “use software”? We chose to not deal with this issue by pretending that it hadn’t changed. For the most part, open source continued to flourish, and more open source projects continued to fuel the cloud computing industry.

But now we’re bracing for another change. How do we govern software when we can’t even know if it was written by humans? Agentic systems can now modify and write new source code with little human intervention. I will not comment on whether this is a good idea, merely that it is happening. Agentic systems can take the output of cloud-based services, and write entire applications that mimic their entire feature set. Does that meet the definition of open source? Does it violate the EULA of a cloud service? And if companies can recreate entire code bases of projects based only on the requirements of applications that use it, does that violate the terms of reciprocal licenses like the GPL? And this is before we even get to the issues of copyright pertaining to all the source code that had to feed the models in order to write code.

If we true back to answering the question “how do we protect the rights and ensure the fairness of all participants”, how do we prepare for these changes? I think a couple of things are in order:
- The right to reverse engineer must be protected to meet the definition of Open Source. This means that the ability to recreate, modify, and redistribute a model, cloud service, or really anything in technology that we use, has to be protected. For years, cloud providers have built in complexity in their services that makes them very difficult to replicate at scale. That is now changing, and it is a good thing.
- This also means that the ability to recreate, modify, and redistribute models must also be protected if it uses the moniker of Open Source.
- Agents must abide by licensing terms in order to be categorized as open source. If you call your agentic systems open source, they must be able to interpret and abide by software licenses. This effectively means that all agentic systems will need to include a compliance persona in order to meet the definition of Open Source.
- Maintainers of Open Source projects must have a way to quickly dismiss the output of agentic systems that file bug and vulnerability reports. This means that in order to meet the open source definition, agentic systems that fit in that category will have to abide by a standard that maintainers use to signal their willingness to accept input from agents. If maintainers decline, then agentic systems will either avoid these projects, or push their inputs and changes into forked repos maintained elsewhere.
These are just a couple of ideas. The bottom line is that the open source ethos guarantees all stakeholders a seat at the table, and we must be willing to make changes to our governing rules in order to ensure fairness for all parties. To do otherwise is to shirk our responsibility and pretend like it’s still 1999. No change to the open source definition should be taken lightly, but as the governing document that protects the rights of those who participate in open source communities, we need to make sure that it doesn’t become more easily exploitable by monopolistic companies and those that wish to extort from community members or commit harmful acts.

Open Source communities and maintainers are not yet prepared for these changes, and it’s our job as community members to make sure that these communities, the backbone of open source innovation, remain vibrant and strong.
December 7, 2025
Things I’m Thankful for – DEI

I read earlier today that the Thanksgiving post is not about Thanksgiving. It’s “a hook for the hack to hang a grievance on, and you can make a home bingo game of it.” And so with that, I’m going to write a “Thanksgiving post” and talk about what has been on my mind lately, which happens to be what I’m most grateful for: Diversity, Equity, and Inclusion or “DEI”.

Imagine going to work and seeing the image from the top of this post plastered on the Xitter account of your employer’s board chair. It’s clear to me that the sort of person who complains about DEI doesn’t know what it actually means, so I think it’s time we explained it to them.

I Am a Product of DEI

Close your eyes and picture in your minds your first mental image of a beneficiary of DEI. Now open them. Did they look like this picture?

Photo by alex starnes on Unsplash

Ok, what about this guy?

Photo by PoloX Hernandez on Unsplash

Ok, now what about this one?

Me, myself, and DEI

What? That’s not your mental image of someone who benefits from DEI? Well prepare your collective minds to be blown. When I was 17 years old, I was a poor white kid in a rural Arkansas high school. At that point, I assumed I would be spending my next years at an Arkansas college or university. That in itself is a form of privilege, but it didn’t compare to what was to come. That summer, I received a packet in the mail from Yale University tell me that “you, too, can go to Yale University!” which I found mildly amusing. I had good test scores (33 ACT) and good grades (top 10% of my class) but I wasn’t the most brilliant student in the world. I hadn’t won any competitions, although I did place 2nd in the Northeast Arkansas regional math contest. I wasn’t valedictorian or even salutatorian. The point is, I was good but not “generational talent” amazing, and it never even crossed my mind to try for an Ivy League college. Thinking nothing of it, I figured “why not?” and mailed my application. To my amazement, I received a congratulatory letter in December announcing that I had received an offer of admission. I decided I wanted to go, found out that the financial aid packages were actually quite generous, and started making plans to move to New Haven, CT, a place I had never seen before setting foot on campus in September of 1991. I learned later on that the admissions rates for someone like me – poor and rural – were a lot higher than kids from wealthier suburbs and urban areas.

I have to admit that I have wrestled with this over the years. Did I take someone else’s more deserving spot? Someone who had better test scores, better grades, and possibly better tutors? I recently found my college essay and had a good chuckle. The prompt was to write about something I was passionate about, and I chose to write about pop music and how modern music didn’t compare well to earlier eras (ha! I was a curmudgeon even then!) Did that separate me? Did I really get in only based on my identity, a poor, southern white kid from the rural Mississippi Delta region? Over the years, I’ve managed to quiet those doubts, but they still linger.

My point is that no one looks at me and screams, “DEI!” When anyone says they want to “end DEI” and “DEI is dead!” I highly doubt they have my image in mind. Why is that? I think we know, but we just don’t want to say it outloud. The fact is, nobody is demanding I give up my DEI card because I am a white, heterosexual, cis-gendered man. In their view, I deserve what I got because of whiteness of it all. They’re perfectly fine with someone like me benefiting from quotas and set-asides, as long as those privileges are not extended to Other people. I don’t have to explain who the others are, right?

It’s impossible to know exactly how I would have turned out if not for my Yale degree – I suspect I would have been fine. But I have no doubts that my Yale education changed my life’s trajectory and was an inflection point. I have no doubt that it opened doors that would have otherwise been closed. I benefited immensely from this experience in so many ways – academically of course, but also culturally. It’s important to reiterate this point: I, a white person, benefited from a DEI program.

DEI Critics Are Lying, Hypocritical Bastards

How is it that those most vociferously opposed to DEI – the ones who scream “DEI!” like some kind of epithet – are simultaneously the most incompetent and least qualified people we’ve ever seen? It’s almost like opposing DEI isn’t at all about finding the most qualified people – perhaps it’s because they don’t want to compete against competent, qualified people. Because when I think about diversity, equity, and inclusion, I think about ways to ensure that the most qualified people are taken into consideration, when they otherwise would be passed over. So next time you find yourself questioning why we need DEI, you may want to ask yourself why you feel that way. And then ask yourself about my story: did I deserve my place? Why or why not?

November 27, 2025
Truth and Reconciliation

I was as shocked as anyone when I heard that Charlie Kirk was murdered. I’m not going to lie – I didn’t mourn his passing. Neither did I celebrate. I was in shock. I, like many many others out there, have been numbed by the political violence of recent years. But I was equal parts surprised, disappointed, and exasperated by the response to what can only be described as a senseless killing. Flags at half-mast. Calls for civility. Calls for anyone to the left of Attila the Hun to “denounce the violence”. The immediate response was angry, full of fear, and only slightly less than terrifying. I could only watch in wonder as Charlie Kirk was elevated as some national hero or someone we should admire. I saw lots of calls for calm, for deescalation in rhetoric, for civil discourse, and to go along to get along and can’t we give peace a chance? I also saw vicious criticism of anyone that didn’t venerate Mr. Kirk, and oh yes, what’s that word again? Can…cel…ing? Jimmy Kimmel. Tens or even hundreds of educators at the high school and college level were fired. The fallout was immediate and in one direction, and I was trying my best not to think of the words “Reichstag fire”, because boy howdy were those recriminations fast and furious. It was as if the entirety of magaville had been lying in wait for this moment, to open the gates of fury. This was their chance to finally exact their performative revenge, to give voice to the grievances they had been nursing for such a long time. Whenever I’m confronted with the fury of MAGA vengeance and grievance, the question I’ve had that has never been satisfactorily answered is thus: what are they so angry about? What, exactly, do they want revenge for? And now that they’ve won every branch and level of the federal government, why are they still angry and in search of revenge? Revenge for what? And now that they’ve won, shouldn’t they be happy?

My mind wandered back to another episode of violence seared in the memory of those of us of a certain age, during the LA riots in 1992. Reporters asked Rodney King, whose brutal beating instigated grievances over long-standing injustice, about his thoughts on the riots. His famous response: “Can’t we all just get along?” One could be forgiven for longing for peaceful coexistence. One could be forgiven for wanting to end the violence as quickly as possible and go back to some semblance of “normal” where we can go about our lives and not have to worry about more spilling of blood. Wouldn’t that be grand? Wouldn’t it be nice if we could simply turn off our brains, click on the TV, and not have to worry about more outbreaks of violence? More killing? And what do we need to do in order to bring about this peace, order, and civility? Not talk about politics? Not call out injustice? Not raise our voices when our neighbors, families, and friends are erased, hauled off to gulags, or deported?

It came as no surprise to me that the alleged Charlie Kirk shooter turned out not to be some leftist agitator or member of any political group, but rather a non-political member of a conservative family who nursed a person grievance on behalf of his friend (I’m still not sure if they were in a relationship and I honestly don’t care enough to dig into it). No one should be shocked by this revelation, as this is the exact profile we have come to expect from so many of our violent mass shooters. Whether shootings in schools, churches, or other public gatherings, it’s the same story told numerous times from a thousand different vantage points: single protagonist, usually male, acting alone, often with no guiding political philosophy, and turning to violence to quell some agitated part of their mind, whether in a simple act of vengeance (Luigi Mangione), in defiance of their self-described persecution, to “teach women a lesson”, to act out their personal racist fantasies, or any number of other personal grievances that led to them committing heinous acts of violence. The question is why? Why do so many young men act out their personal revenge fantasies in the most shocking ways? Why are so many young men incited by hateful messages and rhetoric such that they put their violent thoughts into motion? I think we know why, but we’re not willing to address the reasons directly.

Let’s Be Frenemies and Save America

I have an old friend from college, a traditional non-MAGA conservative, who wrote a post on Medium with the above title, and it did not sit well with me. I was angered by it. He was another in a long list of people calling for civility of discourse. Let’s air out our differences and respect each other’s viewpoints. Let’s have a meeting of the minds and come away with fresh perspectives. It was almost a mirror image, from a conservative point of view, of the Ezra Klein opinion piece in the New York Times written 2 days prior. In both cases, the authors desired to paper over our differences and let bygones be bygones. Who can argue with calls for peace? It’s a stirring call that promises to assuage our innermost fears. It’s so appealing to simply let it go and move on. But see, I can’t do that, because there’s this nagging part of me that can’t dismiss the asymmetrical nature of our violence nor the asymmetrical nature of our politics. If we agree that the violence occurring right now is fueled by rhetoric, why is that happening? Who is escalating the rhetoric?

This leads us directly to the question that forces us to address the elephant in the room: who benefits from civility? Who gains the most from a deescalation of rhetoric? I read a fantastic essay earlier today by A. R. Moxon (no idea who that is), “Eventually You’re Going to Have to Stand for Something.” He included an analogy that speaks to our current predicament – it was about a cruel king who persecuted innocents and took them as slaves and his handlers who enabled him. Some of those handlers were extremists, and some were more thoughtful and tried to blunt his worst impulses. So the story goes, there’s some unrest from subjects who are unhappy with the cruelty and start speaking out against the king, who responds with violence. The thoughtful advisors try to intervene and tell the public that they will have to get along with the king, so stop making a public outcry. The punch line is this:

So the people began to speak out against the king, and the king would respond. Some he would imprison, others he would torture, others he would kill. And a great despair grew in the hearts of some people, while in the hearts of others, hatred blossomed.

One day the king’s party was ambushed, and the king barely escaped, while two of his soldiers and one of his favorite princes lost their lives. Anticipating reprisal, the restless people gathered in a mob outside the castle walls. The moderate princes and advisors became frightened to see that their kingdom had at last descended into violence. “We are going to have to find ourselves some loyal soldiers willing to kill and imprison citizens,” they murmured to one another.

If we think back to our first interaction with a bully, usually in grade school, it’s good to recall what happens when you hand over your lunch money: the bully comes back. And every time he comes back, it gets harder to resist, because you’ve already established ground rules. My problem with the calls for civility is that, at the risk of making light of a dire situation, we’re setting ourselves up to pay a lifetime’s worth of lunch money. But of course, this is not about lunch money, this is about people’s existence; our very existence. Our equivalent of giving up lunch money is watching people get maimed, tortured, persecuted, exiled, and killed. A few years ago, I wrote an essay about how evangelicals will kill us all, and that was before the pandemic. I argued then that they were unwilling to compromise with those they thought were evil and “against God”, and in such a conflict, how can we possibly expect a peaceful resolution? Will they someday wake up and decide, oh my bad, I was so wrong to kill your sisters, mothers, children, and millions of other people. Silly me – I’m so sorry! We’re going to stop being such hateful bigots and learn to live with you. And this is the ultimate problem I have with calls for civility: they’re all asking for us to conveniently forget the past, present, and future acts of violence, and they’re asking us to forgive and forget. By framing the exercise as everyone coming together, they’re putting the onus, the responsibility, on the non-MAGAs to be better. Ezra Klein, as well as my college friend, accepted that framing and willingly obliged so he can go back to… whatever it is that he does. Ta-Nehisi Coates rightfully called out Klein’s behavior, noting that his deescalation only serves to reinforce a status quo that is wholly unfair and serves to erase and condemn entire groups of people to a lifetime of persecution and violence against them. The bargain seems to be this: just go away, liberals, just STFU about our little persecutions against people that nobody cares about. Why do you care so much? We’re not talking about you. And Ezra Klein said, oh of course, and slinked away.

There has been an escalation of rhetoric that has inspired many to commit acts of violence, and despite the efforts of people like my college friend to pretend that this goes both ways, it should be pretty clear that the violence is coming from a single source. It’s the same source that fueled violence against abortion clinics. It’s the same source that fueled violence against Asian people post-COVID; violence against women in the form of rape, assault, and even mass shootings; violence against targeted races and classes, usually black and Latin American; violence against politicians in the form of assassinations and home invasions; and violence in the form of 2nd amendment rhetoric about trees of liberty and the blood of tyrants. The violent rhetoric has centered, in no particular order, on Democrats, women, blacks, Latin Americans, refugees, immigrants of all stripes, gay people, trans people, and really anyone that white supremacists can call out publicly without catching too much flak. It used to be that such language would lead to such a loud response that no one would dare try it. And yet here we are – a movement built entirely on the birth certificate of a former president is now pushing for the extrajudicial persecution and removal of any immigrant, anywhere in the United States. Not enough violent immigrants to catch? We’ll just make them up and detain them anyway. And then we’ll put military boots on the ground in our cities just to instill the proper amount of fear from those “other people”. This is the definition of asymmetrical stochastic terrorism.

Such is the swirl of violence surrounding our radical right-wing reactionaries, that it has now come for their own – witness Charlie Kirk. We’re now seeing 4chan kids, immersed in violent fantasies and coming from right-wing families, choosing the path of violence against their own, because it’s what they’ve learned from their elders as the best way to address an egregious offense. If you grow up believing that the best way to deal with evil is to shoot it, guess what happens when you see someone you love suffer at the hands of a perpetrator? You’re going to think about revenge, and if you are angry enough, you just might act on it. Revenge begets revenge; violence leads to violence. And in our case, the violence rests at the feet of a belligerent movement that has plagued our politics since at least the 1950s, when McCarthy ran amok, segregation was a national crisis, and the reactionaries of the day were just waiting for Barry Goldwater to unite them under the Republican flag.

First truth, then reconciliation

The nagging part of my brain cannot let go of the truth, or rather the lack thereof. To reconcile without truth is just capitulation. Before we can ever reconcile or come to any mutual agreement, we must be able to acknowledge the truth. And the truth is, radical reactionaries have been angling for revenge since before the ink on the voting rights act was dry. This is why MAGA is still angry, despite winning every branch of government and holding complete power. They’re angry because they want others to suffer in an attempt to stanch their own pain stemming from the emptiness of their hearts. And their anger will never be satiated – it is now core to their identity, and this is why they must be defeated. They will not compromise. They want only domination. We cannot reconcile with a bully that still wants our lunch money, or in this case, the death of our nation and the continuing suffering of whoever they deem to be other. Who knows who will be next? It’s the usual targets, but as we’ve already seen, the blowback will affect many more than that.

MAGA must be defeated. Those are the terms – truth and the defeat of the MAGA movement. Without truth, there can be no reconciliation, because those who bear the responsibility must be the ones to acknowledge the pain and suffering they have caused. Reconciliation has to start with them. They bear the responsibility.

October 6, 2025
Open Source, AI, and the Global War on Fascism

(This was originally posted on medium.com)

I have been struggling recently with where to direct my focus and what I could write about that would add something material to the ongoing debates on “AI”, technology, and politics. Thanks to my friend Randy Bias for this post that inspired me to follow up:

This post triggered a few thoughts I’ve been having on the subject. Namely, that open source was born at a time that coincided with the apex of neoliberal thought, corresponding with free trade, borderless communication and collaboration, and other naive ideologies stemming from the old adage “information wants to be free”. Open source, along with its immediate forbear free software, carried with it a techno-libertarian streak that proliferated throughout the movement. Within the open source umbrella, there was a wide array of diverse factions: the original free software political movement, libertarian entrepreneurs and investors, anarcho-capitalists, political liberals and progressives, and a hodgepodge of many others who came around to see the value of faster collaboration enabled by the internet. There was significant overlap amongst the factions, and the coalition held while each shared mutual goals.

From 1998, when the term “open source” was coined, until the early 2010’s, this coalition held strong, accomplishing much with robust collaboration between large tech companies, startup entrepreneurs, investors, independent developers, general purpose computer owners, and non-profit software foundations. This was the time when organizations like the Linux Foundation, the Apache Software Foundation, and the Eclipse Foundation, found their footing and began organizing increasingly larger swaths of the industry around open source communities. The coalition started to fray in the early 2010s for a number of reasons, including the rise of cloud computing and smart phones, and the overall decline of free trade as a guiding principle shared by most mainstream political factions.

Open source grew in importance along with the world wide web, which was the other grand manifestation of the apex of neoliberal thought and the free trade era. These co-evolving movements, open source and the advocacy for the world wide web, were fueled by the belief, now debunked, that giving groups of people unfettered access to each other would result in a more educated public, greater understanding between groups, and a decline in conflicts and perhaps even war. The nation state, some thought, was starting to outlive its purpose and would soon slide into the dustbin of history. (side note: you have not lived until an open source community member unironically labels you a “statist”)

For a long time, open source participants happily continued down the path of borderless collaboration, falsely believing that the political earthquake that started in the mid-2010s woud somehow leave them untouched. This naivety ignored several simultaneous trends that spelled the end of an era: Russian influence peddling; brexit; the election of Trump; Chinese censorship, surveillance and state-sponsored hacking; and a global resurgence of illiberal, authoritarian governments. But even if one could ignore all of those geopolitical trends and movements, the technology industry alone should have signaled the end of an era. The proliferation of cryptocurrency, the growth of “AI”, and the use of open source tools to build data exploitation schemes should have been obvious clues that the geopolitical world was crashing our party. This blithe ignorance came to a screeching halt when a Microsoft employee discovered that state-sponsored hackers had infiltrated an open source project, XZ utils, installing a targeted backdoor 3 years after assumgin the ownership of a project.

One cannot overstate the impact of this event. For the first time, we had to actively monitor the threats from nation states wanting to exploit our open source communities to achieve geopolitical goals. The reactions were varied. After some time, the Linux Foundation finally admitted that it could no longer ignore the origins of its contributors, demoting the status of some Russian contributors. At the other end of the spectrum is Amanda Brock, who prefers to stay ensconced in her neoliberal bubble, unperturbed by the realities of our modern political landscape.

One thing must be clear by now: we find ourselves knee-deep in a global conflict with fascist regimes who are united in their attempts to undermine free republics and democracies. As we speak, these regimes are looking to use open source communities and projects to accomplish their aims. They’ve done it with blockchains and cryptocurrencies. They’ve done it with malware. They’ve done it with the erosion of privacy and the unholy alliance of surveillance capitalism and state-sponsored surveillance. And they’re continuing to do it with the growth of the TESCREAL movement and the implementation of bias and bigotry through the mass adoption of AI tools. This is part and parcel of a plan to upend free thought and subjugate millions of people through the implementation of a techno oligarchy. I don’t doubt the utility of many of these tools — I myself use some of them. But I also cannot ignore how these data sets and tools have become beachheads for the world’s worst people. When Meta, Google, Microsoft or other large tech companies announce their support of fascism and simultaneously release new AI models that don’t disclose their data sets or data origins, we cannot know for sure what biases have been embedded. The only way we could know for sure is if we could inspect the raw data sources themselves, as well as the training scripts that were run on those data sets. The fact that we don’t have that information for any of these popular AI models means that we find ourselves vulnerable to the aims of global conglomerates and the governments they are working in tandem with. This is not where we want to be.

From where I stand, the way forward is clear: we must demand complete transparency of all data sources we use. We must demand complete transparency in how the models were trained on this data. To that end, I have been disappointed by almost every organization responsible for governing open source and AI ecosystems, from the Linux Foundation to the Open Source Initiative. None of them seem to truly understand the moment we are in, and none of them seem to be prepared for the consequences of inaction. While I do applaud the Linux Foundation’s application of scrutiny to core committers to its projects, they do seem to have missed the boat on the global fascist movement that threatens our very existence.

We have to demand that the organizations that represent us do better. We must demand that they recognize and meet the moment, because so far they have not.

June 24, 2025
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:
- AI Native platforms are about to disrupt – and maybe disembowel – what we know today as devops
- AI Native platforms are about to dramatically increase the scope of open source ecosystems
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.
June 24, 2025
The Rise of AI Native: Open Source Ecosystems

I recently posted my thoughts on “AI Native” and automation, and how recent developments in the model and agent ecosystem were about to significantly disrupt our application lifecycle management tools, or what we have erroneously labeled “DevOps”. This entire post is based on that premise. If I turn out to be wrong, pretend like I never said it Considering that a lot of open source time and effort goes into infrastructure tooling – Kubernetes, OpenTofu, etc – one might draw the conclusion that, because these many of these tools are about to be disrupted and made obsolete, therefore “OMG Open Source is over!!11!!1!!”. Except, my conclusion is actually the opposite of that. I’ll explain.

Disclaimer: You cannot talk about “AI” without also mentioning that we have severe problems with inherent bias in models, along with the severe problems of misinformation, deepfakes, energy and water consumption, etc. It would be irresponsible of me to blog about “AI” without mentioning the significant downsides to the proliferation of these technologies. Please take a minute and familiarize yourself with DAIR and its founder, Dr. Timnit Gebru.

How Open Source Benefits from AI Native

As I mentioned previously, my “aha!” moment was when I realized that AI Native automation basically removes the need for tools like Terraform or OpenTofu. I concluded that tools that we have come to rely on will be replaced – slowly at first, and then accelerating – by AI Native systems based on models and agents connected by endpoints and interfaces adhering to standard protocols like MCP. This new way of designing applications will become this generation’s 3-tiered web architecture. As I said before, it will be models all the way down. Composite apps will almost certainly have embedded data models somewhere, the only question is to what extent.

The reason that open source will benefit from this shift (do not say paradigm… do not say paradigm… do not say…) is the same reason that open source benefited from cloud. A long long time ago, back in the stone age, say 2011 – 2016, there were people who claimed that the rise of SaaS, cloud, and serverless computing would spell the end of open source development, because “nobody needed access to source code anymore.” A lot of smart people made this claim – honest! But I’m sorry, it was dumb. If you squint really hard, you can sort of see how one might arrive at that conclusion. That is, if you made the erroneous assumption that none of these SaaS and cloud ran on, ya know, software. To his credit, Jim Zemlin, the Linux Foundation czar, never fell for this and proclaimed that open source and cloud went together like “peanut butter and chocolate” – and he was right. Turns out, using SaaS and cloud-based apps meant you were using somebody else’s computer, which used – wait for it – software. And how did tech companies put together that software so efficiently and cheaply? That’s right – they built it all on open source software. The rise of cloud computing didn’t just continue or merely add to the development of open source, it supercharged it. One might say that without open source software, SaaS and cloud native apps could never have existed.

I know that history doesn’t repeat itself, per se, and that it rhymes. In the case of AI Native, there’s some awfully strong rhyming going on. As I have mentioned before, source code is not a particularly valuable commodity and nothing in the development of AI native will arrest that downward trend. In fact, it will only accelerate it. As I mentioned in my first essay on the topic of open source economics, There is no Open Source Community, the ubiquity of software development and the erosion of geographical borders makes for cheaper software asymptotic to zero cost. This makes the cost of producing software very cheap and the cost of sharing the software pretty much $0. In an environment of massive heaps of software flying around the world hither and yon, there is a strong need for standard rules of engagement, hence the inherent usefulness of standard open source licensing, eg. the Apache License or the GNU General Public License.

There are 2 key insights that I had recently on this subject: The first was in part 1 of this essay: devops tools are about to undergo severe disruption. The 2nd is this: the emergence of bots and agents editing and writing software does not diminish the need for standard rules of engagement; it increases the need. It just so happens that we now have 25+ years of standard rules of engagement for writing software in the form of the Open Source Definition and the licenses that adhere to its basic principles. Therefore, the only logical conclusion is that the production of open source code is about to accelerate. I did not say “more effective” or “higher quality” code, simply that there will be more of it.

InnerSource, Too

The same applies to InnerSource, the application of open source principles in an internal environment behind the firewall. If AI Native automation is about to take over devops tooling, then it stands to reason that these models and agents used internally will need rules of engagement for submitting pull/merge requests, fixing bugs, remediating vulnerabilities, and submitting drafts of new features. Unfortunately, whereas the external world is very familiar with open source rules of engagement, internal spaces have been playing catchup… slowly. Whereas b2b software development has all occurred in open source spaces, large enterprises have instead invested millions of $s in Agile and automation tooling while avoiding the implementation of open source collaboration for engineers. I have a few guesses as to why that is the case but regardless, companies will now have to accelerate their adoption of InnerSource rules to make up for 25 years of complacency. If they don’t, they’re in for a world of hurt, because everyone will either follow different sets of rules, or IT will clamp down and allow none of it, raising obstacles to the effectiveness of their agents. Think about an agent, interacting with MCP-based models, looking to push a new version of a YAML file into a code repo. But they can’t, because someone higher up decided that such activities were dangerous and never bothered to build a system of governance around it.

Mark my words: the companies that make the best use of AI Native tools will be open source and InnerSource savvy.

June 19, 2025
The Rise of AI Native Automation

I conceived of this blog in 2023 as a skeptic’s outpost, demystifying AI hype and taking it down whenever necessary. I had no interest in fueling a speculative bubble, but as a technologist at heart, I’m always interested in seeing what’s coming down the road. This is my way of saying that this post is not about poking holes in the current hype cycle, but rather taking a look at what I see developing in the application development world. Because I see major changes afoot, and I’m not sure folks are ready for it.

No, we’re not all losing our jobs

This is one of those zombie lies that won’t die. Turns out, sprinkling AI sauce into your IT and build environments makes humans in the loop even more important than before. Humans who understand how to build things; humans who understand how to communicate; humans who know how to write effectively; and humans who can conceive of a bigger picture and break it down into lanes of delivery. In other words, the big winners in an AI world are full-stack humans (I stole this from Michelle Yi. I hope she doesn’t mind) – a career in tech has never been more accessible to a humanities degree holder than now.

The big losers are the code monkeys who crank out indecipherable code and respond in monosyllabic grunts to anyone who deigns to ask – those “10x” engineers that everyone was lauding just 3 years ago. We already knew source code wasn’t that valuable, and now it’s even less valuable than ever.

AI and DevOps

I had thought, until recently, that as AI infiltrated more and more application development, that the day would come when developers would need to integrate their model development into standard tools and platforms commonplace in our devops environments. Eventually, all AI development would succumb to the established platforms and tools that we’ve grown to know and love that make up our build, test, release, and monitor application lifecycle. I assumed there would be a great convergence. I still believe that, but I think I had the direction wrong. AI isn’t getting shoehorned into DevOps, it’s DevOps that is being shoehorned into AI. The tools we use today for infrastructure as code, continuous integration, testing, and releasing are not going to suddenly gain relevance in the AI developers world. A new class of AI-native tools are going to grow and obliterate (mostly) the tools that came before. These tools will both use trained models to be better at the build-test-release application development lifecycle as well as deploy apps that use models and agents as central features. It will be models all the way down, from the applications that are developed to the infrastructure that will be used to deploy, monitor, and improve it.

Ask yourself a question: why do I need a human to write Terraform modules? They’re just rule sets with logic that defines guardrails for how infrastructure gets deployed and in what sequence. But let’s take that one step further: if I train my models and agents to interact with my deployment environments directly – K8s, EC2, et al – why do I need Terraform at all? Training a model to interact directly with the deployment environments will give it the means to master any number of rulesets for deployments. Same thing with CI tools. Training models to manage the build and release processes can proceed without the need for CI platforms. The model orchestrators will be the CI. A Langchain-based product is a lot better at this than Circle CI or Jenkins. The eye-opener for me has been the rise of standards like MCP, A2A, and the like. Now that we are actively defining the interfaces between models, agents, and each other, it’s a short hop, skip, and a jump to AI-native composite apps that fill our clouds and data centers, combined with AI-native composite platforms that build, monitor, and tweak the infrastructure that hosts them.

AI Native Tools are Coming

Once you fully understand the potential power of model-based development and agent-based delivery and fulfillment, you begin to realize just how much of the IT and devops world is about to be flipped on its head. Model management platforms, model orchestrators, and the like become a lot more prominent in this world, and the winners in the new infrastructure arms race will be those tools that take the most advantage of these feature sets. Moreover, when you consider the general lifespan of platforms and the longevity of the current set of tools most prevalent in today’s infrastructure, you get the impression that the time for the next shift has begun. Hardly any of today’s most popular tools were in use prior to 2010.

DevOps tools have followed a general pattern over the past 30 years, starting with the beginning of what I’ll call the “web era”:

Progression of automation in the web era

The current crop of automation tools are now becoming “legacy” and their survival now rests on how well they acclimate to an AI Native application development world. Even what we call “MLOps” was mostly running the AI playbook in a CI “cloud native” DevOps world. Either MLOps platforms adapt and move to an AI native context, or they will be relegated to legacy status (my prediction). I don’t think we yet know what AI native tools will look like in 5 years, but if the speed of MCP adoption is any indicator, I think the transition will happen much more quickly than we anticipated. This is perhaps due to the possibility that well-designed agentic systems can be used to help architect these new AI Native systems.

I also don’t think this will be any great glorious era of amazing transformation. Any migration to new systems will bring about a host of new challenges and obstacles, especially in the security space. I shudder to think of all the new threat vectors that are emerging as we speak to take advantage of these automated interfaces to core infrastructure. But that’s ok, we’ll design agentic security systems that will work 24/7 to thwart these threats! What could possibly go wrong??? And then there are all the other problems that have already been discussed by the founders of DAIR: bias, surveillance, deep fakes, the proliferation of misinformation, et al. We cannot count on AI Native systems to design inclusive human interfaces or prevent malicious ones. In fact, without proper human governance, AI native systems will accelerate and maximize these problems.

In part 2, I’ll examine the impact of AI Native on development ecosystems, open source, and our (already poor) systems of governance for technology.

June 4, 2025