Hi everyone! 
’m a 2024 graduate from PES University, currently working at Deutsche Bank. While I initially wanted to participate in GSoC during college, I never found the time—college life was simply too much fun! However, once I started working and found some time on my hands, I decided to revisit GSoC and give it another shot this year.
I started by shortlisting organizations based on my comfort zone—Java. I explored a few orgs, but OpenMRS stood out. Not just because it uses Java, but because of its fantastic documentation and a community that felt more like a group of friends than a bunch of strangers on the internet. Everyone’s ready to help.
Being more of a behind-the-scenes type, I spent my first week just reading documentation—again and again. I didn’t want to ask anything I hadn’t tried to figure out myself first. Once I was comfortable, I started setting up the environment. Ran into a few hiccups, but the community helped me out patiently. Soon after, I found a good first issue and made my first PR in the OpenMRS Core repo. Huge thanks to @manojll for guiding me through that PR—it gave me the push I needed to keep going.
Over the next few months, I contributed as much as I could under the guidance of awesome folks like @jayasanka, @nethmi, @chibongho1, @bawanthathilan, and many more. The last month before proposal submission was intense—I focused on learning, gathering requirements, brainstorming ideas, and even implementing some features to better communicate my vision. One thing that really stood out: communication is key. Don’t hesitate to ask questions or get your proposal reviewed early and often—it makes a huge difference.
Something I wish I had done earlier: join the squad calls, coffee breaks, and other community meetings. You get to learn, share, and bond with others on a similar journey. I started attending them a bit late and definitely missed out.
One common mistake I made in the beginning was taking up too many issues at once. It’s always better to pick one issue, have a solution and PR ready, and then move to the next. Taking too many tickets without working on them makes it harder for others to find issues to contribute to. Also, unless you’re ready to raise a PR, try not to assign the issue to yourself. And if you don’t see any open issues, don’t hesitate to explore the application—try to find bugs on your own, confirm them with the community, and even create new JIRA tickets if needed.
Initially, I treated GSoC like a competition—I had to finish more, contribute faster, do better. But over time, I realized this isn’t a race; it’s a collaborative journey. Talking to other contributors, learning from their experiences, and helping each other out was so much more rewarding—and a lot more fun.
Lastly, remember that PRs aren’t everything. Reviewing others’ code, helping in discussions, or simply pointing someone in the right direction goes a long way—for them and for you. And when you have general questions, drop them in the relevant channels. More people will see it, more can help, and others might learn from your doubts too.
This journey has been nothing short of amazing. I’ve learned a lot, made new friends, and grown as a developer. Regardless of how the GSoC results go, I’ll continue contributing to OpenMRS—it’s one of the best communities I’ve come across, and there’s still so much to explore and learn.
