This long post serves as a bit of my introduction to this community, explaining interests and drivers.
CUPID
I just watched @akkartik’s highly inspiring video about Freewheeling Apps and thought to point out this idea that Dan North (@tastapod) has been putting forth as an alternative (or in addition) to SOLID principles: CUPID Joyful Code.
When I started formulating a response to the five SOLID principles, I envisioned replacing each one with something that I found more useful or relevant. I soon realised that the idea of principles itself was problematic. Principles are like rules: you are either compliant or you are not. This gives rise to “bounded sets” of rule-followers and rule-enforcers rather than “centred sets” of people with shared values.
Instead, I started thinking about properties: qualities or characteristics of code rather than rules to follow. Properties define a goal or centre to move towards. Your code is only closer to or further from the centre, and there is always a clear direction of travel. You can use properties as a lens or filter to assess your code and you can decide which ones to address next. Since the CUPID properties are all interrelated, it is likely that any change you make to improve one property will have a positive effect on some of the others.
CUPID as acronym stands for the properties of code to be:
- Composable: plays well with others
- Unix philosophy: does one thing well
- Predictable: does what you expect
- Idiomatic: feels natural
- Domain-based: the code models the problem domain in language and structure
Joyful coding
Besides these properties and their application I find something else, and important, to be conveyed in this concept. Namely with the word Joyful.
There’s a lot contained in this simple word. And I feel it is hinting at something crucial, often overlooked and missing in Free Software circles, but also more broadly in civic movements and grassroots movements in general.
In another thread @akkartik refers to this observation:
Very true. That refers to monetary compensation. But do developers work without any ‘rewards’? Do they work without incentives that provide motivation? No, they don’t. And that is only natural.
Here is a big difference to how the business world operates, where employees are set to particular tasks and see them through. Salary and job security are important motivators to keep them on it, and also do the chores.
In FOSS more hedonistic motives are the key drivers. Passion and beliefs lead to starting particular projects, and “joy of coding” is often involved to explore innovations. There aren’t fixed organization structures where collaborative relationships are hammered out, as happens in companies. The social dynamics are completely different.
Community collaboration
Having tried my best at stimulating the emergence of inclusive Communities of Action (CoA), and noticing how hard the “herding cats” challenge in grassroots movement is, this insight was kind of profound to me. Generally speaking small and focused communities work rather well. As soon as the audience gets larger and scope broader CoA’s - at least the ones having only volunteers - become nigh impossible to uphold.
Rephrased: If you want to start a highly productive CoA with both a broad audience and scope (i.e. evolve a technology, explore a paradigm), it will likely not live up to expectations unless you either:
- Have committed facilitators able to dedicate near full-time, willing to do the chores, for prolonged time.
- Are satisfied with ‘natural speed’ of evolution and patiently take to ‘gardening’ as growth happens.
Point 2) isn’t what we are used to in our hectic, results-driven society and most people joining the community come with Expectations of productivity and results delivery that do not match this approach. These people move on to ‘greener pastures’ (in their eyes).
Joyful creation
Fascinated by Dan North’s notion of “Joyful coding” I expanded the concept to be multi-disciplinary and made it to be Joyful Creation. After all, when we consider the software development lifecycle, we have many, many stakeholders each playing their part in it. If we want inclusive software development then the choreographed seamless interaction between all these people must be front and center.
Joyful creation takes hedonistic aspects into account, focuses on motivation and expectations, and the incentives that people need to collaborate with others.
Sustainable ecosystems
My biggest frustration in doing all that community work and advocacy for years was witnessing how self-centered and individualistic people are. But the insight I’ve since gleaned is that we should take this as a given. It is just how things work. When doing so, it provides a whole new angle and fresh perspective to look at how to foster healthy ecosystems where technologies evolve and new paradigms take root.
First of all we must go full-spectrum, holistic in our approach: social ↔ socio-technical ↔ technical.
What I am most interested by is 1) the much talked about inherent unsustainability in FOSS movement, and 2) the eternal fragmentation in FOSS and civic spaces. FOSS is successful only when looking at its deliverables. The fragmentation leads to continuous wheel-reinvention and small initiatives being but weak in the face of large wicked problems.
What would be needed to achieve holistic sustainability in thriving ecosystems?
Ecosystems that emerge from grassroots movements and created by and for the Commons. Consider this:
Why can Big Industry, say in the automotive field, profitably uphold intricate global supply lines, where countless high-tech factories deliver parts in a just-in-tim fashion? While a single FOSS project has the highest difficulty to overcome the challenge of becoming popular, should that even happen?
The Fediverse is very interesting here. It is among few open-standards based ecosystems that rose to popularity without any corporate involvement and driven solely by bottom-up grassroots involvement.
Fediverse is also the example where severe cracks in the success formula become increasingly apparent. Where, after W3C standardization, emergence of apps happened but at the cost of ever increasing Protocol Decay (see RFC-9413), and without being able to organize an efficient technology substrate (people and processes that evolve the standards).
Technology adoption
We’ve all heard of the Technology adoption life cycle, and how we need to somehow “cross the chasm” to introduce new technologies and paradigms to large audiences. And searching the web we find a ton of information how we can do this.
Interestingly most of this information doesn’t really apply, or applies differently, in the context of FOSS and Civic grassroots movements. Technology adoption has tried and tested methods that are designed for companies to be followed. In our setting we have unique social dynamics that we must take into account.
And as it happens there are Technology Adoption Models (TAM’s) that do so. I named them in the Fediverse challenge that observed that the technology adoption lifecycle is stuck. These models provide fascinating handholds to think how grassroots ecosystems might thrive and be long-term sustainable.
Malleable systems
I am excited I found this community. The paradigm described on Malleable Systems fits part of what is needed from, looking a (socio-)technological perspective. Smallness in all the things, Small Tech, small groups of people, decentralized all, motivated to collaborate. Spontaneous emergence.
As it happens, though this is just a hunch, when going holistic on what would make sustainable ecosystems thrive, the resulting system becomes organic, subject to the Forces of Nature.
What I observed from first impressions of this community is a strong technology focus. Not denying the social aspects, but not emphasizing them either. I feel that malleable systems would benefit from delving deeper here. Add a component that may be missing.
Social coding
All of the above fascinates me no end. The Social Coding Movement was started to explore all of the above. It is both about “social coding” and “coding social” and explicitly not a community, but a movement. There’s no expectation for its growth and ‘success’. Success is meaningless at it scope. There’s just a DoOcracy, simply meaning “pick up any task and see it to completion”.
Sustainability of FOSS ecosystems is an attention area, and for this the Free Software Development Lifecycle (FSDL) is defined to chunk it into pieces.
Substrate formation is another area. Laying the solid foundations for an ecosystem to stand upon.
And decentralized social networks and their socio-technical protocols and standards, with the Fediverse as a shining beacon and a place where unmet potential is yet to be unleashed (before corporate takeover ensues, btw).
That’s it. My intro. I hope you found it entertaining. Where will things go from here? It’s an adventure.