devopsy.kinsta.cloud

Tag: open source

DevOps Dozen 2026 Nominations Are Open: Recognizing the People and Technology Moving DevOps Forward
When we launched the DevOps Dozen in 2015, we wanted to recognize the people, projects and companies helping this community move forward. We saw the work happening across DevOps every day at DevOps.com. The awards gave our readers a chance to tell us who deserved recognition.

Eleven years later, there is a lot more ground to cover. We have platform engineering teams building internal developer platforms, AI agents taking on software delivery tasks and open source maintainers keeping projects healthy that entire industries depend on. Our awards need to keep up with the work.

Nominations for the 2026 DevOps Dozen Awards are now open through Oct 18, 2026 at 5 p.m. ET. This year’s program includes 24 awards across nine Community categories and 15 Tools & Services categories. We have revised the categories and sharpened their definitions to help people find the right place for their contributions.

I hope you will take a look. Chances are you know someone, or use something, that belongs on the list.

Making Room for How DevOps Works Today

One challenge with any awards program is deciding what should have its own category. Make the definitions too broad and very different accomplishments end up competing against each other. Make them too narrow and you lose sight of how people actually work.

AI is a good example. An assistant helping a developer review code is doing something different from an agent working through a failed pipeline. Operating an AI application introduces another set of responsibilities.

This year’s commercial categories make those differences explicit.

Best AI-Assisted Software Development Solution recognizes tools that help developers plan, write, review, document and test software. The developer directs the work, with AI providing assistance.

Best Agentic Software Delivery Solution covers agents that plan and execute multistep work across repositories, pipelines, deployments or operations. Entries should demonstrate what those agents can accomplish across the delivery process.

Best DevOps for AI Systems Solution addresses the systems being built and operated: Deploying models and applications, evaluating their behavior, monitoring production performance and managing governance throughout their lifecycle. That includes MLOps, LLMOps and AgentOps.

There is also a Community award for Best End-User Application of AI in Software Delivery, recognizing what an enterprise team has accomplished using AI internally.

For anyone submitting in these categories, tell us what improved. Did the team deliver better software? Find defects earlier? Reduce recovery time? Give us enough detail to understand the achievement.

Recognizing the People We Depend On

I am particularly glad to see separate recognition for established open source projects, emerging projects and individual maintainers.

A mature project with widespread adoption deserves recognition for its impact. A younger project may introduce an approach worth celebrating while it is still building its community. Separate categories allow us to evaluate each on appropriate terms.

Then there are the maintainers. Reviewing pull requests, triaging issues, supporting contributors and keeping a project moving takes sustained effort. Much of that work happens outside the spotlight, even when thousands of organizations benefit from it. Open Source DevOps Maintainer of the Year gives readers a way to recognize that contribution directly.

The Community awards also recognize people building communities, leading change inside enterprises and working together on successful end-user teams. Independent books, articles, podcasts, videos, courses and research are eligible under Best Independent DevOps Content or Educational Resource. Community programs and events have their own category as well.

Think about who has helped you learn, whose project your team relies on or who made a difficult transformation succeed. Those are good places to start when considering a nomination.

The Full Delivery Process Counts

There is plenty of attention on AI, but our readers still have software to build, secure, release and operate.

The Tools & Services awards cover software delivery platforms, CI/CD, quality assurance, platform engineering and developer productivity. They recognize DevSecOps, software supply chain security and observability, along with infrastructure automation and cloud operations.

FinOps also has a place, reflecting the importance of understanding and managing cloud, engineering and AI costs. Other categories recognize breakthrough solutions and successful customer implementations.

You can find the full category descriptions here. Please read them before submitting. They explain what each award recognizes and what evidence will help judges evaluate an entry.

One point worth making clear: An end-user team describing its own accomplishments belongs in the appropriate Community category. A vendor submitting a customer implementation should use Best Customer DevOps Implementation in Tools & Services.

Vendor employees can also qualify for appropriate Community awards when the contribution being recognized serves the broader community beyond promoting a product.

How to Participate

Anyone in the DevOps community can nominate. You can nominate yourself, your team, your company or someone whose work you admire.

Community nominations are free. Tools & Services entries cost $300 per nomination. You may enter multiple categories, but each submission should explain why the nominee deserves recognition in that particular category.

My advice is straightforward: Tell us what the nominee did, what problem it addressed and what happened as a result. Specific examples and measurable outcomes give judges something useful to evaluate.

Winners will be determined through a combination of 60% expert judging and 40% public voting. Public voting is limited to one vote per person, per category. Judges do not review categories where they have a direct conflict of interest.

