Posting here to add more detail following my Tweet last night about contract work on Flathub. As some people know, the GNOME Foundation has been supporting Flathub with sysadmin time, legal and hosting costs, as is a strong believer in the importance of a vendor & platform neutral app store for Linux end-user apps. GNOME has a donor who is interested in supporting financial sustainability for app developers and removing barriers to an inclusive ecosystem.
Flathub would like to use these funds to work with a contractor for a short-term project and make steps towards supporting application developers being able to request payments (whether donations or subscriptions). We’re seeking diverse applications from individuals (or groups of individuals - this is something of a polyglot project) and FOSS-friendly companies who can help us move ahead - the funding is available to start right away subject to an agreed contract and statement of work.
Before we get to that and moving anyone’s money around, we need to solve a few basic questions around developer identity and helping people to trust the applications, and we’d also like to address a long-standing request people have had about being able to only use FOSS applications from Flathub.
We have not fully scoped the project, so whoever we select will need to work with us to come up with the specific proposed approach in more detail. Our first sketch of the necessary work items is as follows:
- Initially, we only want first party uploads (ie apps uploaded by the developers themselves) to collect payments for their applications, which means the buildbot needs a verification mechanism to apply a verified first party “blue check” kudos, or remove it as needed. This needs to be automated by one or more mechanisms, such as checking GitHub credentials or authorizing an app, and/or an out of band mechanism such as a DNS TXT record on a domain or a text file at a well-known developer-controlled location that can be cross-referenced with the app. We need to check ongoing authority each time a build is uploaded, and remove it if this stops being the case.
- The frontend should make it easy to see such first party apps, and we’d also publish that kudo in the appstream so it can show up in GNOME Software and KDE Discover. Presenting it in those places is out of scope here - this is a Flathub project rather than a GNOME or KDE one.
- We’d also like Flathub to publish multiple Flatpak repos, so that people can choose to only see/access those first party apps, and not the community contributions which have third-party FOSS apps, extra data wrappers, etc. This will need support in flat-manager to produce multiple metadata and summary files for the different repos, and potentially publish commit objects that belong to multiple collections. We might need to work with Alex to nail down the design for this, but the ideal for Flathub and our CDNs is that the object store itself is shared between the multiple repo origins, so we can configure the CDN to cache identical objects from the “separate” repos with the same cache key. Generating multiple summaries/appdata refs for the same object store is a little subtle - it needs to work with pruning and per-architecture summaries and stuff.
- If we have this repo splitting functionality, it also makes sense to publish another repository that includes only those apps which are under a FOSS license, as this will correct another long-standing issue which people have given us feedback about. (We have a choice between whether this repository is free apps, verified or not, or only apps that are both free and verified. Ideally we’d prefer not to have four…!)
- Once that’s all sorted we might be able to think about a payment system that can collects payments and sends them to the app uploader. Adding payments with something such as Stripe Connect where the GNOME Foundation does not need to get involved in receiving/forwarding seems like an appealing path forward but we’re happy to consider anything that gets the job done without generating too much paperwork. Ideally we’d be able to take a contribution towards Flathub running costs from these payments, at the very least we need to take the transaction costs out.
- We need a place for developers to be able to log in and manage their payments, set recommended prices, etc somehow…? There may be scope to share/re-use code from Elementary’s appcenter-dashboard here, although I must profess to having no idea what Elixir is.
There are some future items that I don’t think we’ll get to right now, but for completeness / extra credit:
- It would also be good to encourage and make it easy for app developers to share some of their payments with relevant platform/runtime (GNOME, KDE, Freedesktop, Elementary, etc) that has enabled their work.
- It would be great if the developer portal also allowed developers who had proven control/authority over a certain app to manage flat-manager credentials, so that we can start to accept binary uploads from verified developers. This is currently managed manually for things like the GNOME and Freedesktop runtimes, and apps like Firefox and OBS, but if automated and backed by a system that can verify developer identity, we can offer it more widely. (As a side note, this ability to push apps into Flathub with a kind of
flathub pushoperation would make it far easier for Electron apps to be published into Flathub, because it bypasses the need to use
flatpak-builderto build them - which is “inside out” compared to how Electron apps typically drive their package/binary/etc builds from Node/Yarn.)
- We can probably rely on GitHub authentication for developers at present given Flathub is based there currently, but eventually it might be interesting to add an authentication system that can include users easily (or, integrate with a collection of OAuth2 providers and lazily provision accounts in our own identity system) so they can manage their subscriptions, donations, etc, as well as allowing developers from other ecosystems such as GitLab, GNOME or KDE to authenticate without going via GitHub.
- It would be nice to set up ways for developers to mark apps/extensions/versions as for subscribers/donors/etc only, so we would need to authenticate users when they access the repos themselves, check their subscriptions, and use the existing “entitlement” mechanism in Flatpak to give them access to the supporter-only content.
The involved components would be flat-manager which is the Rust repo manager that handles pushes to the Flathub repository and updates the repo metadata, the buildbot itself in Python, the linux-store-frontend which is the Node.js frontend that drives flathub.org, and backend which is the Python provider of the API that it uses.
We’d like the successful applicant to submit their work as pull requests against the above repositories, and allow for some time to solicit and respond to review feedback from the relevant module maintainers. Where test suites exist, they must continue to pass and the key parts of new functionality must be added to the suites.
We’d like potential applicants to submit their applications to firstname.lastname@example.org, including:
- some brief notes about their relevant experience with supporting evidence (this can be in the form of a resume or links to some relevant FOSS contributions or other portfolio work)
- a high-level overview of your intended approach for the work packages set out above and your estimation of the time required
- your proposed duration and rate for the project, whether based on fixed fees or time & materials
We’re hoping to select our contractor towards the middle of next month, so we request all submissions by noon UTC on 10th December 2021. We’re happy to take questions about the project from prospective applicants either on Matrix at #flathub-contract:matrix.org or here on Discourse.
Rob (on behalf of the Flathub admins)