Why open source development is like working for a political party

Two things that you never think you'd see together are open source and politics, unless you know, in which case you know. Not only is open source development more political than you may think, but creating change in political organizations is more about listening to the public than you may think. Actually, I need to make the connection because I'm applying for jobs and trying to explain how being elected to the volunteer board of a major political party in Ontario, Canada and hitting over 18M downloads to date in my open source contributions are relevant skills to software engineer roles.

If you're contributing to an open source project, you need to first understand the culture of the project. Each project has a slightly different approach. To start, if you find an issue, make sure to verify it hasn't already been identified by someone else by searching the list of issues. If you do find a similar issue, add a comment to indicate that you are also experiencing the problem. Otherwise, make sure you aren't stepping on anyone's toes by creating an issue ticket. It's best if you read previously filed issues to recognize the style and all the information needed to make sure it is consistent with the way things are done. It's very important to understand the existing code, such as formats, code styles, file naming schemes, testing structures, etc. Make as small a change as possible to be able to do your fix with minimal impact.

Within a political organization, you also need to understand the culture. You need to understand everyone's roles because asking the wrong person if you can create change can be turned down. Often people within political organizations don't even know what they're capable of or what others do. This also helps you understand what people's needs are and you're more likely to get what you want. It helps when you reach out to the right people. Contact info is also generally not public unless you are on the inside. Finding the right contact info involves networking to find someone reliable who is open to helping.

In open source, getting permission helps, but don't let it hinder you. If you are confident it is a small issue or it's important enough to you and you have the time, you can proceed to code the fix. Otherwise, it's best to wait for feedback from the project maintainers. After the fix is coded, however, you still need to apply to have your changes recognized, reviewed, and merged by the maintainers.

Similarly in political organizations, getting people to get behind your suggestions is always advised and helpful, but if you don't get the support you want, you may still be able to do some of the work. If you have already done some work, make sure to briefly state what you've already done. If it's a complicated ask, don't try to sell too much, but rather invite them to call you so you can explain.

In open source, you need to be persistent. Whether you're applying for your change to be merged or if you are just raising the priority of a ticket, maintainers review your work for free. They may not even check the library every week. Be reasonable, but feel free to add reminders as maintainers can forget. Find out other contact information on platforms more convenient to the maintainers.

Similarly in political organizations, it's recommended you reach out to a few different channels to enact political change in case people are busy and people do not always check their emails. People can be part-time or volunteer and you may not even know. Staff changes and people change emails. If your ask gets met negatively, do not despair. Create and distribute surveys to gauge the importance of what you're trying to do and use the results of that to convince others why the membership desires the changes afterward. If your initiative still is not popular, maybe it isn't the best timing or initiative to focus on.

In open source, you need to understand the goals of the maintainers. You need to convince the maintainers the change is consistent with the project goals and that a lot of people need it. You need to get people to reach out and publicly demonstrate that your change is important. If you run libraries that depend on the change, get users to comment on your tickets in the other project and merge applications to emphasize that it is important to them too. Don't try to build something you don't think others will need.

Similarly in political organizations, you need to understand the goals of the people administering the changes you want to see. For each person, understand their goals by briefing their social media or work and explain how your initiative will help them with those goals. Be polite and non-antagonistic, frame your ask in a very positive constructive way, and make sure to say how you are willing to help.

Having my feet in both the political and the open source waters, I can say they feel different, but I can make splashes in both with similar flutters. Both communities are managed by busy volunteers. Both have a framework to learn. Both require humbly listening to others and working towards the greater good. Both have allowed me to make rewarding changes. Have you also worked in both spaces? How does your experience vary? Let me know in the comments.