Open Source Software Pet Peeve
I’ve been working to install some open source software for collecting reference statistics this week. The software is very straightforward and should have been easy to install but the developers neglected to mention that you need to have a particular PHP PEAR module installed to make things work. The module is a piece of cake to install once I realized I needed it.
Stuff like this really frustrates me. Not because I can’t figure it out. I’ve been working with open source software for a while and I realized very quickly what was wrong. However, this type of omission adds to the learning curve and frustration level for folks who are less savvy. The reason, what should be an under 15 minute install could drag out for days if the person doing the install is relatively uninitiated to open source software.
This is why people don’t like open source software and why they won’t use it or think that is difficult. The things the developers take for granted that every knows aren’t universal particularly if you have users of your software who are just getting their feet wet. So note to developers and documenters when you put together the requirements for your open source software. Be explicit in your requirements please. A person might not know what the PEAR DB module is or if they have it. But by trial and error they probably can deduce it isn’t present and they sure can Google to figure out what it is and how to install it. Without clear requirements, you are increasing the chances that the person attempting to try out your software will not be able to install it properly and potentially give up on your tool altogether.
Amen, sister. You get one chance to make a first impression. If we want to get a product past the “inner circle” it needs to be friendlier than that.
I wish I had written this. I’ve also been frustrated at the level of knowledge and experience that is assumed when installing open source. At one point I even made headway on this with my own open source project. For a while we got Swish-e to a point where the installation was simple and to use it you simply opened up a web page and filled out some fields and hit the button. For various reasons we had to give up on that, but I’ve never lost my desire to make things easy enough for an interested amateur to get started.
ummm. Let me get this straight. Open source gives you a free product, but because they didn’t hold your hand during the install, they’re no good.
Have you ever worked with Windows? Because it’s basically the same thing, only they make you pay for the privilege.
Not to mention that knocking all of open source because one developer with one program doesn’t list necessary specs is a little silly. That would be like saying Windows sucks because I had trouble installing some small, third-party app.
(all of this said, I agree that the developer ought to put the specs on their programs, but still.)
Hi Karen(s):
I share your frustrations, but as someone who has been working hard to help ease the install and configuration grind for Evergreen, including writing documentation, I can assure you that any oversights made by developers (at least in the Evergreen project) are not intentional. It’s in everybody’s best interests to make it as easy as possible to get software up and running: users get to work faster, developers get to keep developing instead of answering setup questions, and the community may grow and attract more developers / doc writers / contributors to the benefit of everyone.
As frustrating as it may be for a user to run into a wall, you can help improve the experience for others by sending a suggestion to the project mailing list (if you managed to find your way over/through the wall), or send a question to the mailing list if you’re blocked. Having gone through the process of installing and configuring Evergreen dozens of times, it’s always amazing what a fresh perspective offers (and what unexpected problems other people can run into). We aim high, but sometimes miss the target, so I really appreciate it when people post questions & suggestions to the list.
Doug,
My gripe isn’t with the software. I love open source software and use it often at work and home. As far as I can tell the particular offending open source software is a great little tool. But for an open source project to be successful it needs to have a reasonable adoption rate. Not including basic information like “this requires the PEAR DB module” slows adoption. Additionally, from what I’ve seen this isn’t a unique phenomenon with open source. There is an assumed level of knowledge that I believe sets the bar too high in some cases. Open source software can be great software but people won’t know if they can’t get it properly installed.
Dan,
I’ve been impressed with Evergreen’s recent efforts at improving their documentation and PR materials. Kudos! The first thing I did when I found this issue was email the developers and say “hey, might want to let people know…” My post was meant to be more of a “please keep this in mind developers ” than a “naught open source developers”. I realize that developers are not always the best writers of documentation. I struggle with this issue with my own web developers and documentation is something we try to build an improve upon on a regular basis. But it isn’t easy when the primary focus is on making sure the system stays working and fixing things that don’t work. So we can be a little slack in our level of detail. We’ve been trying to make up for that of late because in two weeks a new member of the team arrives and needs to get up to speed with our systems.
Virtualization is a growing trend for this type of situation.
For example, look at all the excellent applications virtualized by JumpBox: http://www.jumpbox.com/product
Or, if you have a budget virtualize it yourself with something like Xenocode’s Virtual Appliance tool: http://www.xenocode.com/
I, too, encountered this little undocumented feature when I installed this bit of OS software. I’m pretty forgiving, however, since they don’t really plug the product nor claim that it’s perfect. You’ll notice, in fact, that they had to release a new zip at one point because they left a file out of the previous release. I had to point that out to them when I was the poor soul who discovered it. Your experience with the php module and mine with the file makes us, in a sense, part of their OS community. We can help them, if we like their product, by writing docs, providing feedback, giving back code (we did that with a bug fix a while back).
Incidentally, we’ve added more reports to this product, but they behave a bit wonky. If you’re interested, I can probably get the code from our programmer and share.
Karen,
I completely agree with you. I just happen to work with and around a number of people who want everything to be super-easy, and it’s frustrating sometimes, because at the end of the day, computers are really complicated machines. They’re bound to have issues that you have to deal with, and I for one am considerably more forgiving of free software than Microsoft. However, your point is valid: it isn’t that much trouble to tell people what they’ll need to run your software, and if you take that step, it makes more people willing to try out open-source, which is a good thing.
This is one of the reasons I love the use of Wikis for open source product documentation. With an appropriately open Wiki (usually there’s some small barrier to entry, but not too bad) one can log on and add to the documentation oneself. I’ve tried to write documentation before, and it’s amazing the little things you forget to tell people when you’re when you’re waist deep in a project.
dsa: Yeah, the reporting code is scary as hell. I’m sorry.
Karen, agreed. As Bill mentioned we’re trying to solve this problem by wrapping open source server apps in a self-contained environment so they’re ready to use immediately and configuration consists of filing out a couple fields on a web page upon first boot. Check out any of the 10 apps that we’ve made to work this way -> http://www.jumpbox.com/product
sean