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.