In A Contributor’s Story series, our major open source contributors and community members give us insight into the projects they are working on, the successes and challenges they face when developing, and best practices for getting started in open source. For today’s blog post, we have Damir Temir, a LabGraph contributor working on issues and code efficiency through the MLH Fellowship. Let’s learn from them how we can start contributing to LabGraph.
“Working more on open source made me realize what is important in the community: collaboration. Having worked on LabGraph, I learned how to communicate effectively with maintainers and contribute to a Python-first sensor streaming framework.”
I'm a third-year student, studying Computer Science at the University of Illinois Springfield. I'm originally from Kazakhstan, speaking Russian and Kazakh as my native languages.
I like taking part in hackathons with the people I meet online. Some of my favorite ones so far were HackHarvard and HACKUIOWA, as well MLH Fellowship Orientation Hackathons. I like to build heavily data-focused projects where I can work on Machine Learning problems and deliver something that can be useful to people that follow MLOps practices.
I aspire to become a Machine Learning Engineer one day, using my love for math, along with interest in programming, to build cool products! I'm planning to pursue a PhD after completing my undergrad to keep growing in that direction.
My favorite part about open source is the freedom. Open source projects get so awesomely useful because of the people who are truly passionate about the idea of developing and maintaining them. There are no deadlines or corporate pressures to keep the ball rolling, instead, there is a community to which you hope to deliver and help them save time and achieve results. I believe this is how most tech products should be delivered, and more companies should open source their products.
I'm currently on LabGraph, a streaming framework built by Meta Research. In particular, I'm working on being able to transmit real-time messages within a graph to the LabGraph Monitor application.
I first heard about LabGraph from a friend who was previously an open source Fellow at MLH. He was contributing to it by building a YAML parser that converts graphs into a more concise and readable structure.
To start working on the project myself, I started with documentation, trying to understand the concepts that LabGraph is built on. I then worked my way through available examples, as well as trying to read the LabGraph API that helps us build the graphs. I also consulted other fellows and the maintainer, Jimmy [Feng].
I've certainly faced many challenges along the way, including simply struggling to comprehend the idea of a streaming framework, and overcoming a learning curve related to the vast codebase.
I've had to spend some time understanding the fact that the sensors that we use in real life simply transmit digital information and it is up to the software to comprehend it. Sensors create raw, unfiltered data, and the software needs to understand what it's trying to say. Having spent a lot of time reading about useful resources like ZeroMQ and cthulhu, I was able to start making sense of LabGraph and its important purpose to process sensor data.
I've also spent time getting familiar with an extensive codebase that creates the LabGraph API for users to build their own graphs. LabGraph, as a Python-first library, follows great OOP practices that make each class base upon other classes, making use of inheritance and the advantages that come from it. Sometimes it would bring me to a journey of going from one file to another to simply understand the connections between them all.
My current status of adding real-time messaging to LabGraph Monitor is having a minimum viable product (MVP). Using my current contribution, users can connect their graph publishers to a Serializer node, which comes with needed subscribers, to compose a single Serialized Message that is sent over WebSockets API.
Using the MVP, we can display a graph with its data flowing between nodes in a real-time mode. Being able to see data in LabGraph Monitor will let researchers debug their graphs, following data discrepancies between nodes.
Having learned a good portion of required knowledge to continue contributing to LabGraph, I became much more confident understanding the API behavior and reading into the results. I'm now able to use the advantages of the API to deliver useful features, such as using class attributes to determine their place in the Serialized Message.
I've also learned an important lesson: to not mess with something that is already built well, and instead work on top of the already made progress. I've spent a considerable amount of time trying to use the LabGraph API to work to my advantage, but I realized that it's a waste of time, as it has been well-developed. So I realized that I should instead focus on using its functions for my work.
For open source in general, I learned that people are as important for a project as the code itself. You can't make progress unless you communicate with the people who take care of the project.
Don't hesitate to open GitHub issues to ask questions—keeping the majority of communication in the repository will be useful for searching and problem solving. Put a good explanation of your contribution in the pull request, explaining the decisions you made. Finally, if you think LabGraph is boring or too complicated, think again. It's actually a big part of Meta's ventures into the Metaverse.
Read the documentation! Very, very useful information is kept there. You're not going to make sense of it at first try, but try again, and again. I promise it will click. Also, run the code. It will speak for itself.
We would like to thank Damir for taking time to share their experiences with us. It was very interesting to learn about the process of contributing to open source and we would like to thank Damir for their continuous contributions to the Meta Open Source ecosystem. If you’re interested to learn more about Damir’s work, follow them on LinkedIn and GitHub.
Open source at Meta is about more than just code. It's also about facilitating environments where collaborators from all backgrounds and experiences can come together to discuss ideas, foster innovation and work on projects together.
This blog is a part of A Contributor’s Story series where we hear from various contributors about their experiences contributing to the open source projects under the Meta Open Source ecosystem, how to get started, the challenges and successes faced when developing, and what excites them about open source. Look out for more blogs from A Contributor’s Story series where we learn about various other open source projects and how to start contributing to them.
To learn more about Meta Open Source, visit our open source site, subscribe to our YouTube channel, or follow us on Twitter and Facebook.
TAGS
Sign up for monthly updates from Meta for Developers.