I read recently Shubheksha‘s blog post “A Beginner’s Very Bumpy Journey Through The World of Open Source” which describes her initial journeys into the open source world and reminded me a bit of some of my initial adventures into open source. (I even wrote a blog post ages ago — my goodness, literally ages ago it seems! — about my findings on dealing with open source projects on SourceForge (do you remember, that used to be the thing back in the day?) here.

The thing is, there are a lot of organizations out there which make it really hard to join their open source projects. Their argument is that by setting the bar really high the quality of the external involvement they get gets high too. There is probably a bit of truth in that, but I think that what they gain on that side they lose totally in adoption. I think i speak for a lot of developers here who know that not all software is perfect, and as such what is important when an issue is found is the level of support and help you get from the maintainers. Someone who gets involved with you right away (even if they just end up adding the issue found on their roadmap for the next release) will command our patience and understanding, it’s just basic psychology.

On the other hand if you get a lot of attitude, you are very likely to drop that framework right away and go a different route (let’s bear in mind that nowadays there is more than one way of doing the same things and there are tons of frameworks out there).

And this is how you drive adoption — and with adoption you get invariably an increase in help with your open source projects; that can mean anything from an increase in number of pull requests to your Github repo to even more donations (if you support project donations).

I had pull requests rejected in some of the Apache Software Foundations projects with a simple comment just shouting saying:

TABS, NOT SPACES? NO, THANK YOU!

Others got rejected because the project was running Checkstyle as part of the build and generating the report but not failing the build on these — however, the project maintainers were actively checking these on each commit they received and where rejecting them if Checkstyle signalled any issues. That is actually a fair practice, except for 2 small details which got me to abandon that work right there and then:

1. there was no mention of anything of the kind anywhere in their project doccos, so unless you worked on the project before you wouldn’t know to look for these reports and check manually for issues (and fix them of course!)
2. (maybe even more important) the rejection of the pull request was actually pretty mean and included comments about my incapacity to produce useful code

Needless to say that I dropped all the work on that project and moved on. It was in other Apache projects that I came across Simo who proved to be a joy to work with and assisted me through how to send contributions to those projects. And as such, my contributions kept going for a while!

Here is the thing that I found in time to help though with open source: if you are looking to get involved, find some of the projects you are already using in your own projects. Because if you use them already you might have a mental image of how they might work internally — as well and just as important as you might already have in mind a few “niceties” that you would like to see in those projects (so you can use them into your projects)!

Start with those, file an issue in Github, or start a discussion on Slack with the team and see what they feel about it. You will have a better starting point this way. If you feel that the project maintainers are giving you attitude then stop right away — and drop that framework from your project because quite likely it won’t actually make it far due to that attitude. It might have enough momentum to carry another 1-2 versions but in most cases it will crash and burn due to that behaviour.

I found myself for instance taking this approach and submitting pull requests nowadays for Node.js modules, WordPress plugins and themes written in PHP, Groovy and Java code and all of this because I have used one of those modules and wanted some improvements from them.

I am involved nowadays with some of the projects in the Netflix OSS stack and one thing that I have learned and seen applied in Netflix is that we ought to strive to eliminate any friction for a user to join our efforts with our projects — to the point where we relax coding conventions for instance and a whole bunch of other things: let the user work the way he or she is comfortable, because that way they will be more productive in helping you with the project! If someone asks a question that is not an annoyance, no it means that holy cow someone actually checked out your code and wants to understand it — that is a good thing!

You learn all of these in time — though sadly, as I have learned (and it seems so did Shubheksha) a lot of projects out there who still interpret “open source” as “software written by me, me, me for the world but it’s all me cause y’all is dumb”. Sad, but you just learn and move on.