Source-First .NET MAUI with Copilot-Powered Contribution Gestures — Multi-Model Proposals

proposal-codex.md

Proposal: Source-First .NET MAUI with Copilot-Powered Contribution Gestures

Introduction

PolyPilot hints at a future where the tool a developer is running is also the tool they are editing, with Copilot standing by to patch the live codebase and relaunch the experience instantly. Today, .NET MAUI largely hides behind NuGet packages; developers consume binaries, report bugs, and wait for maintainers to publish fixes. Flutter, conversely, places the framework and engine sources on every machine, inviting developers to debug, instrument, and modify the stack. This proposal imagines .NET MAUI adopting a similar source-first distribution and pairing it with Copilot-powered contribution gestures so every MAUI developer can become a potential framework contributor while building their app.

1. Vision: Day-to-Day Developer Experience

A source-first MAUI workspace would clone the framework next to every app, exposing src/Core, src/Controls, platform handlers, and native bindings. Developers could set breakpoints inside handlers, tweak layout logic, and instantly rerun their app using a PolyPilot-style relaunch script. Copilot would surface a palette of gestures—“diagnose handler,” “draft fix,” “write regression test,” “prepare PR”—that operate on the shared workspace. Instead of filing an issue and waiting weeks, a developer seeing a CollectionView bug would invite Copilot to trace the framework, propose a fix, rebuild the framework slice, and redeploy the app within the same debugging session.

The experience hinges on seamless transitions between app logic and framework internals:

• Unified Solution Views show both the app and framework projects, so file navigation, search, and refactoring span the entire stack.
• Relaunch Automation rebuilds only touched projects, copies artifacts to platform-specific cache folders, and redeploys to the active device or simulator with a single command.
• Contextual Copilot Prompts ingest live diagnostics (stack traces, UI tree dumps, layout bounds) and produce targeted suggestions rooted in framework files instead of opaque binaries.
• Self-Hosted Documentation lives next to the source, allowing Copilot to link to architecture notes, handler diagrams, or platform-specific guides while it explains changes.

A normal day might involve shipping an app feature, noticing an accessibility quirk in EntryHandler, invoking the “Copilot fix framework” gesture, accepting a patch, rerunning tests, and submitting a PR before lunch. Developers stay inside their IDE, yet the framework evolves continuously because every user can apply improvements on demand.

2. Technical Architecture

Delivering this experience requires coordinated changes across distribution, build orchestration, Copilot integration, and governance.

2.1 Source Distribution

1. Workload Manifests with Commits: dotnet workload install maui --source would fetch manifest files pointing to specific commits of dotnet/maui, dotnet/runtime, Essentials, Graphics, and Android/iOS binding repos. The installer clones shallow copies into a shared cache (e.g., ~/.dotnet/maui-src) with signed provenance.
2. Workspace Projection: App templates add the framework sources as submodules or git worktree folders under .maui-src. MSBuild switches from PackageReference to ProjectReference, so the app compiles against local framework projects. Solution filters (MauiFramework.slnf, AppWithFramework.slnf) keep IDE load manageable.
3. Binary Baselines: To avoid rebuilding the world, the installer also downloads prebuilt artifacts keyed by commit hash. Developers only recompile projects they modify; unchanged assemblies link from the cache, similar to Flutter’s engine artifacts.
4. Update Pipeline: dotnet workload update maui --source pulls new commits, rewrites the manifest, and offers a guided rebase for any local patches. Copilot can automate conflict resolution and highlight downstream impacts.

2.2 Build and Relaunch Flow

1. Graph-Aware MSBuild uses msbuild /graphBuild so framework and app projects build in parallel. Custom targets detect touched files and skip unaffected heads.
2. Native SDK Coordination ensures Xcode, Android SDK, Windows SDK, and related tooling match the framework commit. A framework.local.props file records paths and versions; maui doctor validates the environment.
3. Binding Regeneration Hooks wrap existing scripts for Java.Interop, WinUI projections, and SkiaSharp assets. Copilot can call these hooks automatically when edits require regeneration.
4. maui-relaunch Command chains dotnet build MauiFramework.slnf, dotnet build AppWithFramework.slnf, platform deployment, and debugger attachment. It detects when Hot Reload suffices versus when a full redeploy is necessary, minimizing iteration time.

2.3 Copilot Integration

1. Workspace Indexing: Copilot indexes app files, framework sources, build logs, and diagnostics. Sensitive app data can be excluded via configuration, but framework files remain fully accessible for AI reasoning.
2. Gesture CLI: A dotnet maui-copilot tool orchestrates gestures—collecting telemetry, launching prompts, applying patches, and triggering builds. IDE extensions simply forward context and display results.
3. Patch Provenance: Copilot-generated edits include metadata (prompt, timestamp, diff summary) stored in .copilot/provenance.json. PR templates reference this metadata for transparency.
4. Testing Hooks: Gestures automatically run the smallest relevant test matrix (unit tests, handler tests, device samples) and document results in diagnostics/<issue>.md so reviewers see evidence without re-running everything locally.

2.4 Governance and Security

1. Signed Manifests ensure developers start from trusted commits. The installer verifies Git signatures and checksums before populating caches.
2. Contribution Policies embed analyzer rules, API check tooling, and documentation checklists directly into the workspace. Copilot knows these policies and can warn when a suggested change violates them.
3. Upstream Hygiene: The gesture CLI enforces clean working trees, rebases on main, and requires dotnet format and API checks before opening PRs via gh pr create. Developers authenticate with GitHub, and Copilot drafts the PR body for review.

3. The Contribution Gesture Workflow

1. Observation: Running the app with source-built MAUI, a developer notices that Entry loses focus when VoiceOver is active. They hit Ctrl+Shift+G to launch the gesture palette and choose “Capture framework issue.” Copilot records the stack trace, UI tree, device OS, and reproduction steps into diagnostics/entry-voiceover.md.
2. Localization: Copilot inspects recent history, handler code, and telemetry to propose likely roots (e.g., EntryHandler.iOS.cs, AccessibilityService). It presents annotated code snippets explaining why each spot might misbehave.
3. Patch Drafting: Selecting “Generate fix” lets Copilot edit the handler, introducing platform-aware guards or timing adjustments. It concurrently creates regression tests under src/Controls/tests and updates relevant docs. All changes land on a new branch copilot/entry-voiceover.
4. Validation: The gesture runs dotnet format, targeted dotnet test, and maui-relaunch ios to verify the scenario on the developer’s simulator. Failures pause the workflow and surface logs for manual adjustment.
5. Documentation: Copilot prompts the developer for a plain-language summary, then drafts changelog entries, release note snippets, and optional screenshots. Metadata attaches to the diagnostics file.
6. Packaging: “Prepare PR” rebases the branch on the latest upstream commit, squashes fix commits if desired, re-runs API checks, and confirms a clean git status.
7. Submission: The CLI opens a PR with labels (area/handlers, platform/ios, kind/bugfix), attaches diagnostics, and links any GitHub issues. Copilot watches CI results and can suggest follow-up patches if pipelines fail.

4. Benefits

4.1 Faster Evolution

• Developers can convert a failing scenario into a framework fix within the same debugging session, shrinking turnaround from weeks to hours.
• Copilot accelerates comprehension of complex handlers, enabling newer contributors to address deep bugs.
• Real apps validate patches immediately, reducing regressions that only appear outside synthetic samples.

4.2 Higher Quality

• Telemetry-rich PRs give maintainers concrete evidence (logs, screenshots, device data) alongside code.
• Regression tests added through gestures steadily raise coverage in historically brittle areas (collection layouts, gesture recognizers, handler mappings).
• Copilot explanations double as documentation, leaving a trail of rationale for future maintainers.

4.3 Stronger Community

• Source distribution builds shared ownership akin to Flutter’s culture; developers feel empowered to fix what they break.
• Organizations can maintain lightweight forks for urgent hotfixes while tooling nudges them toward upstreaming.
• Copilot gestures teach best practices—dependency injection, handler mapping patterns, accessibility guidelines—raising the baseline expertise across the ecosystem.

4.4 Tooling Momentum

