Mapillary: A Contributor’s Story with Saif Ul Islam

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 contributors face when developing, and best practices for getting started in open source. For today’s blog post, we have Saif Ul Islam, a Mapillary contributor working on issues and code efficiency through the MLH Fellowship. Let’s learn from them how we can start contributing to Mapillary.

“[Contributing to Mapillary] has allowed me to learn that little things get the stone rolling into an avalanche. Suddenly, you have new friends, communities, experiences, and a completely changed mindset.”

Tell us a little bit about yourself

Hi, I’m Saif. I’m from Pakistan, in my final year at FAST NUCES, Karachi, majoring in Computer Science. Technically, I'm practicing open source Software Development, DevOps, Cloud, Computer Networking, Software Engineering, Full Stack Web Dev Engineering, Production & SRE, Database Administration, Technical Writing, Linux, and have touched briefly on Data Science, Front-end Design here and there. Why so many domains? I wanted to understand each of them to a degree to inform my decisions over what it takes to build a product from scratch. My primary aim right now is to target Cloud, DevOps, Backend Engineering, and develop skills over Cloud/DevOps/Networking/System Administration. For the future, I'm aiming for Site Reliability Engineering/Production Engineering, Software Engineering, Full Stack Web Development, and wherever life is willing to take me.

Other than technical stuff, I love working with teams, contributing to open source, recognizing business problems, evaluating requirements, being part of hackathons and group efforts for a project, and learning from teammates and experiences. A project is probably nothing without a community that uses and builds it.

What excites you to work on open source?

It feels extremely powerful to realize that you can impact software and contribute positively to software and management by just taking the time out to learn more and getting into these communities. That same software is something that maybe hundreds or thousands of developers all around the world use—and you can help improve the world wide developer experience by solving issues that many people are probably running into!

And the great thing about open source is that it is so diverse that you'll always find something that catches your eye and pulls in your attention. In the process of figuring out how to make that piece of technology better, you'll start to adopt it as something you're very proud of and you'll get into the mindset of saying, "Okay, this solution might be good ... but can we do better?"

Suddenly, new communities and new projects open up that have problems and issues that contributors can help with, and now you start building contacts with talented developers worldwide who are working on the same problems as you. And there are no prerequisites to getting involved with a project.

One of the building blocks of open source is inclusiveness and diversity. You'll find students from schools/colleges/universities looking to get their hands dirty, all the way to 10-15+ years experienced veteran developers that are always willing to answer as many questions as they can to help newcomers. Pro tip, and you'll come across this extremely rarely, if you ask for help and do not get a positive response, it's probably not a good place to contribute and be a part of.

Paradoxically, all open source projects strive towards inviting as many collaborators as they can—a project is only as up to date and maturely developed if it is subject to continuous development and is being actively managed and used by users. Ask for help, and it will always be given in open source.

What project are you working on currently?

I'm working with Mapillary. "Make better maps," as Mapillary states, is an open source alternative for geospatial data and detections. I'm working in a team with Christopher Beddow, Muhammad Omer Ali, and myself in building an SDK for their latest API v4 release to make it easy and convenient for users to use the API.

So far, we've contributed about 6.5K+ lines of code, and still going with 21 open issues, 34 closed ones. Currently, as for Pull Requests, 0 open, 32 merged, 3 closed.

How did you first learn about this project? What steps did you take to start working on this project?

My teammate and I were assigned to the project by my pod leader, Gabriel Cruz. Initially, both of us were very unsure how to start work on the project—neither of us had any idea of what GeoSpatial or GeoInformatics was all about, and it took us time to understand the background context.

We first started picking the project apart from a software engineering perspective, asking questions such as who the user is, what are their expectations, how we can deliver clean code, what are the best practices etc. We were given a total of 12 requirements (only 3 of which remain by now, hopefully 0 soon), and we then started organizing ideas and designing skeletons of code of where everything should go.

We decided on the structure and where to publish. We organized everything into issues as "modularly" we could, in smaller and smaller components that stood on their own. We kept asking specific questions about different ideas, getting feedback from Christopher, who was a fantastic lead, answering everything we asked (and more!), and we started implementing design patterns for our earlier principles of clean code and following DRY.

