Pachli’s application has been published, here: Pachli - Nivenly Application | The Nivenly Foundation
For members, a discussion will be posted in the member-only section. This is a public thread for non-member feedback 
Let us know your questions about Pachli!
Questions:
Why a fork and not a contribution back to main? There may be an obvious reason or I may have missed something spelled out in the documentation already (if so I apologize), but while I see a lot of things to work on I don’t see a reason for a fork.
What is the relationship with the Tusky developers/project? Are any of the (now former?) Tusky developers working on this one?
I believe this might shed some light: Stepping back from the Tusky project — nikclayton
is Nivenly in a good position to address those concerns? @nikclayton
Why a fork and not a contribution back to main?
I stepped back from the Tusky project earlier this year, after contributing to that project for about 8 months (~ 150 PRs), running the two previous releases (Tusky v22 and v23), and being the main (or possibly only) person posting from the @tusky account for ~ 2 months.
Stepping back from the Tusky project — nikclayton sets out why I stepped back from the project. It’s the failures of project governance there, and a clear lack of willingness to address them, that made me think a fork was reasonable.
In particular, if I’m going to talk the talk I should be prepared to walk the walk.
The lack of project governance with the project was noted as an ongoing issue as recently as Oct 30th by @connyduck, Tusky maintainer (Conny Duck: "Tusky" - chaos.social).
What is the relationship with the Tusky developers/project?
There isn’t one.
The Tusky project produced a statement that repeatedly lied (Update #2 on "Stepping back" — nikclayton onwards).
Since then two more members of the project have resigned, one of whom I believe was bought on specifically to work on the issues I raised. I do not know why they resigned.
It’s been more than three months since the Tusky project put out a release, effectively stranding the contributions that people have made to the project in the interim time (features, bug fixes, and translations). There is a “nightly” build, but that’s used by less than ~ 5% of the userbase (at the time I left, I don’t know those numbers now).
From what I’ve seen (and I appreciate that this may come across as harsh, but I think it’s important to speak clearly) the Tusky project is an object lesson in what happens when an open source project becomes an integral part of many peoples’ experience of a service, but with no workable plan to scale and govern the project accordingly.
As the user base increases so do the number of feature requests and bug reports, with the communication and project management burden that that brings.
This leads to maintainer burnout, with its associated human cost.
This is not to cast blame – the sudden influx in November 2022 took everyone by surprise. But the project has not been able to adapt, or prioritise adapting.
Are any of the (now former?) Tusky developers working on this one?
Not at the moment. Given the project’s statement and the refutation I posted I would be surprised if any of them were to contribute.
That said, contributions from anyone, whether it’s in the form or PRs or not, is always welcome.
I hope so. They have a head start in thinking about project governance models and providing expertise to other, larger projects. The Nivenly board (Who is running Nivenly? | The Nivenly Foundation) membership covers for at least some of my own blind spots, biases, and gaps in experience.
The Nivenly membership would provide a much larger sounding board for ideas that I have about e.g., using membership fees to fund grants for contributions from people who would like to participate in the project but are economically unable to do so at the moment.
By way of an introduction as well (and mostly swiping from About Pachli | Pachli):
I’m Nik, I’ve been contributing to open source projects since the early 1990s. I’ve run large open source events (I was one of the co-founders of BSDCon Europe back in 2001). I’ve started open source projects, joined open source projects, been given stewardship of existing projects, and handed stewardship of projects I’ve started over to other people.
On Mastodon I’m @nikclayton@mastodon.social.
I contributed to the Tusky project December 2022 - August 2023. My first contribution improved the FAQ (#16). Since then I contributed more than 150 PRs to the project. If you were affected by Tusky bugs like:
then I’m the one who fixed them.
I also work on accessibility including #3003, #3121, #3272, and #3248.
I was responsible for the 22.0 and 23.0 Tusky releases, and a great deal of the interaction with users via the Tusky Mastodon account. I also did most of the review and merge work of new contributions.
I’m in Zurich, and will be checking in on this thread a couple of times a day (Zurich time) to read and respond.
Is there any appetite for attempting reconciliation with the upstream project? I’m still unsure how I feel about Nivenly sponsoring an app that is essentially a hostile fork.
Also, has there been any progress in building a team in the last ~three months since these threads were started?
Probably not, for both social and technical reasons.
Social
The Tusky project team lied, repeatedly. I’m not going to beat around the bush about that, or try and hide the statement behind weasel words.
If you want one example that is trivially verifiable open Update #5 on "Stepping back" — nikclayton and search for the section that starts “insisted on his solution”.
If you want more examples, and have the time, I’ve written about this at some length, so:
I stand by those words today.
The projects’ goals have also diverged. For example, Pachli will support features found in non-Mastodon servers, which is an explicit non-goal of the Tusky project. I also intend to support opt-in fetching of content from other servers (e.g., view the local timeline of a different server, or fetch missing posts from threads) that the Tusky project explicitly does not want to do.
Technical
The Pachli code has diverged quite a bit from the Tusky code, so it’s generally not possible to merge changes from Pachli back to Tusky without some amount of rewriting.
Having said that, I am always open to collaboration that improves privacy or security for our respective users.
For example, Pachli inherited a critical Tusky bug that meant that post interactions (replies, boosts, favourites, etc) could be applied to the wrong post (Post actions operating on the wrong post · Issue #370 · pachli/pachli-android · GitHub). This is obviously a significant privacy risk, as you might find yourself boosting a post you did not intend to.
The fix in Pachli cannot be directly copied to Tusky because of the code changes I’ve already mentioned. I contacted the Tusky project privately to make sure they were aware of the fix, and to ask if they wanted any help merging the changes in to Tusky. I did not get a response, and a few days later noticed I had been banned from the Tusky GitHub repository (i.e., I cannot report bugs through GitHub, comment on existing issues, etc). Obviously I don’t know for certain that the two events are connected, but the timing was suspicious.
To the best of my knowledge Tusky still has this critical bug, and has not acknowledged it publicly.
Putting aside the question of which side of the discussion is telling the truth, the Tusky project is still not behaving in a way that I consider appropriate. Some examples:
| Pachli | Tusky |
|---|---|
| Does not accept sponsorship or donations, because the project does not have a policy for handling them. There won’t be a policy until there is a process for members to join the project, and have a say in writing and approving a policy. |
Continues to accept sponsorship and donations (e.g., on release notes, and https://tusky.app). Now (finally) has a payment policy buried in the CONTRIBUTING file, but not mentioned on the website, the Tusky OpenCollective, in the release notes, or anywhere else you might expect to find it. Reading the actual policy it has no provisions for fairness or transparency (e.g., ensuring that people are paid the same amount irrespective of gender). |
| Credits contributors in full in release notes , Mastodon announcements, and related blog posts | Does not credit contributors in release notes. or Mastodon announcements . Does not blog, so N/A. Does not post release announcements to Open Collective, where the people who are paying for the project could see it. |
| Releases at least once per month to ensure that contributors’ work promptly makes it to users. | Erratic release schedule. Five months elapsed between v23 and v24, and it’s been more than two months since the last release. |
| Has a code of conduct. | No code of conduct. An intention was announced approximately three months ago, since then, nothing. |
You might look at that and think that’s not fair, Tusky is a volunteer project, and relies on whatever time the volunteers have.
To which I would agree – if the project wasn’t taking people’s money. But it is, and I think that significantly raises the bar for what is reasonable to expect from an open source project.
Too many open source projects think that taking funding for grants or expenses (whether that’s Patreon, OpenCollective, GitHub sponsors, or anything else) means that things can carry on exactly as they were before.
I strongly disagree with that stance. I think that as soon as you start taking money that is not clearly labelled as “This will be distributed to the project’s solo contributor” you have also taken on a responsibility to fairly distribute that money in a transparent fashion. There are just too many examples of, for example, women being underpaid for the work they do relative to men, for anything else to be appropriate.
Does that mean projects shouldn’t accept donations until they have the infrastructure in place to manage those donations properly? Yes, I think it does.
All of the above is about donations to a project. I think that donations direct to an individual through those platforms, Kofi, etc, are different; if you’ve donated to an individual then apart from expecting a “thank you” you obviously don’t get any say in how they choose to spend the money, or any expectation that they will tell you what they spent it on.
Re “building a team”, I am still contributing the majority of the code changes. There is a growing group of people contributing translations for each release (see credits at Releases · pachli/pachli-android · GitHub), and a handful of people who regularly contribute bug reports.
The bug-handling approach seems to be working well so far, based on feedback like:
And there are, of course, network effects. As more people use the app it will inevitably find its way to people who have the time and the skills to contribute.
I’ve deliberately held off on any larger campaign to attract contributors because I want to have the infrastructure in place to support members first. Either under Nivenly, or a dedicated association (Swiss Verein).