There is a mental model baked into almost every AI agent built today, and it is so pervasive that most engineers never notice it is a choice. The model sits on top of the system. It reasons, it decides, and then it reaches down through a tool interface to make things happen. Shells, browsers, file systems, databases — all of them are tools, and the AI is the thing that calls them.

This is a powerful and correct abstraction for a specific job: tool dispatch. It is also the wrong abstraction for a different job that the industry is now backing into without a name for it — co-participation in live execution, where an AI is not the orchestrator above the machine but one actor among several attached to the same running state.

This article argues that those are two different architectural layers, that conflating them is the source of a recurring class of design pain, and that the systems converging on the second model are pointing at a category that deserves to be named explicitly.

Two mental models, drawn out

Start with the dominant one. In AI-on-top, the model is the controller. Everything below it is a tool it invokes, typically through a structured call protocol. The Model Context Protocol (MCP), introduced by Anthropic, is the cleanest modern expression of this: the model emits structured tool calls over a JSON-RPC transport to servers that expose capabilities, and those servers do the work and return results.

AI-ON-TOP (controller / tool-caller)

              +-------------------+
              |     AI MODEL      |   <- decides, orchestrates
              |   (controller)    |
              +---------+---------+
                        | tool calls (JSON-RPC / function-call)
        +---------------+---------------+-------------------+
        v               v               v                  v
   +---------+     +---------+     +-----------+      +-----------+
   |  shell  |     | browser |     | database  |      |   MCP     |
   |  tool   |     |  tool   |     |   tool    |      |  server   |
   +---------+     +---------+     +-----------+      +-----------+

   Humans observe the AI; they are OUTSIDE the execution path,
   reading transcripts and approving/denying tool calls.

Now the alternative. In AI-as-peer, there is a single live execution state — a running process tree, a PTY, open file descriptors, sockets — and multiple actors attach to it. A human at a terminal, an AI agent, a second specialized agent, a monitoring service, a device: each is an actor that observes and mutates the same state through the same interface, under the same rules. No actor sits above the others. No actor owns a privileged control path.

AI-AS-PEER (one actor among many on a shared execution state)

   +--------+   +--------+   +---------+   +--------+   +---------+
   | human  |   |  AI    |   |  AI     |   | device |   | service |
   | client |   | agent  |   | agent#2 |   |        |   |         |
   +---+----+   +---+----+   +----+----+   +---+----+   +----+----+
       |            |             |            |             |
       +------------+------+------+------------+-------------+
                           |  (same observe/mutate interface,
                           |   same rules, no privileged path)
                  +--------v---------+
                  |  LIVE EXECUTION  |
                  |  STATE (single,  |
                  |  coherent object:|
                  |  procs/PTY/fds)  |
                  +------------------+

The shift is not “the AI got weaker.” The AI is just as capable inside the box as it was on top of it. The shift is where the AI lives relative to the execution boundary — and that single relocation changes what the system can do.

MCP is right — for what it is

It is worth being precise and fair here, because the easy version of this argument is wrong. MCP and tool-calling are not mistakes to be corrected. They are the correct abstraction for connecting a reasoning model to capabilities it does not itself contain. Standardizing tool dispatch over JSON-RPC so that any model can talk to any tool server, without bespoke per-tool glue, is a genuinely good piece of systems design, and it has become an industry standard for exactly that reason.

The point is narrower and more structural: tool dispatch is orchestration, not co-participation. When a model calls a tool, the tool runs, returns a result, and the interaction is over. The model holds the thread of control; the tool is stateless from the model’s point of view and disposable from the system’s. That is precisely what you want for “fetch this row,” “render this page,” “run this command and give me stdout.”

It is not what you want when the question is: can a human reach into the same live shell the AI is using, type a few commands, and hand control back — without restarting anything, without a separate session, without the AI and the human living on two different control paths that have to be reconciled? That question is not about dispatching a tool. It is about two actors sharing one execution state. Different layer, different invariants.

The take-over / hand-back pattern

The cleanest litmus test for which model a system actually implements is the take-over / hand-back pattern.

Picture an agent halfway through a long migration. It has a shell open, environment variables set, a dev server running in the background, a half-applied set of changes on disk. It gets stuck. A human pauses it, types directly into that same live shell — fixes a broken auth token, restarts a wedged process, eyeballs the actual process tree — and then hands control back to the agent, which continues from the real, now-corrected state.

