Blog post: Release of Crypt::OpenSSL::X509 1.8.9

I have just released Crypt::OpenSSL::X509 1.8.9. Do note that this is not originally my distribution, but I have helped the author Dan Sully out a little since I am a user of his Crypt::OpenSSL::PKCS12 and Crypt::OpenSSL::X509 and I have an interest in the distributions continued existence, availability and functionality.

So this blog post is more a description of the proces of getting involved, using my involvement in Crypt::OpenSSL::X509 and it’s cousin Crypt::OpenSSL::X509 as examples.

I started out by making a few PRs for some issues we were experiencing, I slowly got involved as Dan not really maintaining the distributions so actively, not doing Perl and working on other stuff – all completely acceptable reasons. Dan started with giving me co-maintainership on PAUSE/CPAN, so I could upload releases. First release I made was simply from a fork, merging a PR post-release, not the best strategy, but it worked out.

Now I have commit privileges on both repositories and on PAUSE/CPAN I have co-maintainership so I can both implement and upload releases. Given this privilege is most certainly daunting and I am faced with a number of questions, some are easy to answer some are more difficult, some will not be answers at this time – anyway questions pop-up in your head:

1. How much can I change?
   • Style?
   • Toolchain?
   • Functionality?
2. Should I fix all the issues?
3. Do I understand all aspects of the implementation?
4. What if I cannot contribute?

Many answers will present themselves as you start to get more and more familiar with the project in question and other parts, over time, as you get more and more hands on. Currently I consider myself an apprentice in this context, everything is new, confusing and you are afraid to break something.

Modern software development is very forgiving, we have:

– version control and branching strategies

– continuous integration and unit-test suites

– collaboration platforms and open source

– and of course Google and StackOverflow

So it is very easy to get back to the original state, get feedback from either humans or machines or get help or find examples, which resemble what you are trying to accomplish.

Some of the PRs I had created enabled Travis integration for continuous integration, this was a contribution I could make without influencing the actual code – and easy one so to speak. Other PRs addressed issues the build tools. Both distributions are based on Module::Install, where all of my own distributions are based on Dist::Zilla, but for now it seems like at good idea to stick with what is already working, no need to change stuff just for the sake of change.

For coding style, I think it is a good idea to stick to the existing coding style of the project. When and if the project evolve even further, perhaps even on boarding more contributors or if PRs are getting difficult to review or understand it will perhaps be time to document a coding style or enforce a coding style.

Which brings me to the next point. Both Crypt::OpenSSL::X509 and Crypt::OpenSSL::PKCS12 are Perl implementations on top of a C-based library. For me this is a marvellous change to get to read some C-code, when reviewing PRs or familiarising myself with the project codebase.

Familiarising yourself with the existing codebase, can be also be accomplished by triaging bugs, the current bug count for the two project looks as follows;

– GitHub: Crypt::OpenSSL::X509 (17 issues)

– GitHub: Crypt::OpenSSL::PKCS12 (2 issues)

So there should be something to get me started.

In my opinion you do not have to fix all bugs, but it is a good way to dig in and learn a lot. Do not be hesitant to contact the bug reporter if you have questions, they might be long time users and have extensive knowledge of the projects inner workings. The same goes for contributors, which might even know even more since they have actually made a change and are requesting a merge.

What got me to release Crypt::OpenSSL::X509 1.8.9 was actually a PR, which I reviewed, it was in part of the code where I have proposed changes myself, so I would say I had an understanding of what was going on. The change however targeted an operating system, with which I am not familiar – so I wrote the contributor and asked, when there was something that was not clear to be. I got a marvellous response, point to some good documentation, so I learned something and I could complete my review.

Another strategy you can apply, or get anxious to start hacking away, is to add tests. Check the test coverage and implement more tests in the weak spots, that is also a good way to get into the functionality and composition of the project.

My advice is to just get started, review, read, code, learn, test… I do consider all that apprentice level, when you make your first release with a feature of your own or by request of some other, you are no longer an apprentice – you are a true contributor – and that is worth aiming for.

Good luck with your endeavours, there are plenty of projects to contribute to and there is nothing wrong with being an apprentice, all masters were apprentices once.