Open source is free to use. It is not free to sustain

We can approve a migration budget, hire consultants, and pay for production support. Then expect the maintainer underneath all of it to keep showing up for free.

That is quite an operating assumption.

My work with FINOS and the .NET Foundation keeps bringing me back to this: adopting a project creates a dependency on the people maintaining it, too.

Someone reviews the pull requests. Investigates the vulnerabilities. Prepares the releases. Helps the next maintainer get started.

Funding that work deserves a serious conversation. So does accountability: what the money supports, who decides, and what the community can expect.

If a dependency matters enough to appear in your architecture review, its future should matter enough to appear in your budget discussion.

Your AI coding agent is a junior engineer with root access

We keep measuring how much code agents produce, how many issues they close, and how quickly they modernize applications.

Those are productivity metrics. They are not governance.

An agent can produce a clean pull request, pass every test, and still remove the undocumented exception that has quietly protected a business process for ten years.

That is not necessarily an AI failure.

It may be an organizational failure to preserve context, constrain authority, and require the right verification.

The answer is not to stop using agents. It is to treat them as non-human engineering identities:
Scoped access. Protected branches. Independent approval. Complete logs. Small, reversible changes.

AI agents do not eliminate engineering controls.

They make those controls executable infrastructure.

Where should an agent’s authority stop in your engineering environment?

Human error budgets

We love 𝗲𝗿𝗿𝗼𝗿 𝗯𝘂𝗱𝗴𝗲𝘁𝘀 in technology. We carefully calculate how much failure a system can tolerate. We measure it. Track it. Alert on it. Review it.
​
But people? Apparently, people only get 𝗲𝗿𝗿𝗼𝗿𝘀. No budget. One more late night. One more “quick” escalation. One more weekend deployment. One more priority added without another one removed. One more meeting. One more fire.
​
And then we act surprised when someone burns out. Here is the uncomfortable part: 𝗦𝗼𝗺𝗲 𝗰𝗼𝗺𝗽𝗮𝗻𝗶𝗲𝘀 𝗺𝗶𝗴𝗵𝘁 𝗵𝗮𝘃𝗲 𝗯𝗲𝘁𝘁𝗲𝗿 𝗿𝗲𝘀𝗶𝗹𝗶𝗲𝗻𝗰𝗲 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝗳𝗼𝗿 𝘁𝗵𝗲𝗶𝗿 𝘀𝗲𝗿𝘃𝗲𝗿𝘀 𝘁𝗵𝗮𝗻 𝗳𝗼𝗿 𝘁𝗵𝗲𝗶𝗿 𝗽𝗲𝗼𝗽𝗹𝗲. If a service approaches its error budget, we slow down feature delivery and focus on reliability.
​
If a person approaches theirs? We call it a busy quarter. Maybe ask them to be more resilient. That is backwards. Your engineers are not Kubernetes pods. You cannot just restart them. You cannot autoscale your best people. And “high availability” should never be a job requirement.
​
Perhaps leadership needs to start thinking about 𝗵𝘂𝗺𝗮𝗻 𝗲𝗿𝗿𝗼𝗿 𝗯𝘂𝗱𝗴𝗲𝘁𝘀 too. And when the budget is exhausted, the answer should not be: “Push through.” It should be: 𝗦𝗼𝗺𝗲𝘁𝗵𝗶𝗻𝗴 𝗻𝗲𝗲𝗱𝘀 𝘁𝗼 𝘀𝘁𝗼𝗽.

AI It Till You Make It: The Enterprise Evolution Of ‘Fake It Till You Make It’

Your AI-generated code compiles. Your strategy deck looks brilliant.

Can you explain either without reopening the chat? 

In my latest Forbes article, I explore “AI it till you make it” and the risk hiding inside it: the competence illusion.

I started as an AI skeptic. Through my enterprise work and involvement with FINOS, I’ve seen its potential to help people understand legacy systems, contribute to open source and turn ambition into capability faster.

But polished output can hide weak reasoning just as easily.

For leaders, the questions go beyond “Did you deliver?”

