Ordered list of blogs will go here with a widget
There is one question that seems to be quite common, both in the numerous conference talks and from the budding engineering community, and that is how does one get started in Open Source software? Through my various contributions over the years, it is one that I haven't really given much thought to until my most recent contributions to the Debezium project.
In a sense, most of my contributions to date have been as a gun for hire. The freelancer who had a client that was looking for a specific modification they wanted out of the software, or it was as an academic or corporate funded project. In those cases, the on-boarding was provided by others in the community that had the tight relationship with the maintainers of the community which made things much easier. They were also fairly large projects that would have their own dedicated governing board, and some also had conferences dedicated to them.
What made the Debezium experience different is that, while the work was originally
chartered as an open-source contribution, I took it upon myself to ensure the
contribution made it back upstream without the prior relationships. There were
quite a few realizations. The first is that it is far easier to get a handle
on how projects work then in the early days before places like Github existed. They have CONTRIBUTION guides in the repo, and sites Github makes it see what the
outstanding issues are. Granted Sourceforge was around first, and it did offer
quite a bit from a project management standpoint, but was also clunky to use.
The biggest realization, is that open-source projects, contrary to popular belief, is very much a social club. For introverts, the very shy, or those who don't like interacting with others, this is perhaps the biggest challenge to overcome. The meetups and conference talks on how to get started usually imply an initial interest in the project, but also an expectation that the attendee has been following the project closely enough to know when the conference is, or has the means to attend. Of course, this also implies they aren't intimidated by the other topics or the people present.
Even without the conference, there's some kind of discussion group that exists as well, whether it is slack, discord, irc, usenet, or even email.
For the rest of you, or as Scott Hanselman calls, the unseen 99%, I'm hoping my experience will help shake some of the fear or concerns of contributing to an open-source project. As I mentioned earlier, things have become much easier with a documented README/CONTRIBUTING guide being standard with open-source projects to facilitate contributing. This not only includes instructions on how to build and test the code-base, but also how to report issues and how to contribute back to the main project. This information has helped when it comes to how to submit a pull request to the Debezium project.
The one thing that is not normally covered in the talks and presentations is that patience is also required. The maintainers that normally keep an eye on the project also act as mentors and are willing to help through most stumbling blocks along the way. While encouraging, the process can take a while. In my case, from the initial submission, it took close to three months, but the change did ultimately get accepted. Bear in mind, while that may seem like a long time, the exchange happened about once a week. However this was a slightly complex contribution. For the most simplest, they tend to be much shorter. So don't get discouraged.
There are quite a few projects that have their conversations via Slack, Discord, or irc. In the case of Debezium, they use a project called Zulip. I did reach out to them, but as an unfamiliar platform, my initial question got lost and there was no response. Don't get discouraged by this. Just try again.
Perhaps the biggest lesson and the best way to get involved is to start small and contribute something. Doesn't matter if it is a documentation fix, or a bug fix (which was my first other contribution to Debezium, and took much lest time to get through). In my case it was something I ran into during my client work, but it could be something else you have noticed. Or an issue that you see on their Github issue board. In any case the best way to get started is that initial pull request.
Just remember, once you start, you cannot stop, and with more contributions comes greater responsibility.