When we talk about how code moves in the free/open source software ecosystem, we often use the upstream/downstream analogy. In this analogy, code flows from an upstream project downstream to the users and vendors. Users use. Vendors package and support. When anyone contributes their ideas (innovations) and code back to the project, it is said to happen in the upstream.
Recently I was in a meeting with a few folks and we were discussing the flaws in that analogy. For one, it describes backbreaking labor or requires magic – how do you get your changes from downstream back upstream without overland hauling, big motors to get through the rapids, or a helicopter firefighter team. It supports the idea that getting things upstream is hard, and therefore undesirable. Our real world experience is that the projects prefer to make it easy to contribute, and then we have to extend the analogy for pipelines that carry water, etc. It also doesn’t really describe the actual flow of innovation, it’s not all in one direction toward a larger ocean.
As a first pass at describing this virtuous flow, I wrote,
We all live on the same river. Care where your water comes from. Care where your water goes to.
What this misses is the circularity of the flow that a river doesn’t encompass. For a river to be circular it is either something magical or it’s not a river, i.e., the analogy is inaccurate. Just as I reached that conclusion, so did JimJag because he jumped up and drew this image on the whiteboard:
That, folks, is a water cycle. It solves the circularity problem because it looks at an ecosystem as a whole. In a normal physical world the water that flows downstream doesn’t spontaneously go back upstream directly. Anything else that happens to get water back upstream directly is a manual process – pumps, helicopters, etc. But a river is not in isolation – it flows from multiple sources down to the ocean, and along the whole way evaporation brings the water back to the atmosphere so that it can come down in ways that may replenish the water sources.
In this new analogy (and diagram), I’m not sure yet where to put the various groups we’re used to putting on the river. Such as, “User”, “Project”, “Vendor”, and “Customer”. Also, it’s unclear to me if the water represents one thing – contributions, code, content, what? – or if the water is in fact us. Looking at my own experience, I work for a free/open source software company, contribute to many projects, benefit from many thousands of more projects, and am a customer of vendors who create and sell solutions around or based on open source. As I’m moving around that water cycle … am I a boat or the water itself?