This is our first video of our non-coding contributions series for those looking to break into open source software development. While you might not feel ready to contribute code to your favourite projects, there are plenty of other ways you can add value!
For full details check out the video on YouTube. For those who prefer to read instead of watch, see the transcript below.
Introductions
JZ Welcome everyone. I’m JZ, COO at Charm.
Bash Hi, I’m Bash head of developer relations at Charm. You would’ve seen me in literally all of our YouTube videos, so hello, once again.
JZ Bash and I are very excited to co-host a new mini-series based on various community topics of interest. Each series will have three mini episodes, meant to be relatively bite sized, yet informative.
Really, we just wanna share our learnings in an interesting way with the community.
Bash So that even means we’ll be bringing in relevant experts and startups to join in on the discussion and lend their expertise. Uh, this new series we’re starting is all about non-coding. You can subscribe to stay updated on when new episodes launch. And don’t forget to like the video if you wanna see more of this content in the future.
Why non-coding contributions?
Bash JZ, maybe we should talk about why we chose non-coding contributions as the topic. We’re a software company. Why would we want non-coding contributions?
JZ It’s a great question. Well, it starts from our very rooted belief in the power of open source. Increasingly, startups to enterprises alike are adopting open source. In fact, our good friends Sourcegraph, Supabase, Cockroach labs all identify as open source companies and we’ve observed that many equate open source community as one filled with only technical developers. We’re here to share that.
There’s plenty of room for non-coding contributors to join the party and there are many ways to do so.
Who this is relevant for
Bash Yeah, so, let’s talk a little bit about who this series might be relevant for. So obviously those who might be wanting to transition into development. So that might include students, users of open source software, maybe even someone who is in the tech field already in a coding adjacent role, or even newly onboarded employees who just wanna be able to understand the product and provide value as soon as possible.
JZ Well, Bash, to ask the devil’s advocate, who might wanna skip ahead? In other words, is there someone the series is not for perhaps those already medium to experience developers?
Bash Yeah, so the interesting thing about this topic is that it’s actually. Pretty applicable across the board. So on one end, it’s obviously very helpful for those looking to break into the industry.
It allows them to showcase their skills in real-world projects through contributions to open source for those who are not quite feeling like they’re. Code is up to par yet, but they wanna start getting involved. It’s a great way for them to gain traction, gain some networking, have some projects that they really want to contribute their code to in the future.
And, for people who are in coding adjacent roles, it allows them to highlight their skills. So potentially if they’re looking to work at software companies, they can show how non code-skills can actually add value to software products and tools. By contrast, it’s helpful for experienced developers who might be thinking of new ways that they can improve their open source products or find creative ways that they can get value from other departments in their organization.
So of course, as we mentioned already, it can be helpful for getting new contributors on and helping them gain familiarity with the project.
What if you don’t have experience in open source?
JZ Okay, well, what if they’re not currently an open source contributor slash maintainer, or what if their company is not open source? I’m just coming at you with the hard-hitting questions.
Bash Right. Yeah. So even if the company isn’t open source, uh, these might be like less known ways that more employees or members of the organization can actually contribute to the success of software products that we’re supporting.
JZ Okay. Well said. Yeah. Well, with that, let’s go over some of the most well known types of non-coding contributions. Bash, why don’t you kick us off with the first one.
Common types of non-coding contributions
JZ Of course. So I’m gonna state the obvious here, which is a documentation. I feel like most of the people that I’ve talked to got their start in open source with like fixing typos, fixing punctuation, maybe clarifying something in the docs. Um, making changes to documentation is a great entry point.
And for those who have great writing skills, that can be a great way to contribute to an open source project. A lot of devs don’t really have much of an inclination towards, you know, writing. They mostly just wanna write code and have things work.
JZ Different type of writing.
Bash Yeah, different type of writing. It’s a pretty good match there.
Companies that support authorship in non-code contribution
JZ I have a more poignant question. The documentation you speak of— essentially form of authorship—are there any companies you know of that financially support this type of authorship?
Bash Yeah, so we actually learned recently from our friends at Digital Ocean that they have a program for people who write articles or tutorials about their tools.
They do actually pay on a per article basis. So if you’re interested in getting involved with that, we’ll leave a link for that in the description if you wanna check it out.
Reproducing issues: don’t be shy
JZ Okay. Well, another way to contribute is via reproducing issues, now in the software testing world. If there’s an issue to be found, it should be reproducible.
Sometimes it’s as simple as writing a few lines of code by a cross-functional partner, ensuring the precise environment, tools, application version, specs with the engineer and functional partner rules such as the product team to solution sales might be able to try this on a regular basis.
Bash Yeah, absolutely. And what helps a lot there too is that there can be so much back and forth between maintainers and people who are creating these issues. Like, if they’re, for example, reporting a bug, like maybe they’re not giving. Enough context to actually be able to reproduce it. So if someone’s looking to kind of maybe help their favorite open source project and they see that there is like an issue where they haven’t really given a lot of context, you know, you can always say like, “Hey, I’m, I’m hoping to reproduce this issue myself. Do you mind providing more information on like what your operating system is? What, what, what terminal you are using” Just more details so that they can actually reproduce the steps, uh, to see if it works on their machine. So that obviously segues into number three, which is reporting bugs.
So obviously to do this, it helps to be a user of the open source tool. Don’t forget as well that when you’re reporting bugs, when you’re interacting with these issues, it means that you care. And that shows for the maintainer of the project. So really don’t forget the value that it brings for you to be a user of open source tooling. Your insights matter, your issues matter.
So in general, maintainers are gonna love hearing from you and knowing that you love their tools.
JZ In other words, don’t be shy to bug the maintainers and, uh, creators about the bugs. They will be very flattered and happy to hear from you.
Bash That was terrible. I love it.
JZ Well, those are the three most common types of non-coding contributions.
What’s up next?
In the next episode of the series, coming out in a few short weeks, we will be discussing less common types of non code contributions that can be explored by more cross-functional partners.
Bash Absolutely. So let us know the comments, your favorite non-coding contributions, either as a user or maintainer, and make sure to join our Discord linked in the description if you wanna get in touch with the community.
Hang out with us there. Don’t forget to like, share and subscribe if you thought this was valuable. We will see you in the next one. Thanks for watching.