Maker Mind MelD Summit

Jon Evans – How to contribute to an Open Source project

You’ve probably been using open-source software (and maybe even hardware) for a while — you might not even know it! Maybe you’ve wanted to get involved in an open-source project but weren’t sure how. Perhaps you haven’t even thought about getting involved before!

This talk will give you an understanding of how open-source projects typically work, how you can become a contributor to one, and some best practices for starting your own. Many examples will be taken from the KiCad EDA software project, but the principles explained will apply to a wide variety of software, hardware, and literary projects.

Watch full video below

Useful resources


Peter Dalmaris: Hello everyone, and welcome to this session. I'm Peter Dalmaris, an online educator and maker, author of Maker Education Revolution and Founder at Tech Explorations. My mission is to help people learn electronics, programming, printed circuit board design, and lots more. But most importantly, I want to help as many people as possible to enjoy the technology education adventures.

Peter Dalmaris: In this session, I'm really excited to introduce you to my guest maker, Jon Evans. Jon is an Electrical Engineer and Open-Source Software Developer based in Boston. Since around 2011, Jon has been designing electronics and firmware for industrial and consumer products, and most recently into 3D printing industry. He's been a contributor to the KiCad EDA project since 2016 and a member of the lead developer team since 2018. He's also created several smaller open-source projects related to LED art installations.

Peter Dalmaris: The contributions of the open-source community, whether it's hardware or software, are hugely diverse, hugely important to the everyday lives of billions of people. Open-source software runs the internet and many of the technologies we use for fun or work we take for granted. Open source helped deliver this video to you through the world-wide packet switch network we call the internet, and made it possible for companies like Amazon and Google to exist.

Peter Dalmaris: I'm fascinated by the ability of open-source projects, especially larger ones, to self-organize and produce high quality outcomes that compete with similar products from commercial organizations. Projects like the Firefox web browser from the Mozilla Foundation or the Apache web server from the Apache Software Foundation are so large and complicated in terms of their organizational structure and the software they produce that they would be multibillion dollar corporations should they be commercial.

Peter Dalmaris: I'm equally fascinated by the story of KiCad, an open-source EDA tool that Jon has been a contributor since 2016. KiCad has risen as a fully featured high quality option for people that want to design printed circuit boards. Jon's insider knowledge of how it works as an open-source project was why I decided that he would be perfect to talk to us about open source.

Peter Dalmaris: I'm eager to hear some of the practical aspects of how an open-source software project works, the tools, and practices that an open-source team uses, and some advice on how anyone can contribute to an open-source project, even those of us who are not programmers. Jon, it's great to have you with us. How are you today?

Jon Evans: Thank you, Peter. I'm doing well.

Peter Dalmaris: Great. Great. I'm going to dive into your presentation, but before we do, I'd like to ask you about your origins as a contributor to open-source projects, not just in KiCad. How did it start for you?

Jon Evans: Well, I would say that I've always been a tinkerer and a maker on the side, even when I was working on commercial projects and I did my day job. And so, I always had some awareness of the open-source movement when it came to building small electronic circuits, writing firmware for things like Arduino, and things like that. And so, my awareness grew mostly out of that.

Jon Evans: What really got me into it, though, was KiCad, because I think that was a story of really seeing how a larger project could work, and especially a larger project that produced a tool that I use and rely on.

Jon Evans: So, how I got started with that is, in my day job, I've been using commercial tools ranging from a few thousand dollars to many thousand dollars. And these tools just aren't accessible to most hobbyists at home, even though they have all the features that I would want to use.

Jon Evans: So, when I started working on more advanced hobby projects, I started looking around at what options were out there. And, of course, found KiCad because, at the time, it was, as you say, not just a toy, but, in fact, a very fully feature design tool and it also happen to be open source.

Jon Evans: So, as I started using KiCad and got more familiar with how it worked, I started thinking about the little ways in which it didn't quite have the feature I was looking for from the commercial tool that I was using and thinking about, "Hey, could I maybe help make that happen, make that feature exist?" So, that sort of sent me down the rabbit hole, so to speak.

Jon Evans: It started off with a few little things and then ballooned into this long list of things that maybe one day I'll get to, but slowly working away at it. And it's been great to get more involved in that community and really feel like I'm helping to shape the tool that I'm also using.