Mitch Ashley and I are currently listed on the judging panel, with additional judges to be announced. The process and judging page has more details.

Here are the dates:
- Oct 18, 2026, at 5 p.m. ET: Nominations close.
- Nov 11, 2026: Finalists are announced and public voting opens.
- Dec 31, 2026, at 11:59 p.m. ET: Public voting closes.
- January 2027: Winners are announced at the Predict 2027 virtual summit.
We depend on this community to help us find deserving nominees. You know which colleagues make your team better, which projects you trust and which products have delivered for you. You also know people whose contributions deserve more attention than they receive.

Take a few minutes to put their names forward. And if your own team has done something you are proud of, we want to hear about that too.

Submit your nominations for the 2026 DevOps Dozen Awards. Good luck to everyone participating.
October 1, 2026
US District Court Decision in AI’s Favor Worries Open-Source Developers

A federal appeals court handed GitHub, Microsoft, and OpenAI an important win in the first major appellate ruling over how AI coding tools can use open-source code.

As we all know, all the AI code-generating programs learned their lessons largely from open-source code. So a group of anonymous open-source plaintiffs argued that GitHub Copilot and OpenAI Codex were built using code from public GitHub repositories, including open-source licensed code. They argued the AI tools had generated code without the author attribution, copyright notices, and license terms that came with the original work. Now, the Ninth Circuit has returned a verdict in Doe vs. GitHub siding with Big AI.

Ouch!

But it may not be as troublesome as it first appears. The Ninth Circuit’s September 16 decision turns on a technical but consequential distinction: AI-generated code that lacks author names, copyright notices, and license information is not necessarily the same as code from which that information has been unlawfully removed under Section 1202 of the Digital Millennium Copyright Act (DMCA).

Writing for the court, Judge Eric Miller rejected the idea that a tool’s failure to include copyright information in a newly generated work automatically amounts to removal of that information. “One who creates a new work and fails to include CMI [copyright management information] cannot be said to have ‘removed’ or ‘altered’ anything,” the court said. It declined, in the court’s words, to transform “run-of-the-mill copyright-infringement claims into DMCA claims.”

For open-source developers, that means one potentially potent legal pathway has narrowed. For AI companies, it means reduced litigation risk, but they’re not getting a blank check to do what they want with open-source code.

Still, as Duane O’Brien, the Open Source Initiative (OSI)new executive director, told me, “The Ninth Circuit answered a narrow question about one provision of the DMCA. It did not decide whether the developers’ open source licenses were honored, and that claim is still before the district court. Nearly every open source license, from MIT to the GPL, is unambiguous about the obligation to keep the copyright notice and attribution intact. Developers offered their work to the world on those terms, and anyone who builds on that work, including companies building AI tools, should honor them.”

Yes, yes, they should. But as writers can attest, AI companies can be cavalier, at best, about their use of copyrighted materials.

However, Karen Sadler, attorney and executive director of the Software Freedom Conservancy (SFC), noted in an interview, “It’s very easy to overread this decision.” Most of the claims (like whether Microsoft removed copyright information before using the code for training) were dismissed on procedural grounds. The plaintiffs hinted at the theory but didn’t actually assert it, so the court did not rule on it but instead said that it considered them forfeited. Or, as the court put it, the “complaint is not about training. It just isn’t.”

That’s not to say another, better-argued case, might come to a different decision. Sandler continued, “The decision notes that the generation of code may indeed be infringement. So the whole decision comes back to whether copyright information was actually removed, not about whether the use was appropriate. Ultimately, this case is really about the way these very narrow claims were made, and it doesn’t read to me like any sweeping conclusion about the use of FOSS by LLMs.”

It is worrisome, though. The accepted rule is that code’s open-source licensing travels with it. For example, a developer reusing an Apache-licensed file is expected to preserve relevant notices. A developer incorporating GPL-licensed code can take on broader reciprocal obligations. Even permissive licenses such as MIT and BSD commonly require preservation of copyright and license notices. AI-generated code deletes the provenance chain.

GitHub and Microsoft have argued from the start that Copilot doesn’t simply copy and paste code. The ruling doesn’t endorse every aspect of that position. But it does make clear that lack of attribution, standing alone, will not convert an AI-code output into a DMCA metadata-removal violation.

That matters not only to Copilot. The same reasoning could apply to providers of AI code assistants, general-purpose language models, and agentic development systems. In short, all AI programs that can generate code. Or, in other words, it’s business as usual for AI coding systems.

That said, the court did not decide whether copying open-source code to train a model is copyright infringement. It does not decide whether such training is fair use. It doesn’t determine whether output that closely matches protected source code infringes copyright. And it does not decide whether an AI vendor, a model user, or both may be liable when generated code triggers an open-source license obligation.

