---
title: "Three models for single source publishing — and challenges with each"
date: 2016-02-11
description: "Model 1: Separate outputs Model 2: Rights-based login Model 3: Dynamic filtering Conclusion  As I try to wrap my..."
canonical_url: https://idratherbewriting.com/2016/02/11/the-problem-with-single-source-publishing/
---
# Three models for single source publishing — and challenges with each
Consider Project Godzilla, as I’ll call it. Project Godzilla involves an API that plugs in requests from a lot of different product lines, thus serving as a kind of master API for dozens of products. The total possible JSON submitted in the request is quite large, since it accommodates so many potential products. But each customer will only use a slice of the JSON. As a result, the delivery engineers want to give customers only that slice of the JSON that they will actually need to make requests.

Here’s an analogy. You’ve got a basket of fruit that you’re offering to people, but each person will only eat one piece of fruit from the basket, such as an apple, orange, or banana. You want to give each person only the documentation for the fruit they are consuming, not the documentation for all fruit in the basket.

There seem to be at least three separate models for tackling this kind of single-sourcing scenario.

![Three models for single sourcing](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/threemodelssinglesourcing-01.svg)

## Model 1: Separate outputs

A lot of the static site generating tools, from OxygenXML to help authoring tools to Jekyll and others would solve this problem by having you apply various tags to the different fruit, or rather to the different elements of JSON in the request. Then you run a build process that spits out a separate site for each product based on the tags you want to include or exclude.

Sounds good, right? Now you have 10 sites and you give the appropriate links to each person. Each person sees only the information that pertains to the product/fruit he or she is consuming.