Week 18: 5 Open-Source GitHub Repositories Every Developer Should Know in 2026

Developers are increasingly working with AI agents that run for long periods, collaborative visual interfaces, MCP servers, browser-based tools, document workflows, and applications that need to interact with AI in much richer ways than plain text.

And that creates a new problem. 

The hard part is no longer finding another tool, it is finding the open-source projects that actually improve the way we build.

For Week 18 of my Open Source GitHub Repository Series, I explored five repositories that solve very different problems:

What makes this list especially interesting is that these projects represent something bigger.

AI-native development isn’t only about better models. It’s about building better environments around those models.

Let’s look at each one.

Repository: excalidraw/excalidraw

Sometimes the fastest way to explain a system isn’t another 500-line document.

It’s drawing a simple box with an arrow or a database cylinder and few notes. And suddenly everyone understands the architecture.

That is the problem Excalidraw solves remarkably well.

Excalidraw is an open-source virtual whiteboard for creating hand-drawn-style diagrams, wireframes, and visual ideas.

The editor is canvas-based, customizable, supports images and shape libraries, exports to PNG and SVG, and stores drawings in an open .excalidraw JSON format. The hosted application also provides capabilities such as real-time collaboration, end-to-end encryption, offline/PWA support, local-first autosaving, and shareable read-only links.

But the part developers should pay attention to is this Excalidraw isn’t only a website. It’s also something you can embed into your own product.

The README provides a straightforward npm integration:

That means you can bring a collaborative, sketch-style canvas into an existing React application rather than building a drawing engine from scratch.

Most applications eventually need some kind of visual interaction.

Think about:

Building canvas interactions yourself sounds easy until you start dealing with selection + dragging + resizing + arrows + bindings + undo/redo + zoom + export + persistence + collaboration.

That’s a lot of engineering.

Excalidraw gives you a large portion of that foundation.

And its integrations are another signal of how reusable the project has become. The repository lists integrations including VS Code, Obsidian, Notion, Replit, CodeSandbox, Meta, and others.

Architecture Design: Create a visual system-design canvas inside an internal engineering portal.

Product Planning: Allow product teams to sketch user journeys and workflows.

Education: Build interactive technical diagrams into developer-learning platforms.

Collaborative Design: Let multiple users work on the same visual canvas in real time.

Developer Tools: Embed diagrams directly into documentation or engineering workflows.

The biggest productivity win is simple: You don’t have to reinvent the canvas.

Instead of spending weeks building drawing primitives and interaction behavior, you can focus on the actual product experience.

And there is another advantage.

Because Excalidraw uses an open drawing format, your visual data doesn’t have to disappear inside an opaque proprietary format.

Sometimes productivity isn’t about writing code faster. It’s about deciding which code you shouldn’t write at all.

Repository: herdrdev/herdr

Here’s a problem that becomes obvious once you start using coding agents seriously.

Traditional terminal workflows aren’t really designed for this.

herdr is.

herdr describes itself as “the runtime your coding agents live on.” It runs as a background server where agent terminals live inside persistent sessions.

According to the README, you can close the laptop, lose the network, or restart the machine and the agents can continue working, with sessions available to reattach later, including over SSH.

That changes the mental model.

Instead of: Terminal → Agent → Doneyou start thinking: Runtime → Agent Sessions → Persistent Work

herdr also tracks whether panes are working, blocked, or idle, helping you identify when an agent needs attention.

And importantly, herdr isn’t trying to replace your coding agent.

The README explicitly says it can run tools you already use including Claude Code, Codex, Cursor, OpenCode, Grok, and others while managing the terminals where they run.

AI coding agents are moving from “answer this coding question” to “work on this task.”

That difference matters. A task-oriented agent may need to:

That isn’t always a five-minute interaction. The environment itself becomes part of the agent architecture.

herdr treats that environment as infrastructure.

Long-Running Coding Tasks: Keep coding agents alive while they work through larger tasks.