The court did recognize the difference between a generic output and a tool returning an existing work with information stripped out. It indicated that a different case could arise if a system operated more like a search engine, returning identical code without accompanying CMI. It also didn’t foreclose conventional copyright claims where output substantially reproduces protected work.

It’s an important caveat. The practical risk in AI coding is likely to be highly fact-dependent. A commonplace loop, sort routine, or API call won’t be copyrightable. A substantial, distinctive code block from a specific repository is a different kettle of fish.

What does all that mean? Stay tuned; there’s a lot of litigation and court decisions to come. Still, as Bruce Perens, one of open-source’s co-founders, told me, “We are indeed facing the issue that this is effectively the end of copyright for both proprietary and Open Source software and many other products. In explaining this to Richard Stallman recently, I noted that Copyleft was a casualty, but the copyright-free world he once dreamed of- the actual motivation behind Free Software- was being achieved, with various unforeseen circumstances.

September 18, 2026
EU-Funded CodeSupply Offers Grants for Open Source Software Supply Chain R&D

Software supply chain, security and compliance tools all depend on accurate information about the packages they analyze, but that data is often fragmented across multiple sources and can be difficult to access or use consistently. A new European Union-funded initiative called CodeSupply, coordinated by the NLnet Foundation, is making €400,000 in grants available for open source R&D projects aimed at improving the availability, quality and interoperability of software package data.

For the current call, projects can request between €5,000 and €50,000, with proposals due Nov. 3. The funding is available for small to medium-sized research and development projects that contribute to CodeSupply’s goals around software supply chain security, software metadata, cybersecurity, open source license compliance and the reliability of the open internet.

Which Projects Are Eligible?

The call covers new and existing technologies with demonstrated real-world impact. Eligible activities range from scientific research and software engineering to security audits, formal security proofs, technical validation, documentation and standardization. The program can also support open source hardware development, usability improvements, participation in technical events, project management and essential infrastructure costs. Projects focused on open source license compliance may also qualify, including tools that help identify, document or manage licensing requirements.

CodeSupply lists publishing current, correct and comprehensive software metadata as one of its three main objectives. The initiative says more complete metadata can help with understanding and managing software components, dependencies, licensing information and security-related information. The call does not describe a specific type of metadata project, but says relevant work could include research, software development and other technical solutions, as well as mechanisms for making essential datasets more widely accessible across the open source and internet ecosystem.

Applicants are expected to show how their proposed work contributes to open source development and connects directly to CodeSupply’s objectives. Proposals should define the problem being addressed, describe the proposed technical work and explain its expected impact. To qualify, proposals must be written in English, align with CodeSupply’s goals, make research and development their primary objective and have a clear European dimension. Projects that pass that initial screening are evaluated on technical feasibility, relevance and potential impact, and value for money.

What is CodeSupply?

CodeSupply is part of the European Commission’s Open Internet Stack initiative, which aims to develop open, secure and reusable technologies that can serve as building blocks for digital infrastructure. The initiative builds on the EU’s earlier Next Generation Internet programs and is intended to give public agencies, businesses and individual users more control over essential technologies.

CodeSupply is a collaboration among four organizations. NLnet Foundation, a Dutch public benefit organization that leads the NGI Zero initiative, is coordinating the project. Other participants include AboutCode, a Belgian nonprofit focused on software package origin, licensing, provenance and software supply chain security; the Edsger Institute, a Dutch nonprofit specializing in reproducible hosting stacks and software composition analysis; and Universidad Rey Juan Carlos, a public research university in Spain. Funding for CodeSupply comes from the European Commission’s Directorate-General for Communications Networks, Content and Technology through Horizon Europe. Read more about CodeSupply here.

September 8, 2026
Trusted Open Source Catalogs for AI and Developers

Open source supply chain security has been a scanner-and-CVE game for years — pull the package, run the scan, cross-reference known vulnerabilities, hope the metadata is current. That model always had gaps, and AI agents are widening them fast. Agents pull open source components from wherever they can find them, at machine speed, and the after-the-fact scan is not a control that keeps up. What developers and platform teams actually need is a curated catalog that vets components before they enter the environment, not after they cause a problem.

Alan Shimel sits down with Leslie Pascual, Field Engineering Manager for AI and Security Solutions at ActiveState, to work through what a trusted open source catalog looks like in practice and why it becomes table stakes as soon as AI agents join the software supply chain. Pascual brings more than 20 years across engineering, architecture and leadership, with a stint hardening enterprise healthcare applications that pushed her into cybersecurity. Her point is direct — scanners compare packages to CVE metadata after the fact, which is fundamentally different from vetting a component before it ships.