This only works if the human and the AI are peers on one execution state. If the AI owns a separate control path — if its shell is “the AI’s shell” reachable only through its tool interface — then human intervention means tearing down and rebuilding, or running a parallel session and hoping the two states converge. The whole value of the intervention is that both actors mutate the same running object.

The industry is visibly converging on exactly this. Devin’s enterprise architecture separates a stateless model “brain” from a persistent execution sandbox (the “devbox”), and exposes that sandbox to a human for direct takeover of the same workspace the agent is operating in. OpenHands runs its agent against an execution server inside a container and additionally exposes a VS Code server port on that same container, so a human can attach to the live filesystem and terminal buffers when the agent gets stuck. Warp’s Agent Session Sharing publishes an agent session to a relay so that multiple participants — human and agent — can watch the same scrollback, see each other’s cursors, and concurrently type commands and steer the run.

None of these teams set out to write a manifesto about peer participation. They arrived at it because the controller-on-top model could not cleanly answer “let a human and an agent work the same live state.” That convergence is the evidence.

The multi-actor invariants

If you describe the peer model at the level of what must be true rather than how to build it, four invariants fall out. These are the load-bearing properties; the specific mechanisms that satisfy them are an implementation concern (and, in some systems, a patented one — not the subject of this article).

1. Uniform rules across all actor inputs. A command, an edit, or an observation is governed by the same policy, permission model, and ordering discipline regardless of whether a human or an AI submitted it. There is not one rulebook for “the AI’s tool calls” and another for “the human’s keystrokes.” Inputs are inputs.
2. No actor holds exclusive control. No participant owns a privileged path that the others must route through. The human is not a supervisor calling the AI; the AI is not a controller calling tools that humans cannot touch. Control is shared, which means it can be handed off without a state transition that any actor has to specially authorize as “now you’re in charge.”
3. A single coherent execution state. All actors observe and mutate one canonical live state — not per-actor copies that drift and later have to be merged. The take-over / hand-back pattern is impossible the moment you have two states pretending to be one. This is the deepest of the four, and it is where most current architectures quietly fall back to the controller model.
4. Provenance and attribution per actor. Even though the state is shared and the rules are uniform, every mutation carries the identity of the actor that produced it. You can always answer “who ran this,” “who edited that,” “which agent took this branch” — across humans and machines alike. Shared state without attribution is a forensic and safety dead end; the peer model requires both.

State these as a contract and the difference from the controller model becomes mechanical rather than philosophical. The controller model satisfies none of them in the strong sense: rules differ between the model’s tool calls and the human’s out-of-band actions; the model holds exclusive control of its tools; there is no single shared live state (the tools are disposable); and attribution, if it exists, lives in a transcript rather than in the execution object.

Peer participation is not agents messaging each other

There is a second, easier-to-confuse pattern that must be ruled out: agent-to-agent messaging. Protocols in the A2A / agent-relay family standardize how separate agents pass structured messages — a planner asks an implementer to do work, an implementer asks a reviewer to check it, completion events get routed back. This is valuable and, like MCP, it is the right tool for its job.

But it is message passing between separate agents, each with its own state. The peer model is the opposite topology: multiple actors inside one shared execution state. The distinction is the same one that separates “two processes exchanging RPCs” from “two threads operating on shared memory.” A2A coordinates distinct execution contexts by relaying messages between them. Peer participation has no distinct contexts to relay between — the coordination happens through the state itself, because everyone is operating on the same object. Confusing the two leads to architectures that bolt a message bus between agents and call it collaboration, when what the take-over / hand-back pattern actually needs is a shared substrate.

A2A / AGENT RELAY                 AI-AS-PEER
   (message passing)                 (shared execution state)

   [agent A]--msg-->[agent B]        [A][B][human] -> one live state
     own state        own state          (no separate states to sync)

Why this matters now

Three forces make the peer model not just elegant but necessary.

Human-in-the-loop at scale. As agents run for hours and take hundreds of consequential actions, “approve every tool call” does not scale and “let it run unattended” is reckless. The workable middle is fluid intervention — drop into the live state when something looks wrong, fix it in place, step back out. That requires peers, not a controller you can only observe through a transcript.

Multi-agent plus human coordination. Once you have a planning agent, an implementation agent, a verification agent, and a human reviewer, the controller-on-top model has no natural seat for everyone. Who is on top? The honest answer is that nobody should be — they are all actors with different roles attached to one body of work. The shared-state model has a seat for each of them by construction.

Devices and services as first-class actors. A sensor that streams readings into the state, a deployment service that mutates it on a webhook, a phone that reattaches to a session the laptop started — these are not “tools the AI calls.” They are participants with their own initiative, observing and mutating the same execution state on their own schedule. The controller model has nowhere to put an actor that acts without being called. The peer model treats it as just another actor.