Peter Dalmaris: Very interesting. KiCad is like the Apache of the web server world. That's what KiCad is for the EDA, electronic design application. And I liked what you said about it, the fact that, you know, there was a feature that you missed and you wanted to see implemented, and you said I'll do it. And so, that's how you started to become a contributor to this particular project.

Peter Dalmaris: But you also have other projects that either you have started to think or you have contributed to. Can you give us a couple of examples of other projects you've done?

Jon Evans: So, one of the projects that I'll show at the end of my presentation is software for generating patterns to display on LED art. And this actually came out of me and a few friends who wanted to build some art installations and found that, although it was quite easy to find software that just did the bare minimum basic rainbow of colours on some programmable LEDs, if we wanted to have more advanced patterns, there really wasn't anything out there that did what we wanted.

Jon Evans: And so, we started experimenting with it and slowly built it into a tool that now several other of my friends have used to build their own LED art installations. So, I didn't really think about it at the start as, "Oh, I'm going to start an open-source project." But I did end up using open-source practices, even though I didn't really know it at the time when I first got started. And that ended up serving me well in the end because it was easy to get people to start contributing to the project even if they weren't as familiar with open source from the beginning.

Peter Dalmaris: Great. Well, I think I'm ready and eager to hear more about open source. So, the floor is yours.

Jon Evans: All right. Let's get into it. Okay. I want to talk to you about how you can start interacting with open-source projects. Open source is all around you. And you've probably been a user of it for a long time even if you don't realize it, maybe you've wanted to get involved but weren't sure how, maybe you haven't even thought about getting involved before.

Jon Evans: If there are open-source tools that you rely on to accomplish your own projects, I want to encourage you to think about getting involved. So, why is it? Why should you give it a try? Well, there are a number of reasons that motivate me, and maybe some of them will resonate for you as well.

Jon Evans: First of all, you getting involved can help the project move faster. Whoever is making use of that project will benefit from there being more work done, whether that's fixing an issue or adding additional features. But because you're contributing to an open-source project rather than working for a company with a boss, you get to set the priority of what you work on. If there's some tiny little bug that maybe only matters to one percent of users, you can fix it if you're in that one percent.

Jon Evans: Second, it can be great for you personally. Contributing to a project is a way to practice and improve your skills, whether it's software development, mechanical design, writing, creating artwork, or however you're contributing. The process of getting familiar with a project is often a great educational opportunity as you get to, not only see how others are solving problems, but engage those people in a conversation if you'd like.

Jon Evans: As an example, we've had many discussions on the KiCad developer's mailing list that I've come away from feeling like I understand something better about programming.

Jon Evans: And the third thing for me is that, it really just feels good to be helping with something that means something to people out there in the world. Knowing that the code I write is helping others with their own electronics designs, often others who wouldn't be able to afford a commercial tool with features like KiCad, is very motivational.

Jon Evans: So, how does open source even work? Let's talk a little about some of the ways that people come together and collaborate on projects in the open. Now, an important caveat, this is just a brief description of some of the features you'll commonly see in open-source projects. And, also, there's a lot of different ways that people do this and no one right way.

Jon Evans: I'm mostly going to be taking examples from the KiCad project because it's been around long enough to establish some practices, there's an active community of developers and users, and, last but not least, I'm one of those developers, so I can speak from my personal experience.

Jon Evans: Now, KiCad is a software project, so some of the examples I talk about are going to be specific to software. But keep in mind that these general principles can apply just as easily to a mechanical design, a book, or any other form of creation where you can collaborate with other people.

Jon Evans: The most important thing an open-source project needs is a place to find it on the Internet. I suppose you could have an open-source project that didn't exist on the Internet, but it wouldn't be very popular. If it's software, you need a place to find the source code. For hardware, you normally want to find CAD files or drawings. For a book, you need a place to read it.

Jon Evans: Normally, you also want to keep track of changes to the project as people fix things and add new things. This could be as simple as an index of past versions and some notes about what changed when. But these days, it's more common to use a version control system, especially for software projects. These systems are useful for a number of different reasons, but for the sake of this talk, the important points are that they keep track of what the latest state of the project is and how it got to be that way.

Jon Evans: Git is probably the most common version control system today, and so you'll see many open-source projects using it to keep track of their work. You may have heard of GitHub, which is a company that provides hosting for Git repositories, but there are a number of other options too, including GitLab, Bitbucket, and Launchpad.

