About the amount of effort to put in packaging and maintenance of an app 😐

[Latitudes]

Hello everyone,

Please don’t judge this thread by its cover, I kinda expect the answer to be “WELL IT DEPENDS”, but I have some deeper interrogations about Yunohost contributions I’d like to discuss with you

Initial context

I currently work at Latitudes, a french NGO working to change the tech world by encouraging its actors to commit to positive impact projects and helping them to know and understand the externalities of tech !

My job is to create a solid tech / product base for the NGO, but it is a short term mission and in a few months the structure may not have a person working full-time on tech.

For this reason, I strongly believe that the use of Yunohost is perfect for our structure, as it allows a very simple installation and maintenance for apps, and make the need for a real tech expert limited. This fits our need : not having to pay an expert full-time, but still managing most of the daily operations !

Our current need

We want to go further in our use of yunohost, with :

• the self hosting of our DB and a new instance of NextCloud
• a bigger infra with several servers for backups and resilience

Not sth extremely ambitious, but still a step further what we currently do.

Yet we’re limited by the fact that the technology we use for the DB & backend does not belong to the list of Yunohost apps.

By chance, we have many partners (both volunteers and companies) that would be willing to help, namely by packaging and maintaining the app we’d like to use.

And this is where my question stands : to correctly explain to our partners what the effort of committing to help us and the community would be, I’d like to roughly understand :

• What the effort of getting into Yunohost packaging approximatively is (for several level of expertise, from someone with a basic knowledge of linux servers to an SRE expert)
• What the effort of packaging a simple app involving just 2 - 3 services would be (here too with different level of expertise)
• What are the expectable efforts of maintenance for an app package ?

---

Sorry if I sound like like a very naive project manager asking for numbers
But as a structure which believes a lot in data privacy, open source and self hosting, we’d love to get involved in the Yunohost community, but to do that we need to know what to ask to our own community of partners
(mainly to avoid volunteer enthusiasm at start that ends up in a non maintained package, by stating what to expect from the beginning )

---

Thanks a lot for your help, once again we really love what you do and the volunteer efforts put in Yunohost and I hope we’ll have the opportunity to contribute ourselves !

EDIT : oh and if anyone’s willing to discuss this topic / our structure commitment orally, I’d be happy to organize this, in french or english, and even for an IRL coffee if you’re around Paris, France

[mrflos]

Hello @Latitudes !
Thank you for you interest in Yunohost packaging and your will to contribute to opensource self-hosted services.

I’m a very small contributor to Yunohost as the maintainer of the Yeswiki Yunohost package and co-founder of CLIC project which is based on Yunohost.

This is my personal view on the actual state of the packaging system, it’s probably very biased but here you have it!

I would recommend that the persons in charge of the packaging have already some good skills in system administration and scripting, especially on Debian environment (apt packages and systemd services).

As a start point, I was very happy with the packaging documentation (i gave you the french one, but English is also available).

Now, with the new packaging v2, the main file used to packaging is the manifest.toml root file. imho, the best way to start is to fork/clone an app with a similar stack (nodejs?php symfony? redis? postgresql?) found in the huge 400+ apps catalog all referenced here: YunoHost-Apps · GitHub

You can test your package on your own Yunohost instance using the git repo url of your app.

So maybe this was a too technical response, but for your questions:

What the effort of getting into Yunohost packaging approximatively is (for several level of expertise, from someone with a basic knowledge of linux servers to an SRE expert)

As I said, for a non beginner, a couple of days should be enough to understand the principles of packaging and have a first small app working

What the effort of packaging a simple app involving just 2 - 3 services would be (here too with different level of expertise)

If those services are just database, cache and app logic, it’s okay, if it’s a more complex architecture, it can be time consuming, i would recommend to embrace UNIX philosophy and package different apps responsible just for one thing and configure them to work together instead of making a unique complex app.

What are the expectable efforts of maintenance for an app package ?

There are some very helpful automated tools that will be able to fetch new releases and make PRs to bump versions, but you will have to test it a little, so the efforts are depending on the activity of the software packaged: if there is a regular release cycle it could be some work. But once the package is at a good level, those maintenance efforts are not so painful. Also there is a community of users that may get involved

[Lapineige]

@Latitudes

I kinda expect the answer to be “WELL IT DEPENDS”

To allow us to be more precise, listing the software considered would help
Especially the programming languages and various tech stack used can make a software packaging go from very easy (with basic linux/server knowledge) to very hard.
In particular the ones based on Docker, or worse a couple of docker images working together, can be very tricky to convert to normal packages.

[Lapineige]

@mrflos