The historical line points here

The lineage is consistent if you read it as a slow migration of execution state out from under any single client. Terminal multiplexers (screen, tmux) first let a process tree survive its terminal and accept multiple local attachments. tmate pushed those attachments across the network through a relay. Jupyter decoupled a live kernel from the notebook front-end so any client could attach to the same in-memory state. Guacamole normalized remote display surfaces for multiple viewers. Cloud workspaces (Gitpod, Codespaces) moved the environment off the laptop. Agent runtimes (Devin, OpenHands, Warp's cloud platform) then added autonomous actors to that picture — and immediately discovered they needed humans to be able to reach into the same live state the agent was using.

Each step loosened the assumption that one client owns the execution. The peer model is what you get when you finish the job: the execution state is the durable object, and every participant — human, AI, device, service — is a client that attaches to it as an equal.

The fourth distinction, stated cleanly

This is the fourth load-bearing edge of the execution-state-centric category:

AI as peer ≠ AI as controller / tool-caller. MCP-style tool dispatch puts the model above the tools and treats them as disposable. Peer participation puts the AI inside the same execution model as humans and devices, with equivalent observe-and-mutate rights, governed by uniform rules, with no privileged control path and per-actor provenance over a single coherent live state.

It is a distinction about position relative to the execution boundary, and everything else — fluid human-in-the-loop, multi-agent coordination, devices as actors — follows from getting that position right.

Naming the category

The systems drifting toward this — Devin’s takeover of a shared workspace, OpenHands’ attach-to-the-container intervention, Warp’s collaborative agent sessions — are all reaching for the same architectural object: a distributed execution-state architecture in which humans, AI agents, devices, and services participate as peers in one live execution topology, rather than a stack with the AI on top calling tools below.

cmdop is built explicitly on this peer-participation model: a persistent execution state that humans and AI agents attach to as co-equal actors, governed by uniform rules with per-actor provenance, so that taking over a run and handing it back is a first-class operation rather than a workaround. It is offered here not as the point of the argument but as one reference implementation of the category the industry is converging on.

The controller-on-top model gave us tool-calling, and tool-calling is here to stay. But the question that defines the next layer is not “what can the AI call?” It is “what can the AI participate in — as one actor among many, on the same live state, under the same rules as everyone else?”

Next in the series: The Session as a Computational Primitive — the execution session as a first-class object decoupled from client, transport, and device.

Durable-execution engines reconstruct a logical workflow by deterministic replay. Execution-state systems maintain a live OS-level execution graph that humans and AI steer in real time. Both say ‘durable.’ They are not the same paradigm.

There are two fundamentally different ways to make a running computation survive failure, and the industry keeps confusing them because both ship under the word durable and both draw something they call an execution graph.

The first way is replay. You record every decision and side effect a program made into an append-only journal, and when the host dies you start the program over from its entry point on a fresh worker — except the runtime feeds the journaled results back in so the re-execution lands on exactly the state it had before the crash. This is durable execution as Temporal, Cadence, Microsoft Orleans, Dapr, and Azure Durable Functions practice it. It is excellent engineering, and it is the right tool for an enormous class of problems.

The second way is steering. You do not re-derive state from a log; you maintain a live OS-level execution graph — a process tree with real parent/child lineage, a PTY, open file descriptors, sockets — and you keep it alive by directly observing the running system, so that interactive clients (a human, an AI agent, a monitoring service) can attach to it concurrently and act on it while it runs.

The first is reconstructed. The second is held. One is replayed; the other is steered. This article is about why that distinction is not pedantry — and why agentic systems are about to need the second kind whether the vocabulary exists for it or not.

A short, fair account of durable execution by replay

Let’s give replay-based durable execution the respectful, accurate description it deserves, because it is one of the most quietly important ideas in modern backend design.

The core problem durable execution solves is this: in an unreliable world — flaky networks, crashing nodes, downstream APIs that time out — you want to write ordinary-looking imperative code that runs to completion anyway. You want to write:

chargeCard(user)
sleep(30 days)
sendRenewalReceipt(user)

and have it be true that the charge happens once, the sleep survives a datacenter reboot, and the receipt eventually goes out — even if the machine that started the function no longer exists.

Durable-execution engines achieve this with event sourcing plus deterministic replay. The runtime does not try to serialize the language’s native thread stack or heap (the JVM, V8, and the CLR do not natively let you freeze and ship a live call stack). Instead it separates code into two roles. Workflow code is the orchestration logic and it must be strictly deterministic. Any genuinely non-deterministic act — calling an external API, reading the clock, generating a random number, writing to a database — is pushed out into an Activity, and the result of each Activity is written to an append-only event history.

When the workflow worker crashes, the orchestrator detects the lost liveness and schedules the workflow on a different worker. That new worker re-runs the workflow code from the top. As the code re-executes and reaches each Activity call, the SDK intercepts it, finds the already-recorded result in the event history, and returns it immediately — without re-executing the side effect. The program “fast-forwards” through everything it already did and resumes exactly where it left off. Each workflow instance carries a stable workflow ID, so signals and queries can find it regardless of which physical worker is hosting it.

This is what makes “sleep for a month” real rather than a metaphor. When the workflow hits its 30-day delay, the worker frees all in-memory resources and the service registers a timer. Thirty days later a worker picks the task back up, replays the event log to rebuild the in-memory variables, and continues. Idle cost approaches zero. Long-running business processes — subscriptions, onboarding flows, multi-step sagas, human-approval chains — become ordinary code.

It is genuinely powerful, and the constraints are the source of the power: because state is derived from a deterministic re-execution of a log, the engine never has to capture volatile heap pointers or CPU registers, and it can run on stock language runtimes. The price is the determinism contract. Read the wall clock outside an Activity and your replay diverges; the rebuilt state no longer matches reality and the engine raises a non-determinism error to protect you from silent corruption.

What replay actually models — and what it doesn’t

Here is the load-bearing observation. Replay reconstructs logical workflow state: which steps completed, what they returned, where the program counter logically sits in the orchestration graph. That logical graph is the workflow graph — a state machine over completed activities and pending steps.

It does not model, and structurally cannot model, live OS-level execution state.

A deterministic replay engine cannot represent a running bash process mid-command with a half-filled input buffer. It cannot hold a PTY whose scrollback a human is reading right now. It cannot keep a TCP socket in flight, an ssh child waiting on a prompt, a long-lived REPL with a populated namespace, or a process tree where killing the parent should cascade to the children. None of that is journalable as a sequence of deterministic decisions, because none of it is a sequence of deterministic decisions — it is the messy, non-deterministic, concurrently-mutated reality of a live operating system. Replay deliberately forbids exactly the thing a live interactive environment is made of.

This is load-bearing distinction #2 of this series, stated cleanly:

Execution continuity ≠ workflow orchestration. Durable-execution engines reconstruct a logical workflow by deterministic replay; they do not maintain a live OS-level execution graph that heterogeneous interactive clients attach to. Steered, not replayed.

Now consider the opposite extreme, because it clarifies the middle. CRIU (Checkpoint/Restore in Userspace) is the purest form of “capture the live OS state”: it uses ptrace to seize a process, dumps its memory pages, CPU registers, file-descriptor table and even TCP connection state (via TCP_REPAIR), and can restore the whole thing — bit for bit — on another machine. CRIU captures precisely what replay throws away.

But CRIU is a snapshot mechanism, not a continuity architecture. It is single-process-tree oriented; it has no control plane, no logical identity that outlives the snapshot, no way for multiple interactive clients to attach to one coherent live object, no consistency model for concurrent steering, no routing fabric that lets “the execution” be addressed independent of which host currently holds it. It is architecture-locked, too — restore generally demands a matching ISA and kernel. CRIU answers “how do I freeze this one process,” not “how do I make a live execution a first-class, addressable, multi-actor object.”

So we have three points on a map, not two:

REPLAY-BASED               LIVE EXECUTION-STATE          CRIU
  DURABLE EXECUTION          GRAPH                         SINGLE-PROCESS SNAPSHOT
  (Temporal / Orleans /      (the missing layer)           (raw OS freeze/thaw)
   Dapr / Azure DF)

+-----------------+        +-----------------+           +-----------------+
  | logical event   |        | live process    |           | one process     |
  | history journal | <----> | tree + PTY +    | <-------> | tree, dumped to |
  | (derive state)  |        | fds + sockets,  |           | disk, restored  |
  |                 |        | held + observed |           | elsewhere       |
  +-----------------+        +-----------------+           +-----------------+
        ^                            ^                             ^
        |                            |                             |
   determinism                  no determinism                 no control
   contract                     constraint; steered            plane; snapshot
                                by peers in real time          only, no peers

The middle column is the one the industry has names for the edges of but not for the center.

The comparison, dimension by dimension

DIMENSION              | REPLAY-BASED DURABLE   | LIVE EXECUTION-STATE     | CRIU SINGLE-PROCESS
                       | EXECUTION              | GRAPH                    | SNAPSHOT
-----------------------+------------------------+--------------------------+----------------------
state model            | logical workflow state | live OS execution graph: | raw OS state of one
                       | (completed steps,      | process tree w/ lineage, | process tree (pages,
                       | activity results,      | PTY, file descriptors,   | regs, fds, TCP),
                       | logical position)      | sockets — held live      | serialized to disk
-----------------------+------------------------+--------------------------+----------------------
determinism            | mandatory; non-deter-  | none; the live system is | none; captures state
requirement            | minism outside an      | inherently non-deter-    | as-is, no re-exec
                       | activity diverges      | ministic and that's fine | ever happens
-----------------------+------------------------+--------------------------+----------------------
what's persisted       | append-only event      | the live execution graph | a point-in-time
                       | history (inputs/       | as a first-class,        | image; nothing
                       | outputs/side effects)  | addressable object       | between snapshots
-----------------------+------------------------+--------------------------+----------------------
multi-client           | no — clients send      | yes — heterogeneous      | no — restore yields
interactive attach     | signals/queries to a   | clients attach concur-   | one process for one
                       | logical instance; no   | rently to one coherent   | restorer; no shared
                       | shared live surface    | live object              | live surface
-----------------------+------------------------+--------------------------+----------------------
AI / human steering    | drive the workflow     | observe AND mutate the   | none while running;
                       | between steps via      | running environment      | you freeze, ship,
                       | signals; cannot grab   | mid-flight as a peer;    | thaw — you do not
                       | a live shell mid-run   | hand-off live           | steer
-----------------------+------------------------+--------------------------+----------------------
recovery method        | re-run from entry      | reconnect to / re-home   | restore the dumped
                       | point, replay journal  | the live graph; identity | image on a (matching)
                       | to rebuild state       | survives host change     | host

The shape of the table is the whole argument. Replay buys you indefinite, cheap, deterministic durability for logical processes. CRIU buys you a faithful freeze of one live process tree. Neither buys you a live execution graph that several actors can steer at once and that recovers as an identity rather than as a re-derivation or a re-thaw. That center column is a distinct architectural category.

A line through history

The lineage helps locate where this category sits, because each prior era solved one axis and dropped the others (a screen → tmux → tmate → Jupyter → Guacamole → cloud-workspace → agent-runtime arc runs through the whole series; here we trace the execution-continuity thread specifically).

• Distributed-OS process migration (Sprite, Mosix, Locus, Condor, late 1980s–1990s). The first serious attempt to make a live process outlive its host. Sprite migrated a running process to a new node, forwarding host-specific syscalls back to a “home node” via kernel RPC; Mosix shipped the user address space between processors. Visionary — and fatally dependent on the home node: a partition or a home-node crash killed every migrated process. Live state, no durable identity.
• CRIU (2011). Migration done right at the snapshot level: userspace ptrace seizure, full memory/register/fd/TCP capture, restore anywhere with a matching kernel and ISA. It nailed capturing live OS state — and stopped exactly there. No control plane, no multi-client coherence, no logical identity layer.
• Durable-execution engines (Temporal, Cadence, Dapr, Azure Durable Functions, ~2014 onward). Solved durability and identity at the logical level — stable workflow IDs, indefinite sleeps, exactly-once steps, scale-to-zero while idle — by abandoning live OS state entirely in favor of deterministic replay. Durable identity, no live state.

Lay those out and the gap is obvious. Sprite had live state but no durable identity. Temporal has durable identity but no live state. CRIU can capture live state but offers no continuity architecture around it. The execution-state-continuity direction is the synthesis the lineage keeps pointing at but never reaches: a live OS-level execution graph that has a stable logical identity, survives host and transport changes, and is concurrently steerable by peers.

Why this matters now

For a decade the gap was tolerable because the thing on the other end of an execution was a program — deterministic, headless, content to run to completion and report back. Replay fits that world perfectly. You do not need to “take over” a Temporal workflow mid-step; you need it to finish reliably.

Agentic systems break that assumption in two specific ways.

First, agents must pause for a human and then resume a live environment. Not resume a logical position in a state machine — resume an actual shell with a half-built project in it, a dev server still listening on a port, a database connection still open, a Python REPL with two hours of populated namespace. Replay can pause a workflow for a month and rebuild its variables; it cannot rebuild a live process tree and a PTY, because those were never deterministically derivable in the first place. The thing the agent is working inside is exactly the thing replay does not model.

Second, a human needs to take over a running session mid-flight — and then hand it back. The agent is three commands into a deploy, something looks wrong, an engineer wants to attach to the same live execution the agent is in, inspect it, type a few commands, and let the agent continue from the now-modified reality. That is concurrent multi-actor steering of one live execution object. Replay has no shared live surface to attach to — it linearizes signals to a logical instance, it does not host a live shell two parties can both touch. CRIU has the live surface but no multi-client coherence — restore hands one restorer one process; there is no consistency model for two actors mutating it at once, no routing identity for “the session” independent of the host.

The agentic workload sits precisely in the hole between them. It needs replay’s durable, host-independent identity and continuity, and it needs CRIU-grade live OS state, and it needs something neither has: coherent concurrent steering by multiple peer actors. Pause for human input and resume a live environment; let a human grab the wheel of a running session and give it back. Replay cannot do live concurrent steering. Raw snapshot cannot do multi-client coherence. You can watch the convergence pressure in the field already — Devin, Warp, OpenHands, Claude Code, E2B, and Daytona are each, from different starting points, reaching toward “a live environment that persists and that an agent and a human share.” They are converging into the center column without yet having agreed on a name for it.

Naming the category

The center column deserves its name. It is the execution-state continuity layer: live OS-level execution state — the process tree with its lineage, the PTY, the file descriptors, the sockets — elevated to a first-class, persistent, addressable object, decoupled from any one client or transport, that humans, AI agents, devices, and services attach to as peer participants. The discipline that produces it is Distributed Execution-State Architecture.

Hold the slogan, because it is the cleanest way to keep the three paradigms apart: a durable-execution engine replays a logical workflow; CRIU freezes and thaws one process; an execution-state system steers a live graph. Replayed, frozen, and steered are three different verbs, and only one of them describes a running environment that a human and an agent can stand inside together.

The systems that exist today are not wrong; they are aimed elsewhere. Temporal and Orleans are superb at making logical processes invincible, and that will remain true and important. But the agentic era needs the other thing too, and the other thing has been the missing column on the map all along.

One implementation built explicitly around this center column — a live, addressable, multi-actor execution graph that is steered rather than replayed — is cmdop, offered here as a reference point for what the category looks like in practice rather than as the category itself.

Next in the series: AI as Peer, Not Controller — the multi-actor execution model, and why “the model calls tools” is the wrong shape for systems where humans and agents share one live execution.

API (Application Programming Interface) — это программный интерфейс для предоставления сторонним разработчикам доступа к вашей программе (модулю, библиотеке, коду, базе данных, сайту и т.д.).

Я, как руководитель компании очень заинтересован в увеличении количества внешних интеграций к программным продуктам своей компании, поскольку это регулярно приводит новых клиентов.

Уже у многих компаний есть собственные маркет-плейсы: Zendesk Apps, Shopify Apps, WordPress plugins и т.д., где сторонние разработчики выкладывают свои модули использующие API этих платформ.

Итак, вы разрабатываете собственный API с подробной документацией. Дело за малым — кто будет этим пользоваться? Одно из решений это публикация кода на Github.com, это действительно просто. Чуть сложнее обстоят дела с публикацией в профессиональных каталогах (PyPi или Npmjs).

• GitHub — хостинг IT-проектов — 36 млн. посетителей в месяц
• PyPi.org — каталог модулей для Python — 2 млрд. установок в месяц
• Npmjs.com — каталог модулей для Node js — 37 млрд. установок в месяц

Преимущества публикации API в профессиональных каталогах очевидны:

• Это бесплатно
• Ваша библиотека доступна для поиска в каталоге каждого репозитория
• Каталоги имеют высокую «трастовость» со стороны поисковых систем и через пару дней после публикации вы можете оказаться в топе поисковой выдачи
• Установка вашего модуля занимает пару секунд с помощью одной команды и ваш API готов к использованию! ($pip install module или $npm install module)
• Внутренняя система контроля версий позволяет удобно выкатывать обновления вашего кода
• Ваш код доступен круглосуточно для разработчиков со всего мира
• Невысокая конкуренция. Как правило, разработчикам лень публиковать, поддерживать и развивать свой код

Некоторые недостатки профессиональных каталогов:

• Нет мультиязычной поддержки ReadMe
• Строгие требования к публикуемому коду
• Отнимает много времени при публикации и последующих обновлениях вашего кода
• Прочие «подводные камни» в зависимости от типа каталога

Выходит простая формула: чем больше разработчиков находят ваш модуль или API, тем лучше для вас. Выходит, что нужно присутствовать везде, как бы сложно это не казалось.

Кстати, GitHub.com не самое практичное решение, т.к. разработчики предпочитают использовать стандартные менеджеры пакетов (каталоги).

Кейс #1

Допустим, у вас есть собственный веб-сервис и вы хотите, что бы разработчики со всего мира создавали дополнительные модули, которые бы вы могли предложить своим клиентам. Вы понимаете, что при выборе продукта ваши клиенты ориентируются не только на ту задачу, которую решает ваш веб-сервис, но и на богатство ваших модулей (внешних интеграций).

Ок, вы поставили задачу своим программистам, чтобы они опубликовали ваш API, но следует помнить, что эта задача больше для маркетологов, т.к. необходимо качественно оформить описание. В итоге вместо пары часов на публикацию кода может уйти неделя, т.к. маркетологам придется работать в тандеме с разработчиками. А когда по той или иной причине программист публиковавший код покинет штат компании, то встанет вопрос «как быть?»

Конечно, для профессионалов разобраться во всех требованиях каталогов и опубликовать код не составит труда, но ведь у них есть и основная работа! А кто будет это поддерживать? А если вы хотите, чтобы описание было на разных языках? Как сделать так, что бы ваш API был доступным на разных платформах и его находили как можно чаще?

Кейс #2

Вы маркетолог и хотите, чтобы о продуктах вашей компании узнало как можно большее кол-во разработчиков со всего мира. Публикации API на 3–4 ресурсах явно недостаточно, ведь вас должны находить по разным ключевым словам. Стандартный ReadMe этого не позволяет, т.к. содержит всего 1 языковую версию, а название библиотеки не позволяет добавить все словосочетания по которым (как вам кажется) вас должны находить.

Стандартные решения вам точно не подойдут, т.к. нужно регулярно работать с описаниями, переводами и обновлять код.

Кейс #3

Вы разработчик и у вас много хороших решений. Возможно, вы периодически публикуете что-то на GitHub, но не более.

Причины для публикации кода у вас могут быть разные:

• Вы хотите, что бы вас заметил крутой работодатель и предложил вам контракт на $ 100.000 в год
• Вам хочется использовать свои наработки от проекта к проекту с простым подключением модулей (без дублирования кода)
• Вы филантроп и хотите, что бы ваши наработки были полезны разработчикам со всего мира
• Просто так =)