Can you explain the assumptions? Defend the trade-offs? Take responsibility when it goes wrong?

Use AI to accelerate learning. Keep ownership of the thinking.

Is your team getting better at the work – or just better at generating the deliverables?

🔗  Read my latest Forbes Technology Council article

Outseta and the .NET Foundation – changes coming up!

For years, .NET Foundation  membership records have lived in several places. Some members applied through our website. Others joined during earlier application rounds managed through spreadsheets. Many are also part of the members team on GitHub.

It worked – mostly.

But members had no simple way to review or update their information. And candidly, we could not always say with certainty who was still an active member.

We are fixing that.

All membership records are moving to one platform: Outseta. You will have your own account, where you can review and update the information we hold about you.

What you need to do

During the first week of October, every member will receive an email from contact@dotnetfoundation.org with a link to activate their account.

Click the link and create a password. You only need to do this once. Activating your account confirms that you want to remain a member of the .NET Foundation.

The activation link expires after 30 minutes. If you open it later, no problem: the page will let you request a new one.

A quick security reminder: please check the sender before clicking. The email will come from our own dotnetfoundation.org domain, and we will never ask you to send us your password. If a membership message comes from another address, do not click the link. Let us know instead.

If you have not received the email by the middle of October, check your spam or promotions folder. Still nothing? Email contact@dotnetfoundation.org, and we will help sort it out.

Thank you for being part of the .NET Foundation; and for helping us build a stronger, more connected community.

.NET Conf Community Days – Call for Speakers!

This is one of those announcements I am genuinely excited about. 🙂

For the first time, I am helping organize .NET Conf Community Days as part of .NET Conf 2026 — and I feel both humbled and honored to be involved.

The .NET community has been a big part of my professional life for a very long time. I have learned from it, contributed to it, spoken at events, organized events, met amazing people through it… so getting a chance to now help shape a part of .NET Conf itself feels pretty special.

And now we need you. 🚀

🎤 The Call for Speakers is officially open!

.NET Conf Community Days will take place on November 12–13, 2026, with two days of sessions led by the broader .NET community.

Web, desktop, mobile, AI, cloud, IoT, gaming, DevOps, open source, architecture, developer practices — if it involves .NET or is something useful and exciting for developers, we want to hear about it.

And please do not think you have to be a “professional conference speaker” to submit.

Some of the best talks come from people sharing something they built, something they learned, something that failed spectacularly, or something they simply cannot stop talking about. 🙂

📅 CfS closes October 6
👉 https://sessionize.com/dotnetconf-community-2026

Very happy to be part of this for the first time.

Now go submit something. I want to see what you come up with. 😄

Space Is No Longer the Destination: It’s Becoming the Next Operating System for Earth

The “next big thing” in space technology is a shift from simply getting to space to living, working, and computing there. We are transitioning from an era dominated by one-off scientific launches to a mature, commercial space economy focused on infrastructure, scalability, and Earth-facing benefits.

Image

The most transformative advancements driving this Next Space Age include:

In-Orbit Servicing & Orbital Refueling

Historically, a satellite’s lifespan was strictly limited by how much fuel it carried at launch. Once out of fuel, a multi-million-dollar asset became space junk.

The Tech: Companies like Orbit Fab (developing “gas stations in space”) and Astroscale are actively pioneering orbital refueling and servicing systems.

Why it matters: In-orbit refueling fundamentally changes the economics of space. It enables “maneuverable” satellites that can change orbits to dodge debris or threats, dramatically extends the lifespan of space assets, and is the absolute prerequisite for massive, deep-space vehicles (like SpaceX ’s Starship) to reach the Moon and Mars.

Edge Computing and Data Centers in Space

Satellites generate mind-boggling amounts of data, but transmitting raw files back to Earth requires immense bandwidth.

The Tech: Companies are beginning to construct and deploy space-based data centers and software-defined satellites equipped with advanced AI chips.

Why it matters: By processing data “at the edge” (directly in orbit), satellites can filter out useless data (like cloud cover in Earth images) and only transmit the crucial insights. This reduces latency and bandwidth strain, enabling near-instantaneous decision-making for disaster response, military operations, and climate monitoring.

