Useful, Welcoming Software is a conceptual model for describing software, and articulating design goals. It is built around two questions:

1. What is this software useful for?
2. Who is this software welcoming to?

Avid Technologies Pro Tools and Ableton Live are useful for producing music. Ableton Live is useful simply because a lot of producers choose to “use” it for aesthetic and practical reasons. Pro Tools is similarly useful because it is still a core component of commercial music production.

However, Live and Pro Tools are “welcoming” to a very narrow user base, because both are expensive, closed source, and only available under restrictive licenses. You cannot legally share your copy of Ableton Live with a friend. Are you allowed to run a copy of Pro Tools on a web server as part of an generative interactive streaming audio exhibit? I do not know, because Pro Tools’ legal user rights are buried in a 240 page End User License Agreement (as of December 2020). Pro Tools is probably only welcoming to affluent audio engineers and producers with professional ambitions.

In the context of Useful, Welcoming Software, “useful,” and “welcoming” are intended to have somewhat more specific meaning than in everyday conversation.

You can think about these questions as aspirational design goals:

1. What do we want this software useful for?
2. Who do we want this software to be welcoming to?

Here’s an example from Fluid Music, which is software I am writing for my dissertation.

Fluid Music aims to be:

1. Useful for creating music that people care about
2. Welcoming to developers with a wide variety of backgrounds

Within the Useful, Welcoming Software model, software is always useful for some purpose. Conceptually, this is more useful for thinking about and articulating software design goals.

Similarly, within the Useful, Welcoming Software model, software is always welcoming to some audience.

The word “welcoming” is intended to express the intention of going beyond “access”. Not only can you access welcoming software, but in the ideal case, it invites you to use it. A high cost, a difficult user interface, or a restrictive user license are all antithetical to welcoming software. Free, well-documented software with a permissive license, and an accessible user interface, is more “welcoming.” However, care should still be taken to consider who is it welcoming to. What language is the software written in? What spoken languages are present in the documentation? Does the website or documentation use subtle -isms? What assumptions does the documentation make about the reader’s background and areas of expertise?

I found that being intentional about what I want my software to do, and who I want to be able to do it helped me make consistent design choices. It also helped me to articulate why I made the design choices I did.

It is is a simple model with modest ambitions. Note that while it may help identify or articulate design goals, this is just a first step. You still need to evaluate the implications of the software you are building. For example…

Amazon Rekognition aims to be:

1. Useful for identifying and characterizing individuals using an image of their face
2. Welcoming to governments, NGOs, and businesses

In an ideal world this would alert you to the fact that there are some serious ethical concerns with the software Amazon is creating. But if you are not familiar with the literature on facial recognition software, that might not be obvious. Know that merely identifying and articulating the goals of software you are working on is not a substitute for understanding and evaluating them.