Kerpan’s law of product management:
Good products are defined by what they aren’t.
Patrick Kerpan, CEO, Cohesive Networks
Swan’s corollary:
Bad products are the integral of every stupid little feature request.
Background
A colleague was recently bemoaning GitHub not having a feature for a markup he was using. Competing products like GitLab had the functionality. The GitHub forums had long threads of other people asking for the feature. What was wrong with them, denying something that was obviously in demand?
You can do that with an Action.
Me
That seems like a sledgehammer to crack a nut.
Them
Works tho, and saves them from supporting nut crackers, small hammers, medium hammers etc.
Me
Avoiding the exploding test matrix of doom
Back at Cohesive when I was working on the VNS3 networking virtual appliance it was commonplace for customers to ask us for extra features based on popular tools. They knew that the virtual appliance was just a Linux base with a bunch of open source tools wrapped together with our proprietary glue to provide an API and user interface. So what harm would there be in adding just one more tool to the mix?
In isolation every request for Varnish for caching, or HAproxy for load balancing, or Ngnix for reverse proxying, or whatever seemed entirely reasonable.
But in aggregate those feature requests took us to the exploding test matrix of doom. Worse still, everyone wanting HAproxy might want a different version, and a different way of configuring it, and a different way of logging. The exploding test matrix of doom was exploding in every direction. And that’s why we held firm against all of it – if we succumbed to one little feature request then it opened the floodgates to them all, and that would inevitably lead to an unmanageable mess.
The universal solution
We fixed the problem at Cohesive by providing a Docker subsystem for plugins. You want Varnish, have a Varnish container. You want HAproxy, have an HAproxy container. You want different config, that’s just fine.
The key is that the subsystem introduced something like the cloud ‘shared responsibility model’. We were responsible for the subsystem working, the individual users were responsible for what they put into it. For sure, we seeded the endeavour with a bunch of samples and examples that were often used with little or no modification; but crucially we’d drawn a line around what we were responsible for (testing for).
Actions is GitHub’s universal solution
The answer to almost every question about extending GitHub functionality has become ‘you could do that with an Action’, at which point the discussion moves to the distance between ‘could’ (a hypothetical possibility) and ‘can’ (something that is achievable right away, maybe with a bit of light web searching)[1].
This gets GitHub out of the business of responding to every stupid little feature request, and bloating the product with lots of knobs and dials that most users never need or want.
Closed to Open to Ecosystem
The whole reason why people need to make feature requests in the first place is that a lot of software (including GitHub) is closed off to end user modification.
Things change when software becomes open, because anybody can take it and change it to suit their needs.
But the real magic happens in ecosystems, where people are sharing their solutions with each other for continuous spirals of improvement and reuse.
We certainly saw benefits from the Docker ecosystem to VNS3 users, and the same is very visibly happening with Actions – value is being provided to GitHub customers by other GitHub customers, without GitHub themselves having to get involved. And of course Docker is a big part of the Actions landscape, so GitHub users can reap benefits from both ecosystems at once. Win, win, win.
Conclusion
Actions is more than just a smart move for GitHub to do more stuff with Continuous Integration / Continuous Delivery pipelines – it’s a product management super move that gets GitHub out of the business of responding to stupid little feature requests. Better still, it’s an ecosystem play where GitHub (and Docker) users create value for other GitHub users without GitHub needing to invest their own time and treasure.
Note
[1] Another Kerpan at Cohesive aphorism was “California can”. When we said “we can do that”, we meant that the functionality was there, in the product, ready to go, now. When visiting Silicon Valley when we heard people say “we can do that”, we understood that to mean ‘I have a great product team and some outstanding engineers, and we think we can build that in the next six months’.
