Build In Public Journal #2
Refining a startup idea, buying some domains, and getting some work done - all while traveling to the beautiful city of Porto 🇵🇹
Hello friend,
I'm excited to share with you what I've worked on over the last couple of days. I'm pleased with the progress, refining the idea, buying a domain for the project and starting the research of how open source projects are implemented.
I'm happy to add as many details as possible in these posts, so you can see my thought process and feel inspired to work on your own projects. Also, I really appreciate receiving feedback. Not having a vast amount of experience in contributing to open source projects means I make mistakes. Your feedback is highly appreciated.
A short summary from my previous post: I've started the "12 startups in 12 months" challenge. I'm aiming to build a product every month. The one that I'm working on right now is a glossary app. I hope to lower the barrier of entry into the tech industry for newcomers. I want to help people understand difficult tech terms through this open source project. If you're experienced in the field, please consider getting involved into the project.
This is what happened in the last couple of days:
All the domains are taken
I did a couple of hours of research trying to find a proper domain. There are many great once, but most are taken. The problem is, they're not taken and used. I believe some people simply buy and hold onto them. There are many .com, .tech or .io domains that I could've used, but they were already taken.
I was trying to find something with glossary. That made sense, but I couldn't find any available domains that were also short. Actually, I did find some, but they were $9000+ (at least, according to namecheap.com). No way I'm spending that much. I could travel for months with that money. 🤣
Lexicon and wordlist didn't sound right. The first one felt a bit too serious or academic. The second one made me think of Storybook, for whatever reason.
I thought about explain or define. But again, those domains weren't available.
But after a while, I finally saw the light at the end of the tunnel. With the help of ChatGPT, I managed to find some domains that were available. I had to choose between:
geekyterms.com -> This didn't sound too interesting to me.
nerdterms.com -> ChatGPT recommend this, but it doesn't have the right musicality. If I were to tell someone about my product, it's harder to pronounce.
techterms.io -> This is a good candidate. I would've preferred a .com domain, but this works.
nerdyterms.com -> This is also a good candidate. It has musicality, it is playful and you get a sense of what it's about right away.
So what did I choose?
I decided to buy two of them: techterms.io and nerdyterms.com. I believe I'll give them different uses, but for now I'll use techterms.io for my open source project since it sounds a bit more professional.
Social media
Now that we have a domain, let's create some social media accounts. I don't know yet which direction the marketing for the project will go, but for now, let's secure some accounts:
X account - https://x.com/techtermsio
BSky account - https://bsky.app
Github organization - https://github.com/techterms
I still need to create some headlines, maybe a logo and do some proper branding. I'll start on that once I have some project management workflow in place. But for now, we should be good.
Researching - How to move forward
I don't have much experience with contributing to open source. From what I've seen, it's very different from working on a client project. Depending on the project type, how big the team is and how complex the workflow is, there are different approaches to managing projects. Not to say that if you've worked on some startups, you've probably noticed that people tend to cut some corners here and there and move faster.
So, creating an open source project that's reasonably well-written and documented can be difficult. I need to do some research, so follow along.
How to plan and manage the project
I'm starting the learning process by trying to answer this question: "How do you plan and manage an open source project?". I believe I can at least get started by watching what others are doing. I could study some Github open source projects and see how they create issues, how they plan future releases and everything else that goes into project management.
Build Your Own X
Github Repo: https://github.com/codecrafters-io/build-your-own-x
Build Your Own X is a collection of useful links for developers who want to build their own version of a particular software.
Why it might help me: I'm building a glossary app, a collection of definitions. The content of the app will be stored in the repository (same as for Build Your Own X).
This is what I've noticed during the research: they don't have a Github project or milestones to manage releases. They only have issues and pull requests. From a projects management perspective, I'm not sure this is helpful. I'll keep digging.
In terms of branching strategy, they mainly use main. I believe I need something a bit more complex. Maybe not the full Gitflow, but something in between.
Mockoon
Github Repo: https://github.com/mockoon
Mockoon is an open source software developed by my friend Guillaume that speeds up mock API generation.
Why I think this repo might help me: this is a mature project and Guillaume is a very experienced developer. At first glance, it seems to implement most of Github's features.
This is what I've noticed during the research: he has a dedicated repository for the website (you can check it out here github.com/mockoon/mockoon.com).
Multiple collaborators are involved in perfecting the project. That's also because they followed the best practices like having proper documentation, a code of conduit and clear instructions on how others can contribute to the project.
In terms of project management, they use a simple kanban board for the roadmap (https://github.com/orgs/mockoon/projects/9). They might also have multiple private projects that I don't know about.
There are two types of issues that they use: bugs and features. Bugs seem to have a predefined, yet a simple straightforward structure: Describe the bug, Steps to Reproduce, and some optional (Screenshots, Product version, Environment version). The features have a more flexible structure from what I can tell. In terms of branching strategy, they seem to be using main and features branches.
Some other useful resources I found
Drawing some conclusions
Based on the research I did, also my experience from past projects, these are some decisions I made in order to manage the project:
Since I'll be the only one working on the project at the beginning, I'll keep the workflow as simple and straightforward as possible.
We need a Github project and the following issue statuses: backlog, ready, in progress, in review, done
We need two issue types:
features - improvements we want to add to the project
bugs - details about what needs fixing
We need a contributing guidelines, a README and a Code of Conduct.
In terms of branching strategy, we could keep things simple for the beginning and have a main branch (that'll automatically be deployed by Github Actions) and feature and bug branches. Initially, I was considering having a develop branch, but I don't think this will be necessary since, after the core codebase is ready, we won't have many functionality changes, just adding more terms and content.
So let's get some work done
Now that I have the domain, the Github community and the repo, let's get some planning and some work done. I'm trying to document the tasks, but not overcomplicate the whole process. Anyway, I started the work by creating some basic tasks:
You can find the status of the project, the open and closed issues and what's been done in the Github repository: https://github.com/techterms/techterms
If this projects interests you (and you want me to feel the pressure of having many eyes on my work) you can ⭐️ the project.
Now a personal update
If you've followed my other social media platforms, you might know that I'm currently in Porto 🇵🇹. I'm surprised how productive I was this week. I think I should be visiting this amazing city more often and I’d highly recommend visiting Porto!
It has beautiful scenery, amazing food, and there are many tourists around. The city is alive. All the city's top attractions are within walking distance, but I also have to warn you: walking in Porto feels like a proper workout. It is very hilly, and you spend a lot of time going up and down, up and down. But I'd definitely recommend this city.
At the moment I'm writing this, I'll be here for another week. I'm not sure how much work I'll get done next week, since I'll also be taking some days off from work.
Thank you for reading this week's article.
See you soon!
Great newsletter! Congrats on the new open source project! I had a look at the issues and you have an issue about the logo, I look forward to see what you create for the logo.