10 things I do to keep open source projects healthy and stress free.
Tags: opensourcesoftware, health, coding, softwaredevelopment
Published: 2017-01-31 04:04:39

---
title: 10 things I do to keep open source projects healthy and stress free.
published: true
description: Tips and things I've learned from my time contributing to open source.
cover_image: https://36iusc2tb88y2g492si2bqd1-wpengine.netdna-ssl.com/wp-content/uploads/2015/09/healthy-lifestyle.jpg
tags: open source, health, coding, software development, stress, health
---

On the first days of 2017, I began working on my latest open source project. It's something designed and built to solve one of my business problems. The project is called Bootparts, and it aims to simplify the process of building websites. Check it out [here](https://yelluw.github.io/Bootparts/) (and star it).

This is not my first entry into the FOSS world. Throughout the years, I've made contributions to different projects in various manners. This time, however, I was in charge of everything. Which put an extra amount of pressure on me. Pressure that I did not expect. Rather than simply ignore it, I decided to manage and deal with the pressure in a healthy manner. Here is how I've done it:

## I decide when to work on the project.

One of the biggest complaints I hear from the open source community is that people expect maintainers to work around the clock. People are shamed and pushed into working long hours (without pay) in order to fix bugs and corner cases. This causes burnout and hurts the community as a whole.

From day one I decided to only work on the project when I wanted. If anyone needed anything added to the project they could fork and add it themselves or pay me (Yelluw) to add it. I'm not against feature requests. What I'm against is the expectation that all open source work is free (as in beer). By limiting when to work on the project I'm reducing the amount of pressure. Any unreasonable expectations from outsiders is simply handled by this rule.

## I take breaks.

Resting is important. More so when you are working on your off hours on a project. I know it's hard for some people, but working too much reduces the amount and quality of the output. Taking breaks allows me to think about the implementation and come up with better solutions. It also allows my mind to aimlessly think about other code. Focusing too much on one codebase tends to be tiring.

My rule of thumb is that for every two weeks of work I rest no less than three days (in series). Not a single line of code is written during the breaks.

## I set expectations early.

By setting expectations from the start, people can't guilt you into doing something that you don't want. For me, expectations are simple:

- I will not offer support.

- I will only fix bugs that are properly reported and are important (they affect me or my paying clients).

- I will not accept contributions.

- I will not accept donations.

These four clear expectations drive away people. I do lose interest from some well meaning developers, but it's the price to pay for peace of mind.


## I document from the start.

This is simple, yet effective. I document the project to reduce the amount of questions and support requests. This lesson was learned years ago. Leaving undocumented code meant other developers would interrupt me during the workday to ask what I thought were stupid questions. Turns out they were not stupid questions. I was being the stupid one by not documenting the code in order to make implementing it simple. Now I document from the start and also make sure to get feedback on the documentation.


## I close issues quickly.

There is no sense in keeping issues open if I don't plan on dealing with them. Out of sight and out of mind.


## I don't accept contributions from everybody.

Not everyone is fit to work on this project. We might not be able to collaborate together. People tend to think that project maintainers **have** to receive their contributions with open arms. No. Not at all. It is up to me to decide if your contribution:

- Fits with the general project roadmap.

- Does not add any additional work overhead.

- Is properly documented.

Does this seem too harsh? Yes, it is harsh. But it works for me. I don't want to spend my time dealing with BS. I want to write code and get paid.


## I don't accept everyone's feedback.

Turns out that there is a fair amount of bad feedback out there. People tend to give feedback without taking the time to understand the context of the project. See, every project has a context under which it's developed. Feedback (advice) that is given without it is trash. I've had people tell me that I should fix this and that because it makes the project unusable (while I'm using it myself on production).

Opinions are like assholes. You will encounter a few everyday. Learn to properly deal with them.


## I define success.

This is where some people tend to lose steam. It takes a lot of time and effort to have a project that **people** consider a success. I don't care if people think the project is a success because I define what success means. Is this project successful? Yes! It has already saved me time and effort. But that's not a coincidence. The project's success was defined from the start as:

*The project will be a success if I can cut down the time I spent working on websites for my clients.*

Success is not based on some vanity metric like how popular it becomes. It is based on the real impact it has on my daily grind. Always define what success is to you and don't let anybody convince you otherwise.


## I have fun with it.

I find coding to be fun (under most circumstances). Having fun means that I enjoy working on it. Even when I'm not too in love with the idea of doing so.

## I learn from it.

We all make mistakes. The first release I sent out had a big bug! But I found it and learned from the mistake. Learning also means that I'm not ashamed of mistakes. No. It means that I will take mistakes as life's way of pointing out what I need to learn next.


## Conclusion

Working on open source projects is very fulfilling. It can also be very stressful. I know that some of the things in here may seem a bit too extreme, but I take my health seriously. I hope these post makes you rethink how you work on your open source project and how you approach maintainers. We are all people with a love for technology. Till next time!


`Need a kick ass Python / Django Developer? Let's talk!`
`Email me at pr@yelluw.com`