• IDEs gain deeper context, enabling hybrid debugging where Hot Reload, Live Visual Tree, and Copilot collaborate.
• PolyPilot-style relaunch scripts become standard, reducing device deployment friction.
• Dev containers or Codespaces images can package the entire stack, improving onboarding for new contributors.

5. Limitations & Challenges

5.1 Build Costs

• Rebuilding MAUI, Essentials, and bindings takes minutes even on high-end hardware; careless edits could derail productivity.
• Developers need ample disk space and RAM to host multiple platform toolchains plus source caches.
• CI parity must be guarded carefully so cached local builds do not mask missing targets.

5.2 Dependency Complexity

• MAUI spans the .NET runtime, Xamarin.Android, Xamarin.iOS, WinUI, SkiaSharp, and Blazor bits. Deciding which layers ship as editable source versus binary dependencies is non-trivial.
• Version drift is inevitable; teams might hold private patches for months. Tooling must make rebasing painless and highlight stale forks.
• The workload download size would balloon, requiring resumable installers and selective sparse checkouts.

5.3 Governance

• Maintainer bandwidth could be overwhelmed by Copilot-fueled PRs. Automated triage, labeling, and reviewer rotation tools would be mandatory.
• API stability needs strict checklists so local edits do not accidentally introduce public surface changes.
• Signed provenance and reproducible builds become essential to prevent tampered framework distributions.

5.4 Platform Constraints

• Many MAUI issues stem from native SDK quirks; source access cannot fix an Android or iOS platform bug. Expectations must be managed so developers know when the fix requires OS updates.
• Licensing for Xcode or certain OEM dependencies may block automated setup; documentation must steer developers through manual installs.
• Blazor Hybrid adds ASP.NET Core dependencies that might remain binary-only, limiting how “source-first” the entire stack can become.

5.5 Copilot Constraints

• Gesture quality depends on rich telemetry; sparsely captured context could yield misguided fixes.
• AI models must stay current with MAUI’s API surface. Without continual fine-tuning, Copilot might recommend obsolete handlers or deprecated patterns.
• Organizations in air-gapped or regulated environments may not be able to use Copilot, so the workflow must degrade gracefully to manual steps.

6. Counter-Arguments

6.1 Merits of Binary Distribution

Binary workloads are simple: install once, trust Microsoft to ship optimized bits, and avoid the cognitive load of framework internals. Deterministic packages ensure everyone shares identical assemblies, simplifying support. Building MAUI locally risks inconsistent optimizations, larger app bundles, and divergent behavior if developers forget to reapply patches.

6.2 Reviewer Bandwidth and Quality

Opening the floodgates to community patches sounds great until maintainers drown in PRs. Copilot can draft fixes rapidly, but human review remains crucial to guard against subtle regressions. Without significant investment in automation, documentation, and reviewer onboarding, the model could create more noise than signal.

6.3 Structural Differences from Flutter

Flutter controls its rendering stack top to bottom, so shipping source aligns naturally with its architecture. MAUI is a thin layer over native toolkits; many bugs originate in platform code outside Microsoft’s control. Even if developers patch MAUI locally, they cannot fix a UIKit regression until Apple ships an update, limiting the payoff of source access.

6.4 Fragmentation Risks

Allowing pervasive local modifications invites ecosystem drift. Enterprises might maintain bespoke forks forever, complicating support cases (“Does this bug exist in vanilla MAUI?”). Binary distribution enforces alignment and gives Microsoft a single set of artifacts to service and patch.

7. Conclusion: Feasibility and Value

A source-first MAUI paired with Copilot gestures would radically shorten the loop between discovering a bug and landing a fix. Developers would gain unprecedented visibility into handlers, layouts, and platform bridges, and the framework could evolve in lockstep with real-world app needs. The model resonates with PolyPilot’s self-hosted ethos and with Flutter’s culture of community contributions.

Yet the hurdles are equally real: build times, dependency sprawl, reviewer capacity, platform licensing, and AI reliability all demand serious investment. A pragmatic path would introduce optional source packs, gesture tooling, and relaunch scripts for advanced contributors while keeping binary workloads for mainstream app developers. If pilot programs demonstrate sustainable velocity and quality, Microsoft could expand the model gradually, ensuring governance and tooling scale alongside enthusiasm.

In short, the approach is ambitious but attainable. With thoughtful tooling, caching, and Copilot integration, MAUI could cultivate a virtuous cycle where every developer is empowered to fix the framework they rely on. The payoff—faster evolution, richer community engagement, and higher-quality releases—justifies prototyping the idea even if the ultimate rollout remains hybrid for the foreseeable future.

proposal-gemini.md

Proposal: Source-First .NET MAUI with Copilot-Powered Contribution Gestures

1. Vision: The Democratization of the Framework

Imagine a world where the boundary between "app developer" and "framework contributor" dissolves. Today, when a .NET MAUI developer encounters a bug in the CollectionView or finds a missing property on a Button handler, they hit a wall. They can file an issue on GitHub, wait for triage, wait for a fix, wait for a service release, and finally update their NuGet packages weeks or months later. The feedback loop is measured in days or weeks.

In the Source-First .NET MAUI vision, this loop tightens to minutes.

The developer is debugging their app. They notice the CollectionView isn't recycling cells correctly on iOS. Instead of sighing and writing a hacky workaround in their own code, they Command-Click into CollectionView.iOS.cs. But instead of seeing metadata or decompiled headers, they see the actual source code, live and editable, part of their workspace.

They right-click the buggy method and select "Copilot: Fix Framework Bug".

Copilot analyzes the local context, the framework code, and perhaps even similar issues from the issue tracker. It proposes a fix directly in the framework file. The developer reviews it, hits "Apply", and—crucially—the framework recompiles incrementally alongside their app. The app relaunches with the fix active.

It works. The developer is delighted. But the vision goes further.

The IDE then prompts: "You've patched the framework locally. Would you like to upstream this fix to dotnet/maui?"

With one click, a Pull Request is generated, complete with test cases derived from the developer's own reproduction scenario. The developer hasn't just fixed their own problem; they've improved the platform for everyone. They are no longer just a consumer of .NET MAUI; they are a co-owner.

This is the PolyPilot model applied to the framework itself: a self-healing, community-driven ecosystem where the tools we use are as malleable as the software we build with them.

2. Technical Architecture

Achieving this requires a fundamental shift in how .NET MAUI is distributed and consumed. Currently, MAUI is delivered as a set of NuGet packages and workload artifacts (binary assemblies). Flutter, by contrast, downloads the engine and framework source code to the user's machine, pointing the project build system directly to these local sources.

To replicate and enhance this for .NET MAUI, we propose a Hybrid Source Distribution Model.

2.1. The "Source-Link 2.0" Distribution

Instead of abandoning NuGet, we leverage it. We introduce a new breed of "Source Packages" or "Editable Workloads".

1. The Local Repository Cache: The .NET CLI (dotnet) manages a local clone of the dotnet/maui repository (or specific release tags of it) in a user-accessible location (e.g., ~/.dotnet/src/maui/8.0.3/).
2. Project File Integration: A standard .csproj usually references assemblies. In "Source Mode," the project file dynamically swaps these binary references for direct project references (<ProjectReference>) to the local framework source.

   <Project Sdk="Microsoft.NET.Sdk">
     <PropertyGroup>
       <UseMauiSource>true</UseMauiSource>
       <MauiSourceVersion>8.0.3</MauiSourceVersion>
     </PropertyGroup>
   </Project>

