On Open Source Entitlements: Users

This post is part two of two on a series of open source entitlement.

In the previous post, I mentioned that working in the world of open source has the potential for others to feel a sense of entitlement. The thing is, I don’t believe that this isn’t limited just to contributors.

Granted, I don’t think those who end up using free and open source software aim to present themselves as being entitled – I mean, they are taking advantage of the software that contributors have made available, right?

But the flip side of this is that users who find themselves working with open source software set expectations that may far exceed the amount for which they paid for the software.

Entitlement Defined

I already covered this in the previous post, but just to make sure that we’re all on the same page.

Office Entitlement

The official definition of entitlement is this:

give (someone) a legal right or a just claim to receive or do something.

And in the context of open source, I believe that there’s a fine line to walk with receiving free work, and expecting free work. And the latter case is the one that breeds a sense of entitlement.

Open Source Entitlements: The User

Free software can be a really tough spot if you’re a user – and most of us do use free software to some degree; however, there are those who think that sense they received the software for free, then they are entitled to having their questions answered, support fulfilled, requests implemented, and so on.

I think the question can be simplified into the following: Do those who release open source projects have a moral imperative to provide support to those who use said project?

After all, anyone who has been involved in any open source community is aware of the volume of support requests, bug reports (and I do use that term loosely), and demands that can come in from those who use the work.

On one hand, I think that it makes perfect sense for those who develop a project for others to use to provide some level of support. This doesn’t mean diving deep into troubleshooting each and every problem, but at least providing some sort of acknowledgment of your users.

For example:

  • Perhaps you clearly state that you only answer questions via email,
  • Maybe you only respond to tickets that show up in the issue tracker for the repository of your project,
  • Or maybe you even offer to troubleshoot each issue that comes in.

The truth is, some people are genuinely helpful, are offering their input, their experience, and even ideas on how to make the project better. Some are letting you know about the issues that they had with trying to get up and running with it so that you can make a more robust product, and, frankly, others demand that you solve their problem free-of-charge, no-questions-asked, just-do-as-I-say-because-this-project-is-mine-and-I-downloaded-it-and-I-deserve-it!

But, come on, just as developers have a moral imperative to provide some level of support – even if that means that they flat out declare that they offer no support – I believe that users have an implicit agreement that they’ll complete their end of the handshake when the time comes.

Finding Bugs

When referring to software bugs, the term can be really subjective.

After all, if it works for one person and not the other, is it really a bug? I dunno. Maybe.

The thing is, there are so many environmental variables that contribute to whether or not a given piece of software will work for each and every user, it’s hard to say if it’s a problem with the system, if it’s a problem with the software, or if it’s a problem with both.

To that end, I think that users have the responsibility to be as clear as possible when reporting issues that they experience when working with a project.

Can you help me with this bug?
Can you help me with this bug?

Sure, it’s easy to get frustrated when something we’ve downloaded doesn’t work, but all things considered, this is something that we’ve downloaded and installed for free that a someone created using their free time.

We didn’t pay anything. If anything, they did.

So maybe we can do a better job of keeping up our end by recognizing the fact that it’s not the end of the Internet if a free piece of software doesn’t work by providing the clearest set of recreation steps possible – including as much information about our setup – so the developer can try to fix the issue.

Saying that “It’s broken,” isn’t productive and is rarely – if ever – worth the time it takes to write the words and click “publish.”

Feature Requests

As users of open source, it’s really easy to get enamored with a piece of software especially if it’s something that becomes a part of our daily lives.

I think that the usual cycle works something like:

  • Hey, I’m going to try this out,
  • Man, this is really great,
  • What did I do before this software existed?
  • Wait, why doesn’t it do this?
  • Okay, I’ll just tell the contributors to incorporate it in the next iteration.

Sure, I’m being a bit facetious, but the point still remains: We use free software and love it until it doesn’t do something that we want. And when it doesn’t do that, we get irritated.

We want it fixed, and we want it fixed now. This piece of Acme Software is going good work in this one area, but if it was merged with another piece of good software, then we’d have the perfect solution for everything.

Except we wouldn’t.

Software is going to have problems. Always. It’s created by imperfect people and imperfect people aren’t capable of created anything more perfect than they are.

Sure, it can be robust. Sure, it can be efficient. But it’s not bug free. And, because of the nature of software architecture, bugs will beget bugs.

So why would taking two imperfect systems that already have their fair share of issues and combining them together make something easier to use?

Is this a good idea?

On top of that, one of the things that I firmly believe is that software should be tightly focused – it should seek to solve a common problem. And yes, individual features should solve smaller problems that are part of the same problem domain, but there’s no reason why we need to expect an application of one type to solve the issues of something out of its context.

