TLDR; What started a few months ago as a small hobby project is slowly gaining traction as an open source project: github.com/SimplQ. Key lessons learned:
- Get a Minimum Viable Product up and running.
- Iterate over a Design Prototype.
- Work on a Product Roadmap and create small independent tasks.
- Use labels to let new collaborators identify easy issues to start with (
up-for-grabs,good-first-issueetc). - Add an informative readme and add detailed setup instructions, make the local dev environment easy to set up.
- Be open-minded when discussing solutions for issues and leave helpful reviews on PRs.
- List your project on websites where people look for projects to collaborate on
- Invest in good automation, CI/CD (TravisCI is free for public repositories).
- Use affordable cloud hosting. I used AWS free-tier (Got AWS Activate $1000 founder's credits).
- Invest in a meaningful domain name.
- Create a Github Organisation, update the description and create a simple logo. It gives your project a professional look... these things matter.
The key is not to find collaborators, but to make your project collaboratable.
Now the whole story...
In early April this year, we were four young software engineers locked up in our apartment, with no plans for the weekend, and wondering what to watch on Netflix.
The Idea
I've always been awed by apps like Splitwise, where technology is used to create a free software that solves some annoyances in our life. That's when my flatmate saw a newspaper article (yeah, he reads the newspaper) about how there are long queues in front of grocery stores, beverage shops etc during the lockdown. Us being reasonably tech-savvy, soon the topic of discussion changed to see if we could build a simple website, which would allow people to enter a queue virtually, without having to stand in a line. And voila, SimplQ was born.
The idea was very straight forward: If someone wants to manage a crowd using a queue, go to simplq.me, give the queue a nice name and your queue dashboard is created instantly. You can then manage people in the queue, add and remove, notify, call them up etc. A joining link / QR code is generated, which can be stuck onto wherever people used to line up, and now instead of waiting in the line, they can get into the queue by going to the link.
The database structure, backend, and the screens to be build were quickly finalised on a notebook, and we set out to work developing a basic MVP. Most of the work was completed in a weekend. Weekdays went with us focusing on our day jobs. We didn't want to leave it half done, so we worked on it over the next few weekends. We also enrolled in a Hackathon with this idea, which was very helpful as it gave us a deadline.
By the end of the hackathon, a fully functional prototype was completed.
Open Sourcing
Weeks went by, after which we decided that we should productionize it, so we worked on it in our free time to see if we can turn it into something that people would gladly use. We did two things:
1) Redesigned the UI to give it a more professional look. I got my artistic friend to help out. He learned and work on a new design prototype using Adobe XD.
2) We decided to open source the tool.
By this time, our companies had gone completely remote, we left Bangalore and went to our hometowns. We met online regularly over the weekend and iterated over the design prototype. This exercise gave three benefits:
We could finalise on a design, and everyone had a clear picture about what is to be done, and what it's going to look like at the end.
We discussed and incorporated a lot of UX improvements which we would have missed while implementing. The cost of iterating over a design prototype is lesser than iterating over an already implemented product.
We were able to take the design, and use it to create an implementation roadmap, and then break into small tasks. The design link and screenshots were used heavily in the issues created, and this proved to be very helpful as anyone why was interested in picking up an issue had a clear idea about the task.
Though we used XD I've also seen Figma being used a lot for prototyping. We haven’t had a chance to try it out yet, but free plans for both have all that's needed. If you are a creative mind like Akash, there are tons of tutorials for both the tools available online to get you started.
It is very important to have a Readme.md for the project, it should have detailed setup instructions to clone the repo and get the code running locally (ours here). Also needed is a Contributing section with some instructions(ours here).
Once we had a design, next was a website roadmap. It gives anyone who want to help out an idea about what's been planned, and how they can contribute in a way that their work fits into the project's overall plan. (ours here)
The key is not to wait for collaborators, but make your project "collaboratable". One of the biggest learning was to break a problem into independent tasks, and create well-defined issues on GitHub. The XD design that we created paid off. You can find a sample issue here. Someone looking at the issue should get a clear understanding of the task, then they send a PR most of the time.
The code should be easy to maintain and easy to change. We kept this in mind, and had to refactor and iterate till the code became decently S.O.L.I.D:
Once you create your well-defined issues, the next step is to label them properly. We use labels like You can do this and Good First Issue to mark issues that don't have any blockers which someone new can readily work on. People/tools discover open issues on Github through labels.
After this, list your project on sites where people look for open source projects to work on:
https://up-for-grabs.net/#/
https://goodfirstissue.dev/
https://github.com/MunGell/awesome-for-beginners
https://firstcontributions.github.io/
In the last few months, I also finished two books which were really helpful, The Lean Startup which speaks the importance of thinking MVPs and Zero to One which is a good startup myth buster.
Finally it proved very helpful that my good friend @maaveric was around to review all my PRs. We reviewed each other's code. When your code goes through someone's review, you naturally start structuring your PRs well, and maintain the code quality.
There are some more points in the beginning of the article that I did not cover in detail. Let me know in the comments if there are any specific questions. I will encourage you to give this a try, you will learn a lot along the way. Thanks for reading!
If you would like to collaborate with me on SimplQ, do check it out. Feature ideas, bug reports, feedback and suggestions are all welcome. (You can raise them as issues here). Please do comment on the code structure and how we could improve there if you are a seasoned web developer. My CSS is horrible, I think it can be improved.
Top comments (0)