While the Kubernetes Application Survey highlighted some things to be proud of, there were some major problems it highlighted as well. These are the kinds of problems the Kubernetes community needs to solve to really welcome the majority.
One of the biggest is the Windows problem.
At the heart of dependency management, whether we're talking about programming languages or higher level platforms such as operating systems, is people. Dependency management is a social act of people sharing and using each others work.
With people at the center of it all we have to deal with things like:
Even before we get to any of this we need to acknowledge that people take on quite different roles in the system of dependency management. Those roles can be wildly different from each other. Sometimes we even need to talk about which role to prioritize over another when making design decision.
Yet, how often do we think of these roles and their differences? Let's take a look at them and see what we can find.
What do users need from their package dependency management? A lot has already been written on this including the output from a survey of Go developers, a specification for a dependency management tool by those who studied the issue and possible solutions, a series on vgo by Russ Cox, and even follow-up posts by Sam Boyer, one of the dep maintainers. With so many words already written, what more do people need to consider?
When Sam Boyer recently quoted Alistair Cockburn in his write-up on MVS failure modes I realized we aren't all thinking of people the same way. Dependency management tools are there to aid people. Who are these people and what do they need and want?
"Those who don't know history are doomed to repeat it." ― Edmund Burke
There are many variations on this saying but the essential element is that it's important, and I would argue useful, to know the history of something. It can provide depth, understanding, and insight.
At the moment there are many debates going on about package management in Go. There are questions being asked, such as how should it work or whose ideas should we follow?
To give context to these ideas it's worth looking at the history of dependency management in Go. It's a story of people, discovery, differences, disconnects, and even a little drama.
In my previous post I shared an example of how dependencies could break under vgo when semantic versioning rules are broken. That post talked about people, trust, and tooling in relation to MVS. One of the pieces of feedback I got was that the example could be more clear. So, here goes...