We tried to do this with sporks, right? And look what we ended up with: A leaky spoon, and a short fork.

As such, not all feature ideas are good ideas. Discussing them is fine, but accepting the fact that the people driving the project may reject it comes with the territory of using free software.

You have the right to suggest something and provide reasons why you believe it should work. Contributors have the right to pushback against it.

But here’s something that closed source does not offer: We have the ability to find other people who can take the given project, fork it, and then create our own version of the code that solves whatever needs we want.

But Think of the Contributors!

Yeah. The contributors have the ability to incorporate feature requests or to address issues as they arise, so why won’t they?

Just as it’s your right to suggest features, report potential bugs, and so on, it’s also their right to maintain the vision of the product. It’s not meant to be an offensive on the users – instead, it’s meant to make sure a product maintains its purpose.

So, as users, we have to be mindful of our position as it relates not only to the contributors, but to the software itself.

We ask for support, report issues, and suggest features – and we do so generally because we’re trying to help others (but let’s be frank, there are those users who are rude – period) build better projects.

But our ideas may not always jive with the vision of the project. To that end, the best we can do is continue to offer feedback, hope that it’s incorporated, and if not, then use another product, or find someone else to create someone tailored to our needs.

6 Replies to “On Open Source Entitlements: Users”

  1. Two quick points:
    1. Developers should provide as much documentation as possible. It does reduce support demands. People do read documentation.
    2. Developers should appreciate bug reports because this is one means to improving the code and also reducing support costs.

    1. I absolutely agree.

      Simply dropping software out there without instructions or frequently asked questions on how to use the product is not a good way to go about releasing work.

      As far as bug reports are concerned, I don’t know of any developer – at least, personally – who doesn’t appreciate them. The only thing about a bug reports that have a negative stigma is when people just say “It’s broken,” or “It doesn’t work,” or something that’s not really descriptive on how to reproduce the issue.

  2. I think the “broken” phrase is OK if the plugin hasn’t been updated in a while and there are a number of unanswered postings over a period of time. This can save other users lots of time.

    But most of the issues I see are poorly phrased questions or problems outside the scope of the particular plugin.

    I don’t think it’s a good idea for developers to offer paid only support either. W3 Cache gives me that impression. It is a mass-marketed plugin with very tailored requirements. I feel like there is an attempt to intimidate me with over the top techno-jargon.

    1. I think the “broken” phrase is OK if the plugin hasn’t been updated in a while and there are a number of unanswered postings over a period of time. This can save other users lots of time.

      Agreed – everything I’ve written is base don the premise of software that’s being actively developed and/or maintained :).

      But most of the issues I see are poorly phrased questions or problems outside the scope of the particular plugin.

      Yeah, and this can be a hard problem to solve because you don’t want to be rude to customers, or to turn them away, and most of us want to genuinely help them, but there is a narrow focus to be maintained.

      I can help with my plugin, you know, but I can’t necessarily help tweak some general WordPress setting.

      At least, that’s not within the agreement when a transaction is made for a plugin.

      I don’t think it’s a good idea for developers to offer paid only support either. W3 Cache gives me that impression. It is a mass-marketed plugin with very tailored requirements. I feel like there is an attempt to intimidate me with over the top techno-jargon.

      We disagree a little here, but – to be clear – I’m curious as to why paid support only a problem? Is it because some plugins – like the one you mentioned – attempt to be so convoluted it’s a lure into paid support?

      If that’s the case, then we agree; however, assuming that jargon is not used (which it should not be), and assume there is healthy documentation and FAQ’s, then I think is reasonable to ask others to pay for support.

      1. Sorry, I wasn’t quite clear. Perhaps “only paid support” would have been better.
        Regardless, my point was as you speculated – luring users.

        I use several code only plugins. These are too difficult for many users to figure out, but the developers are generally straight forward about this. But, judging from the support questions usually posted, the modus operandi is understood and respected.
        But plugins like W3C and Yoast are bloated (at least visually) and some features are surely confusing to everyone. One gets the feeling that in order to use these seriously, they’ll need to spend $$.

        1. But plugins like W3C and Yoast are bloated (at least visually) and some features are surely confusing to everyone. One gets the feeling that in order to use these seriously, they’ll need to spend $$.

          I think that’s the case for some of them, for sure.

          IMHO, W3C could use some work on the user experience end. Yoast’s is fair, but it’s also free and I think the descriptions could be worse.

          That said, I also have to remind myself that developers who build software often think in terms of, y’know, developers. As such, they (or we? trying not to be ‘we’ ;)) end up using a lot of jargon and devspeak throughout the UI that ends up making it so frustrating for the user.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.