I spent last week at Open Source Bridge, a conference about open source technology and citizenship. I worried that because I haven’t been involved in any major open source projects I would feel lost, but instead I learned a lot about the community. Most of the people who attend OSB are also interested in improving the culture of tech.

Open Source Bridge felt like two connected parts. The first is the (open-source) technology. I didn’t go to very many technical sessions because I’m not very interested in details right now. I’m still in the “learning how to learn” phase where details don’t matter too much.

The other part of the conference centered around culture. Tech is not a bubble, and I’ve been hyperaware of the ways that tech culture can be toxic since I was the first “girl” on my robotics team. Now that I’ve transitioned, I’m working on reconciling my place as a white (cis-passing) man. The people at Open Source Bridge have also been thinking about these things, and have ideas on what to do about it.

The four-day conference was somewhat of a whirlwind, and left me with a lot of information to process. The things that really stuck with me fall into three parts:

Getting into open source projects,
Building and maintaining open source projects,
Creating an inclusive tech culture.

Open Source Projects

Being a student new to contributing to huge projects, I was excited for “How can I contribute?” on the second day. The week before OSB, I went to a workshop at Free Geek with the same goal. I still don’t feel ‘ready’ to contribute, but I also realize that the only way to get over this fear is to go for it.

The main thing to keep in mind is that if someone is maintaining an open source project, they are likely looking for contributions. Unfortunately, not all projects are maintained, and not all public projects are open source. One suggestion was to make a small change (such as correcting spelling) to the README. Or, if there isn’t a README, create one. Then, use the maintainer’s response (or lack of) to judge how friendly they are to newcomers.

Both the OSB presentation and the Free Geek workshop stressed that code isn’t the only way to contribute. Since I’m coming at open source from a computer science background, concrete code contributions is what I was initially looking for. But documentation, answering questions, and design are all still technical work that projects need. Less technical work should be valued too, such as filing/duplicating bugs, user manuals, and education. GitHub has a good list of ways to contribute that aren’t just code.

Finding a project is a major hurdle to contributing to open source. I think the best place to look is at tools you already use. Since you use it, you have a stake in making a good product. Otherwise, large organizations such as Mozilla and GNOME maintain a central issue tracker for many projects which is a good place to look for ideas. Mozilla has an interactive tool to find ways for you to contribute. The GNOME project put together a newcomers guide for people who want to contribute code.

Project Management

I was also interested in improving software engineering and project management skills. I don’t (currently) maintain any open source projects, but I have a few ideas kicking around that I will want to launch some day. It was really helpful for me to learn about what people are expecting from a project’s repository and maintainer.

At “Build Management for your Personal Project”, I learned a few tricks to make a repository easier for myself and users. Making an approachable repository is essential if I ever want to grow the project beyond myself. Plus, a repository that’s more documented and fleshed out will make it easier for future me to resume the project.

A lot of what was talked about in “Build Management” was reiterated in “Launch Your Open Source Project”. The gist of it all is: Have a (Readable) README!. It should:

Outline the basics of the project: What is does, Why it is useful, How to use it
Outline how to contribute and point to where to find more information (eg, CONTRIBUTING.md, ROADMAP.md, CODE-OF-CONDUCT.md)
Be focused on the User (not the maintainer)
Be brief

If you want other people to contribute, you need to reduce the barrier as much as possible. Lay out this information in a separate CONTRIBUTING.md. For example, that document might explain:

Which issues are good ones to start with
How to make a pull request
If a contributer should assign themselves to an issue or not
A code of conduct for how to behave towards other users
How to format a commit, pull request, or issue
How contributions (including non-code contributions) are recognized

It’s also important to think about what license the software is under, as this could effect what kind of derivative projects are allowed. Code falls under copyright law, so if there’s not license specified, it defaults to all rights reserved.

If the project is using user data (which most of my ideas do), consider the ethics of your data practices. Data has a lifecycle that should eventually end in deletion, and the user should always have the option to delete their data when they request it. If the data will be used for anything other than it’s intended purpose, the user should be notified (and given the option to opt out). Questions to ask about data include:

Who has access to the data? (User, Admin, Anybody…)
How much of it is collected? (How Often? What format?)
Where is it stored? (Database? Server? Encrypted?)
How is it collected? (Website analytics? Log files? Javascript? Cookies?)
What are the use cases for the data? What data do you need?
Who do you share the data with? Do you provide an API?
What analytics are okay? Why?

I’ve already been using Semantic Versioning for most of my projects, but it’s also important to keep a changelog. The changelog is a place for human-readable diffs. It’s much easier to read a well-organized and bulleted changelog than to scan hundreds of commits for changes. The changelog should be updated for each Major/Minor/Patch release. Each version should also be provided in a way that makes installation easy. Ideally, you want the user to be able to download one file and run the application.

A lot of this feels like overkill for certain projects. However, I think for the majority of projects it is extremely important to consider project management early. Having a plan laid out at the beginning will make growing a community for the project easier. And thinking about issues around data and privacy early will also promote ethical practices.

Culture, Inclusivity, and Technology

Because humans build technology, our culture is embedded in the tech itself and the subcultures that surround it. There’s a lot of room for improvement in the tech world, both at a systematic and personal level. Everyone at Open Source Bridge is working at the personal level to make people feel welcome and valued. However, the systematic level is more difficult to change and requires teamwork.

The first 2 keynotes really focused on improving the culture of technology. Tech, like most jobs in the United States, suffers from monoculture. In the last few years companies and schools have gotten better at making noise towards diversity efforts. For example, my school boasts that 33% of the student body are women. It’s great that they are moving towards equitable enrollment, but we aren’t done.

Most talk about diversity these days boils down to statistics about the number of women. We don’t often see statistics about retention, pay equity, seniority, or “softer” measures such as satisfaction. And most tech companies have not made nearly as much effort in recruiting people of color. Statistics, of course, obscure the humans they attempt to describe.

Lessons Learned

I am interested in making technology more accessible. That means making it open, both in philosophy and source. It also means intentionally building a welcoming culture that explicitly considers the needs of people not currently involved. I’ve been thinking critically about tech culture for a long time, and it was refreshing to be around like-minded people for a week. The next step is applying the concrete lessons to projects I want to get off the ground!