Jon Evans: Using one of these popular Git hosting services is a good idea for most open-source projects because they have good infrastructure to make sure that your project stays available and a lot of extra features that might be helpful for your project, which we'll discuss in a moment.

Jon Evans: The next thing that an open-source project needs to work is some way for people to communicate with each other about the project. A key benefit of the internet is that it's easy to bring together people from all over the world to collaborate on something as long as those people can communicate.

Jon Evans: Email lists are a very common way to accomplish this in the open-source world, since email works across all platforms and all over the world. Some services, like Launchpad and Google Groups, make it easy to setup email lists for your project for free. A number of projects also make use of real time chat for collaboration from the old guard still using IRC to newer platforms like Slack. Discussion forums can be used for connecting users with creators and developers. And the larger and more established projects will even have in-person gatherings, like meetups and conferences.

Jon Evans: Now, as people start using a project, they might run into problems, like bugs in the code or typos in the text of a book. One thing that's really common is to use some kind of tool to keep track of all of these things that should be fixed. These tools are called issue trackers or sometimes bug trackers. Despite the name, though, they are often also used to keep track of feature requests, plans for future versions, and other things that aren't really problems.

Jon Evans: All of the major Git hosting services come with issue trackers and many open-source projects choose to use them, because having the issue tracker integrated with the version control system makes it easy to make links between the two.

Jon Evans: Let's take a quick look at KiCad's bug tracker. KiCad is hosted on Launchpad and makes use of the Launchpad bug tracker. If we take a look at this bug tracker, you'll see that there is a list of issues that people have reported, along with an importance assigned by the development team, and a status to keep track of the progress of the work. You can also search for bugs, and sort, and filter them to keep track of whether or not an issue has been reported before.

Jon Evans: The last tool that you'll see many open-source projects using is some sort of a website in addition to the version control system. This website might just be a simple splash page or it could be an involved site with detailed documentation, user forums, and things like that.

Jon Evans: Not all open-source projects have web sites, but the ones that do are usually easier to get started with. It's easier to find documentation for a project when it's all in one place. And it's easier to get involved when there is a page that explains exactly how and points you in the right direction.

Jon Evans: Smaller projects can sometimes get away with just a Readme file that shows up when you land on their GitHub page. But the larger a project grows, the better it is to have a full website with proper organization of information.

Jon Evans: If we take a look at the KiCad web site, you can see that when you first land on it, there's a lot of information for KiCad users, such as links to download and find documentation. But there is also a place to find out how to contribute, whether that's to the documentation or as a developer.

Jon Evans: Let's talk about how people contribute to open-source projects. It's kind of a cycle. Someone will propose something, maybe it's a set of changes to some software code, or a new image, or anything like that.

Jon Evans: Next, there will be some kind of review process, where the people who maintain the project decide if the change is okay or if it needs some fixes. If it needs a little work, the original person will make an updated version and this might repeat a few times if the change is complicated to get right.

Jon Evans: Finally, it will be accepted and eventually become available to everyone who uses the project. The cycle repeats because now this accepted change is the new starting point for any changes that build upon it.

Jon Evans: So, with that, let's talk about how you could make your first contribution to an open-source project. I'm going to talk about the case where there's a software project and you know how to program first. But keep in mind, the general principles apply even if you're contributing something other than software.

Jon Evans: It might seem intimidating to jump into this community that has people who have been doing it for years. What if they don't like your work or they just don't like you? Well, I promise they'll like you just fine if you're following whatever norms and expectations apply to that particular community.

Jon Evans: I've got a few suggestions to help keep you from tripping up. Every open-source project has a particular way of working. There's not one set of rules for how to contribute. And that way of working might be very different between a single person's project and a large team.

Jon Evans: So, the first thing to do is to figure out what the expectations are for the project you want to contribute to. Usually, the more established projects will have these explicitly written out.

Jon Evans: Let's take a look at how KiCad does it. So, if you land on the developers’ page, you'll see there's first an introduction that talks about how to get started interacting with the code and how to build it. But then, there's the section, ‘How to contribute.’ And they go through all of the different points that are important to make a successful contribution to the project. And this is great because it tells you exactly what you need to know.

