5 Components Are Not Products

The open-source clinical stack is, by now, genuinely excellent. There is a package for building complex regulatory tables, a package of standard analysis functions, a package for listings, a catalog showing every standard table with runnable examples, a synthetic data package, and an interactive exploration framework. A well-funded team spent years building them, open-sourced them, and maintains them professionally. Anyone can assemble world-class clinical reporting capability today for the cost of an internet connection.

And yet almost nobody ships with it.

This is the central paradox of the modern clinical tooling landscape: capability is abundant; adoption is scarce. The same firms that happily use open-source databases and web frameworks in unregulated departments look at a free, superb table engine and see… work. Integration work, validation work, infrastructure work, training work, risk work. The component is finished; the product is not.

5.1 What a product adds

A component does a job when invoked. A product removes a category of worry. The difference shows up as a short, brutal list of questions that every buyer — and every internal stakeholder — asks, whether or not they can articulate them:

Where does it run? A component needs an environment. A product brings one, or installs one in an afternoon.
How do I know it worked? A component returns a table. A product returns the table plus the evidence that the table is right — the comparison, the audit record, the manifest.
Who is accountable when it breaks? A component has an issue tracker. A product has a support channel, a version policy, and a validation package with names on it.
What does it replace? A component must be fitted into an existing process. A product arrives with the process inside it.

The open-source clinical ecosystem answered almost none of these questions, because it was built by a large company for whom the answers were internal: their own validated environment, their own support organization, their own process. What they open-sourced was the machinery. What they kept was the factory.

5.2 The assembly gap

This is not a criticism; it is an opportunity map. If computation is free and abundant, then the scarce good — and therefore the valuable one — is everything around computation: the contracts between pieces, the evidence trail, the validation artifacts, the deployment story, the support promise. These are unglamorous. None of them will ever trend on a conference program the way a new grammar of tables might. But they are precisely what a CRO or a biotech cannot assemble cheaply itself, and precisely what it will pay for.

There is a useful analogy from a different regulated industry. Batteries became commodities; battery management systems — the monitoring, balancing, and safety layer around the cells — became a thriving product category. Clinical reporting is entering the same inversion. The table engine is the cell. The trust layer is the management system.

5.3 The strategic consequence

The consequence for a builder is liberating: you should not compete with the components; you should compose them. Every hour spent re-implementing a table layout engine is an hour not spent on the layer nobody else is building. The successful play is to treat the open ecosystem as a supplier of commodity computation, and to invest exclusively in what the ecosystem structurally cannot supply: the product wrapper that turns capability into accountability.

Components win arguments. Products win budgets. The rest of this book is about the wrapper.

The test. For any tool you are considering, ask: when it finishes its job, what do I hold in my hands besides the output itself? If the answer is “nothing” — no evidence, no environment, no accountability — you are looking at a component, and someone still has to build the product around it. That someone should be paid accordingly.