There are some very helpful automated tools that will be able to fetch new releases and make PRs to bump versions, but you will have to test it a little, so the efforts are depending on the activity of the software packaged: if there is a regular release cycle it could be some work. But once the package is at a good level, those maintenance efforts are not so painful.

I fully agree, with one important note: if the package regularly change its installation process, require big migrations and other significant change, the cost of an update can go from very low (test the automated update PR) to very high

[Latitudes]

Thanks a lot for this very detailed answer
This is precisely what I needed to start searching for partners in our community !!

(I’ve seen those automated tools in action on the n8n yunohost package and it seems extremely useful indeed !!)

[Latitudes]

@Lapineige

To allow us to be more precise, listing the software considered would help
Especially the programming languages and various tech stack used can make a software packaging go from very easy (with basic linux/server knowledge) to very hard.
In particular the ones based on Docker, or worse a couple of docker images working together, can be very tricky to convert to normal packages.

@Lapineige

I fully agree, with one important note: if the package regularly change its installation process, require big migrations and other significant change, the cost of an update can go from very low (test the automated update PR) to very high

Our main target is to deploy Supabase, which is an aggregate of several open source project related to the wrapping of postgresql (with added Rest API, exposed functions and stuff …). The good news is that adding Supabase is like adding 5 or 6 postgre related apps / services

From what I see there’s quite a lot of documentation and hosting options

Self-Hosting | Supabase Docs

I hope we’ll find a simple way to make it fit with Yunohost packaging !!

Oh and btw I realized my username was just “Latitudes” as it’s a shared account with my team. My name is Nicolas, nice to meet you all
And thanks again for the answers !

[Lapineige]

Ok so from what I understand, these are quite advanced DevOps (or something related) tools, which is not really meant for the average Yunohost user.
By that I mean it’s quite out of scope of th project (which isn’t here to ease developers time/experience, but rather to lower the barrier of sysadmin for end users).
So it’s not an issue to package these software, but be aware most contributors are unlikely to focus their effort on such packages.

@Latitudes

The good news is that adding Supabase is like adding 5 or 6 postgre related apps / services

As far as it’s possible, it would be easier and simpler to make each of them a separate package, rather than going for the full complexity of a package with all of them - if that’s possible of course.

Also I don’t see any manual installation documentation ?

[Latitudes]

@Lapineige

Ok so from what I understand, these are quite advanced DevOps (or something related) tools, which is not really meant for the average Yunohost user.
By that I mean it’s quite out of scope of th project (which isn’t here to ease developers time/experience, but rather to lower the barrier of sysadmin for end users).

Yes indeed

Yet Yunohost (even though it’s not primarily meant for that as I understand it) is perfect for our specific use case of “small NGO with a tech team head count <= 1”.

We do have two personas at Latitudes, one expert who would be the maintainer (who does not have a full time job in the ngo), one less expert who would be the yunohost end user (working full time for the ngo).

I may be digressing a little bit here but there’s a parallel with the architecture we’ve created for development in which :

• Supabase is the high tech tool for data storage, auth and access management (sensitive stuff)
• We use the no / low code weweb tool connected to Supabase to develop apps

And what we aim for is to minimize the expert bandwidth needed.

• For dev stuff, we limit model changes and security to supabase on which only experts have an access (volunteers, tech expert partners) and a less expert part of the team can handle limited app / functional changes
• For infra stuff we imagine the same with tech expert in charge of maintaining the packages and - if needed - fixing updates that would go wrong, and a less expert part of the team as yunohost end users to manage the services

This may be a bit out of topic but I’d be curious to know if it makes sense for you this Yunohost dual maintainer / end user collaboration based on the availability of each for the ngo !

[Lapineige]

It’s not off-topic, it’s clarifying the need and purpose of that choice

My previous point was that I understand how it makes sense to use Yunohost in your context, and there is nothing against it as far as I know, but as it’s out of scope for Yunohost project, support won’t be prioritized around such apps / special needs.
Of course, as you are free to make such packages, people are free to find them interesting and contribute to them. My point is rather that it’s likely to be low priority.

[Latitudes]

Got it

My (not so) secret hope is that the use of open source tools by more NGOs thanks to Yunohost may drive an increase of volunteers ready to improve and maintain the most used apps.

People that may not be sensitive to the initial cause of Yunohost may be more interested by various NGOs’ causes, and unite their forces with the current Yunohost volunteers in a virtuous circle

FYI, if you’re interested this is the mission description I shared with our volunteers and partners : Notion – The all-in-one workspace for your notes, tasks, wikis, and databases. (in french)

Sorry if it’s oversimplified, feel free to suggest any modif if you feel like the yunohost description is not relevant !

Nicolas