They get into the mechanics. Packages go through a cool-down period, secure build, attestation and strong provenance before landing in the catalog, which now spans the top nine open source ecosystems and is expanding to twelve — Python, Java, JavaScript, R and more. Continuous monitoring keeps catalogs current with patches and fixes, and SBOMs and attestations ship with every component. The integration side matters just as much: catalogs plug into JFrog Artifactory, Sonatype and Cloudsmith so developers see no extra friction, and mirrored repositories let each customer expose the catalog inside their own Artifactory instance.

The forward-looking piece is where AI agents plug in directly. Tools like Claude and Cursor need a source of truth for open source components, and Pascual argues that the trusted catalog becomes exactly that — the place agents pull from instead of grabbing whatever the internet returns. An MCP server is on the roadmap to extend that intelligence directly into the CI/CD pipeline. The broader read is that shifting security all the way left, past the scanner and into the catalog itself, is what actually makes AI-assisted development safe enough for enterprise teams to scale.

September 1, 2026
Debian’s AI Vote Bets on Accountability Instead of a Ban

Most organizations writing AI usage policies right now are stuck between two bad options: ban the tools and watch people use them anyway, or say nothing and hope code review catches whatever slips through. Debian just spent two weeks working through that exact problem in public, and the way the vote landed is worth paying attention to, whether you maintain a package archive or a private repo.

The Debian Project ran a General Resolution from August 15 through August 28, asking developers to settle the community’s stance on AI-assisted contributions. Eight separate proposals were on the ballot, ranging from an outright ban written into Debian’s Social Contract to a hands-off position treating AI tools like any other developer choice. Debian used the Condorcet method for the vote, meaning developers ranked their preferences rather than picking a single option, and just over 130 of roughly 1,000 eligible developers cast ballots.

The ban needed a three-to-one supermajority to pass, since it would have amended the Social Contract itself. It didn’t come close. Instead, developers settled on an approach that neither endorses nor prohibits the use of generative AI in Debian’s development process. Project Secretary Kurt Roeckx announced the outcome once the vote closed.

The policy that won is notable for what it doesn’t do. It doesn’t require anyone to disclose that they used an LLM to draft a changelog, debug a build script, or triage a bug report. Disclosure is encouraged, not mandated. What the policy does instead is put the obligation on the human in the loop. Contributors have to review, test, and fix model output before it goes anywhere near the archive. “Blindly accepting or uploading AI-generated material without appropriate human review” is treated as a violation of normal Debian practice, full stop, regardless of whether the contributor labels it as AI-assisted.

Three specific guardrails came with it. Confidential material, private communications, embargoed security bugs, cryptographic keys, and credentials can’t go to a third-party AI service without explicit authorization. Bulk automated contributions, like mass bug filing or large-scale patch sweeps, require upfront discussion and someone accountable for the results. And Debian is staying out of the copyrightability question entirely; existing licensing rules apply to AI-touched contributions exactly as they do to everything else.

That credentials clause isn’t hypothetical caution. Researchers tracked 28.65 million hardcoded secrets leaked in public GitHub commits in 2025, with leaked AI service credentials up 81% year over year. A project the size of Debian pasting embargoed vulnerability details into a third-party AI service isn’t a rules violation waiting to happen; it’s a leak waiting to happen.

Mitch Ashley, VP and practice lead for software lifecycle engineering and AI-native software engineering at The Futurum Group, sees a harder problem sitting underneath that requirement. Putting the obligation on the reviewer is the right call, but reviewers are the resource Debian has the least of.

“Debian put the obligation on the reviewer, the right place for it, and this is the component that runs out of capacity first,” Ashley said. “Review was already scarce in a volunteer project where roughly 130 of a thousand developers voted. AI-assisted contributions do not arrive at volunteer reviewer speed. Every organization borrowing this model inherits the same arithmetic. Policy language is free but reviewer hours are not.”

What makes Debian’s outcome worth watching outside the Linux world is the logic behind it. The project didn’t try to regulate the tool. It regulated behavior around the tool, which is much easier to enforce. Banning LLMs assumes you can detect their use reliably, and you mostly can’t. Requiring disclosure assumes people will self-report accurately, and plenty won’t, especially once AI assistance is baked into the editor rather than something you consciously reach for. Debian’s approach sidesteps both problems by holding contributors to the same standard regardless of how the code was written: you own what you submit, you tested it, and you didn’t leak anything on the way there.