А вот причины по которым вы вероятно не станете публиковать свой код:

• Нет времени подготавливать описание (ReadMe), тем более, если оно на нескольких языках
• Нет желания разбираться в нюансах публикации кода и сливать своё время «в трубу»
• Нет времени на поддержку своих библиотек, т.к. каждый раз приходится снова вспоминать все тонкости для обновления кода в каталогах
• Ну или вам это просто не надо =)

Решение кейсов

Как сделать так, что бы код вашего API (модуля/библиотеки) был всегда под рукой и не отнимал время на публикацию или обновления?

Для этой задачи я перебрал много разных решений, но не одно не решало задач моей компании. В итоге я разработал собственный сервис для массового тиражирования API — GitUpload.com

Сервис выводит вашу библиотеку в топ выдачи Google уже через пару дней после первой публикации кода (если вы всё сделали правильно)

Пример попадания библиотеки в поисковую выдачу Google по интересному запросу (6–8 строчка)

Что умеет GitUpload.com

• Автоматическая публикация кода на: Npmjs.com, PyPi.com, Github.com
• Автоматический перевод ReadMe на 6 языков
• Возможность регулярного обновления кода — так сторонние разработчики поймут, что у вас актуальная библиотека и с большей вероятностью интегрируют ее в свой проект.
• Умное клонирование, т.е. ваша библиотека публикуется не 1 раз, а ее можно растиражировать с разными ключами по разным аккаунтам, чтобы ее находили как можно чаще. Ах да, я слежу за тем, что бы не было злоупотребления (спама).
• Панель управления своими аккаунтами от репозиториев и каталогов
• Подготовка проекта и публикация занимает пару минут
• Это бесплатно и навсегда =)

