Democracy

Ansel should be run democratically and fairly to everyone involved.

Defining a cooperative organization beyond open-source code

Developers and users landing here are assumed to share a common interest : they want freedom in how they edit their pictures, now and in the future. Meaning :

• having a sufficient technical control over their image content and properties,
• being free from capitalists who may :
  • increase their application price at the sole benefit of shareholders,
  • mine customer’s photos to train AI models without consent,
  • extinguish applications without releasing the source code,
• having a right to decide on the contours and implementation of said freedom.

Ansel DNA is more technically-minded and fined-grained than most RAW photo editors, while still emphasizing user-friendliness where it’s possible, mostly on typical desktop-centric tasks (interactions with input devices and files, GUI paradigms, etc.). Ansel is not Darktable  or ART  because its vision of what a good image retouching software should be is quite different.

Ansel is released under the GNU/GPL license , making it a free/open-source software. While this gives a (wrong) sense of long-term availability, the reality is its long-term availability depends solely on the will and ability of some developers to perform the (tedious) day-to-day maintainance to keep it working, keep supporting new cameras, etc. which is an underrated task because it doesn’t produce spectacular release notes or keynotes.

Worse, the so-called “freedom” granted by the GNU/GPL license impacts only the source code : it is engineer’s freedom. Open-source licenses essentially waive intellectual property on the code, which means engineers can study and modify it, then share their modifications. Given that less than 6 % of the world population¹ can actually write code, this is a right for only a privileged minority. As for users, well, the GPL license is quite clear :

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;

This statement essentially excludes end-users from the transaction : they have no rights other than running the code as-is, especially no right to get support and bugfixes, let alone get the software shaped to their needs. If some support is still provided, it’s at the discretion of developers and users should be forever grateful for it. This is abused on so-called “open-source communities” (meaning “software forums”) to shutdown and invalidate any user complaint : they simply can’t complain since they are using free work, even though the marketing of open-source projects often wax lyrical regarding the “professional” fitness of those applications. But… promises were made, the “pro” word was uttered but not delivered, so there is a misleading inconsistency somewhere.

Even waiving any responsibility towards users, many projects still try to turn them, if not into customers, at least into donors. Which faces a sad state of affairs : 350 years of capitalism have rotten our brains into thinking that open-source applications were the cheapest competitor to proprietary software. Users simply sit on their bottoms waiting for the projects to deliver a product before deciding if they will bother to donate. This is like starting to fund the NASA after the first rocket was launched to prove the project can indeed deliver : it can’t be. You need to pay the work even before there is a product to sell. And when the product is released, projects like Wikipedia still struggle to get less than 3 $/year from 2 % of their user base.

Open-source applications are competitors of proprietary applications just like public hospitals are competitors of private clinics : they are not. On one side, we have a socialist project started by the belief that everybody has a right to healthcare, and if they can’t afford it, we will make do by finding extra money into the community. On the other side, we have shareholders trying to make profits, hiring surgeons trying to pay for their Malibu home and their collection of Porsche. How are they competitors ? A public service is a way to ensure people have resources to exert their rights, because freedom is only theoritical until you have the means to actually make use of your rights. A private company selling goods or services is a way to make money out of investments. The difference is political. It is also economical, since not having the shareholders on the payroll makes the final product more affordable anyway.

The blindspot of the “Free Software” movement was to avoid thinking the context and the working structure in which such software happens, is developed and maintained. This can be traced back to the hacker culture , which is individualistic by nature and capitalism-compatible by proxy, through technophilia  and technosolutionism . “Sharing as-is” (your work, your code, your hacks) was mistaken for “taking care of” (other people’s needs, limitations, challenges) and entertained with quasi-hagiographic narratives. When you have a hammer, everything looks like a nail : when all you know is code, code is the solution to everything, and trying to wrap it into philosophy and (non-revolutionnary) politics to define “code freedom” still misses the big picture that is the exploitation of everybody’s work by a small but powerful and self-reproducing social class. While 6 % of the World population could write code in 2021, the ratio who could even afford a personal computer back in the 1980’s, when the Free Software movement started, was much smaller. Privileged minorities are always blind to their privileges : this is how you identify them. They failed to see that Free software was nothing more than the brainchild of those privileges.

