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

One of the challenges that comes with working with and using open source is the danger for it breed a sense of entitlement.

For the most part, I don’t think those get who involved in open source software aim to become entitled – after all, building open source projects is a labor of love, right?

We spend our time that could be spent doing other things volunteering to work on something that we’re passionate about, and that we believe will help to make the world (or at least a few people’s lives) a bit better.

But the underbelly of this is that people who find themselves involved in open source either as contributors or as users end up acting entitled from time-to-time.

Entitlement Defined

This is a word that used a lot – perhaps even overused – to describe the millennial generation (at least here in the United States). In fact, I’d venture to say that the word has been used so much that some people use it without really even knowing the actual definition of it.

Most likely, conventional wisdom would define entitlement as a person or people acting as if they deserve something that they do not.

Can't spell entitlement!

But 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 For Contributors

Because I want to be clear that this behavior is exhibited on both sides of the fence, it’s worth mentioning that contributors – not just users – have the propensity to act this way, as well.

Case in point: There are plenty of times in the course of open source development where contributors become so impassioned about a particular feature that they’ll develop a perspective that’s so narrow that they end up ignoring any opportunity for conversation about a feature and view it as some type of attack of their position.

But when you are a contributor and it’s something that you do feel deeply about, it’s hard not to do that; however, I think it’s important for a person to know their role in the overall context of the project before going too far in one direction.

Project Ownership

If you’re a project owner, then I believe that you have the right to set the scope of the project on which you’re working.

I’m not saying that I think it’s a good idea to ignore other people’s input; however, if it’s your project and you have a very specific vision for it, then it’s your prerogative to drive the project in that particular direction.

It’s okay to say no, obviously, but I don’t think it’s okay to rudely dismiss someone’s attempt to offer suggestions to improve your work simply because you reject the idea. There’s graceful ways to handle this.

Your request? No.

Your request? No.

If you’re not going to accept it, at least explain why.

Feature Ownership

But can the same thing be said about features?

For example, let’s say that you’re contributing to an open source project and there’s someone who is serving as a project lead over a particular feature. You, along with another group of people, have volunteered your time to work on the tickets associated with said feature.

The project lead is responsible for making sure that those particular features, y’know, get completed and thus, I believe, has a responsibility to remove any obstructions that may prevent that from happening.

But you’re a contributor, right? You have opinions! They’re better than what the project lead is suggesting, so why be ignored, right?!


If you’re a contributor, you have to at least concede the point that you may not be the one in charge of driving a particular feature or set of features home. Though you may be owning a particular ticket or set of tickets, you’re not responsible for the overall piece of the application to which you’re contributing.

And although you have good ideas, and you have the right the voice those ideas, you also have to accept that those who are the leads may reject the idea. Perhaps it’s permanently, perhaps it’s just for this cycle.

I am a good idea.

Whatever the case may be, I think that we – as contributors – need to be very careful not to displace our passion on the features that we’re working as it relates to the overall project.

If we spend too much time arguing about how something should be done rather than actually doing something, then there’s a chance nothing will get done.

Remember: We’re dealing with software. It’s very nature means that it’s amenable to change. So just because something may not make it to a given release doesn’t mean that it’s potential for inclusion is being shutdown.

Perhaps it’s just being postponed.

But Think of the Users!

Oh, I know.

The thing is, most open source contributors are users of the very same application to which their contributing. On top of that, many of them are building things on top of the product to which they’re contributing.

To that end, contributors also know what it’s like to manage users expectations, issues, requests, and so on.

But contributors aren’t the only ones who can develop a sense of entitlement either. Users have the same disposition – it just looks a bit different.