This is a guest post by OpenHatch volunteer marktraceur (Mark Holmquist).

I spend some of my free time practicing and thinking about a form of acrobatics called parkour. In parkour, one tries to find the most efficient path from one point to another, often with various obstacles in the path. After practicing for a few days, you may find yourself with “traceur goggles” – seeing walls and rails differently, seeing moves in the landscape before even approaching the obstacles themselves, even when outside of training. This effect wears off over time, but it’s exhilarating.

As a software engineer, I feel like I see something similar to “traceur goggles” when I use computers. I often find myself interacting with software, not only hoping to do something useful like write a blog post or send an email, but also aware of how the interface might be better, how it could be faster, or how to fix one bug or another in the program. The untrained eye might look at a wall as just something to walk around, or to signify a forbidden area, where a traceur might see something to climb up. Where someone without software development experience sees a tool for sending emails, a programmer might see an opportunity to build something cool.

This is an important aspect of how we build excitement in new contributors to free software projects, too. When new programmers, or even experienced programmers who are new to free software, enter the scene, they often start seeing lots of projects they could contribute to and help with. They see a lot of ways they could make Firefox better, or Ubuntu easier to use, or emacs a little faster. Maybe they catch bugs in OpenHatch, or GNU MediaGoblin, and report them to the bug tracker. They might even build their own project to fill a need in the community. The excitement of finding bugs, helping projects, and building your own projects that people will actually use, is a power that is hard to match.

But when you’re wearing “traceur goggles”, you realize that private property, or public property with posted signs, is not ideal for practicing parkour. “No parkour” and “no trespassing” signs restrict creative expression, causing frustration when you see you won’t be able to overcome a cool-looking obstacle. I also get that feeling when I use non-free programs, where source code is not available, or source code is visible but not legally modifiable by third parties. It’s a private property sign that’s often implemented as hard protections in software. Working in free software is like something the parkour scene rarely, if ever, sees – a community building a place where its members can express themselves with fewer restrictions.

But people coming into a free project will often be a bit lost at first, and they may come away with a bad impression. OpenHatch helps avoid that initial confusion by teaching basic skills useful for working on any project. OpenHatch also helps contributors work on their first tasks, such as smaller or easier bugs, which helps them understand the importance of being able to work on the software they use, especially since one way we suggest projects to work on is to ask the prospective contributor which free software programs they use. Helping people change the software they use can also give them new insight into the ideals of the free software movement. Those ideals aren’t essential for starting to work in free software, but they’re important to continuing in the long term even when it gets harder.

I’m excited to see what amazing moves the next generation of programmers bring to the obstacles that have been left for them, and I hope you decide to join us in working on those solutions in the free software world, so everyone else can benefit! You can also support OpenHatch with a donation.

One comment

  1. [...] Not everyone needs to learn how to code, but there are plenty of ways to develop a more empowering relationship with software and how it is designed, created, maintained, distributed, marketed, controlled — how it [...]

Write a comment