I first "discovered" Umbraco back in 2005. I've used it to build countless sites, in a multitude of industries. I've used it for simple campaign sites, and really complex application projects. I've found bugs. I've written workarounds. I've suggested improvements. I've bitched about bugs. I've implemented things horribly wrong. I've attended Codegarden (10 times!). I've written a code-first solution for Umbraco (not a joke, it's called UmbraCodeFirst, don't use it). I've stood on stage (scared shitless). I’ve attended training. I’ve bitched some more about bugs. I've attended CodeCabin (you should too!). I've guided other developers. I've organized meetups. I've co-founded a user group. But it took me nearly twelve years to start contributing code.

The reasons are many. In the beginning it was probably because of logistics, it was almost like a closed-source, open-source, project. Contributing was hard. Or at least, the perception of contributing, was hard. Being a "core team developer" was, at least for me, seen as something unattainable. Only the really, really, smart people could do it. I surely wasn't smart enough. When things changed to become more accessible, I had developed an unhealthy attitude of thinking everyone already knew what I knew.

"You must do the things you think you cannot do" — Eleanor Roosevelt

I don't know if this is an example of what is commonly known as "the impostor syndrome", but let me just say this; Trying, and failing, is a far better learning experience, than never trying at all.

"It is not fair to ask of others what you are not willing to do yourself" — Eleanor Roosevelt

When clients and colleagues ask me about what the benefits of open-source vs. closed-source are, I've always said something along the lines of "If you find a problem with an open-source project, you can submit a fix. But if you find an issue with closed-source, you can report it, but then you are left to the vendor's priorities and processes, with no real way of affecting it." I've said this for quite a few years, yet I never really did anything about it. There was always some excuse keeping me from submitting a fix, I didn't have time, it looked too hard, or I didn't know where to start. I had no problems with adding workarounds in my own code, code that could break at the next update, in addition to being an additional moving part that I would need to support. I don't know what changed. Maybe it was me becoming fed up with being a hypocrite. Maybe it was adopting a pull-request/code-review process for every change being made to our projects. Maybe it was the impending doom of mid-life crisis hanging over me, forcing me to step out of my comfort zone. It doesn't matter why I did it, I did it. I changed.

When you find and identify a bug, at that given moment, you are probably the most knowledgeable person in the world, about what the problem is, and why it has happened. Right then, no one is better suited to fixing it, than you. Reporting an issue is certainly good, but you are in the best position of fixing it too. Your PR, even if it isn't perfect, provides a far better starting point for a fix, than an issue, and a rant on Twitter. The last thing we need on Twitter in the Umbraco space, are more rants. There's that guy living his dream of endless summer doing enough of that to go around. Fixing bugs, however, isn't the only way to contribute. Not a developer? Translations and documentation always needs work. Got an idea? Feature requests, with clear and precise details about what you want, why you want it, and the benefits of that feature. Just consider if your feature request is something needed int he core, or if it's a package. If it's a package, your feature request might be something that you need for that package, a missing API. Contributing isn't only about code.

The first step is setting things up, there's a guide for it. The guide will tell you everything you need to know in order for your contribution to be able to be incorporated into the core as smoothly as possible. There are, however, a few things the guide won't help you with.

"No one can make you feel inferior without your consent" — Eleanor Roosevelt

The guide won't help you with self-censoring. Only you can do that. Go to the issue tracker and select something you think you can do. Start small. Once you've seen the source code of Umbraco, you'll see that whatever you do, Niels did it uglier, and with far more spelling mistakes, than you possibly can. No one knows what a usercontrolgrapper is. Your code is fine. On the off chance your code isn't flawless, Umbraco isn't coined "the world's friendliest CMS" for nothing. You won’t be ridiculed. You'll be corrected, and guided, and honored.

The guide won't help you with patience. Yes, your PR will probably sit there for a while. Yes, other PRs will be merged before yours, even if they were made later. It doesn't matter that it was tagged as "Up for Grabs", that doesn't mean it will get merged straight away. It might not even get merged at all. That's the nature of open-source. It doesn't have anything to do with you. There is probably a good reason your PR isn't merged. Let it go. Or try to assert pressure on the people being gatekeepers. I have made five PRs to date. Three of those are still open, it's been months. It doesn't matter, I've done my part. Managing a large open-source project is hard. I have a few small ones, and those are hard to manage. Just imagine the amount of work needed for projects that people actually use.

The guide won't help you with the always ongoing debate regarding tabs vs. spaces. It says to use spaces, which we all know is wrong. Again, you can't make the codebase any worse than it already is.

OK, so you've gotten past your fear of not being good enough. You've set everything up, and you've done that small ice-breaker-PR that got you going. You've wrecked your local dev environment just so that you'll comply with those blatantly wrong whitespace rules. You're ready to tackle something big, something that'll make an impact. You need help, a rubber duck, someone to bounce ideas off of. Use the community! There are others like you, and they are waiting just around the corner. Chances are there's a local meetup group, or a not-so-local meetup group that will think you are awesome for making the trip. And then there's the community slack. The point is, you are not alone.

So far this has only been about contributions to the Umbraco project, but that friendliness stretches further than that. Most package developers will gladly accept contributions.

Earlier this year I contributed to Matt Brailsford's Fluidity project. It was a humbling experience, but I think I learned more about Umbraco in a few hours, than I did in the previous five years. Picking through code to try and see what's going on is almost like being on an episode of CSI. Matt also uses spaces, so obviously Fluidity won't help you with generating a UI for your custom data. Apart from that little insurmountable flaw, looking at code from a skilled developer is, in my experience, the second best way to learn. The best way to learn, is to break said code by contributing to it.

Take the time this holiday season to start contributing; Be it a killer feature, or fixing a UI spelling mistake. Make mistakes. Break things. Then fix them.

"What you don’t do can be a destructive force" — Eleanor Roosevelt

Protip: Use the "ignore whitespace" option in git when reviewing code, and your days of merriment will be a plenty.

If you're wondering about what's with all the gratuitous quotes from Eleanor Roosevelt, they are here because she was great at oneliners, she was smart, a rebel, and we share the same birthday. Mostly because of the birthday thing though.