That’s a template DevOps and platform teams should recognize, because it maps onto the problem enterprises are chewing on right now. Most internal AI policies fixate on “did you use AI,” when the more useful question is “did a human review this before it shipped, and did anything sensitive leave the building to get an answer?” But Ashley’s point holds whether the reviewers are volunteers or salaried: writing “humans must review AI output” into a policy doesn’t create the capacity for reviewers to do it. Debian’s vote looks that fact squarely in the face and refuses to pretend that a ban would do the job review already does — even without solving the underlying capacity problem.

The vote doesn’t resolve every open question. Copyright status of AI-assisted contributions remains genuinely unsettled, and Debian punting on it just pushes the ambiguity downstream to anyone redistributing the archive. But as a governance model, “trust the review process, restrict the specific behaviors that actually cause harm” is a more honest starting point than most enterprise AI policies manage, and it’s one other projects and IT organizations will likely borrow from as this debate keeps repeating itself across the industry.

September 1, 2026
Mezmo Open Sources AI SRE Operations

Site reliability engineering has been quietly buckling under its own success. The scope of what SRE teams are expected to own — observability, incident response, telemetry pipelines, capacity, cost, resilience — keeps growing while the tools underneath fragment further. AI is showing up as both the reason the workload keeps expanding and the most credible path to bringing it back under control, but only if agents get built on infrastructure that reliability engineers can actually reason about and trust.

Tucker Callaway, CEO of Mezmo, sat down with Alan Shimel at PlatformCon 2026 to walk through how his team is trying to move that needle in public. Mezmo’s Aura project, released as an open source AI SRE harness, is meant to give teams an opinionated foundation for building agents that reduce toil, process telemetry and support reliability workflows without turning the ops function into a stack of proprietary black boxes. The bet is that reliability work is too high-stakes to be locked inside any single vendor’s agent runtime.

Callaway and Shimel work through the practical pieces that decide whether an AI SRE agent is safe to run. Telemetry pipelines have to feed clean, structured signals rather than raw noise. Agent memory needs to persist and be inspectable so an agent’s prior actions can be audited. Trust and permissions become a first-class concern — an SRE agent with production access is only as good as the guardrails around what it can touch and when. Open source governance is what keeps all of that honest as more organizations adopt the harness.

The bigger shift Callaway sketches is what happens to SREs themselves. Rather than shrinking the discipline, agentic operations pushes reliability engineers up a level — toward architecting how autonomous systems behave, defining the guardrails they operate inside, and owning the reliability contract for a stack that increasingly runs itself. Reliability architects for autonomous systems is the phrase that keeps coming up, and it looks like where the profession is heading.

July 9, 2026
AI Is Exposing a Growing Blind Spot in Open Source Security

With AI, teams across organizations are now building internal applications faster than ever, often pulling in open source libraries and frameworks without much thought about long-term support, lifecycle management, or security ownership. An unintended consequence of this is that unsupported open source software (OSS) is quietly spreading across environments faster than security and engineering teams can keep track of it.

Most organizations already struggled with open source visibility before AI-assisted development became mainstream. Now, many are also accumulating technical debt at a much faster rate, creating future maintenance, security, and migration obligations every time new dependencies are introduced.

The question is no longer simply how fast organizations can build software with AI. It’s whether they can securely govern and sustainably support the software ecosystems they are creating.

Unsupported OSS is Becoming a Major Blind Spot

Many organizations already have unsupported frameworks and abandoned dependencies inside critical applications; most just do not realize it yet. As AI expands software development beyond traditional engineering teams, it’s becoming easier than ever to introduce open source dependencies without understanding whether projects are actively maintained, security patches still exist, or frameworks are approaching end-of-life.

The result is fragmented software stacks and growing visibility gaps across enterprise environments. It is also accelerating the accumulation of technical debt, creating future maintenance, support, and migration obligations every time new dependencies are introduced. Much of that debt remains hidden until a security issue, compliance requirement, or modernization effort forces it into the open.

While AI is dramatically increasing the speed and breadth of vulnerability discovery across open source ecosystems, the harder challenge is validating findings. This includes understanding exposure, prioritizing remediation, and fixing issues safely, all work that still depends heavily on maintainers and security teams already stretched thin.

AI is Breaking the Traditional Security Feedback Loop

For years, open source security operated on an imperfect but manageable equilibrium. Vulnerabilities were discovered relatively slowly, maintainers had time to validate reports, and engineering teams could prioritize remediation in cycles that were difficult but sustainable. AI is disrupting that balance.

The imbalance between vulnerability discovery and remediation is already becoming visible across the open source ecosystem. Recent reporting around Spring projects illustrates how quickly vulnerability discovery is accelerating. After 17 CVEs were disclosed across all of 2025, between this last March-April alone, 30 CVEs were reported.