Multiple Agents: Run several agents in different panes and monitor what each one is doing.

Remote Development: Reattach to agent sessions over SSH.

Autonomous Workflows: Let agents continue operating while you’re away from the machine.

Agent Orchestration: The project provides CLI and socket APIs that agents can use to spawn panes, interact with other agents, and wait for another agent when necessary.

That last point is particularly interesting.

The runtime itself becomes agent-aware.

herdr reduces a frustrating class of AI-development problems:

The bigger shift is conceptual.

Coding agents need infrastructure just like applications do.

Once agents become persistent workers, the terminal is no longer just a place to type commands.

It becomes their runtime.

Repository: MoonshotAI/kimi-code

The terminal is already where developers have enormous power.

Git.

Docker.

Node.

Python.

Build tools.

Tests.

Deployment scripts.

Now imagine adding an AI agent that can operate inside that same environment.

That is the idea behind Kimi Code.

Kimi Code is a terminal-based AI agent designed to help developers perform software-development tasks and terminal operations.

The README describes capabilities including:

So this isn’t simply a chatbot exposed through a terminal.

It’s an agentic development environment.

Kimi Code supports the Agent Client Protocol (ACP).

That means it can work with ACP-compatible editors and IDEs, including Zed and JetBrains tooling. The README shows how Kimi Code can run as an ACP agent server and appear inside an IDE’s agent panel.

Now the workflow becomes much more interesting. You aren’t forced to choose between terminal agent and IDE agent

The agent can participate in both environments.

Kimi Code also supports Model Context Protocol tools.

The repository documents commands for adding MCP servers through HTTP or stdio transports, managing authentication, listing servers, and supplying MCP configuration files.

That means the agent can move beyond “Understand my code” toward “Understand my code and interact with external tools.”

And that’s where agent workflows become genuinely powerful.

Repository Understanding: Ask the agent to investigate unfamiliar codebases.

Implementation: Let the agent modify files and execute development commands.

Debugging: Combine code investigation with terminal execution.

IDE Workflows: Bring the same agent into ACP-compatible environments.

Tool-Augmented Agents: Connect external systems through MCP.

Shell Productivity: Kimi Code can also operate as a shell, allowing developers to switch into shell command mode from inside the environment.

The real benefit isn’t just AI-generated code. It’s context continuity.

That creates a much more natural development loop Understand → Execute → Inspect → Modify → Verify

instead of constantly jumping between unrelated interfaces.

Repository: documenso/documenso

Not every useful open-source repository is about AI and that’s exactly why Documenso belongs on this list.

Because software development isn’t only about building features. It’s also about building the business workflows around those features.

One of the most common? Getting documents signed.

Documenso describes itself as an open-source DocuSign alternative.

Its goal is to provide a document-signing platform that organizations can self-host, inspect, run, and fork. The project frames this as part of building more open “trust infrastructure” around digital signatures.

That’s a very different philosophy from simply consuming a hosted SaaS API.

Instead of Your App → Third-Party Signing Platform

you can explore Your App → Your Signing Infrastructure

Imagine you’re building:

At some point, someone needs to sign something. You could build a small signature workflow yourself or you could buy a SaaS service or you could use an open-source platform that you can inspect and self-host.

Documenso gives you that third option.

One thing I particularly like about this repository is that its stack is familiar to modern JavaScript developers.

The project currently lists:

For a developer already working in the TypeScript ecosystem, this makes the project particularly interesting to study.

You’re not just consuming a product, you’re looking at a real-world application architecture.

SaaS Applications: Add document-signing workflows to your own product.

Internal Enterprise Tools: Self-host signing infrastructure for internal workflows.

Contract Management: Create approval and signature pipelines.

HR Platforms: Handle offer letters and employment documents.

Procurement: Integrate document execution into purchasing workflows.

Learning and Architecture: Study how a production-oriented open-source TypeScript application combines frontend, backend, database, PDF tooling, authentication, payments, and testing.

