9 things I wish I knew when starting open source project
By: Burhanuddin Rashid
Tags: Ci Cd Pipeline, Github, Open Source, Learning, Stress

9 things I wish I knew when starting open source project Burhanuddin Rashid Jun 17·8 min read

For more visibility posting this on medium. The original article is posted on my website. :)

This blog is about things I wish I knew or someone would have told me before starting an open-source project.

There are many types of open-source projects. We are not going to talk about big projects like Flutter, Kotlin, Android and React. Those projects are managed by giants companies that have large teams and investments.

We are going to talk about those open source projects which are created or managed by an individual developer on weekends with a full-time job. (Basically, people like me 🤪)

So let’s get started…

1. Writing tests

It’s sad that in the software industry writing test is still not a norm. In some projects, writing tests is considered a separate task instead of being part of the development cycle. I am not advocating TDD or 100% coverage here, although they have their pros and cons.

My point is to start regularly writing tests for basic business logic or end-to-end tests, which will create a habit of writing tests whenever you add something new.

3 years back I open source my android library without any test which leads to a lot of manual testing before I publish the library.

I started writing unit tests with 30–40% test coverage. In beginning, it was hard and took most of my time.

The value of this test shined when other people started contributing to the project. It saved a lot of time. I highly recommend asking contributors to write tests as well or else you will keep merging code with less coverage. Then I started writing end-to-end UI tests and it increased the code coverage to 60–70%.

Note: Those tests are not perfect and do not cover all edge cases. But it gives me enough confidence to merge and published it.

Tip: If you want to check the health of the project then look at their tests.

2. Automation

Automation saves time for repetitive tasks. We need to define it once and the machine will take care of it.

I learned 3 useful automation tools and techniques from my open source projects.

1. CI/CD

As I mentioned in the “Writing tests” section where I need to do a lot of manual testing before publishing the library. Even after writing tests, there were few repetitive steps that I need perform i.e running tests, running lint check, building jar, and publishing jar.

CI/CD is the solution for all these problems. 2 years back I was not familiar with CI/CD. It took me a month to set up the CI using a free Circleci service with help of DevOps at my workplace.

After using Circleci for a year, I switched to Github Actions for 2 reasons.

GitHub Actions usage is free for both public repositories and self-hosted runners. It’s easy to set up if your project is on GitHub. Basic tools are available on Github Action Marketplace

2. Using Bots

CI/CD took care of development and deployment workflow. I use bots for management workflow. Bots can be used to automatically add labels and update the status of an issue.

I learned this bot technique from other open-source projects like Flutter and Kotlin where if the issue has no activity or comment for X number of days then the bot first adds a warning comment, on the issue or PR, and then after Y number of days, it closes the issue.

My personal experience with open source projects is that most developers do not write a descriptive issue and need constant follow-up.

This bot also helps to close spam issues and all those create-and-forget issues.