Radical transparency and funding

During the year 2021 I worked on grant applications to fund my work on Free Software and published everything in public, down to the last detail. All the drafts and discussions that led to the document submitted to the organization managing the grant, the contract that was signed after the grant was accepted, the reports submitted for milestones etc. It turns out to be unusual: one can hardly find any organization with such a radical transparency.

Examples are instrumental to successful applications

My motivation for publishing every detail of the fundraising activities of the forgefriends project was born out of frustration. In January 2021 my experience with applying for grants was non-existent and when I decided to give it a try, I looked around for examples. Only to discover there were none. The DAPSI guideline for applicants was the only help I could get to figure out how to fill the template and I was left with daunting questions such as: “Explain the relevance and socio-economic impact and benefits of your solution”.

There are a zillion ways to write down such an explanation and the guideline for applicants did not provide any hint. I reached out to people I know and some of them were kind enough to share their past experience, which helped with the first draft. I then asked them to review the first draft, which was not good at all and they showed me what was missing or not useful. Looking back, this process would have been much faster for everyone involved if only I had one example to get inspiration from.

I believe a number of Free Software projects are run by people who are as clueless as I was and did not even try to get funding because there was no example to observe. But maybe they will ,thanks to the examples that were published, because they can see for themselves how much work an application is, what followup questions to expect, what kind of oversight will be imposed on them during the period, etc.

Radical transparency

Most Free Software projects and organizations advertise their source of funding and some of them go as far as to provide financial details regarding the grants they obtained, publish their annual financial report showing how much money was spent on marketing, paid staff, etc. This is what is generally understood as a being transparent. This high level information can be summarized in a few pages and does not contain details that would can be used as an example, to conduct an audit or to check the facts.

Radical transparency is taking this a step further by publishing the documents to allow any third party to observe the facts.

It is not about invading the privacy of the people involved in the project. It is ultimately their choice to see their name and financial details revealed and doing so without their consent would be wrong. For example most names were redacted in the mails and documents related to the DAPSI grant.

Cooperatively assembling the Free Software puzzle

The most interesting side effect of radical transparency is the ability for each Free Software project to figure out where the other projects are heading.

Late 2021, I wrote a generic grant application that allows anyone interested in working to further federation in the Gitea project to independently apply for a grant by copy/pasting from it. One grant application was derived out of it, sent to NGI discovery and accepted in January 2022. Another grant application on the same topic was also sent at about the same time to prototype fund and accepted late 2021.

If those grants were prepared behind closed door, only to be revealed after they were accepted or rejected, they would likely be competing with each other: their milestones could be conflicting with each other or cover exactly the same topic. But by being prepared in public, each applicant (even when they are not in the same organization) can make sure there is no overlap. They can independently shape their piece of the puzzle so that it fits with what others are planning.

For example, knowing the details of the NGI discovery grant application, I was able to plan ahead to work on an export / import format for Gitea which is complementary to the tasks listed in the grant application.

Collecting more examples of radical transparency and funding

Fundraising is a competition: the amount of money awarded to Free Software projects is limited and helping others is ultimately a self defeating proposition. For this reason only, I suspect there will never be a large number of projects engaged in radical transparency. But I will keep doing it because it is beneficial on a larger scale. And because I like helping others, even when it means less financial gain for myself. If anyone is also interested in doing the same, they are kindly invited to add themselves to the list of radically transparent funding maintained by Arnold Schrijver.

On transparency, funding and efficiency

Earlier this year I applied for funding: a call was opened by the European Union and someone told me it was worth a shot for a project related to software forges. My lack of experience writing grant applications was a handicap but I went ahead anyway. I asked a friend if he would agree to apply with me because I felt it would increase the chances of success. I soon discovered that there was no example of grant applications to get inspiration from. Although people and organizations share such documents in private, within their own network, they are shy about publishing them for everyone to see. This was a handicap to get started. In the spirit of sharing, I then decided to be 100% transparent about my own work: not only by publishing the drafts of the grant application but also the discussions with everyone involved.

