Talks
Open Source for your Benefit
Summarized using AI

Open Source for your Benefit

by Courteney Ervin

In the video titled "Open Source for Your Benefit," Courteney Ervin discusses the concept of 'self code,' which emphasizes coding for personal satisfaction and growth within the open source community. The main theme is to approach open source contributions with a self-focused perspective, ensuring that one's individual goals and interests are prioritized. Key points of the talk include:

  • Self-Love and Open Source: Ervin connects the idea of self-love to open source contributions, suggesting that developers should appreciate their abilities and overcome the intimidation often associated with open source work.
  • Personal Experience: Ervin shares her journey from knowing little about programming to becoming a back-end developer at the New York Public Library, highlighting how personal contributions to open source were pivotal in her transition.
  • Permission to Contribute: She encourages developers to give themselves permission to write open source code, regardless of their experience level, promoting a sense of community and support among peers.
  • Goal Setting: The talk outlines various motivations for contributing to open source, including building a portfolio, learning new technologies, and addressing social issues. Ervin prompts listeners to identify their personal goals related to open source work.
  • Variety of Contributions: Ervin emphasizes that contributions are not limited to coding; they can also include documentation, outreach, design work, and financial support, thus broadening the pathway for participation.
  • Choosing Projects: She gives advice on how to select appropriate projects to contribute to, advocating for finding welcoming communities and ensuring that goals align with the project's mission.
  • Contribution Process: The talk breaks down the contribution process, explaining the importance of following proper GitHub procedures and maintaining good communication with project maintainers.
  • Community Engagement: Ervin underscores the necessity of building relationships within the open source community and being open to feedback.
  • Final Thoughts: She concludes by reiterating that open source contributions should be voluntary and not a source of obligation, encouraging attendees to participate in a way that aligns with their personal aspirations and capacities. Overall, the talk fosters a positive approach to open source work, highlighting its potential to enhance skills and contribute to the tech community in meaningful ways.
