My list of goals has a perpetual “contribute to open source projects” line item. Like many people who use open source software – whether it’s an Apache web server, Firefox web browser, Linux operating system, or any of a number of other tools – I’m not a developer. There are good posts on how non-developers can contribute (and many of my … contributions … are documented on this site). One of the challenges of open source projects can be interacting with the maintainer and other devs. In some open source projects, there is, in fact, such thing as a dumb question.
Open Source but Not Dialog
One research tool I run on my Web server is a good example: Tiny Tiny RSS. It’s excellent at what it does, the project has a companion app, and it’s very stable. But a quick scan of the support-related posts on the project’s site or on Google Play shows the maintainer flies off the handle quite easily. I have a ton of respect for the developer but I’m pretty sure most of my questions would end with me having singed eyebrows.
On the one hand, I can understand that answering the same question repeatedly is tiresome. Librarians get that completely. Particularly when you aren’t getting any compensation for the work, other than reputation. And anyone who has done technical support knows that when something breaks, where it is actually broken and where the user perceives the breakdown can be two entirely different things. But it raises the technical skills necessary to use the app and obscures how really easy the app is to run for most implementations.
A second tool I use has been sitting in my virtual tool shed, waiting for me to get around to fixing it: YoURLs link shortener. I’d migrated from an Apache-based environment to an Nginx one and the tool hadn’t been working quite right. I might have ditched it but I knew that some people had published some of the links, and without the server running, the links were not only dead but unknowable.
I carved out some time to finally get it back up and running and ran into a similarly crusty maintainer. In this case, the question I had was asked, and apparently answered, at least once. But the project had migrated from Google’s Code site over to Github and lost all of the comments. So, while the question had been answered, the content wasn’t there any longer.
It was also clear that this particular question would not be welcome. It didn’t have to do with the actual open source software but how it interacted with the Nginx server. And the maintainer had made it clear this was not of any interest.
I don’t really have any problem with that. They’re doing something I can’t and I’m grateful for that. I appreciate that some open source projects will be unavailable to me because I lack the technical acumen to work out the gray areas where the app works but the environment doesn’t.
This can raise a challenge. It’s not an uncommon one. I was recently installing a forensic tool on my Bash for Windows environment. The installation describes the dependencies this tool will have. Unfortunately, it didn’t describe all of them! At that point, without support, it can become a matter of trial and error to move ahead.
Anyone working with open source should become very comfortable looking (a) for log files that show what’s happening on a server and (b) being able to put an app into a debug mode. Hosted open source apps don’t always allow for (a) but you can almost always use the developers’ debug mode. In most cases, by reviewing a log file and doing some web searches, I can find someone who’s already had this problem. In this one, it was even easier. I just watched the installation and noted down any errors. Once the installation failed, I fixed each dependency, installing the missing software. Finally, the installation ran all the way through.
It’s useful to remember that the project site isn’t the only place to find help. Many – most – of the problems I run into have to do with that gray area. Which means that some other app on some other server has the same gray area. Even if the person has solved the problem using an entirely different open source or commercial app, it can still apply to what I’m doing. A lot of open source products based on PHP will share the same error messages and be fixed the same way, for example.
The latest problem I had came from what is a common problem with any software application: poor documentation. It’s like frequently asked questions; technical documentation often answers the problems it knows about. In this case, I was told to create a new config.php file and add two elements from my old config.php file. Then, when I called up my administrator dashboard, it would cause an upgrade to happen.
But my old config file didn’t have those elements and they weren’t documented anywhere else on the web … except where they were referenced in the technical documentation! Documentation gets out of date even on projects that can be a one-developer gig. In this case, I had to just start reading generally about people who’d posted about their own installations. I finally came across someone describing a file they had – .htaccess in this case, which is both for security and other reasons – that was different from mine. It was crucial, though, because it contained a fundamental component of the app’s behavior – that represented the broken functionality on my server. Problem solved.
I should note that the way I fix the issues that arise with open source applications is the same approach I take with commercial, closed apps. Microsoft, Google, and other companies are often no better at helping users to bridge the gaps between their products and the users’ environments.
Success breeds success as you start to return to the same places when things break, even if they break for unusual reasons. One thing I like when I’m researching technical issues with open source is that I often find questions that I might have answered, had I participated in the community or followed that forum. As you develop that kind of confidence, one of the frictions in adopting open source – the tech support – becomes less of an issue.