The Good Parts

I’m a big open source advocate and spend quite a bit of my spare time contributing to various open source projects. Everything form managing full projects such as Sigil, and KDocker. Also, heavily contributing to projects such as calibre. As well as doing one off patches and filing bug reports to various projects I use.

I believe in the open source philosophy to the extent that I’ve even gotten permission to push patches upstream to open source projects we use internally at work (fully compliant with the licensing) such as PenLight.

At work we use Linux on all of our development work stations and on our servers. The concept of running into an issue and being able to open a bug report or push a patch that fixes the issue is an amazing concept. In practice it works so well. I do work for a commercial software company and our core project is not open source but that doesn’t diminish our use of, reliance on and our love of open source. We even supply full code freely on our website for products surrounding our core application (which it self is closed source). So while we’re not fully open source we are somewhat and becoming more and more each day.

Even the variety of licenses (while some see as a bad thing) I think is a great thing. Most people and even I’ve had issues where trying to get two libraries working together has been hard due to incpompatibilies in the license. But you know what. The differences allow the author of the code to really determine how they want their code to be used. Such as the GPL which doesn’t allow the code to be incorporated into a proprietary project while the MIT license does. I see this choice as a huge benefit.

This even extends to distros themselves. There are so many out there that you can find the one that really works for you and does what you need. The point is open source allows choice and allows people to take an existing project, keep it from dying or even extend it in their own way.

I realize that this has been more about open source in general than linux distros but the two are intricately tied together.

The Bad Parts

Simply put, distros refuse and don’t care to work with upstream to resolve issues.

KDocker

Problem one is the versioning. The current version of KDocker is 4.8 which was released 2012-08-05. The latest version of Ubuntu trusty (14.04LTS) includes version 4.6 which was released 2011-05-30. So they’re two versions behind after multiple releases. I can see if I had made a release just before they did and after they had a version freeze. But they haven’t updated the packaged version in years.

What this situation leads to is user’s of Ubuntu opening bug reports against 4.6 and my response is that was fixed in 4.7 or 4.8 and they need to upgrade. But Ubuntu doesn’t see any need to update the packaged version. This is even though there is a debian directory specifically for Ubuntu to make deb packages and on top of that KDocker’s code is hosted on Ubuntu’s Launchpad service.

The next issue with Ubuntu (and other distros but this is specific to KDocker) is they’ve added files that aren’t part of the upstream packages. In this case it’s “/usr/share/man/man1/kdocker.1.gz “. While I understand a distro wanting to customize a package specifically to integrate better with their distro, this file is straight up wrong. the Man page doesn’t list the options correctly. User’s get frustrated and confused when they check the man page and it’s wrong / what they want to do doesn’t work.

I opened a bug report about this asking the outdated man page be removed in 2010-06-07. 4 years and nothing.

So, as far as KDocker in Ubuntu is concerned, they ignore upstream and damage “MY” project’s reputation even though I’ve asked them to fix the issues they’ve introduced.

Sigil

Communication and patches

This is a 100% distros just refusing to communicate with upstream. There are two example I want to give for this case.

First is an older one. Debian and Fedora (I’m not going to search for the links) had a slew of patches to make Sigil more Linux friendly. Sigil supports Linux (builds and runs) but it’s primarily developed on Mac and Windows. So Linux is somewhat of an afterthought. I do want to support Linux and have lots of Linux specific code to make it better on Linux but there is only so much you can do when you’re not on Linux.

As I was saying Debian and Fedora had a slew of patches to enhance Sigil on Linux. They had them for years and they never told me about them. They were brought to my attention by a user who was confused as to why the distros were maintaining their own patches. These weren’t distro specific ones either but just general Linux enhancements. Once I knew about this I started integrating them into Sigil. The issue is I can’t integrate pataches if I don’t know about them.

After the patches debacle I spent weeks of work to make Sigil more Linux friendly and even rewrote part of the build system so system libraries could be used in place of the bundled ones. Sigil bundles the vast majority of it’s dependencies for Mac and Windows since they aren’t easily installed via a package manager on those OS’s. That said only Fedora has packaged Sigil officially at this point even though Debian was one of the projects requesting these changes.

Licensing

Recently a thread where Debian had issues with some of Sigil’s licensing was brought up again. It linked to a Debian bug report with 184 comments. I read though some of it and honestly there were things I had no idea about. And you know what I’m not going to take the time to read though the entire thing because it goes all the way back to Sigil version 0.2.3 which is very old.

That report links to a blocker about FlightCrew. 98 comments, and again things I’ve never seen before.

I was contacted in the past about FlightCrew’s licensing and explicitly if the xsd (validation) files were allowed to be compiled into the application per their licensing or if they had to be referenced as external files. The Debian person said they’d look into that and get back to me so I would know what changes to make. I have no problem making the necessary changes. No one ever go back to me so nothing happened. That was the only licensing issue ever brought to my attention.

Also, at this point Sigil has a plugin system. I can decouple FlightCrew and make it into a plugin distributed outside of Sigil to resolve this issue temporarily. We’re planning on replacing it anyway with something else that supports epub 3 in the future so pluginizing FlightCrew would happen anyway at some point.

Further in that thread (just scanning) it they’re talking about others. Once again I can’t fix anything unless I know whats wrong. Honestly, I’m pissed that Distros have these discussions which go on for years and don’t include upstream.

Conclusion

This is why I refuse to support (building and running is supported but I mean as far as providing help) for Linux users. Linux packagers (I work on multiple projects including Sigil) rarely communicate with upstream and are often hostile and uncommunicative when upstream tries to reach out to them to resolve any issues they may have. I simply have no desire to waste my time or effort reaching out to every distro to see if they have any issues or complaints. If they have an issue they know how to reach me and we can talk about it. But they don’t!

So… Tell me what’s wrong and I can look into resolving the issue. If you have patches that don’t break multi-platform support I’ll review them. But not communicating with upstream (me) won’t get any changes or fixes integrated into the upstream code.

I should say at this point that not all distros have this attitude. Arch Linux for example has always been very good and positive about pushing issues upstream. This is really an issues with the attitude some (but not all) distros have toward upstream.