The biggest benefit is control.

And because it’s open source, you have more freedom to understand how the system works under the hood.

There is also an important current project detail: the repository says it remains open source, but external pull requests are currently paused except for a small group of trusted contributors; detailed issues are the preferred external contribution path.

Open source doesn’t always mean “fork it and modify anything tomorrow.” It means you can inspect, run, understand, and build on the software while still respecting the project’s current contribution model.

Repository: modelcontextprotocol/ext-apps

This is probably the repository in this week’s list that points most directly toward where AI interfaces are heading.

Because we have spent years teaching computers to return text, then structured JSON, then tool results.

But sometimes text isn’t enough.

Try asking an AI agent to:

Suddenly, a text response feels like the wrong interface.

That’s where MCP Apps comes in.

The official Model Context Protocol repository describes MCP Apps as a specification and SDK for building interactive UIs for MCP tools.

These interfaces can render directly inside compliant AI chat clients, including examples such as Claude and ChatGPT. The project describes use cases including charts, forms, dashboards, design canvases, and video players.

This is a big conceptual change.

Traditional MCP LLM → Tool → Text / Structured Data

MCP Apps: LLM → Tool → Interactive UI

The tool can now become something the user actually interacts with.

The architecture is surprisingly elegant.

1. The tool declares a UI resource: A tool can expose a ui:// resource containing its interface.

2. The model calls the tool: The LLM invokes the MCP server as usual.

3. The host renders the UI: The host fetches the declared resource and places it inside a sandboxed iframe.

4. The UI communicates back: The host can pass data to the UI, while the UI can invoke other tools through the host.

That creates a much richer interaction model.

Data Visualization: An MCP tool can return an interactive chart instead of a paragraph of numbers.

Forms: The agent can ask the user to fill structured inputs through a real UI.

Design Tools: A tool can render an interactive design surface.

Dashboards: Bring operational information directly into an AI conversation.

The repository includes an approach for converting an existing web application into a hybrid web + MCP App.

And the repository ships Agent Skills that can help coding agents:

That’s particularly interesting for AI-assisted development. You can increasingly ask your coding agent to build the integration for you.

MCP Apps reduces a major limitation of tool-using AI, tools can finally have an interface.

Instead of forcing every interaction through natural language, developers can give users the right interaction for the task.

That is much closer to how human-computer interaction already works.

The future of AI interfaces probably isn’t “chat replaces UI.” It’s “chat orchestrates the right UI.”

At first glance, these five repositories don’t look connected.

But look at the broader workflow.

And that tells us something important.

Modern AI applications are becoming multimodal workflows, not simply chat interfaces.

The agent may need to reason → execute → visualize → request input → interact with external systems → complete a business workflow

Each repository in this week’s list handles a piece of that puzzle.

If you’re building applications with visual collaboration or diagrams, start with Excalidraw.

If you’re running multiple coding agents or long-running agent sessions, explore herdr.

If you want an AI coding agent that works across terminal, IDE, and MCP workflows, investigate Kimi CLI and keep an eye on its evolution toward Kimi Code CLI.

If you’re building SaaS or enterprise workflows involving signatures, take a serious look at Documenso.

And if you’re building MCP-based applications and wondering how to move beyond text-only tools, MCP Apps is probably the most important repository in this list to explore.

The developer experience is changing.

First, AI helped us write code. Then AI started helping us understand code. Now AI is beginning to operate inside our development environments.

And the next step is bigger AI will interact with the same rich interfaces humans use.

That means:

These five repositories are a good snapshot of that transition.

And there is one lesson I keep coming back to The future developer toolbox won’t be defined by a single AI assistant. It will be an ecosystem of open-source building blocks that work together.

That’s what makes repositories like these worth watching, not because every developer needs to install all five, because each one shows us a different piece of where software development is heading.

I hope you found it helpful and informative. If you have any questions or feedback, feel free to leave a comment below. Your support and engagement mean a lot to me.