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:
- Trust. Who trusts who and to what amount? How do we verify something came from a trusted source? What about people caring about different needs of trust?
- Accidents. People aren’t perfect. We screw up. How do we handle and work with imperfect people?
- Disagreements. We are good at disagreeing. We end up putting a lot of work into trying to come together. Yet, even when we work together on specs or agree to use them there are cases where people break from them. How do we handle that?
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.
Operators and Consumers
This is the role that consumers and uses the code and applications of others. If they’re using a programming language they would be downloading libraries. If they are doing it for a platform it might be fetching application packages such as a database.
Distributors
Those who distribute code are not always those who develop it. This is more true of platform package management than programming languages. For example, do the people who package up databases for debian write those databases?
In any case, this is a different role with different considerations. For example, do the distributors get to control the hosting location for their packages or is it a 3rd party that does it? Who has to pay for it? And, what do the tools and user experience look like to aid them in distributing packages?
Code Developers
These are the people who write the code. They’re broken out separately because writing code is a different role from sharing and consuming something.
Consider the case of a professional photographer. When they are taking photos it’s one activity and context. When they are sharing those photos, possibly via a stock photo service or some other means, it is a different context. If the person is doing mixed media and consuming the photos it’s another context.
Separating the different roles can be valuable when it comes to understanding the needs of people in different activities.
Dependency Management Tool Developers
Then there are the developers and operators of the tools. This is, again, a different role. A role that is much more a minority of the people than the other ones.
What’s most interesting about this role is it is the one defining the path for those in the other roles. Do the tool developers build what they want or what will enable others? It all depends on their ethos.
The tools these developers build and how they operate them will also have an impact on the platforms. Those in the other roles will evaluate the platform based on how they view the features built by people in this role and try to discern the ethos of those behind it.
Priorities
In this whole mix of roles it’s also worth looking at which roles are prioritized over other roles.
For example, when we talk about distribution of packages is it via a central web service (e.g., npm for JavaScript), a more decentralized approach (e.g., Composer for PHP), or a mixed approach (e.g., Debian APT). With these different approaches consider where search metadata goes, who it’s valuable to, and what the experience is like for the other roles. If we start by prioritizing the needs of people in different roles it can help to figure out how to navigate this space in a way that satisfies the people you want to prioritize.
We also have to consider that no two roles can have equal priority. Sometimes you need to pick. Being intentional and up front about priorities can help make decisions later.
A Simple Thought
By starting with people in mind we can build, use, and discuss tools that help and enable people. People are the important thing in all of this. It’s worth starting there in any discussion.