
My first proper encounter with the open-source debate happened during my very first job interview.
It was a take-home assignment. I had to build something within a limited amount of time and, somewhere along the way, I needed encryption. So I used an open-source library.
During the code walkthrough, I brought it up apologetically. Given more time, I said, I would have preferred to build something of my own rather than depend on an open-source library. Because, you know. Open source.
Anyone could see the code. Anyone could look for weaknesses in it. Code is wide open to invite attackers. Something we built and controlled ourselves would be safer. I expected that to be a fairly uncontroversial statement.
Instead, I realised I had walked right into an ongoing debate on whether to use open source or not. My two interviewers had varying points of view in this matter. Like me, one of them was cautious about using open source solutions. The other was supportive of using something that many people had eyes on.
While it was a memorable interview experience and my first actual tech discussion, I remember realising that something I had assumed had an obvious answer apparently did not.
If everyone can see it, isn’t that a problem?
To me, this was intuitive. If fewer people know what is behind it, fewer people know where the weaknesses are.
Except, keeping the code behind closed doors doesn’t necessarily make it secure. Nor does opening it automatically make it vulnerable.
While open source exposes code to potential attackers, it also exposes that same code to developers, researchers and users who can inspect it, question it, find vulnerabilities and improve it. More eyes looking at it, as my senior had said during that interview.
So perhaps visibility itself is not the thing that determines whether software can be trusted.
Long before I knew what open source was…
Actually, my first experience with the idea of making something freely available to others came long before that interview.
Project Gutenberg.

I used to spend a lot of time there, discovering classic literature. Thousands of books, freely available to anyone who wanted to read them. I didn’t have to own every book I wanted to read. I could simply pick one up and explore an unfamiliar subject or know a new author.
Back then, I wasn’t thinking about the people who had digitised those books or the effort that went into making them available. I was simply enjoying the access.
Project Gutenberg isn’t an open-source software project. It is a digital library built largely around works in the public domain. But looking back, I see something familiar in the philosophy behind it.
Someone had taken something valuable and made it accessible for others to benefit from.
And that is precisely what I had benefited from during my take-home assignment, too. I didn’t have to build every component of my solution from scratch. Someone else had already done part of the work, and I could build upon it.
Perhaps that is something we take for granted as developers. We use libraries, frameworks and tools that other people have built. We solve problems by building upon solutions that already exist. And because we don’t have to start from scratch every time, we get to spend our time building something else. And not re-invent the wheel. We could be building something that might not have been possible otherwise.
From using to contributing..
There is another side to this that I hadn’t thought about before.
Every time we use an open-source library, we benefit from work someone else has already done. But the work doesn’t need to stop with the person who began it.
Someone finds a bug and fixes it. Someone improves the documentation. Someone adds a feature they needed. Another person takes that improved product and builds something new with it.
Beauty of this is making something a little better for the next person who comes along. We don’t have to be the ones who started something to be a part of the project. We can join something already in progress, bring what we know, learn what we don’t, and leave it a little better than we found it.
This time, on the other side..
This October, Women Devs Singapore is organising a Community Coding Month, encouraging developers and women-in-tech to contribute to our GitHub repositories.

And I think it’s a great opportunity to experience open source from the other side. You don’t even have to come up with an original idea. You could make use of what others from WDS have already shared for the benefit of others. You could fix a bug, improve a feature, add a small capability or write a test.
Perhaps you’ll learn something along the way. Perhaps someone else will benefit from what you’ve done.
I think back to that first job interview, when I felt the need to apologise for using someone else’s code. I had seen open source as something I was taking a risk by using. But I’ve learnt there is so much more to it than that.
Someone else’s work gave me a starting point. It allowed me to focus on what I was trying to build, rather than having to solve every problem along the way.
And now, perhaps, I can be part of creating that starting point for someone else. That’s what I hope more of us will get to experience this October.
Happy Community Coding Month!
Stay connected with Sugirdha on LinkedIn