Jon Evans: But sometimes those expectations won't be completely explicit, especially with smaller projects where there isn't a nice website where it's all laid out. Which takes me to the next step, which is to look at other contributions as they come in. Whether it's via an email list or a pull request on GitHub, or however the project takes contributions, it's a good idea to look around for a bit and get a sense for what those norms are. Are there particular conventions for code style, commit messages, how to file pull requests, or email patches?

Jon Evans: Getting these things right the first time by watching others will mean you make a good first impression on the developers who are going to review your contribution. Keep in mind that there are likely volunteers who have limited time, so be patient as you go through the review process.

Jon Evans: So, now, that you have an idea of how you would go about contributing, pick something to start with. And I recommend starting small. Maybe there is a little bug you found and understand how to fix or a small feature you can add. Starting with something that is easy to review will serve as a good introduction for you and give you more confidence to take on larger projects.

Jon Evans: The KiCad projects makes this even easier by having this tag called Starter that is applied to some bugs that the development team thinks are going to be a good entry point for someone who's new to the project.

Jon Evans: Once you have your contribution ready and send it in, make sure to stick around and follow up on it. The reviewers might have feedback for you. And if you keep involved in the conversation, you can resolve any questions and keep the process going.

Jon Evans: One thing that makes me a little sad is when a person submits a contribution, but it needs a little fixing up before it can be included. The developers give that feedback, but the person never replies. And more often than not, the contribution goes nowhere.

Jon Evans: So, you might be thinking, "All this seems cool, but I don't actually know how to program. Aren't open-source projects mostly software?" And it's true, the open-source idea is way more common in software than it is in other areas of creation, like mechanical design or creative writing. All those are steadily becoming areas where open source shows up as well. But the thing is, software projects can benefit a lot from help from contributors who might not know how to program.

Jon Evans: The first example I'll give of this is in testing and reporting issues. As anyone who has worked on a large software project can tell you, there are bug reports and then there are great bug reports. Being able to give in-depth useful bug reports is a skill that you can develop even without a programming background.

Jon Evans: By putting a little bit of extra effort to describe precisely what you were doing when something went wrong, what you expected to happen, and things like that, you can make the process of fixing the bug that much easier.

Jon Evans: Many medium and large projects have specific instructions or guidelines to follow when submitting bug reports, and reading those can be a good way to learn. By taking that first step of actually reporting when something goes wrong rather than just restarting the program and moving on with your life, you're contributing to open-source software.

Jon Evans: If you have extra time, some projects make pre-release versions or nightly builds available for testing. These versions can break more often, so be careful not to use them for critical work. But having users test these out and report bugs early can help the development team move faster.

Jon Evans: Here's an example of how KiCad asks people to report bugs. They describe what kind of things you should contribute in a bug report, such as what application were you using, and what version, and what operating system, and things like this. It's nice when a project makes it clear like this. But even if there's not a description of what kind of things you should include in your bug report, you can look at other projects to get an example of what might be useful to the developers.

Jon Evans: The next example I'll give is in working on the documentation for a project, whether that's a user's guide, website, tutorials, there's all sorts of written material that can help a project by making it easier for users to learn how to use it.

Jon Evans: Developers often struggle to keep documentation up to date with new features as they are added and having users who are willing to take the time to take these features for a spin, understand how they are to be used, maybe capture some screenshots, and update the user's guide can be very helpful.

Jon Evans: If you know multiple languages, perhaps you can help translate the documentation. If you're good with digital art, maybe the project needs some new art assets. If the project doesn't already have a page with specific ways that non-programmers can help, consider asking the developers if they have any needs.

Jon Evans: Let's take a quick look at the KiCad Docs Team page where they explain some ways that people can help. Here you can see what the Docs Team is all about, what kind of channels they use to communicate with each other, and what the tasks are that people can contribute to. This is a great example because it really gives a lot of different points that you might be able to contribute to, even if you're not going to compile and contribute to the KiCad source code.

Jon Evans: The final example I'll mention is that, users can help advance an open-source project simply by being active members of the community surrounding that project. Is there a web forum, subreddit, or some other place where users discuss the project? Putting in time to help that user community grow can be valuable to the project, and you don't need any particular technical skills to get involved that way.

Jon Evans: Helping new users find answers, sharing tips and tricks that you find, and things like that will help make the community stronger, which usually feeds into the project getting stronger, and then everyone benefits.

