Why Users Dumped Your Open Source App for Proprietary Software
Hard as it may be to imagine, "free" is not always the primary selling point.
FOSS adherents are happy to discuss all the reasons that open source is attractive to users and to other developers, from "it's free!" to "the philosophy of open source." Sometimes, they talk about the reasons that people avoid open source, such as "I want a phone number for tech support." But the hard fact is that sometimes people try an open source application — such as yours — and they end up not using it. I realize this is hard to imagine. But it happens, and not merely because the users have evil in their hearts.
While that's copacetic for plenty of people in the FOSS community (the not-adopting the software, I mean, not the evil part), other folks truly want their software to be used, and they want other developers to contribute to enhancing the app. (Whether you also want press attention to give your project better visibility is something else again.) I hate to bring up a dirty word, but the applicable term is marketing. That is: if you want more people to use your stuff, you need to know what it is that's currently chasing them away, and (assuming you care) you need to address those issues.
So I asked several people, especially open-source-friendly techies, about the times they seriously experimented with or used an open source app — and ended up using a proprietary application after all. I'm not speaking of a "trial" scenario in which someone downloaded an open source app, poked at it for a couple of hours, and decided, "Eh." I'm thinking more about situations in which they (or the department, or the company) were prepared to commit to using the software (for personal or business purposes) and decided on a non-open-source option instead.
My aim is not to diminish open source; quite to the contrary. My view is that — to use ordinary marketing terms — to sell an open source app you have to understand and respond to the sales objections. An open source project (or at least those in it who are thinking, "How do we get more users?") has to understand the ways in which it might "lose to the competition" before it can address the problem.
The most common answer is the one you probably expect: It didn't have the features required. That's understandable, because few open source apps have as many hours of development as do mature (you can read "bloated" if you like) proprietary alternatives. Any software that's been around for 10 or 15 years is apt to have more feature depth than will a newer application.
Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world
Esther Schindler
If the comments are ugly, the code is ugly
claird
SVG a graphics format for 21st century
pasmith
Take Chrome OS for a test spin
Sandra Henry-Stocker
Solaris Tip: Have Your Files Changed Since Installation?
jfruh
Android fragments vs. the iPhone monolith
mikelgan
What Gizmodo missed about the Pro WX Wireless USB disk drive
Sidekick: The Good News & the Bad News
Either way you look at it Microsoft Data Center management did not follow standards or best practices in this failure. In which case it makes me wonder more about the outsourcing of corporate data much less personal data.
- mburton325
Join the conversation here
Quick, practical advice for IT pros. Made fresh daily.
Want to cash in on your IT savvy? Send your tip to tips@itworld.com. If we post it, we'll send you a $25 Amazon e-gift card.
Slight clarification of my quote
Esther,I wanted to offer a clarification to my quote you used.
AS2 is not a product I dumped; it is a protocol. I dumped a OSS AS2 product that didn't have the management features that our organization needed, and subsequently the OSS wuftpd site that had duplicated functionality in the later-chosen commercial file transfer framework (but didn't have the management tie-ins).
Thanks,
~ Paul
the "too much tweaking needed" factor
One of the things I learned as the sysadmin to research projects is that programmers make the worst end users. (They can also be bad sysadmins but that's another story :-).)
The computingverse couldn't survive without programmers but they like to fiddle and often don't understand why everyone else doesn't either. Often they don't even realize they do it, too, unless you call it on them. If you point out something doesn't work they'll point out the little tweaks you have to make to get it going (sadly, often while making it sound like you're an idiot for having to ask. You should have read the source code to figure it out!).
Often user interface stuff is slid to the bottom of priorities -- adding features is more fun, and bugs are a required issue. Adding to that a lot of the OSS projects are driven by programmers who also are like this. UI is just "adding pretty" to many of them.
Unless a project has a dedicated team of UI people things are probably going to be klunky. And it doesn't even have to be GUI stuff. You often need easier interface stuff for a completely command-line driven app.
More OSS projects need to realize that UI people are worth their weight in platinum.
What made us dump an open source app we were using?
We haven't dumped an open source app, but we have dumped a proprietary app and the reason was lack of support.We had not been content with the vendor's standard contract and our lawyers had spent months negotiating what they considered to be watertight terms with provision for liquidated damages in the event of software failure.
Unfortunately the the vendor sold up and the new owner didn't want to know us. Although the contract was still valid, having a "throat to choke" proved pointless because what we needed was a working app - not money.
Fortunately my teenage son was able to come to the rescue with an open source app (TeXlive) with plenty of support from the open source community - not that we have found much need for it (support that is).
Open source apps are just that: OPEN!! If there is a bug, you have some chance of figuring out what is wrong and fixing it for yourself ... and everyone else. If you don't know how, you can complain publicly and someone else can have a go. You don't have to wait for proprietary owner who will more likely be interested in adding some new feature than fixing a bug that might only benefit a small percentage of his market.