3. Intelligent Incremental Build: The greatest challenge is build time. Rebuilding the entire MAUI framework for every app change is non-viable. The architecture must support Partial Recompilation.
   • When UseMauiSource is enabled, the build system treats the framework projects as part of the solution but keeps them in a "frozen" state unless modified.
   • Roslyn (the C# compiler) and MSBuild are optimized to detect that only one file in Microsoft.Maui.Controls has changed. It rebuilds only that assembly and hot-swaps it into the app build.

2.2. Copilot Integration Layer

The "Copilot-Powered" aspect requires deep integration into the IDE (Visual Studio / VS Code) and the build pipeline.

• Context Awareness: Copilot needs to understand that the user is editing framework code, not app code. It must respect the framework's coding style, internal architecture, and public API surface rules (breaking changes are forbidden).
• The "Shadow Test" Harness: When a developer fixes a bug, Copilot shouldn't just patch the code. It should generate a reproduction test case in the framework's test suite.
  • The architecture includes a lightweight "Test Runner" that can execute the specific unit test associated with the modified component, validating the fix locally without running the full CI suite (which takes hours).

3. The Contribution Gesture

The workflow is the "Gesture" - the natural, repeatable action a developer takes to improve the tool.

Step 1: Diagnosis & Navigation

Scenario: A label in a HorizontalStackLayout is getting truncated on Android. Action: The developer uses the "Live Visual Tree" to select the Label. They click "Go to Source." Result: The IDE opens LabelHandler.Android.cs from the local source cache. It is fully syntax-highlighted and Intellisense-aware.

Step 2: The "Fix" Prompt

Action: The developer highlights the MapText method and invokes Copilot: "This label is truncating prematurely when inside a stack layout. Fix the measure logic." Mechanics:

• Copilot reads the current method code.
• It is fed context about the Label's parent (HorizontalStackLayout) from the running app's memory (via the debugger).
• It generates a patch for LabelHandler.Android.cs.

Step 3: Local Verification (The Feedback Loop)

Action: The developer accepts the suggestion. System Response:

• Hot Reload (Level 2): If possible, the change is Hot Reloaded.
• Fast Rebuild: If the change is structural, the IDE triggers a targeted rebuild of the Microsoft.Maui project. Because only one file changed, the incremental build takes seconds, not minutes.
• The app updates. The truncation is gone.

Step 4: The "Upstream" Gesture

Action: The developer is happy. They click a small "Contribute Fix" button that has appeared near the modified code. Mechanics:

• The system creates a new git branch in the local dotnet/maui repo clone: fix/label-truncation-android.
• It commits the change with a descriptive message generated by Copilot.
• It pushes this branch to the developer's fork (creating one if necessary).
• It opens a PR creation window in the browser (or inside the IDE) targeting dotnet/maui:main.
• Crucially: Copilot automatically fills the PR description, referencing the files changed and explaining the logic. It also tags the relevant area owners (e.g., @dotnet/maui-android-owners).

4. Benefits

4.1. Accelerated Framework Evolution

Currently, the .NET team is the bottleneck for fixes. By empowering thousands of developers to fix the bugs they encounter, the volume of high-quality patches increases. While triage is still needed, the "hard work" of diagnosis and coding is distributed.

4.2. "It Just Works" (Eventually)

If a developer hits a bug, they are currently blocked. In the Source-First model, they are never blocked. They can fix it locally and proceed. Even if the PR isn't merged immediately, their local build works. They can ship their app. This removes the existential dread of "waiting for Microsoft."

4.3. Educational Value

Developers often treat frameworks as "black boxes." By exposing the source, developers learn how the magic works. They become better engineers by reading the production-grade code of the framework they use daily.

4.4. Community Ownership

This model shifts the psychological relationship from "Consumer/Vendor" to "Collaborator/Maintainer." It builds a sense of shared ownership over the platform's success.

5. Limitations & Challenges

We must be realistic. .NET MAUI is not Flutter.

5.1. The Build Time Elephant

Flutter's Dart compiler is incredibly fast. The .NET build system (MSBuild) is... mature. Compiling the full dotnet/maui solution is resource-intensive.

• Challenge: A full clean build of MAUI can take 10-20 minutes on a decent machine.
• Mitigation: We rely entirely on the correctness of incremental builds. If the incremental build is flaky, the experience collapses. We would need significant investment in build acceleration (e.g., relying on pre-built reference assemblies and only recompiling the implementation assembly being touched).

5.2. The Native Binding Complexity

Flutter draws pixels on a Skia canvas. It controls the whole stack. MAUI wraps native controls.

• Challenge: A bug might not be in C#; it might be in the binding to the underlying Android/iOS API, or in the interaction between the C# proxy and the native view.
• Complexity: Fixing a bug might require understanding Objective-C/Swift or Java/Kotlin behavior, which Copilot can help with, but the "source" available to the C# developer is only the wrapper, not the OS widget itself.

5.3. Binary Compatibility & Versioning

If I ship my app with a locally patched MAUI, I am effectively shipping a "fork."

• Challenge: When the official .NET MAUI 9.0.1 comes out, does it overwrite my fix? Do I get merge conflicts in my framework?
• Risk: Developers might drift onto permanent forks, fragmenting the ecosystem. The "Upstream" gesture must be so easy that staying on a fork is harder than contributing back.

5.4. The "Works on My Machine" Problem

• Challenge: A fix that works for the developer's specific app layout might break a different layout.
• Mitigation: This is why the Shadow Test Harness is critical. Copilot must generate regression tests. Without tests, user-submitted PRs will simply flood the maintainers with regressions.

6. Counter-Arguments (Steel-manning the Status Quo)

Why shouldn't we do this?

6.1. "Frameworks Should Be Immutable"

Argument: The greatest value a framework provides is stability. When Button behaves like Button, I can trust it. If every developer is running a slightly mutated version of the framework, reproducing bugs becomes a nightmare. "My app crashes." "Well, what patches do you have applied to your MAUI kernel?" Validity: High. We risk "DLL Hell 2.0" where no two developer environments are identical.

6.2. The Complexity Barrier

Argument: The majority of developers just want to build apps. They do not want to see LabelHandler.Android.cs. They do not want to compile the framework. Forcing source distribution adds gigabytes of download size and CPU cycles that 80% of users don't need. Validity: Moderate. This mode should likely be opt-in (e.g., "Developer Mode: Advanced"). The default should remain binary NuGet packages for speed and simplicity.

6.3. The "Not Invented Here" Trap

Argument: Flutter does this because Dart is a custom language and Flutter is a custom renderer. .NET has a rich history of binary distribution (GAC, NuGet) that works. Moving to source distribution is fighting the grain of the entire .NET ecosystem, which is built around assemblies, not source files. Validity: High. Tooling (Resharper, OmniSharp) assumes stable binary references. Changing this breaks the ecosystem's assumptions.

7. Conclusion

The proposal for a Source-First .NET MAUI is not just about fixing bugs; it is about changing the culture of .NET development.

The current binary-only distribution model treats developers as users. The source-first model treats developers as partners.

While the technical hurdles—specifically build times and ABI stability—are significant, they are not insurmountable. The "PolyPilot" proof-of-concept demonstrates that when the tool itself is malleable, the user becomes infinitely more powerful.

If .NET MAUI wants to compete with Flutter not just in performance, but in community velocity, it must open the gates. It must lower the barrier to contribution from "Clone the repo and spend 3 hours setting up the build" to "Right-click -> Fix with Copilot."

Recommendation: Microsoft should launch a "Source Link 2.0" pilot for .NET MAUI. Start by allowing developers to easily swap one specific NuGet package (e.g., Microsoft.Maui.Controls) for a local source clone with a single toggle. Integrate Copilot into this workflow. Measure the PR volume.

The future of framework development isn't just open source; it's live source.

---

Drafted by Copilot CLI

proposal-opus.md

Proposal: Source-First .NET MAUI with Copilot-Powered Contribution Gestures

Author: Generated via PolyPilot
Date: 2025
Status: Exploratory Proposal

---

Executive Summary

This proposal explores a radical reimagining of .NET MAUI's distribution model: shifting from compiled NuGet packages to source distribution, combined with AI-assisted contribution workflows. The vision is inspired by Flutter's source-first approach and the self-modifying capabilities demonstrated by PolyPilot—a MAUI app that can instruct GitHub Copilot to modify its own source code, rebuild, and seamlessly relaunch itself.

The central question: Could every .NET MAUI developer become a framework contributor by default?

This document examines the technical architecture required, the potential benefits, the substantial challenges, and ultimately provides an honest assessment of feasibility.

---

1. Vision: The Developer Experience of Tomorrow

A Day in the Life

Imagine Sarah, a .NET MAUI developer building a banking app. She encounters a bug: the CollectionView flickers on iOS when using grouped headers with variable-height items. Today, she would file a GitHub issue, wait months for a fix, or implement an ugly workaround.

In the source-first world with Copilot gestures:

1. Sarah notices the flicker in her app running on her iOS simulator.

2. She invokes a contribution gesture—perhaps Ctrl+Shift+F or a menu item "Fix in MAUI Framework"—which opens a Copilot-assisted session scoped to the MAUI framework source.

3. Copilot analyzes the issue: It examines the CollectionView handler code, the iOS UICollectionView integration, and identifies the problematic invalidation cycle in grouped layout calculations.

4. Copilot proposes a fix in the local MAUI source, explaining the change in plain language: "The InvalidateLayout call triggers redundant measure passes when group headers have variable heights. This patch adds a dirty flag to coalesce invalidations within a single layout cycle."

5. Sarah reviews and accepts. The MAUI framework rebuilds locally—just the iOS platform target, incrementally—and her app hot-reloads with the framework change applied.

6. She validates the fix in her actual app context, with her actual data. The flicker is gone.

7. She triggers "Submit Upstream", which creates a properly formatted PR against dotnet/maui, complete with the Copilot-generated explanation, relevant issue links, and a test case.

8. Two weeks later, her fix ships in a MAUI servicing release. Her name is in the release notes. She's moved from consumer to contributor without ever leaving her development flow.

The Philosophical Shift

This isn't just about convenience—it's about ownership. Flutter developers often speak of feeling ownership over the framework because they can see it, modify it, and understand it. The MAUI NuGet package is a black box. Source distribution transforms it into a glass box.

The Copilot layer adds something Flutter doesn't have: guided exploration. The Flutter source is accessible but intimidating. With AI assistance, the barrier to understanding and modifying framework internals drops dramatically.

---

2. Technical Architecture

2.1 Source Distribution Mechanisms

There are three viable approaches to distributing MAUI as source:

Option A: Git Submodule Model

MyMauiApp/
├── src/
│   └── MyMauiApp/
├── frameworks/
│   └── maui/                    # git submodule → dotnet/maui
│       ├── src/
│       │   ├── Controls/
│       │   ├── Essentials/
│       │   └── ...
│       └── eng/
└── MyMauiApp.sln

Pros:

• Full Git history available
• Familiar to developers who've used submodules
• Easy to track upstream changes, create branches, submit PRs

Cons:

• Submodule UX is notoriously poor
• Full MAUI repo is ~2GB; excessive for most developers
• Version pinning via commit SHAs is fragile

Option B: Source Package Model (NuGet with Source)

A new NuGet package type that extracts source instead of binaries:

<PackageReference Include="Microsoft.Maui.Controls.Source" Version="10.0.31" />

The package would contain:

• Complete C# source files
• Project files configured for local building
• Source generators and analyzers
• Platform-specific sources with appropriate conditionals

Pros:

• Familiar NuGet workflow
• Precise versioning
• Incremental/selective source packages possible (e.g., just Controls.Source, not all of MAUI)

Cons:

• Novel package type requires tooling investment
• Lose Git history and easy upstream contribution
• Merging updates is complex

Option C: Hybrid "Source-on-Demand" Model

Default to binary packages, but with a gesture to "eject" to source:

dotnet maui eject-source Microsoft.Maui.Controls

This would:

1. Clone the relevant portion of the MAUI repo at the matching version
2. Reconfigure the project to reference local source instead of NuGet
3. Set up Git remotes for upstream contribution

Pros:

• Most developers stay on fast, binary path
• Source only materialized when needed
• Clean transition back to binary when done

Cons:

• Two-world complexity
• "Ejected" state requires careful management
• Risk of drift between local source and binary behavior

2.2 Build System Requirements

MAUI's build is substantially more complex than Flutter's:

Aspect	Flutter	.NET MAUI
Language compilation	Dart AOT/JIT (self-contained)	C# → IL → Platform-specific compilation
Runtime	Dart VM (bundled)	.NET runtime (separate installation)
Native bindings	Minimal (own rendering)	Extensive (platform SDK wrappers)
Platform SDKs	Embedder only	Full Xcode/Android SDK/Windows SDK
Build time (clean)	~2-3 minutes	~8-15 minutes (per platform)
Incremental build	Seconds	30-90 seconds

For source-first MAUI to be viable, we need:

1. Aggressive incremental builds: Changes to a single handler shouldn't rebuild the world. MSBuild's existing incrementality helps, but MAUI's multi-targeting and source generators create rebuild cascades.

2. Platform-selective compilation: Building iOS framework source on a machine doing Android development is waste. The build should intelligently target only relevant platforms.

3. Prebuilt runtime dependencies: The .NET runtime itself (CoreCLR, Mono) should remain binary. Source-first MAUI means source-first framework, not source-first runtime.

4. Shared compilation cache: Like Bazel's remote cache or Gradle's build cache, framework compilation artifacts could be shared across machines and developers.

2.3 Copilot Integration Architecture

The PolyPilot model provides a template. Key components:

┌─────────────────────────────────────────────────────────────┐
│                     Developer's IDE                          │
├─────────────────────────────────────────────────────────────┤
│  ┌─────────────┐  ┌─────────────────┐  ┌─────────────────┐ │
│  │ App Source  │  │ MAUI Framework  │  │ Copilot Agent   │ │
│  │  (editable) │  │ Source (local)  │  │                 │ │
│  └─────────────┘  └─────────────────┘  └─────────────────┘ │
│         │                  │                    │           │
│         └──────────────────┼────────────────────┘           │
│                            │                                │
│                   ┌────────▼────────┐                       │
│                   │ Unified Context │                       │
│                   │   (App + MAUI)  │                       │
│                   └────────┬────────┘                       │
│                            │                                │
│                   ┌────────▼────────┐                       │
│                   │  Build System   │                       │
│                   │  (incremental)  │                       │
│                   └────────┬────────┘                       │
│                            │                                │
│                   ┌────────▼────────┐                       │
│                   │ Hot Reload /    │                       │
│                   │ App Relaunch    │                       │
│                   └─────────────────┘                       │
└─────────────────────────────────────────────────────────────┘

The Copilot agent needs:

1. Framework-aware context: Understanding that Microsoft.Maui.Controls.Handlers.Items contains CollectionViewHandler, that handlers map to platform-specific implementations, that there's a property mapper pattern, etc.

2. Cross-boundary reasoning: Connecting the developer's app-level symptom ("flicker on scroll") to framework-level causes (layout invalidation cycles).

3. Contribution-aware actions: Ability to stage changes for upstream PR, generate commit messages following MAUI's conventions, identify related issues, add appropriate tests.

4. Build integration: Trigger incremental rebuilds, understand build failures, suggest fixes for build errors in framework code.

---

3. The Contribution Gesture: Detailed Workflow

Phase 1: Issue Identification

The developer notices a problem. This might be:

• A visual bug (flicker, misalignment, incorrect rendering)
• A behavioral bug (event not firing, incorrect property value)
• A missing feature (no API for a common pattern)
• A performance issue (slow layout, excessive allocations)

Copilot's Role: Help identify whether this is an app bug or a framework bug. Analyze stack traces, compare against known MAUI issues, check if the behavior matches documented behavior.

Phase 2: Source Navigation

The developer invokes "Investigate in Framework Source."

Copilot's Role:

1. Identify the relevant framework components (which handler? which platform code?)
2. Open the relevant source files in the IDE
3. Provide a guided tour: "This is the iOS CollectionViewHandler. The issue likely originates in the MeasureOverride method on line 234, which calls into the native UICollectionViewFlowLayout."

Phase 3: Fix Development

Copilot's Role:

1. Propose a fix with explanation
2. Explain the risk/impact of the change
3. Identify related code that might be affected
4. Suggest test cases that should be added

The developer can iterate with Copilot:

• "What if we cached this value?"
• "Would this break Android?"
• "Show me how similar bugs were fixed before"

Phase 4: Local Validation

The fix is applied to local framework source. The developer rebuilds.

Build System's Role:

1. Detect that only CollectionViewHandler.iOS.cs changed
2. Rebuild only the iOS platform target of Microsoft.Maui.Controls
3. Update the running app via hot reload (for UI changes) or trigger relaunch (for handler changes)

Validation Options:

• Manual testing in the app
• Running MAUI's unit tests filtered to CollectionView
• Running MAUI's device tests on simulator

Phase 5: Upstream Contribution

The developer triggers "Submit to MAUI."

Automated Steps:

1. Fork dotnet/maui (if not already forked)
2. Create a feature branch: fix/collectionview-ios-grouped-flicker
3. Commit with conventional message format
4. Add Copilot-generated description
5. Link related GitHub issues
6. Open draft PR

Copilot's Role:

1. Generate PR description from the conversation
2. Ensure commit follows MAUI contribution guidelines
3. Add appropriate labels/area tags
4. Suggest reviewers based on file ownership

Phase 6: Continuous Integration

The PR enters MAUI's CI pipeline. If tests fail:

Copilot's Role:

1. Analyze CI failures
2. Suggest fixes
3. Help iterate until CI passes

---

4. Benefits

4.1 Accelerated Framework Evolution

Faster Bug Resolution: Today, a MAUI bug goes through: report → triage → prioritization → assignment → investigation → fix → review → merge → release. With contribution gestures, the developer who found the bug also investigates and proposes the fix, often in a single session.

Broader Fix Diversity: The MAUI team is small relative to the surface area. Source-first distribution taps into the collective expertise of thousands of developers who encounter edge cases the team would never reproduce.

Real-World Validation: Fixes are tested in actual production apps before being submitted. The developer knows the fix works for their use case.

4.2 Improved Quality

More Eyes: Linus's Law states that "given enough eyeballs, all bugs are shallow." Source distribution means more developers reading and understanding the framework code.

Better Bug Reports: When developers can navigate the source, their bug reports improve dramatically. Instead of "CollectionView flickers," they report "CollectionViewHandler.iOS.cs line 234 triggers redundant MeasureOverride when grouped headers have variable heights."

Earlier Detection: Issues get caught in development rather than production.

4.3 Community Building

Contribution Identity: Today, most MAUI developers will never contribute. Source-first makes contribution the default. Every developer becomes a potential contributor.

Reduced "Us vs. Them": When the framework is a black box, there's a psychological separation between "the MAUI team" and "MAUI users." Source distribution blurs this line.

Knowledge Sharing: Developers who explore the source develop expertise. They answer Stack Overflow questions, write blog posts, mentor others.

4.4 Educational Value

Learning by Reading: The MAUI source is a masterclass in cross-platform development. Making it easily accessible is educational.

Understanding Platform Differences: Developers see exactly how iOS and Android handle the same abstraction differently.

---

5. Limitations and Challenges

5.1 Build Time Reality

Flutter's Dart compiler is fast. C# compilation is fast. But MAUI's full build involves:

• C# to IL compilation
• XAML to source generation
• Resource processing (images, fonts, assets)
• Platform-specific packaging
• Code signing (iOS/macOS)
• DEX conversion (Android)

A clean MAUI build takes 8-15 minutes per platform. Even with incrementality, framework changes often trigger cascading rebuilds. For this model to work, significant investment in build performance is required:

• Sub-second incremental builds for single-file changes
• Distributed/cached compilation for unchanged dependencies
• Parallel platform builds

5.2 Architectural Complexity: The Handler Gap

This is the fundamental challenge that distinguishes MAUI from Flutter.

Flutter's Architecture:

┌─────────────────────────────────────────┐
│           Flutter Framework             │
│  (Widgets, Rendering, Painting, etc.)   │
├─────────────────────────────────────────┤
│             Skia / Impeller             │
│        (Flutter owns the pixels)        │
├─────────────────────────────────────────┤
│            Platform Embedder            │
│    (Thin shell: window, events, GL)     │
└─────────────────────────────────────────┘

Flutter controls rendering from top to bottom. A bug in a Flutter widget is 100% in Flutter/Dart code.

MAUI's Architecture:

┌─────────────────────────────────────────┐
│          MAUI Framework (C#)            │
│     (Controls, Layouts, XAML, etc.)     │
├─────────────────────────────────────────┤
│              Handlers (C#)              │
│   (Map MAUI abstractions to native)     │
├─────────────────────────────────────────┤
│     Platform SDKs (Not Owned by MAUI)   │
│  UIKit / AppKit / Android Views / WinUI │
├─────────────────────────────────────────┤
│     Platform OS (Definitely Not Owned)  │
│         iOS / Android / Windows         │
└─────────────────────────────────────────┘

Many MAUI bugs originate in:

• Platform SDK behavior (iOS 17 changed how UICollectionView measures)
• Interactions between MAUI handlers and platform quirks
• Platform-specific workarounds that break on OS updates

A developer can't fix these by modifying MAUI source alone. They need:

• Deep platform SDK knowledge
• Understanding of MAUI's workaround history
• Testing across multiple OS versions

Implication: The "Copilot fix gesture" works great for pure MAUI bugs. For platform integration bugs, it's necessary but not sufficient.

5.3 The .NET Runtime Dependency

MAUI runs on .NET, which runs on Mono (iOS/Android/macOS) or CoreCLR (Windows). The runtime is:

• Compiled from C/C++ and assembly
• Highly platform-specific
• Updated on a separate cadence

Source-first MAUI doesn't mean source-first runtime. This creates boundaries:

• Some bugs are runtime bugs, not MAUI bugs
• Debugging across the managed/native boundary is complex
• Performance issues might be runtime, JIT, or GC related

5.4 Platform SDK Requirements

To build MAUI from source for iOS, you need:

• macOS (can't cross-compile)
• Xcode (12GB+ download)
• iOS SDK (specific version)
• Valid Apple Developer account (for device testing)

For Android:

• Android SDK (8GB+)
• Correct NDK version
• Emulator system images

For Windows:

• Windows SDK
• Visual Studio with specific workloads

Total development environment size: 80-120GB across platforms

Flutter has similar requirements, but the tight integration between Dart and Flutter means fewer moving parts.

5.5 Versioning and Compatibility

If developers are modifying framework source locally:

• How do they get upstream updates?
• How do they handle merge conflicts?
• What if their local modification masks a real bug?
• What if they ship an app with local modifications?

5.6 Quality Control at Scale

The Flutter repo gets thousands of PRs. The MAUI repo would see similar volume. Challenges:

• Review capacity constraints
• Test coverage requirements
• Architecture consistency
• API surface control
• Security review for contributions

---

6. Counter-Arguments: The Case for Binary Distribution

A strong proposal requires honestly addressing the counter-argument. Here's the steel-man case for keeping MAUI as binary NuGet packages:

6.1 "Most Developers Don't Want This"

The vast majority of MAUI developers want to build apps, not frameworks. They want:

• Fast dotnet restore
• Predictable builds
• Someone else to fix framework bugs
• To focus on business logic

Source distribution adds complexity for 95% of developers to benefit the 5% who want to contribute. The current model—NuGet binaries for everyone, source repo on GitHub for contributors—already serves both populations.

6.2 "Binary Distribution Enables Caching and Optimization"

NuGet packages are pre-compiled, trimmed, and optimized. Benefits:

• Fast initial setup (download, don't build)
• AOT compilation already done
• Consistent, tested binaries across all users
• No "works on my machine" framework variations

6.3 "Copilot Can Work Without Source Distribution"

The contribution gesture doesn't require source distribution. Copilot could:

1. Clone the MAUI repo on-demand
2. Navigate to the relevant code
3. Help develop a fix
4. Submit a PR

The developer doesn't need local MAUI source for everyday development—only for contribution moments. The "eject-to-source" hybrid model captures this without burdening everyone.

6.4 "Quality is Better Controlled Centrally"

With binary distribution, every developer runs the same code. With source distribution:

• Developers might ship apps with untested local modifications
• Divergent forks could fragment the ecosystem
• Security patches require active source pulls, not just package updates

6.5 "Build Complexity is a Support Nightmare"

Flutter's source model works because Dart is self-contained. MAUI's dependencies—.NET SDK, platform SDKs, Xcode, Android Studio—create exponential configuration combinations. Support burden:

• "My MAUI source build fails with Xcode 16.2 beta 3"
• "MSBuild doesn't find Android SDK after update"
• "Why does the framework compile differently on Windows vs. macOS?"

Binary distribution isolates developers from this complexity.

6.6 "The Feedback Loop Improvement is Overstated"

Yes, contribution becomes easier. But:

• Most bugs aren't simple "find and fix"—they require deep context
• A quick fix might cause regressions elsewhere
• The review/validation process is the bottleneck, not the contribution process
• Low-quality PRs actually slow things down

---

7. Conclusion: Honest Assessment

Feasibility: Technically Possible, Practically Challenging

Source-first MAUI is technically feasible. The components exist:

• Git/NuGet can distribute source
• MSBuild can compile MAUI locally
• Copilot can navigate and modify code
• GitHub supports the PR workflow

The challenge is developer experience. To match Flutter's source distribution smoothness, MAUI would need:

• 10x build performance improvement
• Simplified dependency management
• Robust version/merge handling
• IDE integration for seamless source/binary switching

This is a multi-year engineering investment.

Value: High for Contributors, Neutral or Negative for Non-Contributors

For the 5% of developers who want to contribute, this is transformative. For the 95% who don't, it's at best irrelevant, at worst a source of complexity and confusion.

The "eject-to-source" hybrid model addresses this by keeping binary as default while enabling source for contributors.

Recommendation: Invest in the Hybrid Model

Rather than full source-first distribution, I recommend:

1. Invest in dotnet maui eject-source: A first-class tool for switching to source mode when needed, with easy revert.

2. Build Copilot contribution tooling: The AI-assisted contribution workflow is valuable regardless of distribution model. Build it to work with on-demand source cloning.

3. Dramatically improve local build performance: Whether for source distribution or just MAUI team productivity, faster builds benefit everyone.

4. Experiment with selective source packages: Allow developers to take source for specific subsystems (e.g., just Microsoft.Maui.Controls.CollectionView) rather than all-or-nothing.

5. Document the framework architecture: Much of the contribution barrier is understanding, not access. AI-assisted exploration helps, but good documentation is foundational.

The PolyPilot Inspiration

PolyPilot demonstrates something powerful: a tool that evolves itself through its own use. The developer using PolyPilot to manage Copilot sessions can ask Copilot to improve PolyPilot, and the improvement is immediately realized through relaunch.sh.

This is the purest form of the feedback loop. It works because:

• PolyPilot is a single, self-contained app
• The developer owns the full stack
• Build time is ~30 seconds
• Hot relaunch is seamless

Scaling this to a full framework like MAUI is harder, but the aspiration is right. Every layer of the stack that can be opened, should be opened. The question is how to open it in a way that empowers without overwhelming.

---

Appendix: Technical Specifications

A.1 Proposed dotnet maui eject-source Command

# Eject specific package to source
dotnet maui eject-source Microsoft.Maui.Controls

# Eject at specific version/commit
dotnet maui eject-source Microsoft.Maui.Controls --version 10.0.31
dotnet maui eject-source Microsoft.Maui.Controls --commit abc123

# Return to binary
dotnet maui restore-binary Microsoft.Maui.Controls

# Show current source/binary status
dotnet maui source-status

A.2 Source Package Structure

Microsoft.Maui.Controls.Source.10.0.31.nupkg
├── src/
│   ├── Controls/
│   │   ├── src/
│   │   ├── tests/
│   │   └── Controls.csproj
│   └── Directory.Build.props
├── build/
│   └── Microsoft.Maui.Controls.Source.targets
└── Microsoft.Maui.Controls.Source.nuspec

A.3 Copilot Context Configuration

{
  "copilot.frameworkContext": {
    "includeFrameworkSource": true,
    "frameworkPaths": [
      "${workspaceRoot}/frameworks/maui"
    ],
    "contributionTemplates": {
      "prTitle": "[Area] Brief description",
      "commitConvention": "dotnet/maui-contribution-guide"
    }
  }
}

---

This proposal is exploratory and intended to stimulate discussion rather than propose immediate implementation. The technical and organizational challenges are substantial, but the vision of democratized framework contribution remains compelling.

proposal-unified.md

Unified Proposal: Source-First .NET MAUI with Copilot-Powered Contribution Gestures

Synthesized from: Opus/Claude, Gemini, and Codex proposals
Date: 2025
Status: Strategic Recommendation

---

Part 1: The Debate

Three independent analyses converged on a shared vision but diverged on implementation strategy, risk assessment, and feasibility. This section maps the terrain of agreement and disagreement before presenting the unified recommendation.

1.1 Areas of Strong Agreement

The Vision is Compelling. All three proposals describe essentially the same developer experience: a MAUI developer encounters a framework bug, navigates into framework source with IDE support, invokes Copilot to diagnose and propose a fix, validates locally, and submits upstream—all without leaving their development flow. The "Sarah fixing CollectionView" scenario from Opus, the "label truncation in StackLayout" from Gemini, and the "Entry loses focus under VoiceOver" from Codex are variations on the same powerful story.

Flutter's Model is the Inspiration, Not the Blueprint. All three acknowledge that Flutter's source-first distribution creates a culture of contribution and ownership that MAUI lacks. However, all three also recognize that MAUI's architecture fundamentally differs from Flutter's—MAUI wraps native controls rather than owning the render pipeline. This structural difference limits how directly the Flutter model can transfer.

Binary Distribution Has Real Merits. Every proposal includes an honest "counter-arguments" section acknowledging that binary NuGet packages offer simplicity, consistency, caching, and reduced cognitive load. None advocate abandoning binary distribution entirely.

Copilot Integration is Valuable Independent of Distribution. All three see AI-assisted contribution as a force multiplier, though they differ on whether it requires source distribution to function.

Build Time is the Critical Bottleneck. All proposals identify MAUI's build time (8-20 minutes clean, 30-90 seconds incremental) as the primary technical barrier to source-first viability.

1.2 Areas of Disagreement

Distribution Mechanism

Opus proposes three options (submodules, source packages, hybrid eject-to-source) and explicitly recommends the hybrid "eject-to-source" model via dotnet maui eject-source. This keeps binary as default while enabling source on demand.

Gemini proposes "Source-Link 2.0"—source packages integrated with NuGet, where a project file toggle (<UseMauiSource>true</UseMauiSource>) swaps binary references for local project references. The .NET CLI manages a local clone in ~/.dotnet/src/maui/.

Codex proposes the most elaborate system: workload manifests with commit pinning, workspace projection via submodules or worktrees, and binary baselines for unchanged assemblies. It emphasizes "Unified Solution Views" where app and framework projects coexist.

Resolution: The hybrid "eject-to-source" model (Opus) is the most pragmatic starting point. Gemini's NuGet-integrated source packages and Codex's workspace projection are more elegant long-term but require substantial tooling investment. The recommendation is to prototype dotnet maui eject-source first, then evolve toward richer integration.

Default vs. Opt-In

Opus explicitly argues for opt-in: "Source distribution adds complexity for 95% of developers to benefit the 5% who want to contribute."

Gemini agrees: "This mode should likely be opt-in (e.g., 'Developer Mode: Advanced')."

Codex is more ambitious, describing workload commands (dotnet workload install maui --source) that suggest source distribution could become a first-class option alongside binary.

Resolution: Source-first must be opt-in. The default developer experience should remain unchanged—fast dotnet restore, predictable binary builds, no framework compilation. Source mode activates explicitly for contributors or advanced debugging. This preserves ecosystem stability while enabling power users.

Build Time Feasibility

Opus is the most cautious: "For source-first MAUI to be viable, we need... sub-second incremental builds for single-file changes." It estimates this requires "multi-year engineering investment."

Gemini acknowledges the problem but is more optimistic about incremental builds: "Roslyn and MSBuild are optimized to detect that only one file... changed. It rebuilds only that assembly."

Codex proposes practical mitigations: graph-aware MSBuild, binary baselines for unchanged assemblies, and selective sparse checkouts. However, it also warns that "rebuilding MAUI, Essentials, and bindings takes minutes even on high-end hardware."

Resolution: Current incremental builds are not fast enough for seamless iteration. However, the proposal need not wait for "sub-second" performance. A 30-60 second rebuild for a single handler file is acceptable for contribution workflows (not everyday development). Investment in build caching and graph-aware compilation can improve this incrementally. The key insight is that contributors tolerate longer builds than everyday developers—the opt-in model leverages this tolerance.

The Handler/Native-Binding Gap

This is the most substantive architectural disagreement.

Opus provides the clearest analysis: Flutter controls rendering "top to bottom," so Flutter bugs are 100% in Flutter/Dart code. MAUI bugs often originate in platform SDK behavior or interactions between handlers and platform quirks. "A developer can't fix these by modifying MAUI source alone."

Gemini echoes this: "A bug might not be in C#; it might be in the binding to the underlying Android/iOS API."

Codex is most direct: "Many MAUI issues stem from native SDK quirks; source access cannot fix an Android or iOS platform bug. Expectations must be managed."

Resolution: This is a genuine limitation that cannot be engineered away. The unified proposal must be honest: source-first MAUI enables fixing MAUI bugs (C# handlers, layout logic, property mappers, XAML processing). It does not enable fixing iOS UIKit bugs or Android framework bugs. The Copilot integration should help developers distinguish between these categories—diagnosing whether a bug is fixable in MAUI source or requires a workaround/issue against the platform. This limitation actually strengthens the case for opt-in: developers who need to debug handler code should opt into source mode; developers hitting platform bugs gain nothing from it.

Copilot Independence from Source Distribution

Opus makes the strongest case for decoupling: "The contribution gesture doesn't require source distribution. Copilot could: clone the MAUI repo on-demand, navigate to the relevant code, help develop a fix, submit a PR." The developer doesn't need local source for everyday development—only for contribution moments.

Gemini assumes tighter coupling: Copilot operates on "the actual source code, live and editable, part of their workspace."

Codex also assumes tight coupling but notes that "the workflow must degrade gracefully to manual steps" for air-gapped environments.

Resolution: Copilot-assisted contribution can work in two modes: (1) integrated with source-first development, where Copilot operates on local framework source, and (2) on-demand, where Copilot clones the repo transiently, helps develop a fix, and submits a PR without the developer maintaining persistent framework source. Both are valuable. The on-demand mode has lower friction for occasional contributors; the integrated mode suits frequent contributors who want the source always available. The unified proposal supports both.

Quality Control and PR Flood Concerns

Opus warns: "Low-quality PRs actually slow things down." It suggests that review/validation is the bottleneck, not contribution.

Gemini is more concerned: "Frameworks should be immutable... if every developer is running a slightly mutated version, reproducing bugs becomes a nightmare."

Codex is most alarmed: "Maintainer bandwidth could be overwhelmed by Copilot-fueled PRs. Automated triage, labeling, and reviewer rotation tools would be mandatory."

Resolution: This is a legitimate risk. The unified proposal addresses it through:

1. Copilot quality gates: AI-generated fixes must include regression tests (Gemini's "Shadow Test Harness") and pass formatting/API checks before PR submission.
2. Structured PR templates: Copilot-generated PRs include diagnostic evidence (stack traces, screenshots, device data) so reviewers can assess quickly.
3. Area-based routing: PRs are auto-labeled and routed to appropriate area owners.
4. Graduated contribution tiers: First-time contributors go through more review; established contributors get faster merges.
5. Local-first validation: Developers are encouraged to validate fixes thoroughly before upstreaming, reducing the volume of "works on my machine" PRs.

Overall Feasibility Assessment

Opus: "Technically possible, practically challenging... multi-year engineering investment."

Gemini: "Not insurmountable... launch a 'Source Link 2.0' pilot."

Codex: "Ambitious but attainable... prototyping the idea [is justified] even if the ultimate rollout remains hybrid."

Resolution: The proposals agree on feasibility but differ on timeline. The unified assessment: source-first MAUI is feasible today as an opt-in advanced mode using existing Git/MSBuild tooling. Making it seamless (sub-minute rebuilds, integrated Copilot gestures, one-click PR submission) requires investment over 1-2 years. The recommendation is to ship a "good enough" version quickly, then iterate.

---

Part 2: The Unified Proposal

2.1 Vision

Every .NET MAUI developer should be a potential framework contributor. The barrier between "app developer" and "framework contributor" should be as low as the barrier between "reading code" and "editing code."

This doesn't mean every developer will contribute—most won't, and that's fine. But the developer who encounters a bug should never feel powerless. They should have a clear path from "this is broken" to "I fixed it" to "my fix is in the next release." Even if they choose not to take that path, knowing it exists changes their relationship with the framework from consumer to partner.

The vision is not source distribution for its own sake. The vision is ownership. Source distribution is the enabler; Copilot integration is the accelerator; the contribution workflow is the destination.

2.2 Recommended Architecture

The architecture follows a hybrid model: binary by default, source on demand, with Copilot assistance available in both modes.

2.2.1 Binary Distribution (Default Path)

The default MAUI experience remains unchanged:

• dotnet workload install maui installs binary workloads
• dotnet new maui creates a project referencing NuGet packages
• Build times are fast; developers focus on their apps

This is the right default because 90%+ of developers never need framework source.

2.2.2 Source Distribution (Opt-In Path)

For contributors and advanced debuggers, a new command materializes framework source:

# Eject specific package to source at the current referenced version
dotnet maui eject-source Microsoft.Maui.Controls

# Show which packages are source vs. binary
dotnet maui source-status

# Return to binary (preserves local changes in a branch)
dotnet maui restore-binary Microsoft.Maui.Controls

What eject-source Does:

1. Clones the dotnet/maui repository (or the relevant subset) at the commit matching the current package version
2. Places it in a standard location (e.g., .maui-src/ in the solution root, or ~/.dotnet/maui-src/ for sharing)
3. Modifies the project to use <ProjectReference> instead of <PackageReference> for the ejected package
4. Sets up Git remotes: origin for the developer's fork, upstream for dotnet/maui
5. Downloads prebuilt binaries for unchanged assemblies (binary baseline) to minimize rebuild scope

Why This Approach:

• Familiar NuGet semantics for versioning
• Full Git history available for contribution workflow
• Clean separation: most developers never see this; contributors opt in explicitly
• Reversible: restore-binary returns to the binary path

2.2.3 Build System Enhancements

To make source mode viable, the build system needs targeted improvements:

1. Incremental Build Reliability: MSBuild's incrementality must be trustworthy. A single-file change in CollectionViewHandler.iOS.cs should rebuild only Microsoft.Maui.Controls for iOS, not cascade through the entire dependency graph.

2. Binary Baselines: Unchanged assemblies (e.g., Microsoft.Maui.Essentials when only editing Controls) link from prebuilt cache, not recompiled.

3. Platform-Selective Compilation: dotnet build -f net9.0-ios builds only iOS targets, not all platforms.

4. Build Time Target: Incremental rebuild of a single handler file should complete in under 60 seconds. This is achievable with current tooling; the main work is ensuring build graph correctness.

2.2.4 Copilot Integration

Copilot operates in two modes:

Mode 1: Source-Integrated (for contributors with ejected source)

• Full context of app code + framework source
• Can edit framework files directly
• Proposes fixes with inline diff preview
• Generates regression tests in the framework test suite
• Triggers targeted builds and test runs

Mode 2: On-Demand (for occasional contributors)

• Developer describes a bug; Copilot analyzes symptoms
• Copilot clones the relevant framework code transiently
• Proposes a fix in a new branch
• Developer reviews and approves
• Copilot creates PR via gh pr create
• No persistent framework source in the developer's workspace

Both modes share the same contribution workflow; they differ only in whether framework source persists locally.

2.3 The Contribution Gesture (Unified Workflow)

Whether using source-integrated or on-demand mode, the workflow follows these phases:

Phase 1: Capture

The developer observes a bug—visual glitch, behavioral error, performance issue. They invoke a gesture (keyboard shortcut, menu item, or chat command):

"Copilot, this CollectionView flickers when scrolling grouped items on iOS."

Copilot captures diagnostic context: stack trace, UI tree, device/OS version, recent framework commits.

Phase 2: Diagnose

Copilot analyzes the symptom against framework architecture:

"This likely originates in CollectionViewHandler.iOS.cs. The InvalidateLayout call on line 234 triggers redundant measure passes when group headers have variable heights. Similar issues were fixed in #45123 and #47890."

The developer can explore: "Show me those related fixes." "What would break if we cached this?"

Phase 3: Propose

Copilot generates a fix:

// CollectionViewHandler.iOS.cs
+ private bool _layoutDirty = false;
  
  void InvalidateLayout()
  {
-     _nativeView.CollectionViewLayout.InvalidateLayout();
+     if (!_layoutDirty)
+     {
+         _layoutDirty = true;
+         MainThread.BeginInvokeOnMainThread(() =>
+         {
+             _layoutDirty = false;
+             _nativeView.CollectionViewLayout.InvalidateLayout();
+         });
+     }
  }

Copilot explains: "This coalesces invalidation requests within a single layout cycle, preventing the recursive measure cascade."

Phase 4: Validate

The developer applies the fix. In source-integrated mode, this is a file save. In on-demand mode, Copilot applies it to the transient clone.

The framework rebuilds incrementally. The app relaunches (via Hot Reload if possible, or maui-relaunch script). The developer tests with their actual data.

If validation fails, iterate: "That didn't fix it. What else could cause this?"

Phase 5: Test

Copilot generates a regression test:

[Fact]
public void CollectionView_GroupedLayout_DoesNotFlickerOnScroll()
{
    var collectionView = new CollectionView { IsGrouped = true };
    collectionView.ItemsSource = CreateGroupedData(variableHeightHeaders: true);
    
    var handler = CreateHandler<CollectionViewHandler>(collectionView);
    
    // Simulate rapid scrolling
    for (int i = 0; i < 100; i++)
        handler.ScrollTo(i * 10);
    
    // Assert: InvalidateLayout called at most once per frame
    Assert.True(handler.LayoutInvalidationCount <= handler.FrameCount);
}

The developer runs the test locally: dotnet test --filter CollectionView_GroupedLayout

Phase 6: Upstream

With validation and tests passing, the developer invokes "Submit to MAUI":

1. Copilot creates a branch: fix/collectionview-ios-grouped-flicker
2. Commits with conventional message: [iOS] Fix CollectionView flicker with grouped variable-height headers
3. Pushes to the developer's fork
4. Opens a PR with:
   • Description generated from the conversation
   • Diagnostic evidence (repro steps, device info, screenshots)
   • Links to related issues
   • Test results
   • Area labels (area/controls, platform/ios)

Phase 7: Iterate

If CI fails or reviewers request changes, Copilot helps iterate:

"CI failed on Android. The Android handler uses a different invalidation pattern—let me adjust."

The developer stays in their IDE throughout, never context-switching to learn MAUI's contribution process.

2.4 Phased Rollout Plan

Phase 1: Foundation (0-6 months)

Goal: Prove the core workflow works.

• Ship dotnet maui eject-source and restore-binary commands
• Document the source mode workflow
• Create IDE extension (VS Code first, then VS) for source navigation with Copilot awareness
• Establish build time baseline and identify optimization targets
• Recruit 10-20 pilot contributors to test the workflow

Success Criteria: Pilot contributors successfully submit 5+ PRs using the workflow.

Phase 2: Integration (6-12 months)

Goal: Make the workflow seamless.

• Implement binary baselines to reduce rebuild scope
• Ship Copilot gesture palette (diagnose, fix, test, submit)
• Create regression test generation templates
• Build PR quality automation (auto-labeling, reviewer routing, API checks)
• Improve incremental build reliability to <60s for single-file changes

Success Criteria: 50+ community PRs submitted via the workflow; average time from bug observation to PR submission under 2 hours.

Phase 3: Scale (12-24 months)

Goal: Make contribution the default response to bugs.

• On-demand Copilot mode (no persistent source required)
• Selective source packages (eject just CollectionView, not all of Controls)
• Build caching and distributed compilation
• IDE "Fix in Framework" right-click menu integration
• Community documentation and training materials

Success Criteria: Contribution gesture becomes the primary path for community bug fixes; framework PR volume increases 2x with maintainer burden increasing <1.5x.

2.5 Benefits

For Developers:

• Never blocked by framework bugs—can always fix locally and proceed
• Educational access to production-quality framework code
• Clear path from frustration to contribution
• AI assistance lowers the expertise barrier

For the MAUI Team:

• Higher-quality bug reports with diagnostic evidence
• Pre-validated fixes from developers who've tested in real apps
• Distributed investigation of edge cases the team can't reproduce
• Reduced "us vs. them" dynamic with the community

For the Ecosystem:

• Faster framework evolution through parallel contribution
• Shared ownership culture (Flutter's greatest strength)
• Knowledge diffusion as contributors become experts
• Stronger community identity and investment

2.6 Risks and Mitigations

Risk	Mitigation
PR flood overwhelms maintainers	Quality gates (tests, API checks) filter low-quality submissions; auto-triage routes PRs to area owners; Copilot-generated PRs include evidence for fast review
Ecosystem fragmentation from forks	restore-binary makes reverting easy; tooling nudges toward upstreaming; stale fork detection warns developers
"Works on my machine" framework builds	Binary baselines ensure unchanged assemblies are identical; CI validation required before merge
Build complexity support burden	Opt-in model limits exposure; dotnet maui doctor validates environment; clear documentation of requirements
Copilot generates incorrect fixes	Human review required before commit; regression tests catch obvious errors; PR template requires validation evidence
Native/platform bugs blamed on MAUI	Copilot helps diagnose bug location; documentation clarifies scope of source-first benefits

2.7 Honest Assessment

This proposal is not a silver bullet. Source distribution cannot fix iOS bugs, cannot accelerate Android SDK issues, and cannot make every developer a framework expert. Many bugs require deep platform knowledge that AI cannot yet replicate.

This proposal requires investment. Building the tooling, improving build times, and scaling review processes all require resources. The 1-2 year timeline assumes meaningful allocation.

This proposal changes the MAUI team's role. Today, the team is primarily developers. In the source-first world, the team becomes primarily reviewers and architects. This is a cultural shift, not just a technical one.

This proposal may not dramatically increase contribution volume. Even with frictionless tooling, most developers won't contribute. The value is not volume but capability: the developers who want to contribute can, and the ecosystem benefits from their expertise.

The recommendation is to proceed, cautiously. The hybrid model (binary default, source opt-in) limits downside risk. The phased rollout tests assumptions before scaling. The worst-case outcome is a better contributor experience for power users; the best-case outcome is a Flutter-like contribution culture for .NET mobile development.

---

Part 3: What PolyPilot Proves Today

PolyPilot is a .NET MAUI app that demonstrates a self-modifying development cycle: the developer uses PolyPilot to instruct Copilot to edit PolyPilot's own source code, rebuilds, and relaunches via a shell script. The loop completes in under a minute.

What PolyPilot Demonstrates

1. The feedback loop can be fast. A single MAUI app rebuilds in ~30 seconds. Hot relaunch scripts make iteration nearly seamless.

2. Copilot can navigate and modify MAUI code effectively. PolyPilot's source is visible to Copilot, and meaningful changes happen through conversation.

3. The developer experience is transformative. Using a tool that can improve itself feels qualitatively different from using a static tool. There's a sense of partnership with the AI.

4. Self-hosted documentation works. When the source and docs live together, Copilot can reference architecture while proposing changes.

Gaps Between PolyPilot and the Full Vision

1. PolyPilot is a single app; MAUI is a framework. PolyPilot builds in 30 seconds; MAUI builds in 10+ minutes. The feedback loop that feels instant for an app becomes painful for a framework.

2. PolyPilot owns its full stack; MAUI wraps platforms. PolyPilot bugs are PolyPilot bugs. MAUI bugs may be iOS bugs, Android bugs, or interaction bugs that span layers.

3. PolyPilot has one user; MAUI has thousands. PolyPilot's "contribution" is immediate (the developer accepts and rebuilds). MAUI contributions must pass review, testing, and release gates.

4. PolyPilot's workspace is the whole project; MAUI's source is external. PolyPilot source is already in the developer's repo. MAUI source must be materialized and integrated.

The Bridge

PolyPilot proves the experience is valuable. The unified proposal provides the architecture to scale that experience to framework contribution. The gap is build time and distribution—solvable problems, not fundamental barriers.

When a MAUI developer encounters a bug and thinks, "I wish I could just fix this like I fix my own code," the source-first model with Copilot gestures makes that thought actionable. PolyPilot shows the destination is worth reaching. The unified proposal charts the path.

---

This unified proposal synthesizes three independent analyses into a coherent recommendation. The technical approach is opinionated where evidence supports it and transparent about uncertainties where it does not. The vision is ambitious; the roadmap is pragmatic; the honest assessment acknowledges both the potential and the limitations. The future of .NET MAUI contribution may not look exactly like this—but it should aim in this direction.