Jon Evans: So, what if you want to start your own open-source project? Maybe you have something you've been working on in your spare time and you want to open it up and share it with the world. Maybe you've been meaning to start something and finally are going to get around to it. Let's talk about what you can do to make your first project a success.

Jon Evans: Now, you might ask, "Why does this matter for a little thing that one person made?" Well, many large open-source projects got started with just one person making something that solved a problem for them. Another person found it and it solved their problem, too, and so on. And before you know it, there are a thousand people using it and ten developers contributing code.

Jon Evans: But that's not the only way things go. There are thousands of little open-source projects out there that are still important because there might be three people in the world that need to do one specific thing. And because the project exists, they can do it. Or a little project might serve as the inspiration for someone else's project. You don't have to be thinking about it like a company would, looking for a target market and how many customers you can get. You just need to put your project out there.

Jon Evans: So, you're looking out at this big global community of open-source projects filled with joy, ready to add your new one to the mix, let's talk about what your project needs to be successful. And what I mean by successful is a good member of that community. Other people can use it to meet their needs. And if they like the project and feel up for it, they can get involved and collaborate with you.

Jon Evans: First of all, you should be clear on what the project is. This might sound simple, but you'd be surprised how many Git repositories are out there with no description, sometimes not even a real name. If someone can go read the Readme of your project and understand why you made it, they can have an idea of whether or not they have the same needs as you, and they should download it and check it out. This can be as simple as a single sentence or as complicated as a full web page with screenshots or demo videos.

Jon Evans: Next, you should have a way for people to interact with the project if they want to get involved. For a software project, this means at least having a public version control repository and, ideally, an issue tracker as well. You get these for free from major Git hosting companies, so there's no reason not to use them.

Jon Evans: It's also nice to include a way to get in touch with you, the original creator, whether it's by email or some other means. Sometimes people want to talk about your project, but don't quite know whether or not they should open an issue. So, it's nice to be reachable.

Jon Evans: And, finally, you need to release your work under an appropriate license that makes it clear how people can use and contribute to the project. Open-source licenses can be confusing. There are a lot of different ones and it can seem like a lot of legal mumbo jumbo. Fortunately, there are some resources that can help you select an appropriate license depending on what kind of project you have and what rights you want to retain.

Jon Evans: Don't skip this step. If you release something with no license, it might seem like you're letting anyone do anything. But, in fact, there might be restrictions that people have based on where they are and what kind of legal framework they're under. So, you want to make sure that people can look at the license and understand exactly what rights they have to use and modify your project.

Jon Evans: is one place that can help guide you through the options. If we take a look at that page, you can see it asks you a few simple questions about what kind of situation you're in. And from there, it can take you to some examples of licenses, tell you about what that legal language actually means, and then give you the full text for you to copy into your project if you want to use that license.

Jon Evans: So, with those three steps, you'll have the starting point of an open-source project. Describe what it is, publish it in such a way that people can interact with it and potentially contribute, and license it appropriately.

Jon Evans: So, let's take a look at a tiny open-source software project that I started. This one is the software for animating LEDs that we discussed at the beginning. I used GitHub to host this project. And as you can see, GitHub will show a Readme file at the beginning of the project page.

Jon Evans: So, you can see I have a description for the project that's just a single sentence. It could be a lot more, but at least that is enough to give people a little bit of an idea of what the software is all about and whether they might want to look into it more.

Jon Evans: I also make use of the GitHub issue tracker. Here, it's mostly my own personal to-do list. But as more people got involved with this project, we could also use it to track bugs and things like that.

Jon Evans: And finally, here is a license file. This software happens to be licensed under the GPL Version 3, and GitHub will handily tell you some things about what that license means up here.

Jon Evans: As a bonus, I've also used the wiki function of GitHub to add some additional instructions on how to install and some details about the technical implementation of the project.

Jon Evans: So, if you're not already an open-source contributor, I hope you come away feeling like you at least have a starting point. Keep an eye out for things that you use where you might be able to give back. Take some piece of open-source software you use. And even if you aren't sure that you'll get involved, maybe check the project out in a little more detail. Find where the project contributors are discussing and planning their work and look over their shoulders for a little bit, you just might get inspired. Thank you.

Peter Dalmaris: Yes. Thank you, Jon. That was really informative. It improved my clarity on what an open-source project looks like, and especially some of the tools that you mentioned that I haven't been aware. And that actually seems to be a little progress. Like, GitHub seems to be very impressive, like the complete tool for a software open-source project.