Direct-to-Device (D2D) Satellite Connectivity

The gap between cellular networks and satellite communication is rapidly disappearing.

The Tech: Instead of needing a heavy, specialized satellite phone or a dish (like Starlink), new low Earth orbit (LEO) mega-constellations are successfully integrating with standard consumer smartphones.

Why it matters: This technology eliminates cellular “dead zones” globally. Whether you are in the middle of the Pacific Ocean or deep in a desert, your everyday smartphone will be able to connect directly to a satellite for emergency services, texting, and eventually, voice and data.

Microgravity Manufacturing (Space Factories)

Some materials simply cannot be made properly on Earth because gravity interferes with their molecular structures.

The Tech: Companies like Varda Space Industries and Redwire are constructing automated “space factories” designed to manufacture goods in microgravity and return them to Earth.

Why it matters: Manufacturing in orbit allows for the creation of flawless semiconductors, incredibly pure fiber-optic cables (ZBLAN), advanced pharmaceuticals with perfect crystal structures, and even 3D-bioprinted human organs.

The Transition to Commercial Space Stations

The International Space Station (ISS) is approaching its retirement. Rather than building another government-run station, the private sector is stepping up.

The Tech: Private companies are building commercial orbital platforms. Startups like Vast (with its Haven-1 module), alongside aerospace giants building platforms like Starlab and Orbital Reef, are leading this charge.

Why it matters: These private stations will act as multi-purpose business parks in orbit, leasing out space for corporate research, space tourism, and the aforementioned microgravity factories.

Next-Gen Nuclear Propulsion

Standard chemical rockets are highly inefficient for deep-space travel. To make Mars or sustained lunar bases viable, we need better engines.

The Tech: Major investments are being poured into Nuclear Thermal Propulsion (NTP) and Nuclear Electric Propulsion (NEP).

Why it matters: Nuclear rockets utilize fission to heat propellants, offering twice the efficiency of chemical rockets. This would slash transit times to Mars from nine months to just three or four, drastically reducing astronauts’ exposure to harmful deep-space radiation and microgravity muscle degradation.

Summary

If the last decade of space tech was defined by cheaper launches (thanks to reusable rockets), this next era is defined by utility. Space is no longer just a destination – it is fast becoming the ultimate platform for Earth’s digital and industrial infrastructure.

How AI’s “J-Space” Is Similar To, And Different From, The Human Brain

When people describe AI as “thinking,” they often imagine something brain-like happening inside the model. That intuition is not completely wrong, but it can also be misleading. A useful way to think about modern AI is that it operates in a kind of high-dimensional meaning space: a “J-space,” or more commonly, a latent or embedding space, where words, images, concepts, patterns, and relationships are represented as mathematical positions and directions.

The human brain also seems to build internal spaces of meaning. We do not store the word “apple” as a dictionary entry alone. We connect it to taste, color, childhood memories, gravity, orchards, nutrition, symbols, jokes, and maybe the smell of an autumn kitchen. Both AI systems and human brains compress the world into internal representations. But the way they form, use, and experience those representations is profoundly different.

The Similarity: Both Build Maps Of Meaning

Modern AI models do not understand text as flat strings. They convert tokens, images, sounds, or other inputs into vectors: long lists of numbers that place those items inside a high-dimensional space. In that space, related things tend to sit near each other. “King” and “queen” are closer than “king” and “toaster.” A medical symptom may cluster near related diagnoses. A trading term like “liquidity” may sit near market depth, spreads, order books, and volatility.

The brain appears to do something comparable, though biologically rather than mathematically. Neurons fire in patterns. Groups of neurons encode features, associations, expectations, and sensory memories. Our mental model of “dog” is not stored in one neuron; it emerges from distributed activity across many systems: vision, language, emotion, memory, motor response, and social experience.

So at a high level, both AI and brains create internal maps. These maps let them generalize. If an AI has learned relationships between “forms,” “fields,” “validation,” and “workflow,” it can reason about a new text-to-form system it has never seen before. If a person has seen enough financial applications, they can understand a new trading UI without reading every line of documentation.

