Seeking contractors for work on Flathub project

1

Hi all,

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 push operation would make it far easier for Electron apps to be published into Flathub, because it bypasses the need to use flatpak-builder to 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 admins@flathub.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.

Thanks,
Rob (on behalf of the Flathub admins)

5 Likes
2

Honestly after having used Elixir quite a bit, I’d say anyone with functional programming experience should be able to get up to par without too much effort.

1 Like
3

The new summary format supported by recent versions of Flatpak already has support for splitting a repo into subsets so I think this shouldn’t be terribly complicated.

1 Like
4

True, I think we considered that but at present Flatpak automatically selects those based on the architecture. If we wanted to add a 2nd dimension we’d need to define a way to map multiple variables into those paths, so it would be a 3 x 4 (or however many arches) list of summaries. Alex might remember the details but my idea was more like, could we set up a subdir of refs, eg ‘free/app/bla/bla’ and ‘verified/app/bla/bla’ that was served as the refs/ dir for the repo-free and repo-verified dir, link the objects/ dir together, add all three collection IDs to the commits, generate appdata refs inside those subdirs, generate filtered summaries, then only do prunes in the top level repo…?

5

Hmm Alex said here that we would want to use different collection IDs for the different repository subsets as you describe, but it would be nice if we could find a way to avoid that complexity and continue using org.flathub.Stable as the collection ID. But you would have to find a way to serve different appstream refs for the different subsets, and I don’t think there’s currently a way to do that without using different collection IDs.

6

If you don’t have a different collection ID, doesn’t that mean that someone can share something from the main repo with you and falsely claim it’s part of the subset? It seems ideal to me that the buildbot could sign the collection IDs into the commit that indicated which subsets the commit should belong to, and indeed when filtering refs and making subset metadata, that collection ID could be the key to decide what subsets the refs should appear in. This would actually alleviate the need to have duplicated refs dirs, you would only need to serve different summaries and appstream refs for the different subset repos.

7

Yeah I hadn’t considered that subset membership would be something that would need to have strong security guarantees around it, but if that is the case collection-ref bindings in commit metadata would be sufficient. We would need to do a lot of testing to check that when someone already has apps installed and they change their flathub remote to point to the free subset, the free ones are still updated and any non-free ones are handled gracefully (a warning?). And the case of offline sideloading would also need testing to make sure it works well with these subsets.

We might also want to define a requirement that a collection ID for a repo subset has to have the main collection ID as a prefix (e.g. org.flathub.Stable.free), since currently it is not allowed to change a collection ID on a remote that was already set, but in the case of changing to a subset it would be safe I think. But then what if the user wants to see more than one subset from a remote? That wouldn’t come up if there’s only one but it could in the general case. You can’t set more than one collection ID on a remote. You could have more than one remote but that would get messy if you decide to change what subsets you want to see.

It’s kind of too bad the support we already have for filtering remotes with blocklists/allowlists isn’t up to the task of implementing subsets. It might work for the online case if the filters could be updated from the remote, but it’s hard to imagine how it’d work for offline sideloading.

8

Hi all,

I wanted to give a quick update. The Flathub team and the GNOME Foundation would like to give our thanks to those who expressed interest and applied. Neil McGovern, Nick Richards, Bartłomiej Piotrowski and I received and reviewed four proposals for this project.

We’re pleased to announce that we have awarded the contract to two different applicants who have started work this week. Codethink are the main contractor, and they provided a complete proposal and will have a number of engineers working on the project over the coming weeks. They will be supplemented by James Westman who made a proposal focused on the verification and web parts of the project, and will work closely with the Codethink team to deliver certain work packages.

We were impressed by parts of both proposals and asked whether they would be happy to work together, allowing us to involve more of the community in the project, and share the knowledge about the work being done more widely.

For those eager to follow the progress of the project, we’ve set up a GitHub project board to track the work items (which belong to different underlying Flathub modules) and are using the same Matrix chat room to discuss the project, daily standups, etc.

Many Thanks,
Rob

6 Likes
9

We’re pleased to announce that we have awarded the contract to two different applicants who have started work this week.

Thanks @ramcq for providing this very interesting update about the project of improving the flatpak infrastructure (which I really think could be very beneficial for GNOME). Looking forward to see the work completed :slight_smile:

10

Hi @ramcq

So far, the discussion here seems to be focused on the technical side of implementing payments, but I haven’t seen any information on what types of funding will be allowed. E.g. will developers be able to set up a pay-what-you-want mechanism with a custom suggested price, as in elementary OS’s app center? Or have an optional subscription mechanism with a total monthly income goal, as is an option on Liberapay?

The reason why I ask is because I’m concerned about the final funding mechanisms being suitable for closed-source software, but not open-source software. If, for example, the developer can only set one mandatory price, open-source developers would have to choose between:

  • asking for funding for their project, but potentially losing their users to a gratis fork of their project
  • putting their project out there for free, but not being able to turn it into a sustainable part-time job

This model does work on e.g. the Google Play Store and the Apple AppStore, but only because closed-source projects can’t be legally forked and republished with a free pricetag. I hope this community agrees that funding open-source projects is a priority, moreso than funding closed-source ones.

What are the funding mechanisms that you’re currently thinking about with this new payment implementation? And is there any way to influence what those will be or are they “set in stone”, at least for the first version?

2 Likes
11

Hi @mirek,

We’re hoping to handle both one-off up-front payments and subscription models, as well as an option to restrict downloads based on whether a payment has been made - which will be up to the developer. A proportion will be taken for the Stripe fees and to support Flathub itself, and the developer will be able to select a contribution towards a platform (ie GNOME or KDE). I’m not sure whether there have been specific thoughts about the pay what you want model (ie the user can control the payment amount, potentially with a minimum the developer can set before the app is downloadable) but I’d be very open to that if it’s not hard to achieve! The Codethink + James Westman team are planning to make a report soon to update on their progress so we’ll be able to ask them… :slight_smile:

Cheers,
Rob

2 Likes
12

For those following this thread, @danielsilverstone-ct has posted an first update on the project over at Situation report - New Flathub website work, app verifications, logins, etc.

13