So we picked everything apart, then we got to the code. We followed a code-review process. And I would say that we have been successful so far. Every file and structure has an idea behind it. Some ideas initially merged into the code base have still not yet been changed because of how modular we made them.

And now we have even more ideas even after the initial requirements, like documentation, using features from other packages, integrating visualization, implementing an API like Twitter, and so on. We just need time in the coming weeks and no distractions to push us.

I'm not sure how much progress we will have accomplished by the end, but maybe "good enough for now" will lead this project to widespread adoption within the community it is being built for. That is my goal.

Did you face any challenges or roadblocks along the way? How did you go about solving them?

One thing I realized (and this was because I had been working alone for quite some time) was that I started solving problems before asking others. And what that means is that I started solving bits and bits of other problems everywhere around me, admittedly in good spirit, but I completely forgot that I was on a team. An example of this is a Pull Request I made that I later closed, since it was too big of a PR doing too many things at the same time—I had started with one issue, and that started to grow into other smaller problems. The end result was that it became a gigantic PR. I later realized this could be problematic in large teams thanks to the suggestions to me by my teammate Omer. It was definitely a big realization and I started thinking of being even more modular if I could.

I spent 2-3 days in the initial timeline trying to understand GeoSpatial and the Mapillary API because I had no idea what the field was even about, to be honest. I knew it had something to do with geography, longitude, and latitude, but other than that, I was not sure what to say earlier.

What resources did you find most helpful when working on your project?

The sessions held by MLH and Meta during my tenure were the most helpful resources. They gave me a view into how flexible this field can be, and helped me realize I should stop worrying about my future as a Software Developer.

Sometimes your impostor syndrome can come up from time to time and makes you question your value. I would advise students/undergrads to reach out to professionals working with open source projects or working professionally in the industry, arrange 1-to-1 online meets with them, get feedback, and share your fears and worries with them. In my opinion, having a person as a resource can not just help you get advice on projects and feedback, but they also play the role of someone with whom you can share your thoughts and mindset with so that you can feel comfortable in the open source space.

What is the current status of development for this project?

I'm working towards closing 7 issues assigned to me right now, and as said above, we have 6.5K+ lines committed in the project, out of which I have made about 5.6K contributions to the code base.This also includes a Pipfile.lock which should make the lines go down to 4.5K contributions instead.

I'm focusing on getting the requirements from my end finished soon, then I will be working on releasing documentation for the first major release, and solving the integration of some packages we have in mind for testing and visualization. We also plan to adopt a style similar to Twitter's SDK for their SDK in our second sprint late in August, because that is what users will be dealing with. We will be making a proper PyPI release as well and releasing Jupyter Notebooks that demonstrate the capabilities of the SDK. We are also attempting to make it a priority to follow test-driven development (TDD) in the future. We wanted to make base requirements be finished before we started writing tests because we did not want to be in a situation where we had little time in the end and requirements still remaining. Thankfully, it has not gone that way.

For my initial contributions, I spent time figuring out the Software Engineering aspects for this as it was very important to me to have something that not only "works, but is easy to read, scale, and keep building on in the future.

The thing about open source is that you should make your code base follow best practices (e.g. following DRY) and keep it extremely maintainable, clean, organized, and simple enough for any newcomer to pop in and start contributing as fast as possible.

Reflecting on the work that you did, what did you learn about the project, process of development and open source as a whole?

1. I learned an entire new domain that I didn't even know vastly existed.
2. I learned software engineering and put them in practice for this project: architecture, pair programming, testing, documentation, planning and workflow, communicating with team mates, trying to follow best practices, and keeping notes on Notion. Had fun overall.
3. This project was a breakthrough for me in open source. I started contributing to more than just Mapillary. I'm also contributing to JinaAI, Meshery (a past project on MLH), learning about AWS Amplify, joining SIG Interoperability @ CD Foundation, contributing to @CLIGuidelines. I'll keep contributing as much as I can in the future as well.
4. You need someone to walk you through open source for the first time. I might be the only person at my university doing open source because although it seems simple to get contributing, it can be intimidating to go from writing programs for yourself to suggesting code changes on projects that initially you believe are from strangers, and thus are not even sure how they'll react to your PR ("Will they judge me? My code? What if they don't like my suggestion?" all the way to, "I'm not skilled or talented enough to contribute to these large projects", "There most likely are better devs than me, I'm just a student", and, "Is this really helping me in my career? I'm not sure, I don't have anyone working in open source around me, so it must not be a great choice, since very few are into it"). I come from a background where GitHub is just an account to push your semester projects to. We just don't have meetups, discussions, hackathons, tech conferences. We don't have any of that. You must understand the shock I had when I realized there is just so much going on that I didn't even know of back when I was starting open source, and this opportunity by MLH and Facebook has given me a deeper look into what the open source paradigm looks like. I would like to keep this light burning and bring it to where I study as well.