The grant was accepted and transparency became a core value of the project, from the spreadsheet where all expenses/income are kept to the monthly reports summarizing what was done. Although it is not a very big project, full transparency also means there is a lot of information and digesting it can be very time consuming. However, someone with enough time on their hands could know almost everything, down to the last detail. Including how the money is spent to further the project.

The spreadsheet is one page long and once all expenses below 100€ per month are trimmed, there only are two items: 3,000€ per month (which amounts to roughly 1,500€ per month after taxes in France) for our salaries. And a single income source for the project: the European Union over a period of nine month, from May 2021 to January 2022 included. The work being funded is divided into deliverables and the monthly reports published for the project conveniently help trace what was done on a particular topic. This is on purpose since they are also used to show progress to the European Union. And by reading the reports it is trivial to figure out who did what. Even a superficial analysis shows that I’m the only one working on most deliverables and that I did most of the work on the others.

There are many possible interpretations for this imbalance, one of them would be that some people are more efficient than others in a given context. For instance I would make a very inefficient manual worker, although I would likely be paid the same as my colleagues. Another example, closer to my skills, would be if I was co-authoring a book of fiction with someone (this has been a dream of mine for the longest time). The main author would presumably be a seasoned writer and my contribution would comparatively be very small because it takes me a long time to come up with just a short paragraph that is decently written. But we could agree to be paid the same for this work, regardless of our respective skills. In the context of the project funded by the European Union, it turned out that I was more efficient.

I’ve been told that when people are paid the same they should by as efficient. Or that people should be paid depending on how how efficient they are, which is another aspect of the same idea. But I think it is impossible to expect the exact same amount of work for the same amount of money regardless of the person. What really matters is that there is an agreement between every party involved. I agreed to a 50/50 split the European Union grant when the project started and I’m fine with this agreement, regardless of how efficient each of us is.

How do horizontal Free Software communities respond to a takeover?

In march 2021 the libreboot project was taken over by one of the core developers and went from a democratic governance to being controlled by a single person. In July 2021 the same happend to the misskey project. Such a “coup” is a bug in how a democratic project is setup: it should not be possible for a single person to take control of the entire project. But it is possible, by design, in horizontal communities such as Enough or fedeproxy.

Although the people who lost their influence over libreboot could have forked the repository and start a new one to keep going, they apparently did not. There were a few assets that could not be forked:

  • The domain name
  • The IRC channel
  • The wikipedia page

Bootstraping a new project with a new domain name, an empty IRC channel and a two year period to build enough of a reputation to deserve a wikipedia page is a lot of work. Enough work to put the person who wants to fork at such a disadvantage that it effectively prevents it from happening. In democratic communities this centralization is acknowledged and considered acceptable. There is no need to fork because the voting process gives everyone the power to control these centralized resources.

Online horizontal communities must be designed to fork as a whole because there is no way to prevent someone from taking over exclusive resources such as the domain name. If there was a way, the community would not be horizontal, by definition. However the concept of a fork cannot be applied to a centralized resource (e.g. domain name), it is only meaningful for decentralized resources (e.g. DVCS). It follows that all centralized resources must be removed from horizontal communities otherwise their ability to fork is diminished and it opens a path to the tyranny of structurlessness.

Allocating pty in a shell script

When a command requires a tty although it should not (some OpenStack client subcommands do), it will fail when included in a crontab. Unfortunately there is no packaged utility such as ptyget to allocate a pty. Fortunately ssh -tt can be used instead:

-t‘ Force pseudo-tty allocation. This can be used to execute arbitrary screen-based programs on a remote machine, which can be very useful, e.g. when implementing menu services. Multiple -t options force tty allocation, even if ssh has no local tty.

$ ssh-keygen
$ cat .ssh/id_rsa.pub >> .ssh/authorized_keys
$ ssh -tt $USER@127.0.0.1 tty < /dev/null
/dev/pts/14
$ ssh -t $USER@127.0.0.1 tty < /dev/null
Pseudo-terminal will not be allocated because stdin is not a terminal.

