How to correctly contact upstream app authors


This the story of how I got banned (temporarily) from GitHub.
(I don’t blame GitHub support, this was entirely my fault.)

I had a list of really cool apps that I would like to package in F-Droid (some of them from the really nice Android Experiments collection).
And I had some free time this morning so I decided to go through my list to check which apps complied with our policy and create issues to ask each app author if they would be OK with publishing the app in F-Droid.

But because I was a bit in a hurry, I copy-pasted the same minimalist message containing a simple question and a link to the F-Droid website (thinking the website was self-explanatory).
By looking back at it, I now realize that my messages really lacked context and how it looks like I’m spamming some random repositories to promote my niche app store.
This is not a correct way to contact app authors and gives a bad reputation to F-Droid, and I apologize for that.

So here are a few guidelines that I should have applied to myself:

  • Don’t assume every app author knows what F-Droid is: explain what we do, how we package apps and what it means for the author.
  • Don’t copy-paste messages: explain why we want to package this app specifically.
  • Don’t create 30 issues on the same day.

Also, I had to explain to GitHub support how we handle RFPs and they don’t really like the fact that we contact repository owners that didn’t ask us to package their app:

If the GitHub project owners have initiated a request, and you are responding to their request by opening an issue in their repository, then we are okay with the activity. However, if you are seeking out apps that you are interested in, and you are initiating the request via an issue in their repository, we would consider it a prohibited activity.

So we might have to rethink how we handle these things.


Dear GitHub,

What if the request is initiated by a member from the wider community? Where would you draw the line between a general community member and an F-Droid contributor? What if the requester is a contributor to both projects (but not an owner)?

I completely understand their reaction, which is appropriate, and I also see their point, but outright banning this type of request unless it is initiated by the project owner is overly harsh, and frankly ridiculous in the face of the open community we’re trying to foster.

I think it’d be okay if requests are initiated by a variety of people, and stay low-volume and polite, following the guidelines in your post. That is to say, people should do everything in their power to be the opposite of a spammer.

Also, thanks for writing down your experience here.

1 Like

“Also, I had to explain to GitHub support how we handle RFPs and they don’t really like the fact that we contact repository owners that didn’t ask us to package their app:”

Github is not FSF or Richard Stalman lol.
When a code is free software, you have the right to package the code, change the code…
Just inform them that the sofware will be packaged in F-Droid, if they could give futher support…

I think GitHub should reconsider their approach on that matter. I don’t remember any repository owner being annoyed by us asking or considering our question as spam.

I also think that the person that opened the RFP should open the issue on GitHub (or otherwise ask the app author) and that we should avoid doing it.


@Rudloff If you would like an app to be included in F-Droid you should also start by opening an RFP and then ask the app author linking to the RFP issue.

Oh, I always thought the correct order was to first ask for permission, then open an RFP.

Also, this page seems to imply that if you open a merge request directly, you don’t need to create an RFP. Maybe it should be rephrased?

1 Like

This also brings up a related issue about adding new apps to F-Droid. One big advantage F-Droid has over other app stores is that we are a community curated app store. That means that a community of people tries to include the valuable apps, and exclude the cruft. So just because there is an RFP and it is easy to add an app, does not mean that we should add that app. Otherwise, this can easily overwhelm the collection with apps that one person requested, and are basic so easy to add. Also, apps that are only interesting to a few people are a lot less likely to be maintained. That will make this even worse, if there are lots of basic, unmaintained apps only used by a few people.

This is not an abstract concern. We were already there, but then the MD5 signature thing inadvertently triggered a big purge of unmaintained packages that few people cared about. We can also learn from Debian. There are lots of procedures about also removing unmaintained packages. Basically there is an assigned maintainer for every package. If packages are abandoned, they can be removed from Debian.

Unfortunately, a lot of the good apps out there are a lot harder to package and maintain. So that means its a lot less fun to work on them.


As far as I’m concerned, the more apps in F-Droid, the better*. Ranking the apps and finding the good ones is a separate (and hard) problem, IMO.

* so long as they meet the inclusion criteria, of course. The more apps that meet F-Droid’s inclusion criteria, the better.

1 Like

Of course, the idea when we bring a package into F-Droid is to stay in really good relations with the developers and original devs.

1 Like

@Coffee we don’t have a good system for ranking and finding the good ones, so we should keep that in mind as we are adding apps.

1 Like

@hans And trollers who will destroy apps reputation.
Reviews will avoid this. Maybe by giving strong weight to F-Droid team members voting.
It’s a F-Droid ranking in fact.

We could also have an anonymous opt-in system like the Debian Popularity Contest. It would help us figure out what apps are really used.


The idea of being Anonymous is good but what happens when spamming?

@Rudloff Back to the topic of GitHub & F-Droid RFPs, I think what truly failed your process was the volume copy/pasting, which, of course, would flag GitHub’s spam detectors. In truth, I don’t think what they said about proactive RFPs actually reflects GitHub’s stance iff said requests aren’t spammed. It does help, too, to spread stuff out over time.

E.g., here’s a great exchange that I initiated & @Izzy expanded, with a dev who’s preparing an app for RFP:

I’ve a number of those, &, in most cases, not only does GitHub completely ignore the RFP, the dev is thankful (& probably a li’l flattered :wink:), especially when I continue to follow through w/ them in the process. Of course, that would be difficult if I were to try that on 30 apps simultaneously, but ~5 or so @ once is really no problem.

A bit OT: @Rudloff Most of those Android Experiments have no licensing info, so, if you’re following up on those RFPs (as you should), try to RFE/help the devs on that. I usually point toward Github’s own tool:


Encouraging toward F-Droid-compatible licensing would be useful (obviously :nerd_face:).

With OpenDNSUpdater, the dev already had almost abandoned the app even – and TPS and I convinced him to pick it up again. That issue is a good example also for what @Rudloff wrote as it meets the condition of explaining what F-Droid is. To me it even looks a bit like that was the final trigger for the dev :smile:

Interpreting Github’s response: we (F-Droid) can hardly be held responsible if “some user” opens an issue asking for F-Droid inclusion. So when the issue is already there, it should be perfectly fine for us to “jump in” and help. So where there’s no such issue yet, we just need an independent … oops :rofl:

1 Like

I’m not sure what this comment means. If we did have a system for ranking apps, it wouldn’t actually work until after the apps are added, or am I missing something?

But sure, if we know that an app is popular, it should be prioritized.

1 Like

we had a good discussion and come up with a good plan for a Popularity Contest. Some of the required pieces are already in place. It just needs someone to implement it:


@hans I still don’t understand how that’s going to help us decide which new apps to add.

Or I just generally don’t understand your point.

1 Like