If you are a respectful, experienced volunteer interested in actively developing client and server applications that solve our user stories, your contributions are welcome. Please dive in!

Alternatively, anyone can support the project financially with a Librem One subscriptionπŸ”—.


This is a summary of progress to basic functionality. We use upstream project names where convenient.

Server Android iOS PureOS
Backup 🧞 Nextcloud 🧞 Deja Dup
Text πŸ‘ Synapse πŸ‘ Riot πŸ‘ Riot πŸ”§ Chatty
Voice πŸ”§ Calls
Video 🧞 ?
XMPP πŸ”§ Prosody πŸ”§ Chatty
Files 🧞 Nextcloud 🧞 Nextcloud 🧞 Nextcloud 🧞 ?
Hub πŸ”§ Keel πŸ”§ Hub 🧞 Unsure πŸ”§ GOA
πŸ”§ Web
Mail πŸ‘ Dovecot πŸ‘ K-9 Mail 🧞 Geary
πŸ€– Prototype
Social πŸ‘ Smilodon πŸ‘ Tusky πŸ‘ Amaroq πŸ”§ Web
πŸ€– Prototype
Tunnel πŸ‘ Keel πŸ‘ OpenVPN πŸ‘ PIA πŸ”§ CLI


Unfortunately we don't have the resources to onboard volunteers without prior experience. If you're curious about the tools we use, here's a short list of jumping off points. Some of these projects have onboarding teams, so keep digging till you find one you like. Enjoy the journey and happy hacking!

Project workflow

Projects are listed atπŸ”—. Projects follow the same conventions (detailed below) unless impractical. Naturally we rely on and collaborate with a vast number of other libre projects, and follow their conventions when contributing upstream.

Ticket requirements

Submit your ticket while it's still fresh! Take a screenshot! Aim for these requirements, and the product owner will make a best effort attempt to complete the submission. Tickets must meet these requirements before being assigned to a milestone:

User story template

Keep user stories simple and focus on everyday outcomes. Save technical details for the suggested solution. For example...

User story: I am an everyday user. I want to send a private message to my friend, so that only they can read it.

Bug report template

Steps to reproduce:

What should happen?

What happens instead?

Ticket state

Release workflow

We number releases with semantic versioning. Release candidates are tagged in GitLabπŸ”— before testing. Once tested they are released to an environment branch per GitLab FlowπŸ”—.