Behold! The most important news stories of the week!
How much time did it take for an open source alternative to be made?
This is a rather interesting chart. Put together by André Staltz, this chart takes a number of popular, proprietary pieces of software… and then measures how long it took for a viable, open source alternative to be produced.
I can’t firmly attest that all of the data is correct… but, at first glance, at least some of it is.
The author then goes on to plot out the data — showing how quickly open source alternatives are made over time. The results are both fascinating… and expected.
As time goes on… open source alternatives to proprietary systems are being made at an ever-increasing speed. It would be interesting to add some additional projects here to get some more data points — AmigaOS, MS Windows, etc..
I was alerted to the Betterbird project by a member of The Lunduke Journal Community, and it seems worth a look. From the project description:
“Betterbird is a fine-tuned version of Mozilla Thunderbird, Thunderbird on steroids, if you will. Betterbird is better than Thunderbird in three ways: It contains new features exclusive to Betterbird, it contains bug fixes exclusive to Betterbird and it contains fixes that Thunderbird may ship at a later stage.”
To further explain the reason for Betterbird existing, the project provided this example:
“Based on the current situation in version 102, a look at quality assurance, or lack thereof, is appropriate. Thunderbird has never had an organised quality assurance team, they let the product ripen at the customer site, at worst causing data loss like for version 102. The 102 release with mbox and MSF corruption causing data loss and deleted MSF files was nothing short of disastrous.”
The Betterbird team isn’t exactly wrong here. I’ve used Thunderbird for many years (well over a decade) and I can recall several instances of serious bugs in Thunderbird causing significant loss of data for me, personally. Testing and QA has been a noteworthy problem with Thunderbird for a very long time.
Betterbird just released their latest version (91.13.0) for Linux, Windows, and Mac. And, when you look at the chart of features added (and bugs fixed) in this fork of Thunderbird… it certainly looks compelling.
I’m a big fan of AppImage’s — single .ISO images that contain a piece of software, and all of the necessary dependencies to run it on a reasonably modern Linux system. But a big issue is making them. While some tools exist to aid in the packaging of AppImage’s, the process hasn’t exactly been automatic.
A new Python script entitled “arch2appimage” — gotta love on-the-nose naming — fixes this issue by taking an Arch package (such as from the AUR) and auto-magically turning it into an AppImage. Dependencies and all.
The resulting AppImage should then, in theory, run on any semi-modern Linux distribution.
The Serenity OS project has tackled yet another item that nobody was quite expecting: Emoji. If you go to emoji.serenityos.net you can see a full grid of the standard (UTF-8) emojis… and watch as the Serenity OS crew recreates all of them — in a low-res, pixel art, open source style.
Why? Who knows! But I rather dig that they’re doing it! It’ll help emojis to fit in a bit nicer on systems with more 1990s style interfaces. Like Serenity OS. Which… is probably why they’re doing it. ;)
At last check they had recreated 772 of the standard set of 1853. With progress moving crazy fast… much like everything else this team tackles.
The comparison between original and open source apps is missing a critical bit of info: some notion of feature parity. Some of the open source versions intentionally eschew some feature compatibility, but others are pale imitations that stall-out when the magnitude of the task is finally appreciated. Most tend to be in that large gulf.
One significant issue is the difficulty of doing organized testing. Any network email client faces significant interoperability challenges with anything more complex than POP3. Any IMAP4 implementation must (theoretically) test with multiple server implementations using a staggering set of test scenarios. This is further
complicated by the fact that essentially no
two IMAP4 mail servers really work the same way even if they provide all the mandatory protocol.
Further, the assumption that the email environment seen through a server-specific user-agent and an IMAP4 user-agent will be the same, or just two different IMAP4 user-agents, is frequently less true than scriptural purity can provide.
Another issue is generality of use cases. While Linus created “git” to replace his previous tool supporting the Linux kernel effort, git is not a simple replacement for revision control systems. From one point of view, git is an “anti-control” system. It allows arbitrarily many different people to simply copy an entire tree and do with it as they wish. The only coordination happens when a modified tree is (attempted to be) merged into a managed mainline. This is a real advantage in an environment where the BigBang/BigCrunch/Repeat cosmological model can be used.
Git is not adequate for an environment where entropy is automatically managed more aggressively. This distinction seems to be lost given the assertion of equivalence.
Different software systems exist because of different goals and requirements, not only because of political philosophy.
The comparison between original and open source apps is missing a critical bit of info: some notion of feature parity. Some of the open source versions intentionally eschew some feature compatibility, but others are pale imitations that stall-out when the magnitude of the task is finally appreciated. Most tend to be in that large gulf.
One significant issue is the difficulty of doing organized testing. Any network email client faces significant interoperability challenges with anything more complex than POP3. Any IMAP4 implementation must (theoretically) test with multiple server implementations using a staggering set of test scenarios. This is further
complicated by the fact that essentially no
two IMAP4 mail servers really work the same way even if they provide all the mandatory protocol.
Further, the assumption that the email environment seen through a server-specific user-agent and an IMAP4 user-agent will be the same, or just two different IMAP4 user-agents, is frequently less true than scriptural purity can provide.
Another issue is generality of use cases. While Linus created “git” to replace his previous tool supporting the Linux kernel effort, git is not a simple replacement for revision control systems. From one point of view, git is an “anti-control” system. It allows arbitrarily many different people to simply copy an entire tree and do with it as they wish. The only coordination happens when a modified tree is (attempted to be) merged into a managed mainline. This is a real advantage in an environment where the BigBang/BigCrunch/Repeat cosmological model can be used.
Git is not adequate for an environment where entropy is automatically managed more aggressively. This distinction seems to be lost given the assertion of equivalence.
Different software systems exist because of different goals and requirements, not only because of political philosophy.
Assertions of equivalence without regard
to these real differences can discredit
the cases where the advantages are real
to everyone’s ultimate disadvantage.