The Free Software movement was made to fit into this individualistic, free-enterprise, liberal-market capitalism, and made everybody think that it was enough to let everyone start their own project or fork it from others. Then, social Darwinism  would sort things out. Yes, but… who pays for the work ? Worse, since capitalism gives value to work only when its product is sold on a liberal market, and that value is indexed on the product scarcity, how exactly are we supposed to convince users that something dematerialised, infinitely downloadable for free has any value ? Many open-source projects have tried many different strategies to fund their work, they are all precarious and crippled because they still want to fit a working structure that is communist by nature into a capitalistic framework (more on that below).

While non-profit organizations may work for humanitarian projects, where donors will never be the target recepient of the work, for software projects, donations are interested because donors are users. This entertains a consumer-like behaviour, where passive (and somewhat oppressed) consumers wait for the goods delivered by an elite minority of board members who calls the shots. Those non-profit organizations are still privately run, and the public has no other right but to stop donating if they don’t feel heard. The board of the Linux Foundation  is almost exclusively composed of executives from hardware vendors and GAFAM , the board of the Free Software Foundation  is composed of scientists and computer technicians. There is no representation of users there, there are vertical hierarchical structures of “those who know” over “those who need”, perpetuating the same kind of domination as capitalism, minus profits.

This is justified by the fact that the open-source licenses waive any form of responsibility (warranty) from developers towards users, which makes it a one-way transaction that apparently gives all the power of decision to developers. But all that is of course a construct, and not a forgone conclusion. On the other end, because the capitalistic dogma is so deeply impregnated into user’s brains, the source code brings a software on a free, dematerialised and non-scarce market that voids any notion of capitalistic value, which makes it ok for users to get the product of the work without contribution : another one-way transaction. Meanwhile, some developers are burning out and exhausting themselves to provide reasonable user support, without getting a reasonable income from their (exploited) work, maybe in the hope that it will end up paying in the long run, once they “make it”. Or developers accept the unspoken rule of open-source (it should only be a hobby/part-time), which inevitably sets open-source back, as a forever-poor sibling of proprietary software. Or, finally, some open-source companies like Automattic  or RedHat  start getting more and more aggressively greedy over time, facing the backlash of their communities. This is not sustainable, for neither of the involved parties.

We need to turn those two parallel one-way transactions into a circle. This is how :

1. No technology can exist outside of the society that produces it. Technology needs science. Science needs research. Research needs structures where it can be conducted freely. Society is the environment where all of that happens, as well as the support system that makes it happen.
2. No technology can exist without work. If the product of the work escapes the capitalistic system (scarcity-based and competition-based liberal market), then the work producing it should escape it too.
3. No technology that is privately-owned will serve the common good and the public interest. Technologies, not just devices, should be owned by their users, not just by their makers.
4. Work is the only wealth. Workers should benefit from their work, whether sold on a liberal market or not : it should be paid no matter what. Work should happen in a safe and fair environment. It is a collective, social responsibility to make that happen, because the product of the work serves the common good and public interest. Work that doesn’t serve those should simply be stopped.
5. Technologies owned by their users open the way for a new kind of production : collaboration between makers and users, instead of competition between makers and coporate wars to win markets through convincing customers of some product’s superiority (making users pay for advertisment in the end…). But capitalism doesn’t know how to sell the product of cooperation, because there is no separate buyer or seller anymore, only a community of persons who work toward something together : fulfilling their needs, turning their theoritical rights into actual freedom by creating the the context to exert them.
6. There is a mutual responsibility of makers towards users (fulfilling their needs through/with technology), and users towards makers (giving them a safe and fair working environment and material living conditions). This is the very basics of a community²…
7. Open-source leading to true freedom can only happen inside a cooperative  structure. Which is an old, proven and already-working communism, where the company (therefore the open-source project at large) is owned by its clients and by its workers, who share voting powers. This goes well beyond a mere intellectual property waiver (open-source/free license).