Organizations are now trying to manage exponentially larger software ecosystems using governance and remediation models designed for a much slower era of software development. That imbalance is becoming increasingly difficult for maintainers, security teams, and enterprises to absorb.

Governance Needs to Catch Up to the Speed of AI

Open source is not going away. AI will only make it more foundational to how software gets built. But enterprises can no longer treat open source governance as an informal process handled only during vulnerability remediation cycles.

As AI accelerates software creation, organizations need better insight into the open source software running across their environments, including which components are unsupported, approaching end-of-life, or no longer actively maintained. It’s no longer enough to know which components have vulnerabilities. Organizations also need to know whether the software they depend on can still be supported and secured over the long term.

Enterprise and security leaders should focus on a few practical priorities:

Identifying unsupported and end-of-life dependencies before they become operational risks

Understanding which OSS components are business-critical and actively maintained

Reducing Reliance on Reactive “Scan and Patch” Remediation Cycles Alone

Building longer-term support and lifecycle planning into how open source software is adopted and maintained

Open source remains foundational to modern software development. But as AI accelerates software creation and vulnerability discovery simultaneously, unsupported OSS is becoming harder for enterprises to govern, support, and secure at scale.

Organizations that navigate this shift most successfully will not simply be the ones building software fastest. They will be the ones capable of maintaining visibility into the open source software they depend on and treating OSS governance as a core operational discipline, not an afterthought once vulnerabilities appear.

June 25, 2026
What Five Localization Pull Requests Revealed About Open Source Governance: A Field Report on Open Source’s i18n Infrastructure Gap
A bot recently approved one of my Pull Requests (PRs) with the cleanest possible verdict: “No Issues Found — Recommendation: Merge.” The story did not end there.

Weeks later, a maintainer finally reviewed the contribution. By then, the parts of the repository targeted by the localization work had been removed as the project evolved. The PR was closed, not because the translation was incorrect, but because the review arrived after the underlying code structure had changed.

That outcome highlights a broader challenge in open source internationalization (i18n). The problem is often not translation quality. It is the absence of processes that allows language contributions to be evaluated, routed, and integrated before project evolution overtakes them.

Translation is Not the Hard Part

When people hear “i18n,” many maintainers think it means “drop a JSON file in.” That is not what it involves. Internationalisation is a system: stable keys, defined fallback behaviour, plural rules, date formatting, and ICU (International Components for Unicode)–style placeholders that must survive runtime interpolation. A six-character English label can easily expand to fourteen characters in Hindi or German, breaking UI layouts.

Hindi introduces a script layer that many English-centric projects rarely encounter. Devanagari vowel signs (matras) reshape preceding consonants, and conjunct consonants can expose limitations in font support. Tone also matters: “आप” reads as respectful, while alternative forms can feel too casual for a developer tool.

When a contributor submits a Hindi PR, maintainers often have no practical way to evaluate whether the translation is correct, complete, safe to merge, or maintainable across releases. That is the gap. Not goodwill. Not bandwidth. Infrastructure.

Four Projects, Four Signals

A few months of work across AI and developer tooling makes the pattern legible:

