Relational Architecture

Software is designed by and for people. How do the relationships of those people affect the architecture of the software itself?

When looking at software systems, I ask: "What do people need, and when?" Often people's needs take the form of things they need to know, but sometimes their needs might be for control, or stability, or the peace of mind that comes from not needing to know anything at all.

I am interested in both the design of the software itself, and the broader system that the software is a part of. Some of the questions I like to ask are:

• How do you structure your releases? What release cadence, testing process, versioning system, changelog/release notes process do you use? What needs do these structures meet? How do you know about those needs? What relationships do you have to people using your releases?
• How do you structure your branches? What needs does that structure meet? How do you know about those needs?
• What are the core concepts in the system? How did you determine that they were the core concepts? How do they reflect the needs of your users? How do you communicate the core concepts to users?
• Relatedly, what are the core classes, functions and modules in your codebase? How much do contributors and/or users need to know about them? How are they impacted by changes to them, and how do you communicate with them/warn them about changes?
• How do new features get added? What do contributors need to know to add new features? What are the barriers to contributors meeting their own needs?
• How much control does the end user have over what their experience is like, and how much do they rely on you to meet their needs? How does the structure of the software influence how much control they have?
• Do you have any kind of plugin or extension system? How did you decide on the scope and interface for it? Have you had to make any changes? How do you, your users, and other members of the community interact with third party plugins or extensions?
• What dependencies do you rely on? How do they affect you, or even your users? Is your project a common dependency for other projects?
• What in your system causes pain and frustration to you? To your users? To your contributors? Is that frustration inevitable or could it be fixed by restructuring?

I'm not a software architecture expert. But I think the relational lens is a fruitful one when making structural decisions. My goal is to develop and share a better understanding of how relationships impact architecture, so that projects can use that wisdom in their design.

Right now, I am primarily exploring this topic by going on 'Project Tours'. These are recorded sessions in which an open source maintainer functions as a tour guide to their project, showing me the lay of the land and answering my questions about how their design reflects the relationships and needs of contributors and users.

If you are a maintainer who would like to participate, please fill out the form below. It's totally free so long as you're willing to have the recording of the tour posted publicly. I can also do tours privately for a fee, but I encourage folks to allow me to share the recording, as it can be a very helpful tool for onboarding new contributors.