Microservices vs. inner source

I just listened to Eberhard Wolff’s BED-Con talk on microservice-based system architectures, which he prefers to call Independent Systems Architectures (ISA). One purpose of calling it ISA is to emphasize that there should be no common data model and no shared reusable libraries between microservices. Obviously, by discounting reuse, ISA may increase development speed short-term while increasing cost and quality problems long-term. Eventually, in his talk, Wolff came around and argued that microservce implementation independence and reuse are a trade-off rather than an either-or decision.

In my mind, this raised the question about how inner source relates to software architecture in general and microservices in particular. After all, inner source promises increased developer collaboration for better reusable libraries and components. Do microservices suggest no inner source is needed, because no or little reuse is needed?

My answer is that the strength of inner source plays to the trade-off between independence and reuse. Traditional reuse is imposed top-down, for example, in classic product line engineering, while inner source based collaboration and reuse happens bottom-up, based on developer rationale and voting with your feet. Thus, if developers believe it is in the interest of their microservices, they can choose to collaborate on libraries they use or decide against it, rather than being forced to collaborate on a plattform they’d rather not use.

So, I guess, it is microservices and inner source, rather than microservices vs. inner source.