That is the first real similarity: intelligence needs compression. Neither AI nor humans can keep every detail of the world in raw form. Both need internal structures that preserve what matters.

The Difference: AI’s Space Is Mathematical, The Brain’s Space Is Lived

The biggest difference is that AI’s J-space is not experienced. It is not conscious. It has no body, no pain, no hunger, no embarrassment, no delight, no fear of being wrong in front of a room full of people. Its representations are powerful, but they are not lived from the inside.

A human concept is embodied. “Hot” is not merely close to “fire” in a semantic field. It is connected to skin, reflex, danger, comfort, coffee, fever, memory, and survival. “Market crash” is not just a pattern of words; for a trader or technologist in financial services, it may carry stress, institutional memory, regulatory implications, and the muscle memory of incident response.

AI can model those associations statistically. It can write convincingly about them. But it does not feel the stakes. It predicts and transforms patterns; it does not inhabit them.

That difference matters because human intelligence is not only pattern recognition. It is pattern recognition tied to consequence.

AI Learns From Artifacts; Humans Learn From Being In The World

AI models are trained on data: text, images, code, audio, video, logs, documents, and other artifacts humans or systems have produced. That gives AI access to enormous breadth. It can absorb patterns across medicine, law, software, finance, literature, and history at a scale no human can match.

But humans learn by acting in the world. A child does not learn “cup” only by reading millions of sentences about cups. They grab one, drop it, spill from it, see someone react, and gradually build a concept that blends physics, language, social behavior, and intent.

This is why AI can be strangely brilliant and strangely brittle. It may explain an architecture pattern beautifully, then make a basic mistake about the operational reality. It may generate a plausible workflow that ignores the messy constraints of real organizations: permissions, incentives, audits, legacy systems, procurement, fear, politics, and fatigue.

The brain is slower and narrower, but it is grounded. AI is broad and fast, but often indirect.

AI’s J-Space Is More Inspectable, But Less Understandable

There is an interesting paradox here. AI representations are, in one sense, more inspectable than the brain. We can look at vectors, activations, attention patterns, embeddings, and model weights. We can probe them, visualize them, cluster them, and compare them.

But that does not mean we fully understand them.

A neural network may contain billions or trillions of parameters. Its “knowledge” is not stored as tidy facts. It is smeared across the system. Similarly, the human brain does not have a clean folder labeled “childhood,” another labeled “C#,” and another labeled “fear of public speaking.” Both systems are distributed and emergent.

Still, there is a difference in kind. Brain activity is part of a living organism with goals, homeostasis, emotion, and self-preservation. AI activation is computation inside an engineered system. Both are complex, but they are complex in different ways.

The Brain Has Memory; AI Has Context

Humans have durable autobiographical memory. We remember who we are, what happened to us, what we regret, what we want, and what we promised. Memory shapes identity.

AI models have something more limited. A model has trained knowledge baked into its parameters, and during a conversation it has context. Some systems may also have external memory tools, retrieval systems, profiles, or databases. But this is not the same as human memory. It is more like a combination of pattern recall, document retrieval, and temporary working context.

That difference changes everything.

A human remembers not only information, but meaning. “I failed at this before” changes how a person approaches a problem. “My father taught me this” changes how a memory feels. “This community trusted me” changes how a leader behaves.

AI can be given those facts. It can reason over them. But it does not become accountable to them in the human sense.

Creativity: Similar Shape, Different Source

AI creativity often looks like movement through J-space. It combines distant concepts, finds analogies, completes patterns, and generates variations. Ask it to connect open source governance, financial regulation, and agentic AI, and it can produce something useful because those regions of meaning can be mathematically traversed and recombined.

Human creativity also involves connecting distant ideas. But it is powered by intention, taste, frustration, memory, risk, and identity. A person creates not only because an association is possible, but because something matters.

