IMO the principal aspect, which was made obvious by the issue discussed, is the overboarding amount of routes Jolla propagates for reporting issues, detailed as follows.
- FSO is the “principal location for reporting issues for SailfishOS”, as repeatedly stated by multiple sailors.
For this purpose most issue trackers of SailfishOS-related projects by Jolla at GitHub remain closed, as argued by Jolla (@vige, @rainemak) etc. - I denoted multiple times that exactly this makes proper and easy handling of bug reports by advanced users and SFOS-software developers hard and tedious, e.g. by referencing and intermingling them with extant bug reports at GitHub, GitLab, Codeberg etc.!
The counter-argument was: “This is not what Jolla wants!” - As this was a pretty clear statement by Jolla, @nephros as SFOS-community member developed the
Buggertool to ease reporting bugs to FSO for SFOS-users, despite knowing that a forum software is fundamentally unfit for tracking as well as documenting the analysis and resolution of software-related issues. - Recently Jolla started to propagate a separate “SailfishOS issue repository” (solely for tracking some issues for SFOS’ software components in various GitHub-repositories controlled by Jolla) at GitHub for reporting bugs WRT SailfishOS, because “that is much easier”; AFAICS that is just one more unsuitable place to dump issue reports, because each GitHub-project already has an (optional) issue tracker, hence that “SailfishOS issue repository” is another centralised heap of issue reports which are basically as loosely linked to the corresponding software proper as at FSO.
- Additionally Jolla maintains its internal issue tracker, which is something nobody outside of Jolla should have to care about or even know of; but this is apparently the only bug tracker Jolla deems relevant for all, because everything revolves around it: Unresolvable (except for sailors)
JB#xxxx-references in git-PR- and -commit-comments,Tracked by Jollalabels at TJC and FSO etc. etc. The exact status, meaning and information hidden behind these labels is opaque to developers and users, hence these labels are basically useless for anyone without access to Jolla’s internal bug tracker. - Furthermore there are even more routes for reporting bugs, e.g. Jolla’s Zendesk instance which Jolla proposes as “the official support channel for individual SFOS-licensees”, but is not well searchable and yet another database plus web-frontend, the latter being even worse than FSO and far worse than a proper issue tracker for this.
And if all these different routes with piles of already heaped up and often already stale issue reports fail to deprive you of your motivation, it will be suggested that you must “discuss” issues you care about live IRC-session (“community meeting”) in the morning on a working day; I am positively surprised that so many volunteers regularly participate and absolutely appreciate that, but perceive the expectation by some sailors that volunteers have to show up simply as impertinent: I usually have to work and due to clearly uttered expectations will never participate, as these statements did contradict any proper and structural modelling of social behaviour on an par.
Hence I keep asking (myself, other SFOS-users, other developers and lastly sailors) for more than 10 years:
Does a proper modelling at Jolla exist of the various flows of information, OSS-issue tracking must at least be able to comprise (many more should be coverable)?
- Starting from a user report at FSO to an upstream OSS-project, while being fully (!; i.e. including all information and all potentially relevant references) traceable for any SFOS-developer (just model this for, e.g. me).
- Starting from a sailor (= Jolla employee) to an upstream OSS-project, while being fully traceable for any SFOS-developer (again, e.g. me).
- Starting from a SFOS-app-developer detecting an SFOS-bug (while being transparent to all SFOS-users and -investors, both, financially and non-financially investing).
If @Jolla still does not have answers to these questions, this corroborates to my former perma-question, “Why does @Jolla not care about properly comprehending, modelling and executing OSS-development-processes, although these are obviously crucial for Jolla’s own business development prospects?” Maximally easing collaboration (technically, socially, organisationally, infrastructurally) for acquiring contributions from volunteers (issue reports, code and documentation contributions) is obviously crucial for an OSS-company to reduce the workload of the paid employees, especially if this company was facing bankruptcy multiple times, i.e. the cost / revenue ratio apparently has not been balanced for longer periods of time.
Why?
P.S.: The fact that issues with this OSS-forum are software issue (e.g. “Discourse”'s mixed-quoting-issue) which are not at all transported upstream by Jolla, strongly underlines this meta-issue, because Discourse is a central, absolutely crucial part of the SFOS-infrastructure deliberately chosen by Jolla as its principal egressing information channel to users and developers, and as the only ingressing one. Actually, FSO’s issue handling by Jolla is a litmus-test.
P.P.S.: While it is nice to see an SFOS-developer gaining understanding that this lack of knowledge and oversight is a fundamental issue for economic success for SailfishOS and Jolla, fully comprehending exactly this is what Jolla’s management shall have strived for right from the start (~ 15 years ago), but they still seem to be completely liberated from that; i.e. the Nokia-“culture” / -thinking from before Stephen Elop entered the company still seems to prevail (“OSS is just a helpful sticker to excel economically, because we can reuse vast amounts of extant software, but we sure do not have to alter our mindset, understanding or execution”); I have not perceived a significant change since then, ca. 15 years ago, despite that scheme is not working (although RedHat, SUSE, etc. showing which OSS-development schemes do work well, for a even longer period of time) and that is even worse for smaller companies, e.g. Jolla. Well, one could have observed these public, well-visible developments closely for multiple decades, or instead contract some consultant (company) now to provide this knowledge and its application.
Yes, I do perceive that Jolla as a company and especially some sailors do have significantly improved on some of the aspects addressed here in the past couple of years, and apparently continue to do so, but I am afraid that these changes are executed “too little, too late”, which leads right back to the dire resource issues which lets and did let a sustainable development of SFOS (e.g. fixing significantly more bugs than new ones become introduced, regardless if Sony, Jolla, the cellular network providers etc. are to blame) appear questionable. I really would like to see Jolla and SailfishOS persist, as there is no sufficiently well working alternative as a “mobile phone Linux distribution suitable” (for me, at least), invested lost of time since 2015 into maintaining software which in crucial for me, but the endless chain of regressions are often outweighing the fixes and new features of a fresh SFOS release from my perspective as a user and developer, thus regularly requiring a lot of work just to keep software running under recent SFOS releases. As consequence many significant developers of software for SFOS have already quit and I am regularly considering it, because some AOSP-distribution (LineageOS, GrapheneOS etc.), primarily with apps from F-Droid also provides one with a complete OSS-software stack, but better maintained, mostly more feature-rich (partially “much more”) software; I really do not want that, but massively gaining spare time while significantly improving some functionality of my phones sounds quite attractive.
Hence I do expect to see some SFOS-roadmap documented by Jolla, which actually has become a point even more SFOS-users address in the past 12 months than before due to the tremendously debilitating bugs the Jolla C2 and Xperia 10 IV / V exhibit since SFOS has been released for these devices in 2024. Knowing well that communicating release dates many weeks in advance when developing software in an heavily resource limited environment mostly becomes obsolete very soon after such an announcement has been made, but to provide a temporally ordered list without specific dates or timelines which software components are going to be addressed / altered / overhauled / fixed / enhanced next would be tremendously helpful to assess if software one maintains is going to be affected; while some of this information has been provided on a very abstract level in the regular, bi-weekly postings by Jolla, this information is only provided in hindsight (when the planning, implementation, quality assurance / review and committing the PR has already been carried out) and has to be actively (re)searched (because a continuously expanded roadmap does not exist), which exposes developers to stress, because the software one maintains often has to be adapted within a couple of weeks, because bigger batches of changes in SailfishOS are usually committed in the weeks before the initial-Beta release of a new SalfishOS-version: If one does not have the time to permanently monitor Jolla’s announcements at FSO and (sometimes triggered by them) commits at GitHub, one likely can be hit absolutely by “the SailfishOS:Chum GUI app and / or Storeman does not work for a cBeta-users”, only to receive multiple such messages a few weeks later from EA-users to be informed that havoc is imminent (by the upcoming GA-release a week later): The timeline have become too short about ten years ago and are kept as such by Jolla despite exactly this developer feedback, especially from infrastructure software developers.
P.P.P.S.: Please do not simply try to dismiss this message as …
- derogative
- criticising specific technical aspects (I did not address any specific technical aspects, only structural ones)
- crazy
It is rather, “what other choices do we have?”
- Individually
- Among your kin (“the hood”)" / like-minded people
- Jolla
- A a community / company / society / country
… to archive some digital sovereignty.
TL;DR
I perceive Jolla failing to build a SailfishOS-developer community for over ten years now, because Jolla does not seem to see a strong necessity for that. Lots of lacking points SailfishOS has have been reported repeatedly in the forums (TJC and then here at FSO) right from the start in 2013, first and foremost the inability to earn money by distributing paid apps in the Jolla Store (nothing I personally want, but originally the demand was denoted quite often, though most of these developers went) and the completely outdated, unsupported, unmaintained and insecure Qt5: Despite these points (and many other, minor ones) being obviously crucial for an SFOS-ecosystem to ever work and Jolla has never denied this fact, Jolla actively refuses address or talk about these. As the software quality (i.e. the number and gravity of regressions) by Jolla clearly has been decreasing in the last couple of years and Jolla does not plan to resolve the most severe structural issues, I do not believe SailfishOS has a sustainable future due to ever decreasing number of app developers (I think ca. 50% of the volunteering developers ceased using and developing for SailfishOS since the late 2010s, and probably an even higher percentage of the software developing sailors due to repeated restructuring of the company).
Consequently I am convinced that time is running out for Jolla, if they do not start to address these structural deficits: My hope for this to happen is still alive (otherwise I would have not written this lengthy message), but my expectations are low when extrapolating Jolla trajectory without any change of their course.