Furward Momentum (Introduction)
- Building Your Support Network and/or Team
- Mapping the Technology Landscape
- Learning the Fundamental Skills
- Choosing Your Path
- Starting and Growing an Open Source Project
- Building Your C.V.
- Getting Your First Tech Job
- Starting a Technology Company
- Career Growth and Paying It Forward
When you’ve reached this stage, you’ve already mapped out the technology landscape and learned the fundamental skills for your chosen profession. (Education is an ongoing thing, but you should at least have a solid grasp on the basics.)
And then you, along with the rest of the think tank, decided on the path you wanted to pursue. So you might expect the immediate next section to differ depending on which option you chose. That’s not so.
Whether your destination is employment or entrepreneurship, the immediate next step is largely unchanged. What differs is the details of your strategy.
Goals for Job-Seekers
Your goal is, ultimately, to demonstrate all of the following to prospective employers:
- That you have real-world experience with the technology you purport to know.
- That you are capable of working with people (especially if your desired career involves written communication skills, which it almost certainly does).
- That you are capable of making individual technical contributions to a new or existing project.
- That you are simultaneously capable of looking at the big picture and diving deep on technical problems.
This might seem like a short list, but each of these points is incredibly valuable. It is worth dedicating some time toward purposefully demonstrating each of these as you work on open source software.
Goals for Start-Ups
Your initial goal is to establish yourselves as local experts in some niche. Open source software will mostly be used for transparently demonstrating your team’s technical aptitude and community focus.
As your company grows, open source software will become a reliable recruiting funnel for finding skilled technologists to hire. (Possibly even the people reading this guide right now who chose the other path.)
But at all stages in your company’s maturity, open source projects are an effective way to develop and rapidly prototype a new idea, which can become the cornerstone of some new innovation that gives your company a competitive edge.
What If My Software Sucks?
That’s fine. It’s OK for your open source project to be a bit shitty.
Why Start an Open Source Project?
Regardless of your goal, you need two things if you want to succeed:
- Real-world, hands-on experience with technology
- Reputable participation in the technology community
There are many possible avenues toward achieving these goals. If you have a better one in mind, I implore you to try your way. If it works for you, great.
The two ways I know to do this are to contribute to a larger open source project (which may be tricky for newcomers) or to start your own. Choosing one does not prevent you from pursuing the other.
How to Start an Open Source Project
If you’ve familiarized yourself with version control software (i.e. Git) when you were learning the fundamental skills, you may have already started an open source project (even if you don’t realize it). If you haven’t, start reading here.
The first step in starting any open source project is to identify a problem you want to solve with software.
This can be as small as “Node.js’s scrypt function has an unfriendly interface so I’m going to write a human-usable wrapper” or “I want a native ByteArray object in PHP to improve performance and reduce memory usage”.
This can be as large as “I want to write my own text-based online RPG framework”.
Some of my past projects included:
- Fursona Sticker Switcher: Simple GUI app that swaps out an image (or symbolic link, if your OS supports it) so you can swap out an active image in your OBS overlay with a single click during livestreaming.
- FAQ Off: Choose-Your-Own-Q&A platform intended to make a type of online harassment easier to mitigate.
- FloofPal: Simple GUI app that watches your Twitch chat and greets new viewers (and swapping out different images; i.e. animated GIFs).
- Dhole Cryptography: JavaScript and PHP wrapper for libsodium for use in furry projects.
My projects have something in common: They provide something for the furry community. (Often, the furry streamer community.)
If you ever find yourself hating to use a specific library or interface when you work and want to write a different user experience that’s easier to use (which wraps the crappy library or interface), that’s a perfect open source project.
If you’re pursuing an entrepreneurial path and find a lot of people complaining about how much time they waste doing Task X, writing a tool to automate Task X is a great idea.
With an idea in hand, all you need to figure out is licensing, project hosting, the project structure, and which (if any) integrations you wish to use, and then you can start writing code.
Project Licensing
If you do not release your open source project under a public license, anyone who uses it is (by default) committing a copyright violation.
For this reason, you’ll want to choose a license for releasing your work. Some popular examples (and their motives) include:
- ISC License — “Use it however you want, even if you make money off it, just don’t try to sue me if it sucks.”
- MIT License — Despite being the most popular option, there isn’t really one “MIT” License. The main differences between MIT and ISC are the sort of thing only lawyers care about.
- GNU Public License (GPL) — “I care about user freedom, as defined by the Free Software Foundation.” A lot of companies are allergic to GPL code. This can be an advantage or a detriment, depending on your goals.
There are literally hundreds of other licenses to choose from.
Project Hosting
Once you have your idea, you next need to decide where your project will live: Will Github be a good place to host it (or is Gitlab or BitBucket more appropriate)? Is this a personal project or a team effort that needs to live in an organization’s repository?
These are the kind of questions that most technologists don’t consciously think about much, but we’ve built up the muscle memory already.
Project Structure
If you’re starting from scratch, you’ll need to think about your project’s folder structure. I typically do something like this:
- bin — Command line programs (calls code inside src)
- docs — Documentation
- lib — (optional) Library functions (what gets exposed in .so/.dll files) for C projects
- public — (optional) Public document root for web-based projects
- src — Tested source code
- test — Test code (unit and integration tests)
This may or may not be sufficient for your projects. If you’re writing an extension to an existing framework, a lot of these decisions will already be made for you.
Integrations
At a minimum, open source projects are generally expected to have continuous unit testing, typically facilitated by Travis CI. This lets you know whether a pull request will break your project or not.
How to Start
First, you’ll need to decide if you’re starting an individual or a group project. (You’ll want at least one of each, at the end, but pick which ever one is easier for you to start with.)
For individual projects, you own the whole shebang.
For group projects, you’ll want to decide who will own what aspect of the project. The easiest way to decide this is to assign roles. The rules are made up and the points don’t matter here, but one example of what this might look like is:
- Project Manager: Does high-level overview and planning stuff. Responsible primarily for breaking big problems into smaller chunks and delegating them among the rest of the team.
- Front-end Developer: Got design skills? Want to make your product look polished, easy-to-use, and accessible to people with disabilities? You’ll shine in this role.
- Back-end Developer: Are you more interested in how stuff works than how it looks? Back-end developers tend to shine here.
- Technical Writer: Documentation is your domain. Making sure everything from the README file to every last page of the reference manual is up-to-date and accurate is your charge.
- Community Advocate: The person who triages bug reports, reviews pull requests from third parties, and owns the responsibility for reporting upstream bugs to other projects. This should almost always be someone who has a lot of patience and communicates very clearly.
Growing an Open Source Project
Open source projects grow based on two factors:
- How much interest they gain in a wider community (which is a marketing problem).
- How successful they are at attracting new contributors (which is both a documentation problem and, rarely, a “not being toxic assholes” problem).
I’m not a marketing expert. Understatement of the year, really. There are plenty of guides on the Internet written by people who understand the marketing and governance problems better than I do.
However, there are a few tricks I’ve learned over the years that tend to make an open source project grow:
- Build something everyone needs.
- Build something everyone wants.
- Contribute heavily towards another project that yours integrates with, and someone from the other project will become interested in what you’re doing.
A quick note on contribution: It is absolutely valid to contribute additional unit tests to another project. It’s equally valid to contribute documentation improvements.
Some of the Old Guard in open source engage in an excessive amount of gatekeeping, and will insist you’re not a “real” developer if you only fix documentation or add test cases.
Fuck those guys! (And, yes, it’s mostly men who are guilty of this.)
If you’re materially improving an open source project, you’re an open source contributor. If you had to read, understand, and/or write code in the course of your contribution, you’re a “real” developer. Do NOT let Impostor Syndrome take root.
What’s Our Stopping Point?
Open Source never really stops.
Once you’ve started a few projects that other people use (even if it’s just other people reading this guide) and maybe even contribute to (even in small ways)…
Once you’ve opened a few issues and/or pull requests on a handful of other open source projects…
Once you’ve experienced the joys and pain of running a software project (big or small), you’re ready to move onto the next step in the series.
Next: Building Your C.V.