That is why AI is excellent for ideation, synthesis, drafting, and reframing. But the strongest results usually come when a human provides judgment: “This is too generic.” “This misses the politics.” “This sounds clever but not true.” “This is the sentence that matters.”

AI can generate. Humans can care.

Why The Comparison Still Matters

Even though AI is not a brain, comparing AI’s internal spaces to human cognition is useful. It helps us understand why AI can generalize, hallucinate, surprise us, and fail in non-obvious ways.

It also helps us design better systems. If we know AI works through representations rather than lived understanding, we should give it grounding: tools, retrieval, feedback, constraints, examples, tests, and human review. In regulated domains like finance, healthcare, and law, this is not optional. A fluent answer is not the same as a correct answer. A confident pattern is not the same as accountable judgment.

The future is not about pretending AI is a human brain. It is about understanding what kind of intelligence it actually is.

Conclusion

AI’s J-space and the human brain are similar in that both create internal maps of meaning. Both compress complexity. Both use distributed representations. Both can generalize from prior patterns to new situations.

But they are not the same. AI’s space is mathematical, trained, and computational. The brain’s space is biological, embodied, emotional, and lived. AI has representations without experience. Humans have experience that gives representations weight.

That distinction is not a reason to dismiss AI. It is a reason to use it well.

AI is not a synthetic brain. It is a new kind of cognitive instrument: a machine that can navigate meaning at scale, but still needs human grounding, human context, and human judgment to turn pattern into wisdom.

How to make AI a better consumer of innersource?

AI is rapidly becoming a new class of “developer inside the organization”, not just writing code, but navigating repositories, understanding conventions, reusing components, and stitching together systems. That makes a quiet but important question suddenly urgent: how do we make AI a good consumer of inner source?

Embodied AI connecting to systems

Inner source promises open-source style collaboration inside the enterprise: shared repositories, reusable components, transparent contribution flows, and cross-team ownership. But most of that was designed for humans. AI agents don’t naturally understand social contracts, repo norms, or the “tribal knowledge” that keeps inner source ecosystems coherent. If we want AI to be useful here, we need to redesign the interface between agents and codebases.

1. Treat inner source as a product surface, not just a codebase

Most inner source initiatives fail for AI consumption because they expose repositories, not intent.

Humans can infer:

  • “This repo is the canonical implementation”
  • “This folder is deprecated but still used”
  • “This library is preferred over that one in finance apps”

AI cannot reliably infer that unless it is explicitly encoded.

To fix this, inner source needs a product layer:

  • Canonical ownership metadata (who maintains what)
  • Stability signals (experimental / recommended / deprecated)
  • Domain tags (“risk”, “pricing”, “identity”, “trading UI”)
  • Usage guidance (“use this for new builds, not legacy wrapper X”)

This is where initiatives like the FINOS ecosystem are relevant, because they already enforce structured governance across financial open source components, which is exactly the kind of signal AI systems need.

2. Make conventions machine-readable, not just documented

Most organizations rely on README files, wikis, and architecture pages. That works for humans who can interpret ambiguity. It fails for agents that need deterministic structure.

To make inner source AI-consumable:

  • Move conventions into structured formats (YAML, JSON, CODEOWNERS++, ADR metadata)
  • Encode architectural decisions as queryable artifacts (not prose)
  • Standardize “how to use this repo” into schema-driven manifests

Think of this as upgrading from:

“Read the wiki before contributing”

to:

“Query the repo for its rules of engagement”

3. Give AI a semantic map of the ecosystem

A single repository is easy. An inner source ecosystem is not.

AI agents need a graph, not a folder tree:

  • Dependency relationships between services
  • Component reuse graphs (who uses what)
  • Domain boundaries (payments vs risk vs onboarding)
  • Critical paths (what breaks trading systems vs what is cosmetic UI)

This is where code intelligence platforms and tools like GitHub’s ecosystem (especially with advanced code search and dependency graphing) become foundational. Without a semantic map, AI will “hallucinate architecture” by guessing.

4. Use MCP-style connectors to standardize access patterns

A major step forward in agentic systems is the rise of structured tool interfaces, such as the Model Context Protocol (MCP). The key idea is simple: instead of letting AI scrape repositories, you give it tools.