A cooperative is a way of breaking this dichotomy between “us” and “them”, makers vs. users, that feeds mutual resentment : developers are the dictators taking the application for their personal playground, to whom users should always be grateful no matter how they destroy it, users are the annoying leaches that keep raising cryptic issues and feature requests, while donating too little.

In a cooperative, makers and users alike are members-shareholders. They all own the project, they all have one vote in the general assembly. The project is to make photo editing free for the foreseable future, under some unified vision of what photo editing is (how technical & fine-grained it should be vs. how easy and user-friendly). To fulfill that goal, many means are involved, like education, advocating, documentation, and obviously a software application. The project is more than just an end-product, which can take some time to appear and be ready : the project is everything above and around, it’s a goal and all the means to make it a reality.

The responsibility of the members is to secure a yearly budget to cover all project costs, most likely from yearly members dues. From that budget, a certain amount of working hours at a certain hourly rate is decided in general assembly. How this budget will be spent (what kind of tasks, hardware, tools, etc.) is also decided in general assembly. For technical tasks, like software development, that will be the high-level orientations (like improving masking, batch workflow, etc.) and not on implementation details or actual design, which are poorly suited for democratic processes. Developers might push backend-oriented tasks (like rewriting or refactoring technical debt, to reduce long-term maintainance cost), users might push feature-oriented tasks (like supporting new camera features, image formats, etc.) : the purpose of the general assembly is to deliberate and rank priorities.

The agreed tasks will then be tackled by paid workers in the order of priority until the work budget is consumed. This is not limited to technological work and development, but applies to any kind of work previously agreed upon. When the budget is consumed, workers will report where they stopped in the todo list, what they could finish, what they couldn’t, and what resources were missing to finish. The general assembly will then decide if it is possible and desirable to invest more resources to finish, or to slide the remaining tasks into the next yearly budget. This gives workers visibility over their yearly income without promoting over-committment and burn-out.

Users can form panels to work with developers on understanding the actual issues faced, test and validate solutions into a design process. Any user can be turned into a worker and start collecting income for their work on agreed tasks, upon approval of the general assembly.

This makes it everyone’s responsibility to ensure the resources to go forward are gathered, and to give workers what they need to work decently, safely, without getting exploited. No amount of work should be free, no matter the task. Work should not be limited to programming or other technical tasks.

The limits of democracy

Democracy by vote is essentially expressing the will of the majority, which has been known to oppress minorities. It is therefore not perfect. Minorities might voice reasonable and legitimate concerns, only they will not be shared by the majority. Disabled persons come to mind : some design details may make the whole application completely unusable for them, even though they don’t have the numbers to impose their views in a vote. On the other end, it is not possible to accomodate each and everyone’s peculiar needs without creating monsters. This needs to be carefully evaluated and arbitrated.

The responsability of the majority is therefore to identify who are the structural minorities, that is what properties tie those minorities together (health condition, social origin, education, level of income, etc.). If a minority raises an issue that is blocking for them because of one of the defining properties of said minority, there should be a way to bypass or re-weight the majority vote. This remains to be defined, but the easiest way to encompass this is during deliberations, which relies upon the empathy and understanding of the majority.