Peter Dalmaris: Actually, hardware as well. A lot of hardware tends to be based on computer files which are hosted on GitHub. And then, the backtrackers, the wiki tool, all those things together give you a very good place to begin with. I think even the website, up to an extent, can be handled by GitHub. Right?

Jon Evans: Absolutely. They have a feature to allow you to host simple websites if you'd like.

Peter Dalmaris: That's great. The licensing issue also seems to be confusing people. Like, there's so many different open-source licenses out there that when I go to GitHub and I upload one of my course firmware files if there is a project, I am always getting confused. I tend to go with a standard MIT license, which seems to be probably quite liberal in terms of what you can and can't do. But I don't look at the fine print that I should. Do you have a go-to license personally, like for you, that you prefer?

Jon Evans: Well, I think there are two licenses that I'll most often consider, not that I've had to consider this too often. But like you said, the MIT license is a very popular license. It's quite permissive and allows people to do all sorts of things with your work.

Jon Evans: And another one to look at is the new public license or GPL. That one, I say, is a little bit more restriction on how people can use your work and specifically whether or not they can take your work and make changes to it and keep those changes to themselves.

Jon Evans: So, depending on the application of your project and whether it's something that you think it's important for the improvements to go back to the community or whether it's more important for people to be able to take that piece of a project and use it in a commercial application, those might guide the difference between those two.

Peter Dalmaris: Right. So, it's a comparative here between these two licenses, the GPL, and the MIT. The MIT license says do whatever you want, really. If you want to make changes and keep them for yourself, that's okay. But the GPL will not allow you to do that. So, if you contribute to a GPL project and you make changes, then you need to release those changes. You can't keep them. Is that right?

Jon Evans: Yes. That's it in a nutshell. There are a few more details than that. There are websites such as the one I showed that can explain what all of those details mean and help you figure out whether or not they might be relevant to you.

Peter Dalmaris: Great. I was wondering as you were talking about the open-source community and when you join an existing open-source project, you really need to understand how that community works. Essentially, you're getting into a team, it could be a small team or it could be a big team. And that team has been functioning in a particular way for a long time. So, the way by which you can become a contributor to the team is to just sit around and listen and watch, right?

Jon Evans: Right. And it's not because people are trying to make you jump through hoops for no reason. It's just that, like you said, they've been doing that way for a long time and they've figured out what works best for them. Most people who are involved with these teams are doing it in their free time. And so, they might have figured out things that might seem harsh, such as taking a while to get back to people about a contribution or things like that.

Jon Evans: But when you put it into the perspective of these people are balancing having to do some other kind of work for money and having to take care of their family and things like this, it starts to make more sense why there are these workflows that they set up that they ask everyone to follow.

Peter Dalmaris: Yeah. It just makes life so much easier. It's the same thing if you were working in an office environment, you can't just, say, go wearing flip flops if there's a certain standard code of conduct and dressing, so several things like that.

Peter Dalmaris: Most open-source projects don't have an office, so they work online, so how you write an email, how you fill in a bug report, things like that are part of how things are done here. So, take a bit of time to understand how the community works before you contribute.

Jon Evans: Exactly.

Peter Dalmaris: Another question I've got is, from your experience, whether you believe that there is a thing called the gold standard in an open-source project. So, I'm looking at the big ones, for example, the Apache Foundation with the Apache web server. It goes back a very long time. And in a way, it has started the open-source movement. And they've written a lot of the rules about how such thing works. Do you think there is a gold standard in this space?

Jon Evans: Well, I always have trouble with top ten lists and things like that, but I would say it's definitely an exciting time for open source. I can think of a number of projects that are really trying to be good projects, in addition to trying to produce a good product, like whether that's the software KiCad or mechanical design or a circuit board or anything like that.

Jon Evans: It's one thing to put effort into making that product quality, but it's another thing to put effort into having a good project that is self-sustaining and encourages new people to come in and develops those processes, that not only can keep the people who started the project excited and happy and continuing to contribute, but also seem welcoming and have as low a barrier of entry as possible for new contributors.

Jon Evans: And I think it's really great to see so many projects move in that direction where they have this community outreach, they have very nice pages explaining how to get involved and trying to make it easy, so that the open-source movement grows to people who might not have considered it before.