Federated development and federated forges

I’m very new federation. Over the years I heard rumors that it was good without understanding why and how. I ran a mastodon instance for a few years but did not use it much: I’m a developer and not much of a microblogger (reading or writing). Beginning of last year I started using https://peer.tube/ and was happy to see it work for real but did not use any of its federated features. But when https://joinmobilizon.org/ was announced I thought it made a lot of sense to organize events in a federated way: smart move. And all along I thought I should read about fediverse but I still have no idea what it means (really).

Continue reading “Federated development and federated forges”

libvirt functions discovery in python

The C API of libvirt is well documented and one can easily understand how the virNetworkGetDHCPLeases function should be called. However, it is less straightforward with the python libvirt module despite the libvirt development guide. The example from the sources shows the corresponding python method is DHCPLeases

import libvirt
conn = libvirt.open("qemu:///system")
net = conn.networkLookupByName("default")
leases = net.DHCPLeases()

But how did virNetworkGetDHCPLeases become DHCPLeases?

Continue reading “libvirt functions discovery in python”

Volunteer work is not worth a dime

Even when nonprofit organizations publish their financial records (such as the mediawiki foundation), the work done by volunteers has an estimated financial value of zero. These organizations will however unanimously claim that volunteers are an essential part of society and have a very special place in their heart. While most of them are sincere, observation tells us a different story:

  • In the context of fundraising, volunteers are second class citizens compared to organizations who donate money
  • A lack of transparency excludes volunteers from decisions and day to day work

How is it that one year of a volunteer who is worth $60,000 on the market is considered less valuable than a $60,000 grant used to pay the salary of the same person?

Continue reading “Volunteer work is not worth a dime”

virt-resize applied to Debian GNU/Linux cloud images

The Debian GNU/Linux cloud images can conveniently be used out of the box with the following:

$ wget -O debian.qcow2 https://cloud.debian.org/images/cloud/buster/20201214-484/debian-10-generic-amd64-20201214-484.qcow2
$ virt-sysprep -a debian.qcow2 --run-command 'dpkg-reconfigure --frontend=noninteractive openssh-server' --ssh-inject debian:file:$HOME/.ssh/id_rsa.pub
$ virt-install --connect qemu:///system --boot hd --name debian --memory 1024 --vcpus 1 --cpu host --disk path=$(pwd)/debian.qcow2,bus=virtio,format=qcow2 --os-type=linux --os-variant=debian10 --graphics vnc --noautoconsole
$ virsh  --connect qemu:///system domifaddr debian
 Name       MAC address          Protocol     Address
-------------------------------------------------------------------------------
 vnet0      52:54:00:3e:6f:1a    ipv4         192.168.122.84/24
$ ssh debian@192.168.122.84 df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       1.9G  1.3G  481M  73% /

However, 2GB for the root file system may not be enough: virt-resize and virt-rescue should be used to expand it.

Continue reading “virt-resize applied to Debian GNU/Linux cloud images”

Onboarding devops with infrastructure as code

Enough is a software released as a pypi package and a docker image to maintain an infrastructure composed of multiple machines, physical or virtual. In other words, it is an infrastructure as code based on Ansible and OpenStack. In addition it is built exclusively on Free Software, primarily because it helps with backdoors and viruses. These two properties combined create a unique opportunity to onboard volunteers devops willing to help nonprofit organizations defending whistleblowers.

Continue reading “Onboarding devops with infrastructure as code”

Looking for a Free Software vegetarian developer position

After four years volunteering for non-profits (from the Freedom of the Press Foundation working on SecureDrop to the Maison des Lanceurs d’Alerte working on Enough), I find myself looking for paid work. It is a challenge, mainly because I do my best to only use Free Software and only write Free Software. The last part (writing Free Software) has become increasingly easier in the past twenty years: there are hundreds of companies willing to pay a full time developer to exclusively contribute to a Free Software code base. The first part (using Free Software) is still very difficult.

Continue reading “Looking for a Free Software vegetarian developer position”