My internship at Ceph centres around a project: replacing the python ssh library in cephadm. Cephadm, like ceph, is an open-source project, so all of its code can be viewed on Github: https://github.com/ceph/ceph. At this point, as someone who has only contributed code to open-source software (setuptools and now ceph), open source really feels like the norm to me now.

I really like the collaborative and transparent nature of open source. I like how ceph users can look at the codebase, open an issue or a PR with their own code changes, and that change can be merged into ceph and backported into older versions of ceph– I like this type of interaction between user and developer. I haven’t worked in a non-open source corporate setting before, nor do I know much about the processes behind it, but I imagine a similar tech company that is not open-source would have more layers in between the user and the developer. If the user has an issue with something, they may try to contact the customer support (first non-technical), then perhaps they would be transferred to a technical support, but in between these layers they may never get to speak directly to an engineer. (Note Ceph also offers technical support through Red Hat)

This transparency and these types of user and developer interactions in open source are what I find pretty awesome. For my project, I use the python ssh library asyncssh to establish SSH connections with hosts and run remote commands. Asyncssh is also open-source: https://github.com/ronf/asyncssh, and from what I can see, the majority of asyncssh was created by one individual: Ron. Ron is amazing to be honest. To understand how to use the library, I would read the documentation and look at the code. I would also look at github issues tab for asyncssh, a lot of which were not actually issues with the code, but moreso questions on how to implement something with asyncssh. From seeing how the creator of asyncssh would do something with the library he wrote, it really helped to impart some implicit knowledge. The existence of this implicit knowledge is something that I find can be a barrier to getting started with open source as a new contributor. What I call implicit knowledge or tacit knowledge are things that are not easy to learn from looking at the codebase yourself, but rather things you have an intuition for (from having a mental model, from your experiences, from writing the code yourself, from encountering a similar problem before, etc.)

That’s why I think mentorship is so important, and I’m happy that the Outreachy internship had mentorship as a key component. I really think all internships should have mentorship as a main component. My mentor for the Outreachy project, Sebastian, has been really helpful! I’ve learned so much from him and I’m really grateful for his help ^^

When you first enter an open source project, it can be overwhelming to see all the code that others have written, and not knowing how all the pieces fit together. But as time goes on you, too, begin to develop some of that implicit knowledge. And over time you begin to slowly understand things. And then maybe one day you’ll become a mentor as well.

After thought: Not really sure what to call this blog post– I sat down with the intention to write about my project progress, but ended up talking about why I like open source and mentorship. Well, I guess it does suit the blog theme of stream of consciousness!