Open WebUI provides a positive example of how language contributions can be integrated when review pathways are clear. A Hindi localization correction PR (#23745) was merged on April 15, 2026, after addressing a set of erroneous interface translations. The contribution involved no architectural changes—just improved language quality—but still made a widely used self-hosted AI interface more accessible to Hindi-speaking users.

Kilo Code — what review latency looks like: PR #8377 received extensive automated review and multiple rounds of contributor fixes. Automated checks eventually reported no remaining issues, but maintainer review arrived only after the repository had evolved and the targeted application paths had been removed. The PR was closed with an invitation to resubmit against the current architecture. The translation itself was not the blocker; the review cycle outlasted the relevant code paths.

Hoppscotch illustrates a different pattern. Hindi localization PR #6025 remains active after multiple rounds of automated review, contributor updates, and community language feedback. Bots identified missing keys, fallback behaviour, and consistency issues, while contributors iteratively refined the translation. The process demonstrates both the value of automated review and its limits: tooling can identify structural problems, but language maintenance still depends heavily on human review and maintainer capacity.

OpenClaw highlights a different challenge: maintainer capacity. In issue #3460, maintainers acknowledged multiple requests and pull requests for localization support but stated that they lacked the bandwidth to support multilingual contributions properly. They cited the need for a formal i18n architecture, translation review processes, and ongoing maintenance before accepting language additions. The issue attracted volunteers offering support in Spanish, Japanese, Portuguese, Korean, Chinese, Vietnamese, and other languages, illustrating that contributor interest already exists. The bottleneck was not willingness from the community—it was the infrastructure required to support that willingness sustainably.

The maintainer position: insufficient bandwidth for multilingual support. New translation PRs would be closed. The community was already at the door; the project hadn’t yet built a doorway.

The `hermes-webui` maintainer captured the meta-pattern best in a Chinese localization review: “The translations themselves are the hardest part and you’ve already done that. The infrastructure to make it work safely is the remaining piece.”

OpenStatus — what collaborative review looks like: A Hindi localization PR was reviewed using a combination of automated tooling and language-specific feedback from community participants. Translation issues were discussed openly, refinements were made, and the contribution was merged. The project illustrates that maintainers do not necessarily need to be language experts if a review pathway exists for community validation.

If AI developer tooling remains English-first, English fluency becomes a de facto requirement for participation. The tooling choices maintainers make early on determine whether language contributions can scale. Most teams frame this as a library selection problem. It is, in practice, a governance problem.

Consider three commonly used localisation workflows:
- gettext is mature and handles plurals well. But in fast-moving web applications where locale files change frequently, its operational weight can become a bottleneck. Contributors face non-trivial setup costs, and maintainers must review large .po file diffs.
- i18next is widely used in React and Node ecosystems because its JSON-based approach makes diffs easy to review without a build step. However, without enforced key naming conventions or CI checks for missing keys, localisation can become inconsistent. Untranslated strings may propagate without clear visibility.
- FormatJS addresses more complex requirements such as plurals, gendered strings, and runtime interpolation. However, its ICU syntax—{count, plural, one {# item} other {# items}}—introduces a steep learning curve. Without supporting tooling, contributions may become difficult to review or modify safely.
None of these libraries, in isolation, resolves the underlying issue. What enables sustained internationalisation is the addition of a governance layer: documented key conventions, defined fallback policies, CI checks for structural correctness, and a clearly identified reviewer role.

Mozilla’s Pontoon platform provides a useful reference point. It does not replace localisation files; it makes them maintainable at scale by embedding them within a structured workflow.

What “Maintainer-Safe” Looks Like

Three concrete CI/CD and governance moves address most of the gap:

Add a CONTRIBUTING-i18n.md: Treat it as seriously as CONTRIBUTING.md. Cover locale file structure, key naming, machine translation policy, screenshots, and placeholder safety so interpolation does not break at runtime.

Make CI carry the mechanical risk: Missing-key checks, invalid JSON detection, malformed ICU messages, and untranslated fallback diffs are all detectable. CI cannot assess tone, but it can allow maintainers to merge with confidence.

Credit language contributors: Use release notes, contributor graphs, and attribution metadata. If a Hindi locale ships, the contributor should not disappear behind “updated translations.”

The most frustrating part of open-source localisation is not translating large locale files. It is watching valid contributions stall because projects lack a safe way to accept them.

If you maintain an OSS (Open Source Software) project, audit your contribution workflow this week. Could a new contributor add a language without asking basic questions? If not, the next merge is not blocked by translators. It is constrained by the project’s current design.

Author’s Note: This piece is an expanded follow-up to my essay ‘Open Source’s Hidden Language Gap,’ published by Communications of the ACM (CACM) on May 8, 2026.
June 19, 2026
MiMo Code Is the Open Source Answer to Claude Code

Terminal-based coding assistants for AI-curious developers are hot these days, and the most popular choice appears to be Claude Code. But Anthropic’s commercial offering has a new open source rival: MiMo Code, released under an MIT license by Chinese smartphone giant Xiaomi.

Unlike Claude Code, MiMo Code is not restricted to a specific LLM provider. It was also optimized for “long-horizon automated programming tasks,” according to the introductory blog entry. The software aims to “maintain decision quality and state continuity over dozens or even hundreds of execution steps.”

The AI community has taken notice of this release. Since its v0.1 release last week, MiMo Code has garnered 9,000 stars on GitHub, and has been forked 783 times.

And unlike Claude Code, which costs $20 a month to start, MiMo is free, and may not even require connecting to a cloud provider, if the user installs a model on their own machine.

Tackling Long Horizon Memory Retention

Large Language Models (LLMs) are inherently stateless. They don’t remember the context from one task to the next.

To maintain continuity, the frontier lab model providers resubmit all the source material with each prompt. For long-running agentic operations, this approach can be prohibitively costly, so it falls on the code assist tools to maintain the context of long-running jobs.

Such tools typically manage this problem by providing LLMs with a short summary of previous work. Such automated compression, however, can lead to errors in long-term reasoning.

Instead, MiMo Code tasks a sub-agent to extract key information to store in a copy of SQLite, or in markdown files, which later can be consulted. The software also runs two background processes, called “Dream” and “Distill” to deduplicate identical material and derive reusable CLI commands, respectively.

MiMo Code also comes with provisions for running complex jobs in parallel.

“When the task scale becomes large enough — for example, migrating an entire project from one programming language to another — and dozens or even hundreds of parallel work units need to be coordinated simultaneously, round-by-round tool calls are no longer sufficient,” the company blog post stated.

A weakness of agents is that they specify orchestration logic in natural language, which is a recipe for errors.

MiMo Code’s Dynamic Workflow casts orchestration logic as JavaScript that runs in an isolated sandbox. Because the code is deterministic, all the threads of a workflow are guaranteed to execute: There are no hanging “if” statements without corresponding “then” executions. There are no “for … while” loops that prematurely stop functioning.

A New Way to Run Agents

Unlike Claude Code, MiMo Code does not wire the user to a single proprietary environment. Installing the application involves downloading the code and installing via a npm command (It requires Node.js to run)

In fact, as a Linux terminal application, MiMo Code doesn’t need to connect to external resources at all. Using the Ollama framework, users can run MiMo Code against a model, such as Qwen 2.5 Coder, running directly in the environment.

For benchmarks, Xiaomi paired MiMo Code with the latest release of its own model, the MiMo-V2.5 released in April. In three separate benchmarks (SWE-bench Verified, SWE-bench Pro and Terminal Bench), MiMo Code outperformed Claude Code – running either Claude Sonnet or MiMo-V2.5 – in running one-shot repository-level issues.

“Most of MiMo Code’s design goals—multi-turn memory, background state maintenance, completion verification, and cross-session evolution—mainly show their value in real development scenarios that continue for dozens of turns,” Xiaomi’s blog post boasted.

In a video review, Tyson Cung compared MiMo Code and Claude Code across a few real-world scenarios. He concluded MiMo is best for prototyping and learning projects, but Claude Code is best for production work, where the safety guardrails can be well worth the $20 monthly fee.

“The best way to decide is to try both,” Cung concluded. “Use each one on a real project and see which one fits your workflow.”

June 15, 2026
New Relic Adds Open Source Tool to Observe AI Coding

New Relic has made available an open source extension to its observability platform for coding tools at no additional cost.

Nic Benders, chief technical strategist for New Relic, said the New Relic AI Coding Observability capability will make it simpler for DevOps teams to centrally monitor usage of a diverse range of artificial intelligence (AI) coding tools, including the cost of the tokens consumed, using the same platform they already have to observe IT operations.

Regardless of the type of AI coding tool employed, New Relic AI Coding Observability normalizes the data collected, he added.

That capability makes it possible for organizations to employ multiple AI coding tools as they best see fit, or swap one out for another as additional advances are made, noted Benders.

The arrival of New Relic AI Coding Observability coincides with the sharing of a survey of 200 technology decision makers in the U.S. that finds a full 94% rate code generated by AI as being of a higher quality than human-authored code at the time of review, with 67% reporting AI now generates or significantly refactors between 51% and 75% of their organization’s weekly code output.

Nearly two-thirds (62%) also said their engineering teams often trust AI-generated code enough to ship it to production without line-by-line manual verification. A full 88% also lead organizations that made vibe coding a part of their workflows, with only 5% restricting it to non-production environments, and no respondents banning the practice outright.

However, more than three quarters (78%) also report there has been an increase in incidents. In fact, 86% report an increase in time senior staff spends fixing code and 74% report at least 25% of AI code needs significant rework when considering the past 12 months. Eighty-two percent experienced at least one production failure tied to AI-generated code in the past six months compared to 19% reporting no AI-generated code challenges in this time period.

A full 96% also rate observability as very or extremely important when working with AI-generated code. Well over three quarters (78%) now routinely prompt AI tools to include specific telemetry—such as logs, traces and metrics—directly into generated code to ensure it is observable.

Collectively, the results suggest that IT leaders are overestimating the quality of the code finding its way into their production environments, noted Benders. Many of those organizations are also about to discover that maintaining code over an extended period of time is a lot harder than writing code, he added. After all, when there is an issue the only source of information will be the AI tool that wrote it, which may not always surface a reliable explanation for why it opted for one approach or another, said Benders.

As such, it’s no longer a question of whether organizations will need to revisit how they manage the software development lifecycle (SDLC), but to what degree, he noted.

Regardless of approach, software engineering in the AI era is never going to be the same again. The issue now is how best to observe and manage massive volumes of code moving through DevOps pipelines that is of uncertain quality and, often, provenance.

June 15, 2026