after more than three and a half years as lead (and most of the time sole)
app maintainer, I “retire” from F-Droid.
I don’t use Android myself anymore – don’t you worry, I don’t use any less
free systems either – so my own interest and motivation are low. Also, I
really think maintainers should indeed be users of the “product”, they should
dogfood it and actually care about the whole platform.
Given some dissent about the way to handle upcoming challenges (like complex
builds, app developers eager to use latest pre-release stuff from Google and
how to monitor all the stuff builds (and Google itself) start pulling in at
buildtime etc.), I and my personal believes about software might also hinder
F-Droid’s further success: Newer generation always have a different
view on “values”, on techniques, on problem-solving, so these new problems
might need fresh people to solve them.
Unfortunately, I wasn’t able to “train” a successor. While we had and have some
very talented, dedicated people that do have my trust, I really hope some of
you will help spreading the workload and join their ranks soon.
It has been my great privilege and pleasure to be part of this. Thanks for the
past years and as always: patches welcome
Sad to see you leave Boris. As an enthusiastic F-Droid user, thank you for your contributions over the years!
Maybe if you could elaborate a bit on the roles and responsibilities you’ve had for those of us not close with the actual development it would help people interested in stepping up and joining the contributors community.
I hope F-Droid will continue strong. Good luck with any future adventures you undertake.
I have done only a tiny fraction of your work (8k commits vs .3k) so I know how hard it is to maintain such a large amounts of regular contributions like you did. I wish you the best with your new projects.
Thank you for F-Droid, I regret a lot having waited so long until reading something like this, but I feel motivated to change from a user to a collaborator, to serve and to carry on with the work.
Again, thanks for everything, it is always a joy to thank people who have created software that serves.
I’d been putting off contributing for the longest time, I guess now is the time to start. It sounds like this departure is going to be a major blow to the project. Does it go as deep as hosting/infrastructure for the f-droid website, forums, wiki, etc? Should we start drawing up a list of now un-maintained packages? I’ve recently been able to go 100% without Google Play Services largely thanks to F-Droid & I do not want to go back now.
I really like F-Droid much! It’s my single source of apps which I do trust… Well of course this blind trust is not a good manner, but if I just need to get something which works I find it most likely on F-Droid. So a new lead maintainer is needed, because I believe there are many others like me.
At another topic: @anon25111075 thank you for your effort and time you put into F-Droid, due to the lack of expertise I certainly underestimate it anyway so you might as well just double the meaning of these words! And I wish you all the best!
I would also like to know which other system you use by now
For those of you worried about the future of F-Droid - it’s obvious that Boris has carried the maintenance of many apps for years. But it’s also true that he’s not the first to do so and leave. There was once David too.
There are always people willing to help new maintainers over at fdroid and #fdroid-dev. I haven’t left those, and I hope Boris won’t either.
Thank you so much for your efforts. It was mainly FDroid which pulled me into free software and open source and I have to thank you very much for being so kind and helping me patiently out with my initial noob questions.
It would be super helpful, if you’d give some kind of “tutorial” on how to continue your work. Maybe a case study on an android app?
Laptop, SSH, paper :). I wasn’t a heavy mobile user in general and
only got interested in cellphones when they became more PC-like. So
with 3.5 years in F-Droid, I only have about 4-5 years of actual
mobile phone usage. Coming from a more old-school unix environment,
reverting back.
Does it go as deep as hosting/infrastructure for the f-droid website,
forums, wiki, etc?
I only worked on fdroiddata (with small contributions to documentation,
website and server), so others like client and forum and core
infrastructure are not affected at all. Not saying that their
situation is perfect, so if you want to chip in, there always
a lot of work to do… regardless of “branch”
roles and responsibilities
Basically it was adding and updating apps. Apps are described by meta
information and buildscripts stored in simple text (migrating to yaml)
files, so it’s actually easy to get used to. While there are some really
sophisticated (and sometimes) weird apps out there, most apps are either
based on gradle or have an option to output a gradle build (like newer
cordova/HTML apps). So you can copy an adapt old builds in most cases.
There is no fixed list of “duties”, so its up to whatever you
encounter while doing maintenance. Here is a list of what I have come
up with:
Monitor the fdroiddata commits for apps that updated their version
code (but don’t update the app itself): Look into that and add the
actual build information.
Monitor the wiki for failing builds, investigate and ideally fix
the build
Monitor the “request for packaging” queue and try to add new apps
(the fdroid import tool has become quite convenient to use).
Talk to upstream, if he wants to include the app, and explain why
e.g play-services are hindering an inclusion etc. Also: Try to
keep fdroiddata as clean as possible. If an app requires a complex
set up, you can most likely upstream some if not all of your
changes: Most app devs test and build on their system only, some
have a “works for me, so its your problem” attitude, some are
really greatful, since you actually point out issues that they
just warent aware of.
Propose changes to fdroidserver tools, like updating the installed
SDKs, NDKs and other build-tools. Adapt the binary-scanner and
importing tool. While fdroidserver is largely handled by others,
app maintainers are users of the tool and see if anything is
broken or if tasks they are doing manually get repetitive and
can be automated.
Documentation changes to the (hopefully soon to be re-launched)
website.
Talk to upstream, other devs and users on IRC, forum, and answer
incomming mails.
Should we start drawing up a list of now un-maintained packages?
We never came to a state where we have lots of maintainers for one
specific app. Instead most of the contributors just work on whats
seems relevant right now, regardless of what app. So the list
would be rather lengthy We maintain a list of apps that need
updating and apps with broken builds in the wiki, having a look
at the commits that only upgrade the versioncode instead of adding
new builds also helps and is most of the time more reliable.
@anon25111075 Thanks for all your contributions over the years! You have been key to this whole project, keeping it going in one of the more essential parts of dealing with build failures. One key part you have been handling that is often thankless is that of constantly explaining to people the free software issues even when upstream claims their apps are free software. Your shoes are certainly big ones to fill in F-Droid, so I hope you’ll stick around long enough to get new contributors up to speed.
For new contributors, F-Droid is a big project, so there are many things that need doing. @anon25111075 has laid out a good overview of the things that he was handling, and indeed that is probably where there is the biggest need of new contributors right now.
One really great way to contribute would be to automate as much of the fdroiddata work as possible. In the past year or two, the foundation has been laid to allow for a lot more automation. Things like gitlab-ci builds, jenkins.debian.netbuilds, fdroidserver as a library, etc. Some ideas for automation projects:
run fdroid import on new rfp issues, try a build, and run the binary and non-free scans, posting a report back to the issue tracker
build with fdroid build for all submissions to fdroiddata in gitlab-ci
Related to getting involved, I got the idea from other projects to make a “first timer” tag for issues. The idea is that any issue with the “first timer” tag will require less fdroid-specific knowledge to work on. There are a few things there already:
@anon25111075 Thank you for your contribution! I do have one question though. Since you are the one who updates Fennec Fdroid, what will be the fate of the app when you are gone?
As an enthusiastic F-Droid user, thank you for your contributions over the years!