00:00:16.760 Hi everyone, my name is Courteney Ervin, and today we're going to talk about self code. Self code is a term that I created, much like Shakespeare, and it's exactly what it sounds like: coding for yourself.
00:00:22.769 This is a mildly interactive talk, so if you have a notebook or a phone where you'd like to write some things down, I will give you a moment to prepare for that. I also want you to emotionally prepare yourself to do a little bit of work while I talk to you for the next 20 to 25 minutes. Okay, are we mentally in that headspace? I don't see any nods. I was a teacher, and I need to see some engagement. Great, awesome! Thank you.
00:00:39.230 Before we dive into self code, I want to start by discussing a related concept: self-love. Self-love is about loving yourself and has emerged from many social justice movements, especially the body positivity movements, where people make a conscious effort to love themselves, including their strengths and weaknesses.
00:00:54.930 In the world of open source code, there can be a sense of obligation or intimidation, where you think, 'I should be writing open source code' or 'I should be contributing to open source projects.' This feeling can hold you back from participating. So, what I want to do is take the idea of self-love and apply it to your coding. Love your code, appreciate your code, and recognize yourself as a developer, regardless of your strengths or weaknesses. Feel that you are good enough.
00:01:12.310 Now, let me take a moment to talk a bit about myself. I wrote this slide on a Thursday, so I’m not breaking any laws or anything! Right now, I’m a back-end developer at the New York Public Library. I’m working on an open-source reading application that libraries can use to distribute eBooks to their patrons. Additionally, I maintain an open-source project called Code Montage, which we will discuss later.
00:01:20.560 Three and a half years ago, I knew zero programming languages. I had a small amount of markup knowledge but absolutely no experience with back-end languages. Now, I am a full-time back-end developer, and I can honestly say I would never have made that switch without my personal contributions to open source code. When I started, I had about eight hours of PHP experience—nothing else.
00:01:49.330 When I began writing Rails code as a new developer, I was unaware of the norms in software development. I didn’t know enough to be intimidated about writing open source code. My ignorance protected me, and this lack of knowledge helped me contribute. I want to give you that same sense of ignorance—that freedom to step into open source initiatives.
00:02:01.259 So, first, give yourself permission to write open source code. Actively decide right now that you’re going to do this! You’ll get as much out of this talk as you’re willing to put in. Let’s make eye contact with someone you don’t know in the room—people in the front look back, and those in the back look forward. It may feel scary, but you can do this. Now, mouth to that person, 'You got this,' and give them a thumbs up. You don't have to say it out loud; just acknowledge it.
00:02:38.540 Great! Now that you have that permission, you can do whatever you want. I also want you to understand that open source code, at its best, is not just about working as a team. Often it looks like being alone in a room late at night, feeling lonely while trying to write one more thing for a project you care about.
00:02:56.180 As a maintainer of an open-source project, I am very open to contributions from others. Contributing to something big like Rails is a different process compared to smaller projects that are just waiting for someone to invest their time and care in them. So, consider this your permission slip—thank you for listening.
00:03:17.310 To begin with a self-focused approach to open source, reflect on what you want to achieve. For the next while, I'll go through some potential goals you might want to contemplate as you think about your open source journey.
00:03:41.000 Perhaps you're at a company where your code is private, and you can’t share it, but you want to land a job in the future that isn't at this company. Open source is great for building a portfolio. Maybe there's a specific tool you use that you want to support and maintain. Or perhaps you want to learn a new technology without simply making another Twitter clone that no one uses.
00:04:12.5 You might feel you don’t have a side project currently, but you want to contribute to a larger cause or initiative rather than create something just for yourself. There might also be a social issue you are passionate about and want to fix a technical problem associated with it, or perhaps you have a social cause you care about, as some non-profits are severely lacking in technology.
00:05:02.000 If you follow what I'm calling the 'Space Jam Equation,' there may be a developer you respect, and you want to work with them; the best way to do that is to contribute to their open source project. Finally, you may simply want a job and need to demonstrate your capability before getting hired.
00:05:38.600 So how many people found their motivation in that list? Raise your hand! Great! Now take a moment with your phone or notebook to write down your specific goal related to open source. Get that down, and I'll pause for a moment while you think about it. Let's not look at me while you write.
00:05:41.410 Now that you have a goal—whether it’s in your head or on your device—keep in mind that your open source goal might not strictly revolve around code. It could involve stepping outside the bounds of traditional coding. Consider ways to contribute to open source that do not involve writing a single line of code.
00:06:18.870 Outreach can be simple, like giving a star to a repository on GitHub that you appreciate, or complex, like organizing an event for a tech that resonates with you. It could involve reaching out to non-developer stakeholders—those who might be affected by a certain problem so they can engage with an open source project.
00:06:38.550 You can also contribute by writing documentation that's easy to read and understand. Perhaps you've seen a typo in a documentation file that you want to correct or maybe you know a second language and wish to translate a project to make it accessible for a wider audience.
00:06:59.320 If you enjoy design or want to enhance your skills, consider doing design reviews or creating a logo for a project. Getting started with QA (quality assurance) and writing tests is another excellent way to contribute without writing code. There are numerous projects out there that desperately need additional tests.
00:07:18.970 Contributing to code maintenance can mean updating documents about the deployment process, writing tests, or submitting bug reports. Maybe your goal is to transition from a developer to a lead developer role, and you can achieve that by actively engaging with projects through code reviews or significant contributions.
00:07:40.990 Remember, open source is often perceived to be a passion project. If you'd like to see a project continue to exist, consider contributing financially, even if you lack time to code. These are various ways to contribute, and very few of them require writing code, so think about what kind of contribution you want to make.
00:08:01.120 Now, once you know how you want to contribute and what your goal is, it's time to identify which project or issue you wish to work on. Your search will depend on your specific goals. If your priority is to find a welcoming community, start asking developers about projects they contribute to or enjoy.
00:08:14.670 If you're looking for a particular technology to work with, GitHub has various search features that can help locate open-source projects related to specific technologies or problems. Websites like Open Hatch allow you to find bite-sized issues that you can tackle quickly if time is limited.
00:08:41.250 If you're interested in social good, Code Montage, the project I maintain, lists open source projects based on their commitment to social good. For instance, if you're passionate about education or poverty alleviation, you can find related projects to contribute to.
00:09:01.590 During December, there’s a project called 24 Pull Requests that challenges developers to make a pull request every day for 24 days around the holidays, which can be a great way to dive in and get involved. For those who like a challenge or to be a bit of a hero, the PO Triage project lists GitHub projects that could use help according to how many unresolved issues they have.
00:09:27.570 It’s crucial to find a community that will provide a warm welcome, particularly if it's your first time contributing to an open source project. Look at the labels on GitHub issues that are marked as good for newcomers. Observe the community before you commit to working on a project.
00:09:47.390 Examine recent activities and pull requests within the project. Look for channels like Slack, IRC chat, or email that you can use if you need assistance. Make sure to check how responsive the community is to contributions; this can enhance your experience.
00:10:19.820 Once you've found an issue that resonates with you and want to help, claim it! There's nothing more frustrating than dedicating your time to resolve an issue, only to discover someone else has already completed it. Announce in the community that you plan to tackle it.
00:10:41.810 Even if someone has already called dibs, if you notice they haven't made a pull request after some time, it might be worth revisiting that issue. Before you commit to the project, ensure you find a community that fits you because the setup process can often be quite tricky.
00:11:03.730 Setting up an installation environment can be quite challenging since the creator is already set up and may not foresee issues arising for new contributors. Don’t allow installation difficulties to dissuade you from engaging with open source. If installation is problematic, that can actually lead to your first pull request.
00:11:25.400 Document the problems you encounter during installation by submitting a bug report to the project. If you resolve an issue during installation, consider that your first contribution. Clear documentation can greatly enhance the chances for other users to contribute to the project in the future.
00:11:42.170 Once you have chosen your project, understand that your contributions should be meaningful to you, and you should aim to enjoy the work you're engaging in. Before you begin to write any code, make sure to read the README and the contributing guidelines of the project.
00:12:04.790 In addition to understanding the project, always check in with the community before making extensive changes. Don’t waste time on changes that might not align with the maintainers’ vision. When you start your actual work, ensure that the output you create is polished and thoughtful.
00:12:31.060 This leads us to the Git process: when working on a project, you start by forking the main project repository. Usually, you follow specific Git commands to facilitate your contribution, such as cloning, creating a new branch, and making commits before pushing it to the repository.
00:12:54.960 Make sure your pull request is small and focused. Large pull requests that include too many changes make it difficult for maintainers to review your code efficiently. Clarity in your pull requests will go a long way in making it easier for your code to get merged while also inviting constructive feedback.
00:13:20.410 Lastly, the maintainer reviewing your pull request is a person too. Establishing a good relationship and engaging respectfully will benefit both parties. Also, once your pull request has been made, be open to feedback. If it hasn’t been accepted, that doesn’t mean your work isn’t valuable. Use the opportunity to learn and improve your contributions.
00:13:41.360 Remember also that what you do today could align perfectly with future career opportunities, jobs, or recommendations. Your contributions are tangible work that show your capability to solve real problems. Even if a pull request is not accepted, you can still utilize the experience in your job search.
00:13:59.250 Conversely, if you're a maintainer, you should create a friendly environment that encourages contributions. Make specific requests for help when needed, and express appreciation toward anyone who assists or contributes, whether in code or administrative capacities.
00:14:20.300 Also, be transparent about the type of help you need—sometimes it might be financial support for maintaining a project rather than code changes. Don't be that project with poor documentation that discourages potential contributors. Make the installation process and contribution paths as clear as possible.
00:14:42.370 Finally, never forget to say thank you to contributors. These gestures of gratitude build a caring community that keeps people coming back. A simple thank you can go a long way, whether in a pull request comment, tweet, or personal message.
00:15:04.490 For developers and maintainers alike, understand that open source is not obligatory. You don’t have to contribute if it doesn’t fit your current life or goals. If it doesn’t work for you, it’s okay to take a step back and not feel guilty about it.
00:15:25.900 Those feelings of obligation can weigh heavily on new developers. Open source can be incredibly beneficial, but if it doesn’t benefit your life now, don’t pursue it. There's a lot of joy and useful skill development that can come from open source work, but it should never become a burden.
00:15:45.100 Thank you for your attention today! I hope you choose to write some open source code if you feel encouraged to, and I hope that if you don’t, you allow yourself some time to sleep instead! Alright, have a great day!
Explore all talks recorded at BathRuby 2016
+12