Too many of us who work with open source software in our daily lives think of ourselves as users, people who merely take advantage of open source tools without considering ourselves as an integral part of the development process. That's right. By working with an open source tool, you're automatically part of that tool's development process. You are not a user. You are a contributor. Whether you're a good contributor or a bad contributor is up to you—you still have a responsibility.
Look at it this way: in the proprietary software world, an application's development involves more than just the people who write code. There are whole departments dedicated to quality control, documentation, and marketing. Most open source projects don't have the luxury of having those departments. We are those departments. And, generally speaking, we aren't great at our jobs.
Segregating ourselves into developer and user silos is a cultural hold-over from proprietary software. It's a mistake to attempt imparting that culture in the world of free and open source software. The community of people working with and on a particular tool is as much of a valuable feature as any of the ones that are coded.
For open source applications, it's not sufficient to sit on the sidelines as a mere user, complaining into the ether that something isn't working or that documentation isn't thorough.
That part of the program that doesn't work? You could have caught it in a release candidate or test build and reported the bug. That inaccurate or deficient documentation? You could be the one to flesh it out. And all that complaining isn't exactly helping to paint a positive impression of our community as a feature.
So what can you do? Well, the simple answer is "be better." Of course, while that snarky response certainly makes me giggle, it's not particularly helpful. Let's take a different tact. As I wrote earlier, we, the folks who regularly make use of open source tools, are essentially the equivalents of the marketing, documentation, and quality control departments in a closed-source shop.
While there's a high percentage of polymaths among open source coders, they simply don't have the available time to effectively write, test, document, and market their tool, especially if they're doing this in their free time. So it comes to us. Here's a rundown, not just of what you can do, but what you should be doing.
Marketing
In a way, marketing is the easiest of all because it ties into everything else—make fantastic stuff and show it to the world. You don't even really need to share that you used an open source program to do it. If what you've made is impressive enough, people will ask. This is particularly true for open source tools used for creative production, but it's not exclusive to that domain. People evaluate a tool based on the work that other people are doing with it.
These are little things, but they mean a lot. And you need to start with little things, not just for building trust in the community, but to save yourself from burnout too. It's not really prudent to jump up and offer to redesign the website for your favorite open source program. Even if you do manage to convince everyone else that you have the skills and credibility to pull off a project of that scale, it's a huge thing. It's going to require a lot of coordination: decisions, communication, and so on, and those kinds of big requests/offers happen all the time because everyone thinks that they can do it better.
Start small and start where marketing is most needed and effective. Show up. Be awesome. Let folks see you doing it. When they ask how, tell them.
Also, don't be a jerk about it. Remember that the community is a feature of the program, and you're part of it.
Documentation
This is a big one that always gets listed in those "things you can do" articles. And it's true. For free and open source applications, quite a bit of our documentation is just horrible. Either it's not thorough or it's overly technical or it (and this is my favorite) only covers installation. Bad documentation doesn't just make a program more difficult to use, it's also pretty bad on the marketing front.
The easy (and perhaps too-often offered) recommendation is to contribute to whatever official documentation project is tied to the program, if such a thing exists. And if it does exist, that's definitely still where the most meaningful contributions can be made. However, just like with marketing, you want to start small and start where it's most needed and effective. Sometimes a Wiki doesn't exist, or there isn't an official repository for documentation. And even if there is, it's probably a good idea to develop some trust with the people who are already there. They should be able to believe that you actually know what you're talking about.
So maybe start on your own space, or some space on social media. Write tutorials or overviews on a blog. Create feature walkthroughs and video tutorials. Post those on the interwebs. Write articles on sites like this one. If you're really ambitious, write a book.
You can also build example files, templates, and presets. If you're working with a tool on a regular basis, chances are good that you've created some assets that help you with your workflow. They could be templates in a word processor, brushes in a paint program, material settings in a 3D renderer, a particularly effective window layout for specific tasks, your .vimrc file, the magical command line incantation you use for encoding to a particular video codec. All of these are useful productivity assets, and they're valuable for documentation. Who knows? Perhaps they're good enough and general enough to eventually bundle with the official release of the application.
Whatever you create that's related to documentation, release that content under a Creative Commons license and then offer it to the documentation team. All of these things double as both documentation and marketing (assuming you do them well, and you will... I just know it!).
Of course, there's the possibility that your offer to the official documentation project might be rejected. That's not a huge worry, though. A rejection doesn't necessarily come because what you've made is bad. Sometimes it's just not the right fit (for example, some documentation projects are purely reference documentation and tutorials don't quite fit). You've still created documentation, and now you've at least built up a bit of credibility. If you follow the guidelines of the documentation project, there's a much higher likelihood that your future work will be included.
Quality control
This is the other big one. The key thing I want to lean on here, though, is timing and technique. While it's always helpful to report bugs, the "when and how" of those reports is pretty important. For instance, it's a lot more useful to report a bug or performance regression before the next stable release. There's a reason why people avoid the .0 release of any particular piece of software—it’s because it hasn't been thoroughly tested. And in the free and open source software world, a big chunk of that responsibility falls on us.
So you need to actually use release candidates and development builds. And when I say "use,” I mean really use for real tasks. I don't mean just opening the program and poking around at new features. Use it for real work (you backup your data anyway, right?) and see if anything breaks or slows down. If you're really adventurous, make your own development builds by downloading the source and compiling it yourself. In most cases it's remarkably easy, even for non-coders.
And when something does break, make your report useful. Posting in a random web forum? Not useful. Most projects have some kind of bug reporting/tracking system. Make your report there. When making your report, do everything you can to ensure that the issue can be replicated. Explain exact steps you took, provide relevant details about your computer's hardware and operating system. Ideally, include an example file that highlights the issue. If a programmer can't reproduce the issue, the likelihood of a fix drops exponentially.
Responsibility
There are a lot of benefits and advantages to working with free and open source software. However, when it comes to manpower, these projects are at a marked disadvantage. For years, we've been considering non-coder contributions of marketing, documentation, and quality control as acts of good will. But it's time for a bit of a tweak to that mindset. That behavior isn't charity, it's a responsibility.
Now, I'm not saying that it's incumbent upon you to go out and market, document, and do bug reporting on every piece of open source software that you use. Again, that's a way to burn yourself out with a quickness. Start small and start where it's most needed and effective. Pick one tool you use and do one of those three things (one should be easy, you're already making fantastic work, right?). Then, over time, add other tasks. Then maybe start doing the same with one other program you use. And go from there.
The more you do that and the more people who follow suit, the better things get for everyone.
4 Comments