In addition with our new service offer currently under development, we also provide digital support services primarily for associations.
Today, we present a first feedback on a digital support program completed during the year.
Among all the little new things we’re announcing, it might be useful to put the right words to clearly define our projects.
So, what’s the difference between the à la carte services we presented last week, and the digital support program featured in our roadmap?
It’s very simple: à la carte services are just software installed on demand, like a WordPress site or a Nextcloud instance. These services are provided as is, with no training or data migration assistance, and only our technical support to help out when needed.
It’s the perfect option for a geek who wants to host a static site and is just waiting for us to give him the key to an S3 bucket, or a resourceful association that needs a Nextcloud, provided that the people in the association :
But in most cases, and particularly for non-tech associations, installing open-source software is all very well, but it’s not enough: without training, the transition to open-source tools is difficult, and the tools are sometimes used the wrong way and not to their full potential… Especially as associations don’t always know in advance which open-source tools could help them, and sometimes need help to get started.
That’s why we offer digital support: we provide tailored help in migrating to open-source tools, by taking stock of what already exists. To meet identified needs, we offer “à la carte” services, and also suggest other ethical hosting providers if we can’t meet certain needs with our service offering.
Digital support also includes training if required, and long-term follow-up.
“À la carte” services are therefore a component of our digital support, but cannot stand alone in most cases.
We aim to provide this service first and foremost to associations / non-profits, whether they have employees or not.
That said, these services are aimed at everyone:
As for our solidarity rates, we also want to give priority to associations, but without discriminating against other categories: as micro-enterprises are often quite precarious, we don’t rule out offering them solidarity rates, even if their structure is essentially for-profit.
On the other hand, a local city is not a for-profit organization, but even so, we are aware of their financial resources (and their budgets allocated to tools from Google, Microsoft et al.), and we know that they are not a category that can be described as “precarious”; so we don’t plan to offer them solidarity rates.
Here’s a diagram showing how we work with each structure that contacts us.
You’ll find details of each of these steps below; click on the step you’re interested in to find out more.
Someone technically literate who does not need any of the administrative stuff and only willing to have a website will be skipping a number of steps to limit themselves to contact, service installation and support.
On the other hand, for an association which is not at ease with tech stuff, we’ll probably go through all the steps and spend more time on training, face-to-face where possible, sometimes with several sessions.
The Beta is a community center for artistic and cultural expression maintained by the Saxifraga association since 2019, located in Angoulême (France). After having carried out several interventions there in 2023, we are accompanying the Beta towards its migation out of Google by beta-testing our digital accompaniment. The Beta will be our case study throughout this article.
It usually begins with an e-mail to our contact address, from someone interested in ethical tools for their association or personal needs. This essential step serves several purposes.
Assessing the level of technical knowledge: from our discussions, we quickly realize whether the person in front of us seems technically at ease, or whether they will need assistance (which we will offer in all cases).
Assess the need for a diagnostic: does the structure or person have a clear idea of what they’re looking for? Is a diagnosis of digital practices (step 2) necessary? In general, this is something that can be deduced from the formulated request: “I want a Nextcloud” is very different from “I’m looking for a way out of Google tools”.
Clarify that our services have a cost: we can’t yet discuss concrete amounts without knowing exactly what services the structure needs, but we do make it clear fairly quickly that we charge for hosting services, to avoid any illusions on the part of the structure. Our audience sometimes confuses “free software” (as in costless) and “free software” (as in freedom), or is accustomed to the costless nature of other well-known free software services such as Framapad.
The Beta has quickly become a privileged partner for us since our arrival in Angoulême two years ago. In 2023, we held a cycle of four activities throughout the year to raise awareness of digital ethics. It was a subject that already interested the Beta.
So in 2024, when we set out to launch our digital support program, we thought the Beta could serve as an experiment for our first digital support. We told them about it, warning them that it would take a long time to get technically ready, and they liked the idea - they were in no hurry. That’s how the support began.
One of the triggers for this support was the increase in price of Wix, their web host and site engine, which went from €200 per year to €310 per year to host a site of a few pages.
The diagnosis serves to identify the structure’s needs, when it doesn’t know exactly what digital tools could help it.
It allows us to take stock of the tools currently in use (sometimes scattered across a number of platforms), to define the structure’s expectations of our intervention, and to identify potential new tools it might need.
After several email exchanges and sometimes a video or face-to-face meeting, we determine whether the structure needs a diagnosis or not (in general, individuals don’t need a diagnosis).
If they do, we ask them to fill in our diagnosis of digital practices, a short form that enables us to get a better idea of the structure we’re dealing with.
The diagnosis can be carried out by anticipation during the initial contact, and ideally in visio or face-to-face to ensure that the person interprets correctly the questions asked, particularly in terms of tools. Some common mistakes:
Once the diagnosis has been completed, it’s up to us to study it internally and come back to the structure with a proposal for specifications.
The diagnosis filled in by the Beta in September 2023.
The Beta was using a bunch of tools on many different sites: Framapads, Framacalcs, Wix, a Google Drive, Gmail, Discord… The structure was simply trying to do the best it could with the existing technical means and their knowledge.
The specification is a document that formalizes the scope of our intervention and specifies its outlines. It contains proposals for software or services based on the needs formulated in the diagnosis.
The proposals we formulate are used directly to draw up our quotation.
This is the simplest and most satisfying stage for any librist who knows their alternatives by heart…
… Or not. It depends on how far along you are to decide.
Beyond the purely technical questions of which software to use, we have to face up to the harsh reality of things: sometimes, even if a structure puts its good will into making the transition to open-source tools, it may still want to comfortably accomplish its associative purpose rather than spend most of its members’ time fighting with open-source services that don’t work well or that don’t help them to pursue their goals (unfortunately, not all open-source software is emancipatory).
And so, we sometimes have to compromise on our librist ideals to provide the best possible support. If you’re going to provide digital support, you’ll have to face this dilemma:
As far as we’re concerned, in a good number of cases, we recommend open-source software because we feel that our beneficiaries have everything to gain in terms of efficiency, ease of use, issues around the protection of their own data…
But there are situations in which we can’t propose an open-source alternative, because it would be counter-productive for the structure to change their tools (too much training time, too many difficulties to take the step, too much time wasted for few results), or when there is no open-source tool really adapted to their needs.
In such cases, we suggest staying with a proprietary tool, much to our regret, so that using an unsuitable open-source alternative doesn’t become a handicap for the structure.
Here you’ll find, in no particular order, the “compromises” we’ve reached in recommending free solutions. These are biases, and they might make your hair stand on end, but you have the right to disagree, and we have the right to disagree with you too.
For the website: for “non-technophile” structures, we won’t suggest (for the moment) any alternatives other than WordPress. Too bad for fans of SPIP.
For the creation of visual content (posters, logos…): if the people in charge of design are comfortable with Adobe tools (notably Illustrator and InDesign), Canva or Publisher, then we don’t try to change their habits. We considered the following alternatives:
In short: they all have more or less severe flaws that disqualify them in the face of tried-and-tested solutions such as the Adobe suite.
It’s also worth noting that in Angoulême, the city of comics - where we’ve done most of our digital supports - people who have professional skills in visual content design draw them from their school curriculum, in which they mainly learn how to use the Adobe suite. It’s hard to change such ingrained habits.
Obviously, if we can’t touch the Adobe suite, that means we can’t migrate their Windows to Linux. Support for the Adobe suite on Linux is miserable, even in Wine, and the software is too greedy to run smoothly in a virtual machine without a gaming computer.
This generally leads to two situations:
The organization provides one or more workstations (shared or individual) to its members, on which there is a jumble of software installed and a lot of data scattered around. Even assuming that the Adobe suite is not used, a migration to Linux remains complicated as it requires changing many habits, transferring data, ensuring software compatibility… and this change is generally not a priority in the eyes of the organizations we support.
The members of the organization work on their personal computers, in which case we’re not going to ask them to install Linux on their hardware! We’ll be happy to invite them to one of our install parties, but if it’s personal hardware, it’s not conceivable that this should be part of the specifications for the structure’s support.
Obviously, we’re not thinking of a dual boot, as the latest versions of Windows make it unstable (Windows detects it and replaces itself first in the boot order, randomly, after an update or not), which would make the structure dependent on a later intervention on our part to repair the dual boot.
For managing crowdfunding, ticketing, membership online: so far, no matter what anyone says, we haven’t found a better solution than HelloAsso for recording membership fees, which is why it remains the solution we present as the best compromise.
There’s no other French payment service that’s as easy to use and has such low management costs, even if HelloAsso isn’t free and even if the way they solicit financial contributions to their structure is not as ethical as we’d wish (a checkbox checked by default, a dark pattern in short).
That doesn’t stop us from suggesting Paheko for accounting.
As a general rule, we don’t recommend a solution. By mid-2025, we may make the Matrix instant messaging service freely available upon registration, but even once this service will be in place, it will be difficult for us to suggest it in most cases.
If the discussion platform is used to federate a community with little involvement in the structure’s project (supporters, for example), it’s generally not feasible to suggest a messaging system like Matrix, as this would require supporters to install additional software just for this structure, and would therefore have the impact of drastically reducing their involvement rather than on a platform like Discord where the effort is negligible.
For a structure that has a Discord server to receive 200 people from its audience, how many will migrate? How many will create an account on another platform, install a new application that will drain their phone battery, just for a structure that the person would like to follow from afar? Without a doubt, very few people; if this is the structure’s main means of communication, it’s leading it to its demise.
For an organization that uses a WhatsApp group to communicate internally with 20 people, the solution of an open-source messaging system becomes a little more feasible, but remains very inaccessible for most, especially when it concerns people who are not at ease with digital technology, who already have a hard time using WhatsApp and who don’t see themselves at all installing a new application to communicate.
Setting up bridges between several messaging systems would be too laborious and time-consuming for us, and the tools available for this purpose are still very unreliable.
Changing software means relearning habits, and if a certain category of people doesn’t have the time, inclination or ease to change applications, what do we do? Leave them by the wayside? Member training can help to ease the transition, but even training has its limits.
And if these compromises don’t suit you: do better! Lend yourself to the exercise of guiding a non-technophile organization towards open-source tools, and face up to your own dilemmas. We look forward to hearing your feedback!
Here’s how we filled in the specifications with the Beta.
The Beta specifications, provided with their consent (click on the image to see the PDF version).
Solutions in green represent services ready for deployment, those in orange are (or were) not yet technically ready on our side.
Finally, you’ll notice that this specification is limited to the service hosting, and does not currently include other digital support components (training, support, etc). This is an area for improvement.
If the subject of pricing hasn’t already been addressed, this is where we get into the details: based on the service proposals we formulate, we can propose different prices for the hosting service.
This is also where we present the existing alternatives to our offer.
If Nextcloud is one of our proposals, we’ll start by presenting Framaspace, the Nextcloud from Framasoft, free for 50 user accounts and 40 GB maximum, only for associations and militant collectives (a large part of our audience). Framasoft provides for free what we would charge €180 per year (the price of our Nextcloud at 40 GB, not counting the annual fee), with broadly the same privacy considerations.
Next, we recall the existence of offers from other ethical hosts, such as Le Cloud Girofle, Nubo, Zaclys, Libretic, ReflexLibre and a few others that we cite on a case-by-case basis; for example, we present the main instance of Paheko in case our hosting offer from Paheko isn’t entirely suitable. We demonstrate that we don’t want to compel them, that our aim is not to lock the structure in with us.
We even go so far as to mention the existence of the Google Workspace offer for non-profit organizations: the free Google Suite and its free 100TB. We explain how difficult it is to formulate a paying counter-offer to this, and that we are not in competition with Google because our services, like our business model, are not of the same nature; that Google makes its business on the resale of hosted personal data, and that it’s up to the structure to judge whether this is an acceptable compromise or not.
We want the choice of ethical alternatives to be first and foremost an informed choice. And as a general rule, structures already know that this offer from Google exists, and affirm their motivation to distance themselves from the digital giants for ethical reasons. They know why they contact us: it’s not for the price, but to contribute in their own way to an alternative society model.
Then, if we feel that the structure might need financial help, we explain that we don’t want the price to be a deterrent, and that we’re ready to adapt to the structure’s budget so that our tools are affordable for them.
We also explain that it’s as if we were paying out of our own pocket for the proposed discount. We remind them that we rely on donations so that the solidarity prices we offer don’t affect our finances.
Once we’ve negotiated any solidarity rates and accepted the quote, we proceed to set up the services and issue an invoice.
This is the part we won’t go into in detail, as we’ll be devoting an entire series of articles to the technical side.
If there’s one thing to be said for this, it’s that it’s a particularly time-consuming part: it takes us a good half a day to set up a Nextcloud from scratch, with all the right parameters (until the day comes when we can automate part of the process… but it’s still complex, and we’re still in the experimentation phase).
At the end of this stage, and preferably when the invoice has been paid, we give access to these services to the structure. To do this, we contact them and ask them to provide us with a list of names, e-mail addresses and respective rights for each person to be added to our SSO, and then send an activation link to each person, enabling them to set a password for their individual accounts.
If we have an individual person in front of us (a private individual or a micro-business), the question of access is naturally simpler.
This stage can also be very time-consuming, depending on the type of support. For some of them, it is not necessary, as the organizations consider themselves sufficiently autonomous to take care of their own skills development.
Most of the migrations we’ve had to carry out so far have been relatively straightforward.
File migration: moving existing data to Nextcloud is almost too easy, all you have to do is upload the folder containing all the files from the structure’s old “Drive”. You still need to configure access rights and shares, but Nextcloud is intuitive enough that this operation doesn’t require our intervention.
Calendar migration: With the ability to import a calendar to Nextcloud, and thanks to the interoperable calendar formats, this operation is not an issue; it is also quite uncommon for someone to need to migrate past events, so importing isn’t always necessary.
Email migration: This is the technical part. For each Gmail address you own, the ideal solution is to configure automatic email forwarding directly from the Gmail web interface. For other addresses, a Sieve filter installed on the original mail service might do the trick, if other more conventional options aren’t available.
Accounting migration: In general, we don’t recommend migrating an existing accounting system, but rather waiting for the end of the accounting year before making the transfer, although Paheko does have import tools if you need them.
Migration of mailing lists and members: The tools we use support the import of a list of members in CSV format. The structures we work with may need a helping hand.
For other data (forms, surveys, etc.): generally speaking, import is not necessary, as the data on these tools is for ephemeral use.
The training phase is designed to enable the structure’s members to fully get their hands the proposed tools, and is particularly useful for non-tech structures. It can also be used as an additional time to configure the tools with the people concerned, particularly for migration purposes. It can take place in person as well as remotely, but rarely by email (a training session is not an exchange of e-mails, otherwise we’d call it technical support).
It sometimes requires several sessions, because it’s not always possible to assimilate all the necessary knowledge at once, because you may spend much longer than expected on certain tools, and because many questions may naturally arise as you use them.
The quality and usefulness of training depends very much on the conditions in which it is carried out:
Training content is tailored to the organization, although it can generally be adapted from existing frameworks depending on the software (Nextcloud, Paheko…). A good first approach might be to list habits prior to tool migration, and present how to readapt these habits with the new services so that members of the structure get their bearings starting with the performance of routine management tasks.
In the future, we’d like to foster self-training by offering easy-to-follow video tutorials covering the most frequently encountered needs, although teaching material on this subject already exists on the Internet.
With the Beta, it took us several sessions to prepare the move of the tools, present them, guide on their use…
On July 3, we met face-to-face to prepare the migration of their website from Wix to WordPress, create accounts and access rights, and present the services in their entirety (without going into detail about usage).
On July 13, we took part in the annual Beta Seminar (coincidentally held at the same time as the CHATONS Camp): this was an all-day internal meeting for Beta members at a countryside house, to which we were invited to present the digital tools we offered. We presented Nextcloud, Paheko and WordPress, focusing on cases of use specific to their structure. Judging by the audience’s enthusiastic response, we had a successful presentation!
On August 22, after a month’s summer break for the Beta, we completed in their presence the migration of the Beta’s domain name out of Wix, an operation that took time for reasons beyond our control: the Beta had to create an account with another domain name provider, initiate the transfer… and therefore, devote time to the technical side.
On September 12, we came on site to help the Beta reconfigure their Gmail mailboxes. We helped them set up automatic forwarding and migrate their e-mails to us.
Finally, on September 19, we guided them on how to use the Paheko service to send their newsletter to several hundred people, and cleared up any remaining grey areas on the use of Nextcloud and WordPress.
Support is the invisible and often rather thankless work we have to do when the organizations we support encounter technical issues with our services.
The weekly time devoted to support will increase proportionally with the number of organizations, and requires someone to be there to respond: if this technical problem prevents access to our services, it could paralyze the structure depending on it until the problem is resolved.
As for follow-up, this is not systematic, but can be set up with certain structures.
In the short term (one week to two months), the follow-up consists of making sure that the tools are used correctly: not in a (too much) roundabout way, not dangerous in terms of security, not used in a gloriously complex way (if you only knew…) when there are much simpler solutions to meet the initial need. It makes it easier to identify blocking points that the people concerned wouldn’t always dare bring to our attention: missing accesses, difficult data migration, hidden bugs…
Over the long term (punctually, six months or a year later), the follow-up consists of re-contacting the structure to ensure that it is satisfied with the tools provided, and to see if it expresses new needs which we could meet with existing tools or new services.
The digital support process is sometimes fraught with difficulties. Even with training and face-to-face sessions to complement the provision of digital services, the human factor doesn’t solve everything and can often be the cause of many problems.
No time: the most common problem is that the associative structures we support are completely overwhelmed by their own activities and have no time to devote to their digital tools: neither to diagnostics, nor to migration, nor to training their members… Even if we organize training sessions for their members, what’s the point if nobody comes? This may be due to a lack of consideration for digital tools: associative volunteers don’t always feel concerned by tool changes, until the day they directly affect them.
Internal reluctance: sometimes, a member of the organization may oppose the changes, for (legitimate) fear of losing comfort and having to relearn how to use the tools, and for lack of consideration for personal data protection issues. As a hosting provider, we don’t think it’s up to us to convince them of the merits of their organization’s approach.
Over-solicitation of our support: we haven’t yet solved the support pricing equation. For the time being, we only charge for hosting, but it has happened that we have exchanged more than 50 e-mails with a supported structure over the course of the year, mixing urgent requests with requests for advice on related subjects, or requests for technical adjustments to services. It takes us a considerable amount of time to answer them, and we probably won’t be able to handle the load if 50 structures do the same.
We’re delighted to be gradually bringing this support program to fruition, even if a number of ambiguities remain, notably on the question of pricing policy - we’ll have a chance to expand on this in a future article.
Being in contact with structures, and in particular associations, to help them in their degooglisation process, remains a very gratifying process overall: it gives us the impression of helping people to accomplish their associative missions, of putting our digital technology at the service of their struggles, to enable them to change the world in their own way.
In spite of this, we operate with extremely limited means and scope, an infinitely smaller impact than other structures like Framasoft, and still fragile prospects for salaried employment in our association, a step we feel is increasingly essential to guarantee the structures we support that we’ll be there to help them.
We would like to thank The Beta for their warm welcome, their (reciprocal) interest in our missions, and their cooperation and availability in the experimental support process we have carried out alongside them.
We would also like to thank the Maison des Peuples et de la Paix, community center and our head office, which we haven’t mentioned until now, but which followed the same support program as the Beta a few months apart, and which supported us in the same way during our experiments.
Well done if you’ve read all this far.
See you next week for a new article!