Another issue of any social group is groupthink , because any social group tends to degrade into a club over time. Groupthink is when individuals don’t feel free to raise issues that go against the (alleged) group consensus, for fear of repercussions regarding their place and perception in the group. Those repercussions can be very subtle yet very real. It becomes damaging when individuals start supporting decisions, inside the group, that they would not have supported on their own : this is the turning point where individual rationality gets lost. To avoid this, anonymous vote can be used, but it doesn’t apply to deliberations where there is necessarily a speaker. There is culture of sane dissension to build, maintain and encourage. One way of solving this issue is to randomly appoint a “devil’s advocate” for each session, whose job will be to constantly disagree and expose corresponding arguments.

Any community based on a shared interest for photography & free software is expected to be biased in favor of rich, educated, computer-litterate, English-speaking men. It will have to be a conscious effort to try and include women, less-educated persons, non-western citizens, etc. Combined with democracy-by-vote and groupthink, it can be really damaging to start with such a socially homogeneous group, if not managed carefully. This will be a daily challenge that everybody needs to be aware of. It will also feed the survivorship bias , where the outcasts are not here to provide feedback on why they didn’t join, participate or feel welcomed and outcasts will need extra care to be reached and welcomed.³ No amount of racism or sexism can be tolerated in a such environment, even as a joke, because that would make the majority laugh at the expense of minorities in a context from where they are already filtered out.

Democracy is also a slow process. Things may happen that need a prompt decision, like a security breach into the project server or social media accounts, or any pressing legal issue. Someone should be elected for short-term mandates to be able to quickly take those decisions on behalf of the community.

The limits of experts vs. laymen

Just like doctors or laywers, developers have niche competences and experience, that will give them some sort of power and even charisma over laymen. This power can be abused to oppress the majority by using its lack of knowledge at the benefit of the oppressor. This relationship will always be asymetrical, and that has to be acknowledged. Also, developers will have to be consulted during deliberations in general assembly, to assess the feasability of tasks and the resources needed, before votes happen.

Just like doctors, lawyers, etc. developers should uphold some sort of code of ethics that go with their symbolic power, among which :

1. a duty to honestly inform, to the best of their knowledge, and to simply explain what can be simply explained,
2. a duty of due process and due diligence when researching and developing solutions,
3. a commitment to work in the best interest of the community.

On the other end, developers (or any other experts) might be perceived as all-knowning, omnipotent wizards by laymen, who may then ask too much of them. Although software is a quite malleable medium, there are still non-negotiable technical constraints that apply, and everything that is technically possible may not be possible within the current circumstances with the current resources.

Both these positions will need to be understood as to prevent mutual resentment growing.

The limits of collaboration

Everybody is a designer.

Every job you know nothing about looks easy to do. Designing and building technical objects is one of them. It is even exciting to contribute to it. But a software that will be used as a tool by thousands of users other than yourself is not the same thing as your own nightstand.

Users should be welcomed to participate in problem definition : start from one or several users having a particular problem in a particular workflow, see if that can’t already be solved with current tools and perhaps some education, and if not, try to survey how many users share the same problem. If the problem is not exactly the same for everybody, try to find a common expression of the problem that allows to generalize it.

Once the problem is defined begins the design process, which follows formal steps to avoid racing to the first (and most likely not optimal) solution because, again, human intuition is better to build nightstands rather than tools used by thousands. But following the process is not enough.

Psychology and cognitive sciences converge toward a consensus : the best size for working teams is between 4 and 7 members. Starting at 8 members, productivity starts dropping dramatically.⁴⁵⁶ For a team of 4 members, there are 6 interpersonal communication channels, while for 8 members, there are 28 communication channels. This makes it hard to cognitively keep track of everybody involved, who is in charge of what, process non-verbal cues, which creates communication overload. Above 9 members, clans start forming, politics get mixed in the process, and social loafing  embarks.⁴⁵

This means that work should be split into working teams having each no more than 6 to 7 members, even though it might get exciting for the community at large to take an interest into everything. Communication is the turning point here : you need just the right amount of it, no more, no less, otherwise it cognitively saturates team members and hinders communication itself. There, it’s the work in itself that takes a hit.