Примеры библиотек опубликованных с помощью GitUpload.com

• https://pypi.org/project/py-translator/
• https://www.npmjs.com/package/sigma_sms
• https://github.com/markolofsen/py_translator/

Проект некоммерческий и немного сыроват, но он работает стабильно и доказал мне свою необходимость. Не судите строго — попробуйте сами!

Кстати, дальнейшее развитие проекта я планирую за счет привлечения компаний желающих отдать задачу тиражирования API мне на аутсорс.

Спасибо, что дочитали до конца. С любовь, я.

Еще совсем недавно поисковые системы рассматривались не более, чем база данных со строкой поиска. Постепенно качество поиска повышалось под очевидным предлогом: результаты выдачи должны быть максимально-релевантными. Монополист поискового рынка Alphabet, которой принадлежит Google, добилась хороших результатов релевантности выдачи, но не более.

Сейчас уже нет необходимости бороться за повышение качества поисковой выдачи, поскольку стратегия поискового бизнеса изменилась. В след за сменой стратегии основного лидера, стали подтягиваться и мелкие игроки, например, Яндекс.

Пользователям больше не требуется супер-релевантные результаты поисковой выдачи, т.к. качество текущих результатов удовлетворительно и лучше уже просто не требуется.

Если писать картину, в какой-то момент она наконец будет завершена и понятна зрителю.

