Fixing a Bug in ZERODHA's Code Base
Welcome to the second part of our Open Source Contribution series, where we delve into the world of Zerodha's code base. Make sure to check the "Takeaways"
1. Introduction
In this episode of ‘Open Source Contribution’, we are dealing with two things.
General Ettiquete to follow when trying to contribute to Open-Source.
I have made a few videos now and the general feedback from the maintainers is that a lot of pull requests are close-worthy (of not much importance)
I went through the code base of ZERODHA,
most of their code is closed-sourced, and rightfully so. The parts that are Open-Sourced are mostly in Python and GoLang, things that I don’t have experience in and how I tried to understand their codebase and tried to contribute.
2. Keep in Mind
Embrace the Learning Mindset: When starting your open source journey, it is crucial to approach it with a mindset focused on learning. Rather than rushing to contribute, take the time to understand why certain choices were made within the project. By immersing yourself in the codebase, you gain valuable insights into the project's inner workings and the reasoning behind specific design decisions. Treat the initial phase as an opportunity to expand your knowledge and deepen your understanding.
Setting the Foundation: Before diving into active contributions, invest effort in setting up the project environment and familiarizing yourself with the codebase. Gradually progress from understanding various parts of the project to solving documentation issues. This incremental approach allows you to gain confidence and build a solid foundation for future contributions.
Choose Your Issues Wisely: As a beginner, it is crucial to exercise caution when selecting issues to work on. Avoid picking problems that are beyond your current understanding or those that are excessively complex and created by the project maintainers. Instead, focus on existing issues raised by others. By solving these problems, you demonstrate your ability to collaborate effectively and work within the established project workflow.
Avoid Self-Created Issues: While it may be tempting to create your own issues to work on, it is generally not recommended for beginners. Maintainers prioritize existing issues, and self-created issues may not align with their immediate goals. It is best to work within the existing framework and contribute meaningfully to established tasks. This approach increases the chances of your contributions being valued and integrated into the project.
Quality Over Quantity: One common pitfall aspiring contributors encounter is the desire to make numerous pull requests in a short period. However, it is essential to prioritize quality over quantity. A single well-executed pull request that showcases your deep understanding of the codebase is more valuable than multiple superficial contributions. Focus on crafting meaningful and impactful solutions that align with the project's requirements.
Sharpen Your Skills: While open-source contributions can be a stepping stone to job opportunities, they should not be the sole focus of your development journey. Continuously work on honing your programming skills and strengthening your understanding of the fundamental concepts. Remember that sustainable success in the field requires a solid grasp of the core principles of software development.
Respect the Maintainers and Projects: When contributing to open-source projects, always maintain a humble and polite attitude. Understand that maintainers invest considerable time and effort in managing the project, and spammy or unnecessary contributions can create challenges for them. Instead, ensure that you genuinely comprehend the codebase before making any contributions. This approach fosters a positive relationship with the maintainers and reflects your professionalism.
3. Zerodha’s Codebase
As you can see from ZERODHA’s Github, the part which is open-sourced is mainly the SDKs.
Now what are SDKs ?
SDK
SDKs, or Software Development Kits, are sets of tools, libraries, and documentation that enable developers to build applications or interact with specific software systems or platforms. In the context of the given paragraph, SDKs refer to the collection of Python, JavaScript, Java, and Golang SDKs provided by Zerodha. These SDKs allow developers to connect to Zerodha's APIs, enabling the creation of custom front-ends that communicate with Zerodha's backend for tasks such as placing orders or retrieving financial data. The SDKs wrap the necessary API calls into convenient functions, making it easier for developers to integrate with Zerodha's services.
Since SDKs are just needed to create once and not much change is made on a day-to-day basis, these are fairly inactive (maybe used on a daily basis).
In the kiteconnect.js repo the issue Support for TypeScript seemed interesting, but a pr was already merged, went through other issues too but all seemed to be assigned.
But then I saw this
Moving on, I came across another interesting project related to Zerodha, but this one was not hosted on their official GitHub repository. It appeared to be a personal project of Zerodha's CTO, which I believe is extensively used within the company. Although not directly hosted in the Zerodha repo, it seemed to be an active project with numerous contributions. This project served as a standalone self-hosted newsletter and mailing list manager. In Zerodha, where emails need to be sent out for trade settlements, user balances, and promotional purposes, this project played a crucial role. It enabled the efficient management and delivery of emails to millions of users. As it directly impacted the business operations, it presented a good opportunity for contributing.
However, it's important to note that Zerodha has a small tech team and doesn't frequently hire. Therefore, contributing solely with the intention of securing a job might not be the most effective approach. It is vital to have a strong understanding of the codebase and not rush into making contributions without proper comprehension.
The project functioned as a newsletter manager, allowing users to create campaigns, manage email lists, and broadcast emails to subscribers. To explore the project, I ran a demo version and familiarized myself with its functionalities. Although I won't delve into the setup procedure here, I focused on identifying relevant issues for potential contributions. While browsing the issue tracker, I found a few interesting problems to solve. However, some required expertise in SMTP, which I lacked at the moment. I also encountered documentation-related issues and some bugs that required further investigation.
Among the issues, one that caught my attention was the redundant data field in API spec (collections.yaml). This issue seemed approachable and aligned with my current understanding of the project. However, I refrained from immediately attempting to solve it. Instead, I opted to seek feedback from the community, discussing whether this would be a suitable issue for me to contribute to at my current skill level and familiarity with the project.
Now, what is a Spec file ?
the OpenAPI spec is a fundamental tool for building HTTP servers and defining their routes and responses.
When creating HTTP servers, you'll have multiple routes that handle different requests and return specific responses. The OpenAPI spec allows you to document these routes comprehensively in a single, extensive file. It captures essential details such as expected inputs, outputs, and even potential status codes.
The beauty of the OpenAPI spec lies in its testing capabilities. By leveraging the spec file, you can effortlessly generate a Swagger page—a convenient web page where you can interact with the API's endpoints without building a complete website.If you have the Spec file, you don’t need to write the SDK, they will be autogenerated.
See me struggling finding ways to autogenerate the redundant “data” field in API spec
4. Didn’t solved the issue? Do this
I chose a careful approach. While someone had recently worked on the Swagger introduction, I didn't want to overlap their efforts. Surprisingly, I couldn't find any existing automation for generating the OpenAPI spec. To ensure coordination, I reached out to the person leading the initiative. Basically asked them how did they generated the Specfile(automated/manual). Would it make sense to introduce documentation through the project and how adding the same would make the task easier. [here’s the comment]
TAKEAWAY !
Polite Inquiry and Collaboration:
Before making significant contributions, it's wise to politely inquire about ongoing efforts and ensure alignment with the project's goals.
Handing off tasks to the appropriate individuals helps maintain a collaborative and respectful atmosphere within the repository.
Focus on Continuous Learning:
Rather than aggressively posting pull requests on day zero, it's crucial to prioritize learning and skill development.
Sharpening fundamental skills and understanding code bases enables meaningful contributions in the long run.
Motivation and Future Direction:
It's important not to solely rely on unconventional hiring paths or external motivations when contributing to projects.
The focus should be on personal growth, understanding the fundamentals, and developing the skills necessary to contribute effectively.
Empowering Contributions:
Acquiring the ability to understand and navigate code bases allows individuals to decide whether they want to contribute to existing projects or embark on their own.
The goal is to provide everyone with the skills and knowledge to participate actively in the open-source community, regardless of their eventual contributions or hiring outcomes.
Hi Harkirat, your channel is super amazing, it gave me a lot of insights on opensource contributions, also at this moment I made an open contribution which finally got merged in "Ivy" which is a ML framework going to be publically available soon!