Spending nearly my entire working day (and many evenings) with Open Source projects I don’t maintain I have come to form an opinion or two on the use of OSS – specifically when it comes to contributing to projects.
We’ve come a long way as a community with tools like Github, making it easier and easier to get an OSS project out in the wild and accept contributions. As we’ve done this though, projects seem to support users with varying degrees of success. Some projects flourish, graciously accepting community contributions. Other projects do quite well accepting feedback but largely having maintainers drive the direction of the project. Still others fall to extremes of accepting every pull request that comes along with reckless abandon or apathetically allowing the project to rot and become another abandoned github relic.
Along with this more and more companies are building their businesses on OSS. Not just a piece here and there, but entire complex ecosystems of software maintained by all kinds of different folks. Each of these business have their own unique quirks, personalities, and constraints.
I’ve worked for a few of these businesses and I know that those constraints and those personalities, they aren’t easy for me to change. I have to work with what I have and try to find tools that do what I need. When I find a tool that’s 90% of what I need and I’m willing to put in the effort to push it across the line and make it work for me I get to come face to face with the maintainers of that project.
I’d like to say this always goes smoothly, that I’m always able to express my use case in a way that folks understand, and that my use case always falls inline with the intent of the project. I’d love if my skillset in a particular language was always up to par, and that my ability to write quality tests was always appropriate. I’d love to always understand the roadmap for the project & the maintainers expectations around how I should contribute. This just aint so.
As much as I may feel like I don’t understand a particular project well enough, sometimes it feels like the maintainers don’t understand me. What’s worse is when I interpret (accurately or not) an attitude from maintainers that I “just don’t get it” rather than making an attempt to help me understand.
This sounds really familiar to me. This sounds like that whole observation the world made that Dev & Ops need to work more closely. The observation that the people who build the software need to interact more closely with the people who use the software. That building empathy and a collaborative environment where everyone can communicate and be involved will help get us past our differences. For me, this problem isn’t just with the developers in my company. This problem extends to the developers who build the systems I use every day and most of those developers don’t work for my company.
Just as we have to invest in building relationships within a company, when you use OSS you have to invest in building a relationship with those you work with outside your company as well. This goes both ways, and the more effort maintainers put into understanding users, the better this is for everyone. This isn’t easy – so if you aren’t a maintainer and you’re reading this, understand that very often the interactions you have with maintainers is done outside their full time job, outside their ordinary deadlines and pressures, and it’s done because they enjoy working on a project. If folks are like me, when something stops being enjoyable for too long, I stop doing it. Keep them in mind when you have a complaint.
Further, for a popular project the ratio of users to maintainers is pretty imbalanced and not in the favor of the maintainers. They have a hard job and for those that do that job with grace and empathy for their users, my hat is off to you.
So when we talk about DevOps and Empathy and all these great ideas to make your company work better – don’t stop there. Think about all those projects that make your job exist, and all those users that make your project a success. Try to take a little time and understand each other and work together to make more awesome.
| Reference: | Empathy in OSS – It’s Important from our JCG partner Aaron Nichols at the Operation Bootstrap blog. |