Поисковые алгоримты уходят на задний план, в ход идет цифровая диктатура. Основной доход Google получает от своей рекламной сети Google Adwords.

Т.е. источник извлечения прибыли это реклама. Достаточно посмотреть по сторонам как становится понятно, что практически ни одна компания не способна вести бизнес, если ее нет в поисковой выдаче. Совсем недавно обычные компании боролись за места в естественной выдаче за счет SEO-оптимизации и увеличения цитируемости. Чудеса закончились. Монополия на поиск от Google все время работала не столько над увеличением качества поиска, сколько над закручиванием гаек для интернет-бизнеса и сейчас попасть в поисковую выдачу стало практически невозможно.

Независимо от уникальности контента, скорости загрузки сайта и качества кода, компания Google не просто не заинтересована в том, что бы какой-либо сайт находили, а против этого. Нужны клиенты? — неси кровные в Adwords, а иначе извини. Только представьте, что практически 50% всех интернет-продаж происходят благодаря рекламной платформе Google. Выражаясь иначе: покупая через интернет вы платите Google. Кстати, стоимость рекламы в Google несоизмерима с практической пользой, которую компания производит.

Я не призываю к радикальным переменам, просто испытываю некоторую тревогу.

Или взять например Facebook, который умело манипулирует сознанием масс за счет алгоритма ротации постов в ленте своих пользователей. О чем сегодня выгодно или не выгодно говорить — решает Facebook.