Peter Dalmaris: Yeah. So, I guess that that is the gold standard, is, having a lot of that culture that enhances the way that people are involved, used to operate, and be productive. And code that culture in the website, have the tools that especially beginners can use to get into the project and make that first few steps as easy as possible so there's some clarity there. So, that is what is needed, especially large project that is more than two or three people, have clarity across.

Jon Evans: Yeah. And it can really help the project move forward, not only for the developers, but also for the users to feel like they are included in that cycle directly, even if they don't ever become developers, to feel like the developers are listening to them and that they are part of this project in some way.

Peter Dalmaris: It is intimidating, I've got to say. Like, when you even consider contributing to an existing and established open-source project, you think, "Who am I to become involved? These people are wizards in programming and I'm going to make a fool of myself." Which is I guess it's a normal feeling to have, but it's not like that. There's so many different ways by which you can contribute that do not involve programming.

Peter Dalmaris: So, you don't need to be a wizard in programming. You can be a wizard in writing documentation or a wizard in icon design. So, find what you're really good at and use that skill to contribute into a project that you are really excited about, and perhaps you use as well, which actually helps a lot, doesn't it?

Jon Evans: And, also, for the larger projects, take for example KiCad, there are a lot of contributions that people can make to the code of KiCad that they don't need to be wizards to make. There's just so many different features in electronics design software from the schematic to the PCB layout and all the different parts there, that there are a lot of things that just take a lot of time -- they don't take any particular taglines. It's not an algorithm that needs to be optimized or anything that needs a computer science degree. It's just work that the more people contribute to, the more it'll get done.

Peter Dalmaris: Yeah. That's right. So, you can start at your level. You don't have to become a PhD in artificial intelligence before you are ready to contribute to an artificial intelligence open-source project. You can start at your level and build your way up, your skill up.

Peter Dalmaris: Another thing that I wonder is, again, always drawing from your experience, what are some of the core skills of a person that wants to contribute, always contributing to an open-source project?

Peter Dalmaris: Now, I'm thinking here things such as, of course, you need to have some technical skills of some kind. You need to be able to work with people, so collaboration and collaborative skills. Communications, communication especially in written form through bug reports, through emails, or email list. So, communication is important. Are there things that you would add to this list that you need to have actually some good working knowledge and skill in such areas?

Jon Evans: So, I would say, just to expand upon the communication skills is just reading skills. And more particularly, especially if you're going to be working on a complicated project, is research skills. So, knowing how to find the answer to your own question, the better you can do that, the faster you'll be able to work on a complicated thing.

Jon Evans: And you can always ask others to help you find the answers. But, you know, other people might not be awake at the same time as you, or they might have a lot of emails to get through. So, it's always going to be faster if you know how to do your own research and know how to find the answers to things, be they technical or otherwise.

Jon Evans: And another thing, you know, I sort of touched on it a little bit, but empathy. Just having in mind that everyone you're interacting with, if you're working on this project, is doing it because they're motivated by something or other. And everyone's motivations might be different and everyone's ability to contribute time might be different.

Jon Evans: And there might be some people who are excellent programmers but can't write a good email and vice versa. And just keep in mind that, you know, there is a community that is trying to achieve a goal. And each member of that community might be contributing a different thing to it.

Jon Evans: And just to keep that in mind, because when you're communicating with people on electronic means, especially via email, when there's a long-time delay, it can easily distort the meaning of things, especially across language barriers. It can make people's words seem like a different thing. So, use a little bit of empathy and assume the best in everyone.

Peter Dalmaris: Absolutely. I think this is really good advice. How common is this these days, the electronic medium being in between us somehow makes communication less personal. And things flare up really quickly unintentionally.

Peter Dalmaris: And, actually, this is what I do in my everyday communications, I assume that the other person I'm writing to is writing back, is really a good person and so I'm not trying to insult or, you know, be nasty in any way. I tend to attribute any miscommunication in things like I'm tired, the time can be late. I've got something else bugging me in my mind and I can't concentrate, which happens in email. A messenger alert popped up and distracted me so I couldn't finish a sentence properly.

Peter Dalmaris: All those things are possible, so I just assume the best in people. And almost 99.9 percent, this is actually the truth, it's what's going on.