What is the best takeaway you have from working on this project and open source in general?

Gosh there's so many I can't list them all on top of my head. This opportunity has been a mindset changing experience for me and I now think way differently than I did back in the start of 2021. Previously, I had come from a place where there is absolute zilch about open source and anything other than "get into your third year, find a web dev internship, make an FYP in the final year, graduate" which is talked about as the ideal path here. It's beyond imagination for someone like me if you asked me back in 2020 if getting into DevRel, open source, and community was even a reasonable option. No communities, meetups, discussions, standups, anything like that here.

This experience has broken my perception about software engineering and communities to quite an extent and proved me wrong in the assumptions listed above. Now, I can't imagine progressing in my career without being involved in communities and open source platforms. I just can't. There is something to learn from contributing and being part of the open source projects and helping better shape them in as a guidance. My experience has been vastly improved and I have built more than I could imagine. Not just my technical skills, but my softer sides as well on how I work and explain things to my coworkers.

I'm looking for other opportunities in open source and community as well. It gives me inner satisfaction to be able to do work that impacts so many people around the world and solves challenging problems every day. I love working with people from all over the world now because there is always a perspective to learn and understand that you didn't even know existed before you met and talked to them.

What advice would you give to future contributors to the open source projects?

I'll be honest, open source needs a push or a cultural idea. I didn't start contributing more heavily and effectively until I got involved with other people doing the same problems as me. It was a mindset for me, "Who will ever care if I made pull requests or issues on GitHub?" back when I was looking for jobs and positions this year earlier, and "I would love to contribute to this project, but this code base looks so complicated and I'm just not sure how to get started" and then I would never be able to make out time for that project and just leave it.

If I just kept doing open source by myself, alone, or some personal projects that I just released as public for the "open source" idea, that wouldn’t really help in many ways. Find people like you, either online or in person, find projects that suit you, start a small community of people where you come from, or join an already existing community, find organizations the Linux Foundation, CNCF, CD Foundation that host and promote open source projects, attend online meetups, learn to deal with the fact that not everyone's the same skill set as you - some are stronger, some weaker - and how to improve your softer skills to match those skill sets, to improving your explanation styles and how to communicate ideas and problems in a better way.

You'll meet people both from starting their tech journey, to people who have some considerable experience, to people who are going to have a project as their first open source experience, to people who have worked on open source for several months to years. Open source tries to ask where you are coming from and what kind of experience you're going to be bringing to the pod you'll be dealing with everyday. What brought you to tech? What are you trying to get out of it? Why is a community important to you? What kind of discussions or ideas can you bring and how much do you enjoy working with others?

As far as what you should not do:

1. Open source really isn't a place if you like working alone most of the time.
2. Everyone is learning from everyone and trying to get a bit of exposure wherever they go and everyone contributes in their own way. Some prefer management, some prefer coding, some prefer marketing, some prefer technical writing. Take your pick, whichever you really enjoy.
3. Open source isn't a place that is meant to stress you out. There is always a way a software can be improved. It's a Software Engineering fact. Open source is more about building projects that you believe have value if you can bring projects to people more than yourself. If you enjoy working on something, you shouldn’t feel stressed—you can always leave something and come back to it when you're feeling better.

Please do not wear yourself out by looking at people who have contributed a lot and saying to yourself, "This is really difficult, I may not be able to make contributions." This is false. Any and all contributions are always welcome. And there will always be people willing to guide and help you if you ask for it.

We would like to thank Saif 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 Saif for their continuous contributions to the Meta Open Source ecosystem. If you’re interested to learn more about Saif’s work, follow them on Twitter, LinkedIn and GitHub.

About A Contributor’s Story series

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.