Вообще складывается такое ощущение, что с миром происходит что-то не то. Каждая монополия стремится контролировать или использовать человека. Религия, правительство, поисковые системы, социальные сети. Со временем список расширится в сторону VR-коммуникаций, где битва пойдет за сознание человека и случится как фантасты уже сейчас подсказывают: эко-системы (конгломераты) контролируют все сферы жизни человека.

Удивительно, но до сих пор не существует компаний, которые бы несли реальную пользу, ориентированных больше на развитие сознания человека, изучение трансциндентных областей жизни. Как будто существует только эмпирическое существование и больше НИ-ЧЕ-ГО. Цифровое рабство это не только про деньги, но также и поле битвы за сознание человека.

Бытует мнение, что домен для компаний уже не столь важен, т.к. деньги вложенные в покупку домена лучше всего пустить в маркетинг. Это утверждение работает, когда речь идет о небольших стартапах, но крайне не верно, когда компания вкладывает значительные средства в укрепление бренда на рынке.

Примером неудачных стартов я могу назвать сервис объявлений «Юла» от Mail.ru, ужасное написание домена youla.ru (а ранее и вовсе youla.io) не позволяет домену закрепиться в визуальной памяти. Написание «you» (Ю) просто ужасно для русского языка.

Или бренд Beru.ru от совместного проекта Яндекса и Сбербанка. Тут немного получше, ребята сделали вирусную историю на судебных прериях якобы за бренд «Беру!». В самый разгар спора я предложил яндексу купить свой домен kupi.ru вместе с товарным знаком «купиру», но практически сразу получил отказ.

Satom.ru — аналог яндекс.маркет, с хорошей (в отличии от яндекс.маркета) реализацией. Ребята постарались, выражаю почтение. Но бренд. Я вот даже сейчас в попытках вспомнить адрес сайта потратил около 10 минут, что бы найти их в поисковике. Satom не вызывает никаких ассоциаций

Конечно, существуют рекламные кампании с внушительными бюджетами, где задачей ставится узнаваемость бренда массированной атакой, например, Avito.