What I Learned Working in Opensource

Three months ago I made a swift and interesting turn in my career: I officially became an Opensource developer. That was an impromptu decicion: I saw an internal job ads at my company, and decided to see what it’s like, didn’t even expect that I would get the job. Fast-forward until today, I’m glad I made that change, not that I didn’t like my old job (I loved it), but because working as an opensource developer has helped me learning valuable lessons that I don’t think I would have learned otherwise.

1. Clear communication really feels good

While communication is important everywhere, and certainly you need to communicate with your co-workers all the time if you’re a dev working in any kind of projects, communication in Opensource community is much more important. Users and contributers of projects come from different backgrounds, with wide ranges of ages, cultures, experience, skills, etc., hence almost everything needs to be stated as clear and concise as one possible can.

In fact, clear and concise communication is a good practice for any team working in any project, but sadly in a slow-change environment we can sometimes play fast-and-loose with it since majority of people have similar backgrounds and can understand one another well enough. I’m not saying that it’s always a bad thing, but that kind of implicit communication and lack of documentation can make onboarding a nightmare and discouragement for developers with less experience.

It’s no surprise that communicating in this manner requires great efforts from you as developers, but a lot of people will be thanking you (maybe unknowingly) for what you do when they read and understand clearly what you want to say. And I’d argue that giving endeavor in choosing your words wisely will also help you to be a better developer in the long run. After all, what’s the point of communicating if it’s not for others to understand?

If you are new to a project and/or to the whole ecosystem, the good communication in opensource projects help you get on track faster. I know it since I’m experiencing it myself: almost every project has easy-to-read and up-to-date documentation, even books, blog posts and tutorials for newbies to get started with; coding style generally follows industry standards, and the list of FAQs are so complete that it can be a challenge to come up with a question that hasn’t been answered. Another nice thing is that almost everything is written down, which leads me to my second point.

2. It’s easier to improve yourself

As somebody with no IT education background, it’s not uncommon for me to be absolutely clueless on some simple technical details that everybody else seemingly understands. When that issue happens during a discussion, I’d have to choose to either jump in and ask, or to just nod along. As embarassed as I am, I have not always choose to ask: for one thing, I’m shy to disrupt someone else, and most importantly, it’s unlikely that I would understand something right away after one or two sentences. For that reason, I’ve always thought, and sometimes I said it out loud, that technical details should be written down or recorded at all time. Wouldn’t it be great to have record so that I can have a short look to be reminded about what I forgot (and what I forgot to investigate)?.

Sadly having everything on records were kind of an expensive practice: writing down the meeting notes take times, efforts and requires great understanding of the problems at hands, which I oftenly lack of. I’ve tried several times to jot down what people say in a discussion, but it turned out to be very difficult. Meanwhile, video meeting records’ permission are not always a breeze to manage, which makes recording certainly not an option when it comes to meetings with secretive information. (To be fair, even if the meetings were all on records, I wouldn’t have time to re-watch them all, just like I wouldn’t have time to re-read the whole meeting minute; the difference is that there’s not a good way to “search” for some minor piece of information in a video).

In my previous team, we once had applied the silent meeting practice, in which we operated all discussions in the written form, and personally I think it was great. Sadly that stopped at some point (I still don’t know what made it stop) and we got back to verbal discussions where details are spread everywhere, but never came down to written.

Working in opensource projects, therefore, has been a nice experience. No more losing tracks from the ongoing discussion after missing some few key technical terms, with expressive documentation and written communication, it’s now easy to just google whatever term you don’t understand. And with all information designed to be consumed independently, it’s finally easy to onboard yourself with whatever new to you.

3. It’s soooo free

Working in opensource also means freedom; mostly due to the fact that most of the code you write are or will be public anyway, so it’s unlikely that somebody hack into your computer to steal any intellectual property. It means freedom to choose whatever tools and services in your day2day work, and no more extensive layers of authentication and authorization you have to get through every morning before being able to work; it means you can choose any location and time to get the job done, without much caring about security requirements (is the hotel’s wifi secured enough?)

Also, as everything is in industry standards, you’re not, by any means, forced to use a tool stack because that’s the only one offered by your company. “The sky is the limit, feel free to pick what you like” is kinda the motto I go with since I made the change (I certainly don’t miss Windows). It’s also a good thing to finally be able to discuss what I do to anyone who wants to know, and the presentation is generally starts with “It’s on the internet and opensourced, you can see it yourself”

Some ending words

Tbh I don’t have many words to conclude this post. I planned to write a much longer post about how great I feel about working in Opensource world, but in the end it just came down to the three points that I’ve mentioned. Short, it was, but for me those points were critical: just the availability of having documentation for almost everything has helped me learning at a faster rate than I’ve ever been, and I’m thankful for that. I’ve gained so much knowledge, which I’d love to share with you in the future.

Anw, does the fact that I praise so highly about working in Opensource mean I think it only has up sides comparing to working in traditional firm? Well, no, but so far I’ve been enjoying all the differences as I’ve just started to experience them. Who knows, maybe I’d change my mind later on?

One thing for sure: this new position has openned my eyes about the importance of great communication in technology development. It’s something I’ve known for long that I need to improve, but only now realized that I need to improve it now, given how essential effective communication is in Opensource development. Communication skills will be hard to achieve, especially for some shy dude like me, but will surely come handy later on in my life and career.