We have never been able to create software as quickly as we can today. Low-code platforms and (agentic) AI development tools keep reducing the distance between having an idea and getting an application running. And they bring back, once again, the promise that everybody could build all the software they need (with as many caveats as you want, of course)
But what is the point of all this software if it doesn’t improve people’s lives? and makes the world a better place to live in?
Making development faster to build doesn’t make it free to create (e.g. from a energy consumption perspective),. Even less to maintain. Or harmless to use. We can generate more software but this software could still generate more exclusion, more resource consumption, and more tools that solve problems nobody really had or that were already reasonable solved before.
This is the starting point of my new position paper: Social³Source: Connecting Social Provenance, Societal Qualities, and Social Purpose on an Open-Source Software Foundation. This is the abstract:
The speed at which software can be created and deployed today has increased dramatically. But what is the point of all this software if it does not contribute to society? The ultimate goal of building software should be bettering human lives and society. And this goes beyond publishing the software as open source; it requires considering how it is developed, the societal qualities it embodies, and the purposes it serves. This is what I call Social3Source. This paper presents the concept, principles, and initial discussion for the implementation of Social3Source, illustrating how it integrates social considerations into open-source software development. We have never generated as much software as we do today. Let’s make sure it counts.
You can read the full paper or keep reading for the main ideas.
So, how do we make sure this growing amount of software brings value to society? I propose starting from an open source foundation. But being open source is not enough; we need the source to be social as well. Social regarding how the software is built, the qualities it embodies, and the purposes it serves. Allow me to elaborate on this.
Open source is the foundation
Open source gives us essential freedoms: we can inspect, use, modify, and redistribute the software. Communities can adapt it to their circumstances and continue developing it beyond the involvement of its original creators.
These freedoms matter. They are the foundation of Social³Source.
But an open-source license doesn’t tell us whether the people affected by an application had a say in its development. It doesn’t tell us whether they can actually use it as eexpected. And it doesn’t tell us whether using it helps them.
So I propose looking at three complementary dimensions. The superscript three in Social³Source is there for a reason (beyond making the name slightly harder to type 😉 and complicating my life for the indexing of the work in scientific repositories).
1. Social provenance: how and by whom is the software built?
Software development involves many more people than the ones writing code. Translators, documenters, domain experts, people reporting problems, and users testing early versions all contribute to the result.
Recognizing these contributions is a first step. But we should also ask whose perspectives they represent and whether they cover all the views and dimensions that the software targets. And it is not just about being part of the “team”. They need to be able to influence the project. And for that they need to be an active part of the project governance. Having a diverse community around your repository is of limited use if all important decisions remain in the hands of the same small group.
To formalize this dimensino, I build on our previous work on the Software Diversity Card to consider participants, usage context, and governance together. Each software project should clearly specify aspects such as: Who contributes? Which diversity perspective they bring? Which communities does the software serve? Who decides what gets implemented, and how are disagreements resolved?
A simple list of contributors cannot answer all these questions. A list of commiters even less.
2. Societal qualities: what properties does the software embody?
Any social software should go beyond just providing the expected functionality. It should do in a way that it also respects and encourages a good number of desirable societal qualities.
Accessibility, multilingualism, privacy, fairness, affordability, and environmental sustainability are obvious candidates. But they are not a closed list, and their priorities (and the trade-offs that must be considered when deciding to implement them) depend on the people and circumstances involved / targeted by the software.
We will need a taxonomy of this type of properties (and we need to join forces with experts from social science, as part of an interdisciplinary effort, for this). And a library of potential architectures / techniques / libraries / standards that can be used to guarantee them.
Note also that offering a property is not enough. We need to make sure the users for which that property is useful can actually use it. For instance, supporting several languages sounds like an improvement. But imagine that English suppport works locally while every other language requires an external AI translation service. For someone without reliable connectivity, the application is multilingual mostly on paper. Implementing a feature and enabling people to benefit from it are two different achievements. We should evaluate both.
3. Social purpose: why does the software exist, and whom does it help?
Almost any application could, in principle, help an organization doing useful work. An NGO can use a spreadsheet or an accounting package. This is valuable, but such a broad definition would allow practically every application to claim a social purpose.
I’m interested in a more explicit connection to the mission: software created or adapted to help communities and organizations carry out their specific social activities. Coordinating food distribution, matching volunteers with requests for assistance, or helping people access shelters and public services are examples.
Of course, this goes beyond NGOs. Public services, cooperatives, and informal community groups can also benefit from software adapted to their needs. The question is whose situation we expect to improve, which activity the software supports, and what barrier it helps remove.
The three dimensions need each other
Consider an open-source application helping migrants find local services and navigate administrative procedures. Its purpose sounds useful. But developers alone may overlook some of the problems migrants encounter as they didn’t live the experience themselves.. Involving migrants, social workers, and translators could change the requirements. Their participation could reveal that the application needs simpler interactions, additional languages, or support for modest devices and limited connectivity.
Those requirements would then affect implementation choices. An AI translation service might broaden language coverage, but also introduce errors, resource costs, and a dependency on connectivity. Locally maintained translations might be preferable for some sensitive information, even if fewer languages can be supported initially.
Finally, evaluation should look at whether people can find services and complete the relevant tasks more easily. Having deployed the app is not evidence that we have helped them. If the target audience (migrants in this case) don’t end up using the application, it’s not yet an example of Social³ Source.
This is why I want to connect provenance, qualities, and purpose. Each can inform decisions in the others.
How do we put this into practice?
The immediate question is how to turn these ideas into something that teams can actually use when building software. In the paper, I propose a model-based approach. We already use models to describe an application’s data, behavior, and interfaces. We could also use them to describe the communities around it, the societal qualities it should support, and the goals it is supposed to serve.
The objective is to make these commitments explicit and connect them to design, implementation and evaluation. To support this approach, we could extend existing modeling and low-code platforms such as BESSER. Existing languages for user profiles, goals, and governance provide starting points. The paper shows a BESSER user-profile model, as an example of describing language competences and accessibility needs. Together with the modeling languages, we also need to provide generators that automatically transform those models into relevant artefacts. For instance, code-generators could embed best practices to automatically generate an accessible version of a UI when this is one of the non-functional social requirements of the software, even if the designer didn’t take the time to do that himself when modelng the interface.
Reusing them (both languags and generators) across projects could reduce the effort required to implement societal qualities, provided their assumptions and limitations are clear.
And the development process itself must also be accessible. Inviting people to participate doesn’t help much if they cannot understand or change the specifications. Graphical editors, forms, and conversational interfaces could offer different ways to contribute. We still need to evaluate whether these interfaces give people meaningful influence over the software being built.
None of this comes for free. Participation takes time. Social qualities often involve a higher delivery cost (as they need extra development and testing work). Qualities can conflict, and communities may disagree about their priorities. We need to make these trade-offs explicit rather than assume that every desirable property can be maximized at once.
The paper presents an initial position and a research roadmap. We need better interdisciplinary foundations, suitable metrics, social modeling languages, reusable generators, and methods for negotiating priorities. And, above all, we need evaluations with the communities the software is intended to serve.
A possible social score is one of the research directions. But deciding how to compute a meaningful score, what evidence it should require, and which comparisons would be fair remains an open problem. Adding another badge to a repository would be easy. Making it useful would be harder.
Efforts addressing one or two of the dimensions already deserve recognition. Social³ Source is a proposal to connect them and consider them throughout the software lifecycle, rather than wait until the application is finished.
I’d be very interested in your feedback and opinions. And I’m open to any type of discussions / actions that can push this further. I know many of you are interested in this, and a few have already expressed similar ideas in the past. Let’s make it happen!