For inner source, this means:

  • search_components(domain=”risk”)
  • get_recommended_library(use_case=”charting”)
  • validate_usage(pattern=”trading-ui-grid”)
  • find_owner(service=”pricing-engine”)

This turns inner source from passive code storage into an interactive system of APIs for developers and agents alike.

5. Encode “trust and safety” as first-class signals

In regulated environments (especially financial services) AI consuming inner source cannot be neutral. It must understand:

  • What is production-safe
  • What is experimental
  • What requires review or approval
  • What is prohibited for certain environments

Without this, AI will confidently suggest technically correct but operationally unsafe patterns.

This is where governance frameworks from organizations like FINOS become particularly relevant: they already define structured compliance and lifecycle expectations for software in financial ecosystems.

6. Teach AI organizational memory, not just code syntax

Inner source is not just code reuse—it’s history:

  • Why something was built
  • Why something was deprecated
  • Why a “simple refactor” never happened
  • Why two seemingly identical libraries coexist

Humans absorb this over years. AI needs explicit memory scaffolding:

  • Architecture Decision Records (ADRs)
  • “Why this exists” documentation
  • Incident-linked provenance (what broke in production before)
  • Migration narratives

Without this layer, AI will repeatedly rediscover old mistakes, at machine speed.

7. Optimize repositories for retrieval, not just build

Most repos are optimized for:

  • CI/CD
  • Compilation
  • Developer onboarding

Very few are optimized for:

  • Semantic search
  • Chunked retrieval
  • Contextual embedding
  • Agent navigation

To improve AI consumption:

  • Flatten overly nested abstractions where possible
  • Add explicit “entry points” for understanding a system
  • Provide curated “golden paths” (how 80% of users should build things)
  • Reduce ambiguity in naming (AI is extremely sensitive to naming drift)

This is where platforms like GitHub are increasingly important, because code search and semantic indexing become the primary interface—not folder browsing.

8. Design for “collaborative AI contribution loops”

The end state is not AI reading inner source. It is AI participating in it.

That requires:

  • PR generation with rationale explanations
  • Automated alignment to repo conventions
  • Feedback loops from reviewers back into agent memory
  • Continuous refinement of “what good looks like” per repo

Over time, the system becomes self-calibrating: inner source defines AI behavior, and AI behavior reshapes inner source norms.

Closing thought

Inner source was originally about scaling human collaboration across silos. AI changes the equation: now we are scaling machine collaboration with human-designed ecosystems.

The organizations that succeed won’t just “use AI on their codebases.” They will redesign inner source so that it is legible, navigable, and governable by agents: with as much care as we once applied to human developers.

Because in the near future, the most important contributor to your inner source ecosystem might not be a team at all—but an agent that never sleeps, never forgets, and only understands what you made explicit enough to be understood.

Joining the .NET Foundation Board

I’m #humbledandhonored to share that I have been appointed to the .NET Foundation Board of Directors – Thank You for your service, Kendall Miller!

The .NET ecosystem has played a significant role throughout my career – as a developer (of it and with it), architect, open source contributor, community organizer, speaker, mentor, and Microsoft MVP. Being entrusted with helping guide the future of this community is both humbling and exciting.

Thank you to everyone who voted, supported my candidacy, encouraged me to run, and contributed to the conversations along the way. Most importantly, thank you to the countless maintainers, contributors, volunteers, sponsors, and community members who make the .NET ecosystem thrive every day.

I look forward to working alongside my fellow board members and the broader community to help the Foundation continue to grow, support its projects, and create opportunities for the next generation of developers.

Here’s to the future of .NET and open source. Looking forward to be working with the new members, Meagon Hansen and Hayden Barnes, and congrats Mitchel Sellers on his re-election to the board! Louëlla Creemers, Chris Woody Woodruff – thank you for your service! Chris Sfanos, Kevin Griffin, Jonathan “J.” Tower, Irina Dominte Scurtu, thank you for the trust in me, looking forward for collab!