Peter Dalmaris: I've got one more thing that I wanted to ask you, Jon. So, let's say that I contribute a little sketch with 20 lines that I wrote yesterday in blinks and LED in a particular pattern. Really basic stuff but it does something cool and I want to share with the people. But it could be something a lot more interesting, like it solves a much bigger problem.

Peter Dalmaris: So, I decide to put my project on GitHub. And I write the Readme file and give it a license and I click on publish. And, now, it's public, anybody can get it. Is there something else that I need to do after that? Or should I expect, that somehow Google will put it in front of people that will start contributing? Like, how do I let other people know of the new project that I've just created and published?

Jon Evans: Well, I would say that you should start a conversation with potential users of the thing that you've published in whatever forum you find is useful to that community. So, if it's a sketch that maybe does something cool with some electronics, then if you also like to hang out on electronics forums or subreddits or things like that, maybe post a link there. And show a demonstration of why your project is cool. Like, what it did it let you do? Give some people that inspiration to think about, "Oh, can I use this for my thing as well?"

Jon Evans: You know, it's one thing to just be able to search for a keyword and come up with your project. But it's much better if you can actually put an interesting example in front of people on some forum that they tend to read daily, or weekly, or whatever it is. And then, from there they can see, "How is this done? Oh, I can see. It's open source and I can go dig through it and maybe use it."

Peter Dalmaris: Right. So, there's communication coming up again. Once you create a project and you publish it in some website, like GitHub or your website, you still need to tell people about it. So, that's like working a way as an evangelist of your own work, of your own project, invite people to have a look. And make it as easy as possible through demonstration videos, through a quick Readme that explains what it is. But communication, again, is key. You can't get away from that.

Peter Dalmaris: All right. Jon, I'd like to finish up with a couple of questions. The first of which is to ask you to give us maybe three or four key learnings. You've covered quite a lot of ground in your presentation, but maybe extract three or four key learnings for the people that are watching that they can remember and take away with them.

Jon Evans: So, I'd say the first thing is that, open-source people are very different. Like, every person who is contributing to an open-source project is doing so in a different way. And there are lots of different things that projects need and can use. So, if you care about a project and want to contribute to it, look for ways that match with your skillset and match with your own desire to practice your craft. Because you're almost certainly not getting paid for it, so make it something that's going to motivate you in some other way.

Jon Evans: The next thing would be, every open-source project is going to be different. There is no one set of rules, like I said. So, the best thing to do if you want to help a particular project is to spend a little time studying that particular project and absorbing its community and how they interact.

Jon Evans: And the third thing is, speaking of community, if you're thinking about starting your own project, have that community mindset. You know, even if your project doesn't take off and build its own community, it's going to be part of this global open-source community. And so, if you put in that little bit of effort at the beginning to help other people potentially interact with it, then you're making that contribution to the community that much more valuable.

Peter Dalmaris: Great. Thank you. Now, what are some next steps? One, maybe two, next steps that you'd recommend people interested in being open-source project contributors to take?

Jon Evans: Well, I would say, you know, being a little bit selfish here, that KiCad is a great place to start if you're at all interested in electronics design or even if you're just interested in software and want to take a look at a midsized software project. Even if you don't want to contribute to KiCad itself, if you take a look at some of the links in my presentation, you can read through at your own pace some of the things that KiCad makes available for new contributors and maybe try them out if you're interested.

Peter Dalmaris: Great. Thank you, Jon. And we'll have your presentation available to people that want to have another look at it, including the links down below this page that contains the session video.

Peter Dalmaris: Now, how can people get in touch with you? Email perhaps or some other means of communication with people that want to ask you questions?

Jon Evans: Yes. I'm very happy to chat with people about open source in general or KiCad in particular, and the best way for people to reach me is by email. So, my email address will also be on the page.

Peter Dalmaris: Awesome. Thank you. Well, Jon, it was a pleasure. I learned quite a lot, much of the process of open source and how open-source works. I was demystified. Thanks to your presentation, I really appreciate it. Thank you.

Jon Evans: Thank you so much, Peter.

Get life time access to all Maker Mind-Meld masterclasses

Watch each masterclass from the comfort of your own home and learn about their tools, techniques, and thinking processes so that you can become the best maker you can be, at your own pace.

Get audio downloads of all 22 session, the Maker Mind Meld "Playbook" session notes.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}