I think you are starting with a fundamental misunderstanding of how software flows with time. Let me point out some of the underlying principals of software development and then discuss how these impact Lumina/TrueOS afterward.
No project is an island
Every single project needs/uses some other external utility, library, communications format, standards compliance, etc in order to be useful. This is especially true with graphical applications, since they need to utilize the current: display system (X11/Wayland), audio system (OSS, ALSA, PulseAudio, SNDIO, etc), and more.
A static project is typically a dead project.
Even if a project has no considerable changes to it’s codebase or feature set, it still needs regular upkeep and maintenance to ensure that it continues to build/run with the current ecosystem of libraries and utilities (because the entire ecosystem is always moving forward - stop too long and your project will no longer build/run).
“Upstream” decisions can have drastic consequences on your project.
From no fault of your own - your project can be rendered obsolete/broken by changing standards in the global ecosystem and how they effect your project’s dependecies. Case-in-point, the audio subsystem “wars”. ALSA vs PulseAudio is the fight that people are more familiar with (ALSA lost), but do you remember the “JACK” audio system? That one lost in a big way to ALSA (even though Jack was/is better at low-latency functionality), and nearly all development/support for Jack has disappeared in the meantime. This means that all those audio recording/mixing utilities which used Jack have been rendered “in-operable” by an upstream decision.
Operating system focus is key
What OS is the project originally designed for? This determines what the “upstream” dependencies will look like and which “heartbeat” you should monitor at all times. For Linux-based utilities like Okular/Firefox, this means that the only audio subsystem to be supported is PulseAudio (even if we have OSS on FreeBSD which works 10,000x better), the only OS-subsystems which are used are based around SystemD/DBUS. For FreeBSD/TrueOS this presents a massive challenge to continue to support Okular/Firefox since those applications are essentially incompatible with the subsystems used on our OS (it takes a lot of work/time to “port” those apps over to work with FreeBSD - and this often introduces bugs and other issues as well).
With these principals in mind - lets look at the Lumina/TrueOS/PC-BSD projects.
PC-BSD) This was designed/based around KDE on FreeBSD. KDE/Plasma5 has been available for Linux OS’s for well over a year now, but we still do not have it available on FreeBSD yet (it is still in the experimental “area51” repository where people are trying to get it working first).
What about KDE4 on FreeBSD? This runs into principal #2 above - it is basically a dead project (replaced by version 5) and is continuing to accumulate security vulnerabilities (hald anyone?), OS-incompatibilities (gotten your screenlocker working yet?), and is relying on other dead projects for critical functionality (policykit/consolekit - both replaced by systemd on Linux). For PC-BSD 10.x we tried to mitigate a lot of the changes in KDE by making our OS-configuration utilities DE-agnostic, but that only gave us a short reprieve from the underlying decay and started to result in a “split-brain” framework where our (functional) tools were available at the same time as the DE’s disfunctional tools.
As a developer with PC-BSD for a long time (and involved with testing it from nearly the beginning), I was keenly aware of the “winds of change” that were blowing in the open-source ecosystem (especially in the desktop-environment subsystem, way back before systemd was even announced) and so I started working on a FreeBSD-based desktop environment which did not rely on all these Linux-based subsystems and frameworks so that we could ensure a FreeBSD-based desktop OS would outlast these other Linux-based desktop implementations which were having their fundamental frameworks ripped-out from under them and replaced so frequently.
All of these ecosystem changes finally came to a head for us near the beginning of 2016. We could see KDE4 really starting to deteriorate out from under us, we could see that FreeBSD’s “Release” branch would never allow us to compete with the rate of graphics driver/standard changes that were coming out of the Linux camp. We started rolling monthly “snapshots” of PC-BSD based on FreeBSD’s “Current” branch (ostensibly in preparation for FreeBSD 11.0) and quickly discovered that the “rolling” release model for the monthly snapshots was solving a lot of our longstanding issues with PC-BSD. We had newer drivers. We had bugfixes in a timely manner. We had a single “supported version” of our project which made better use of our limited developer hours. The list goes on. At the same time, we started switching over to Lumina instead of KDE by default and discovered that everything we had been working towards started “clicking” together. The interface was stable. There was only a single set of OS-configuration utilities. The number of “upstream” bugs from the Linux camp which affected us dropped considerably. Was Lumina as “finished” as KDE? - definitely not - but we could tackle the critical issues one at a time and ensure that once something was fixed it was fixed for good.
With all of these changes (and the lack of a clear “upgrade” path from PC-BSD to the new systems), we decided that we needed to change the project itself (name and all). That was the only way to ensure that people were aware of the differences, and that TrueOS really was a different kind of project from PC-BSD. Note that this was not a “hostile takeover” of the PC-BSD project by rabid FreeBSD fanatics. This was a simply a rebranding/refocus of the PC-BSD project into something that could ensure longevity and reliability for the forseeable future.
Does TrueOS have some problems? Of couse! That is the nature of “rolling” with upstream changes all the time - not only do you always get the latest version of something (a good thing), you also find yourself on the “front-line” for finding/reporting bugs in those same applications (a bad thing if you like consistency). What you are also being exposed to is just how much “churn” is really going on in the open-source ecosystem at any given time (although I do think the churn is a bit more aggressive right now than normal). Because the changeover to a rolling model was still not that long ago, we are still adjusting to some of these new realities and working on implementing contingency frameworks and/or automated QA tests to help mitigate some of the churn - but it takes time.
So just bear with us right now. We are devoted to a stable/reliable/secure experience for our users (and ourselves - don’t forget that we also use TrueOS every single day) - and you can be assured that we will continue striving toward this goal in the best way possible - not just for the moment, but also for the long-term future of the project.
Now for the Lumina “desktop-utilities”: These small utilities are developed for a few reasons:
Missing functionality in TrueOS.
Sometimes, we just cannot find an open-source application which fits the criteria for inclusion into the TrueOS base install, but the functionality it considered critical and must be filled. The Insight file manager (lumina-fm) and lumina-archiver are two good examples of tools developed to “fill a hole” in TrueOS.
Sometimes a utility that we have been using for a long time starts losing functionality, or the upstream project starts expecting more dependencies that are either not available on FreeBSD and/or bring along a ton of other garbage dependencies for the ride. If we cannot find an alternate replacement for this utility (see #1) then it comes down to us to write a replacement.
Note that this process will sometimes be started quite a while in advance of the current app completely breaking. We try to be proactive and anticipate the way development trends are going for any utility that we tend to rely on for TrueOS, so that when the time comes we are not left with glaring holes in our project.
lumina-pdf is a utility that falls into this camp.
okular might work for now, but we don’t anticipate that lasting for very much longer. While
qpdfviewer is a valid replacement for okular, when we start looking at the move to Wayland down the road we see that even that utility will become unfunctional. Since the Wayland transformation is still a ways off though - we are fine with putting
lumina-pdf on the backburner for now (but at least the majority of the interface/functionality is already done).
Developer “Fun Time”.
As a developer it is very useful to take a small bit of extra time (usually on my days off or when I only have a small timeslot where nothing is scheduled) to just do something different. This provides a “playground” (so to speak) to take a step back and re-think an application, experiment with new libraries/features, and generally learn/grow as a developer. If one of these projects turns into something useful, then we will devote a bit more “official” time to it to polish it up and release it - but not everything makes the cut.
lumina-mediaplayer is a utility that would fall under this category. It started out as a weekend/hobby project to replace
pithos as my normal Pandora radio application (after I got fed up with how fragile Pithos is with regards to LibreSSL versions, GNOME3 integrations, etc…) and has gradually become something useful to more people than just myself. The local-file playback functionality within it is really just to provide a baseline level of functionality for the user if they don’t want/use Pandora radio, and fills a niche as a “fallback” utility in case somebody really doesn’t need the breadth of functionality that VLC or another “full featured” media player provides.
Bleh - I just realized I wrote a small book here… sorry for abusing your eyes like that.
I will finish up mentioning that if you have additional questions about anything I talked about here, feel free to open up a new thread here on discourse about it or similar. While TrueOS is technically a “benevolent oligarchy” - we really don’t try to keep secrets about our reasons for development decisions and such. More often than not, if you just ask we will gladly answer any questions.