|
| 1 | +--- |
| 2 | +title: "Using open source work to offset the bias against short-term contracts" |
| 3 | +description: Using open-source work to offset bias against short-term contracts. |
| 4 | +date: 2025-11-17 00:00:00 +0100 |
| 5 | +categories: [Documentation] |
| 6 | +tags: [documentation, career, open-source] |
| 7 | +pin: false |
| 8 | +image: |
| 9 | + path: /assets/img/cover-images/using-open-source-work-to-offset-the-bias-against-short-term-contracts.png |
| 10 | + alt: Cover image showing the words “Open-Source Contributions & Short-Term Contracts” in bold text. |
| 11 | +published: true |
| 12 | +--- |
| 13 | + |
| 14 | +Short-term contracts are common in technical writing, but they come with a reputation problem. Even when you do excellent work, a series of brief engagements can raise questions during hiring. Open-source work offers a practical way to offset that bias and build a stronger professional profile. |
| 15 | + |
| 16 | +Technical writing roles are sometimes short-term because businesses seek specialized, time-bound expertise. These contracts typically last less than twelve months and focus on specific documentation needs, while long-term contracts involve deeper engagement with product teams and release cycles. |
| 17 | + |
| 18 | +Some technical writers rely on short-term contracts because they are the most accessible opportunities available to them. Factors such as location, market saturation, and personal circumstances also influence the types of roles they receive. |
| 19 | + |
| 20 | +## The advantage of short-term contracts |
| 21 | + |
| 22 | +Short-term contracts offer clear advantages. One important advantage is that short-term contracts expose you to diverse industry experience faster than long-term contracts. You can work in healthcare, fintech, and e-commerce within a few years. Each contract exposes you to different documentation systems, style guides, and user bases. |
| 23 | + |
| 24 | +For instance, you can spend eight months documenting API endpoints for a payment processing company. Then your next contract puts you in a medical device startup, writing regulatory compliance documentation. Six months later, you're creating user guides for enterprise project management software. In less than two years, you've gained expertise that would take many years to accumulate in a single company. |
| 25 | + |
| 26 | +## The downside of short-term contracts |
| 27 | + |
| 28 | +Despite the clear advantages, short-term contracts have their downsides. In my experience, the major downside is the bias many potential employers and recruiters hold against them. They view a resume full of brief engagements with suspicion and may question your loyalty. They wonder if you lack the persistence to work through difficult problems or challenging team dynamics. |
| 29 | + |
| 30 | +Some assume you were let go from each position. Others think you’re a job hopper who will leave as soon as a better offer appears. These assumptions are mostly wrong, but this is the reality you face when your resume shows a pattern of short-term engagements. |
| 31 | + |
| 32 | +## Open source to the rescue |
| 33 | + |
| 34 | +The right balance of short-term and long-term engagements is best. This mix lets you gain diverse industry experience while avoiding the red flags that come with a resume full of short-term contracts. |
| 35 | + |
| 36 | +The question now is: how do you get long-term engagements when long-term contracts are scarce? |
| 37 | + |
| 38 | +Working on open source projects offers a solution. While <a href="https://damilola-oladele.dev/posts/documentation-experience-in-open-source/" target="_blank" rel="noopener noreferrer">getting started with open source isn't easy</a>, it's often easier than finding a long-term contract. This is because many open-source projects have documentation problems. So most maintainers are eager to find experienced technical writers who can commit to helping out over an extended period. |
| 39 | + |
| 40 | +### Finding an open source project |
| 41 | + |
| 42 | +Once you decide to pursue open-source work, the next step is finding the right project. |
| 43 | + |
| 44 | +Start with projects you already use in your daily work. If you rely on a particular library, package, or framework, investigate whether they need documentation help. Since you already understand the tool, you have a head start on contributions. |
| 45 | + |
| 46 | +You can also explore platforms like <a href="https://openhub.net/" target="_blank" rel="noopener noreferrer">Open Hub</a>, <a href="https://github.com/explore" target="_blank" rel="noopener noreferrer">GitHub Explore</a>, <a href="https://libraries.io/" target="_blank" rel="noopener noreferrer">Libraries.io</a>, and <a href="https://sourceforge.net/" target="_blank" rel="noopener noreferrer">SourceForge</a>. Then reach out to their maintainers through their communication channels. Many projects use Discord, Slack, or Discourse for community discussions. You can introduce yourself and express interest in contributing to documentation. In some cases, you might need to send an email directly to project maintainers. |
| 47 | + |
| 48 | +Some projects host their source code on GitHub or GitLab. You can reach out by commenting on documentation-related issues or searching for maintainer contact information in repository files. Also, many maintainers include their public social handles in their profiles. Use the information to reach out to them. |
| 49 | + |
| 50 | +Understand that this process takes time and effort. You'll need to reach out to multiple projects to increase your chances of finding the right fit. Not every project will respond, and not every response will lead to a commitment. So be ready for many disappointments. |
| 51 | + |
| 52 | +### Selecting the right open source project |
| 53 | + |
| 54 | +Any open-source project with documentation work is valuable, but some are easier to contribute to, and some are more valuable than others. |
| 55 | + |
| 56 | +Start by prioritizing projects with active communities. This ensures you can get help when getting started, understand the project’s documentation standards, and receive faster feedback on your contributions. An active community also signals a healthy project that is likely to continue for years. |
| 57 | + |
| 58 | +At the same time, consider the size and popularity of the project. Contributing to a well-known project carries more weight with potential employers than working on a small or obscure one. Larger projects also tend to have better-organized documentation processes and clearer contribution guidelines. |
| 59 | + |
| 60 | +Finally, whenever possible, focus on open-source projects that are products themselves. These projects operate like commercial products, even though they are open source. They have dedicated user bases, regular release cycles, product roadmaps, and professional maintenance standards. Think of projects like <a href="https://www.djangoproject.com/" target="_blank" rel="noopener noreferrer">Django</a>, <a href="https://kubernetes.io/" target="_blank" rel="noopener noreferrer">Kubernetes</a>, <a href="https://wagtail.org/" target="_blank" rel="noopener noreferrer">Wagtail</a>, or <a href="https://www.postgresql.org/" target="_blank" rel="noopener noreferrer">PostgreSQL</a> that companies actually build their businesses on. |
| 61 | + |
| 62 | +This distinction matters more than you might think. Working on open-source projects that are actual products demonstrates to potential employers that you have experience in a product environment. It shows that you understand end-users’ needs, feature documentation, release cycles, and cross-functional collaboration. |
| 63 | + |
| 64 | +### Doing it right |
| 65 | + |
| 66 | +Finding and selecting an open source project isn't enough. Since open-source work is easy to track, you can't make minor contributions just to add the experience to your resume. |
| 67 | + |
| 68 | +Potential employers can visit the project repository and see exactly what you contributed. They can review your pull requests, read the documentation you wrote, and verify the scope of your involvement. Claiming significant contributions when you’ve only fixed typos or formatting issues will backfire. |
| 69 | + |
| 70 | +Also, since the goal is to offset the disadvantage of short-term contracts, your open-source engagement needs to be long term. Commit to working on the project for more than 12 months. This duration demonstrates the same qualities that employers look for in long-term contract candidates: dedication, reliability, and the ability to see complex projects through to completion.<br><br> |
| 71 | + |
| 72 | +This post isn’t meant to create bias against people who prefer short-term contracts or those who have no choice but to accept them. The goal is to share a strategy that helps technical writers build stronger professional profiles when opportunities are limited. A combination of short-term contracts and long-term commitments through substantial open-source work creates a balanced approach that supports your career growth and presents a compelling resume. |
0 commit comments