This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
Hey everyone!
I’ve been using F-Droid for a while now and love it. Quick idea: how about we add a “Most Popular Apps” tab? The “New Apps” tab is cool for finding fresh projects, but they can often be buggy or incomplete.
A “Most Popular Apps” section would be a great way to quickly find solid open source apps that lots of people use and trust. Plus, it would help newbies like me find reliable open source alternatives to common apps.
Sorry if this has been brought up before, I couldn’t find a recent thread. What do you all think?
2 Likes
We have gotten community agreement to provide some metrics, but only without compromising at all on privacy. That’s not that easy to implement, so we currently only have limited metrics:
Also, it is possible for anyone to generate certain kinds of metrics based on publicly available data. For example, each app could be ranked by “update frequency” based on fdroiddata YAML files. You can find the publicly available data here:
3 Likes
I wrote a bunch of scripts here (Thore Göbel / F-Droid Metrics · GitLab) to:
- Pull the data from F-Droid Metrics
- For a hardcoded list of app ids I am interested in, compute the download numbers over time
- Plot the data (see the graphs/ directory)
The download numbers are computed by summing up the number of hits on the APK files:
- across the three reverse proxies http01, http02, http03, and
- across all apks that are hit.
This seems to be like a “good enough” estimate to me. It only includes the requests that actually download APKs (as opposed to just browsing which would e.g. cause screenshot downloads).
I ignore the origin server, and only count the reverse proxies. Mirrors are not counted (due to lack of data afaik).
1 Like
I plotted all of them, there are now 1072 graphs on the page
edit:
here is the patch to add the average to file name:
Summary
diff --git a/plot_data.py b/plot_data.py
index a221e2d..bd36a9b 100755
--- a/plot_data.py
+++ b/plot_data.py
@@ -19,12 +19,16 @@ for app in apps:
x_values = list(app_downloads.keys())
y_values = list(app_downloads.values())
+ average = 0
+ averageCount = 0
plt.figure(figsize=(10, 6))
plt.plot(x_values, y_values, marker="o", linestyle="-")
for i, (x, y) in enumerate(zip(x_values, y_values)):
plt.annotate(str(y), xy=(x, y), xytext=(x, y), ha="center")
+ average += y
+ averageCount += 1
# Rotate x-axis labels for better readability
plt.xticks(rotation=45)
@@ -41,6 +45,8 @@ for app in apps:
ticker.FuncFormatter(lambda x, p: format(int(x), ","))
)
- png_file = f"graphs/{app}.png"
+ averageResult = round(average / averageCount)
+
+ png_file = f"graphs/{averageResult}-{app}.png"
print(f"saving {png_file}")
plt.savefig(png_file)
1 Like
Anyone have an idea why Termux is so off the charts?
My best guess is that someone is using Termux in an automated setting, to run tests in a CI or something.
Donno what we would find server-side, it is the same data. The webservers don’t log user agent, if I remember correctly. Our goal with the metrics is that all the metrics are safe to release publicly, and we write to disk a little as possible everywhere. So there would just be data about uncommon things, since there has to be at least 100 occurances for something to make it to the weekly metrics reports. Also, the server logs are only kept for a couple of weeks.
One thing that this data can clearly tell us is relative relationships. Download counts will always be misleading, since we do not have data from the mirrors, which are the majority of the downloads. I recommend normalizing the numbers to a 0-to-1 floating range, with 1 being the max downloads of any app in that weekly. Or it could be max in all time. Then the graphs should probably be logarithmic, since most will be close to 0. This will show relative activity and trends, like how quickly updates are downloaded.
3 Likes