This is part of a series aimed at beginner and intermediate developers, releasing or intrigued by releasing their ideas as Open Source Projects.
These reflections are biased and personal. More articles are planned. By sharing some reflections, I hope to inspire you to do your own projects
- Reflections (this)
- Learning Go lang as a Java Developer (TODO)
- Open Source Health and Community files (TODO)
- Open Source Security (TODO)
The needs
It all started years ago. I now and then needed something that seemed to always involve recreating the same old Bash script, either by me or someone else.
The overall requirements were simple, as they often are at a high level.
What we developers mostly do is really just about shuffling information from point A to point B, right?
Here, the goal was to mirror a bunch of Git repositories - to another Git provider, to disk, to an archive format, in a CLI app.
I needed this privately and in my work role. I've seen people struggle, investing a lot of time doing these things manually, and that bothers me.
Yet, it always seemed to stay as a simple Bash script. Quickly done, but as soon as anything extra had to be added - special cases, error handling, modularization, packaging, etc. - Bash scripts don't hold up for bigger tools, as most of us would agree.
So I decided to create a full CLI application for it.
The Pre-Decisions to be Made
Does such a tool exist already?
The first thing to do was to not reinvent the wheel.
There exist a few tools that are Open Source and solve this problem. At least one written in Go, a few Bash scripts, and if counting import functions like the one in Gitea.
I tried them out, but I couldn't find any that worked fully the way I wanted. And as I had other ideas of where I wanted to take the project, I decided not to deep dive into
starting to apply patches to the existing projects.
There also exist a few commercial tools, but I felt this small a tool is something that should also exist in Open Source forms.
Conclusion: There was a place for this CLI tool in this world.
Hacking on it at Work-hackdays or in Private free time?
We have hacking time at work at the end of sprints and on other occasions. One approach would be to hack on it during these occasions over time, crafting it into something useful.
I quickly decided to do it fully in my private spare time instead, for the following reasons:
- Hack opportunities at work should be used for short bursts of learning and creativity, not long-term carving of a full project.
- The solution doesn't fit into the core organization's business - it would always be an odd duck there if so.
- Tying it to work would make it feel like just more work - I'm doing this for fun and learning Go etc - it would put pressure and stress on me.
- Doing it on the work-hackdays would take forever. A few hours, spread over weeks.
Conclusion: I should do it for fun in my spare time.
Choice of Technology Stack
I've spent most of my time over the years in the Java/Kotlin world, with a few projects in JS/TS, Python/Ruby, and like every senior developer, dabbling in other at times.
For a long time though, I've wanted to really learn Go and/or Rust. So this would be an opportunity to get the motivation to dive into a new languague
The reason I picked Go is that quite a few CLI applications in the Open Source DevOps world are written in it, and I want to be able to submit patches to third-party projects at times. Also, writing in Go means one binary with many target architectures.
I was considering doing it in Java, for example, with Pico CLI and GraalVM of which of which I had a good impression since earlier tries but I decided that I really wanted to learn Go instead.
Conclusion: I should do it in Go and learn from that.
Other Learning Goals
With this, I also wanted to delve deeper into the subjects of delivering a nicely packaged Open Source project, following most of the Security practices - scorecards, SLSA,
and using tools like GoRelease to create builds of various kinds.
Conclusion: Take the opportunity to learn and delve into topics of your choice.
Keep the Scope
As I planned to experiment a lot, and I was totally new to Go, I knew I would do a lot of unstructured work.
Here it was important to set the scope - when would it be good enough for an alpha release?
I early on decided on what functionality it should have, and as tempting as it would be to sit and refine and expand it further, this was good.
I could sit with this for a long time.
Conclusion: Release the project as alpha when you are equally embarrassed and proud of it.
Estimation - How Hard Can It Be?
Learning a new language is a small part of learning the language itself, but much more about learning the ecosystem and its idioms.
What libraries are used, how are they used, what are the idiomatic ways of doing this and that?
I would have to spend a large amount of time learning and researching during this project, maybe 50% of the time I would
have spent just coding in a language and ecosystem I know.
Conclusion: Multiply your time estimate by three when learning new core stacks and involving experimentation. The language syntax will be the small thing.
The Creation Process
Initial Commit
The basic implementation was done in a day - it had no builds, error handling, documentation, edge cases, maintainability, etc.
This is where most Friday hacks end up, and most of them never goes further.
But as all senior developers know, making something work is many miles from releasing a product.
Soon done, eh? Not really.
Finding the Time
At times it was really hard finding the time to spend with the project, especially as I had an exhausting spring at work.
It's not every night that you feel like reading a book for 2 hours about something specific, or learning a new tech.
Or spending time writing documentation. I have kids and a house, and I couldn't afford to let a private project consume me more than other hobbies.
But something always has to give - I ended up watch fewer series, and any gaming has been almost non-existent during this period.
With that said, while I wish I could spend more time on the project, it was almost always motivating - I had a few night sessions where I slept less and coded or studied,
because I was so excited to get further. Also, when something is fun, it is fun, whether it's lifting weights, writing a book, developing, etc.
The Things I Forgot
I've been so used to working in teams for a long time. With a solo project, you have to manage a lot more hats and be quite good in every part of them, not often technical.
I spent quite a lot of time digging into good CLI design and idiomatic choices. Another area was the release process and building binaries for different platforms.
Following SLSA and other standards in Open Source also took time. And we want good test coverage, right?
Working in a team, someone else will hopefully do the logo you wanted, the documentation needed to be written.
Working solo, it's only you or it won't happen.
Writing code is not even 50% of delivering a project. And there's the rest.
The Impostor Syndrome Strikes
Impostor Syndrome is common in our knowledge-based developer world. Everyone has different skills, and at any given time, there will always be someone that knows more than you.
Being in a team, you have someone to discuss things with.
Alone, not as much.
But, it is all about accepting that one will do some stupid things in the code at times.
And, that Open Source isn't about being perfect. It's about learning, solving and releasing things that might be of use to others.
The Grind
Well, what can I say - it is done when it is done.
There were a few late nights debugging, refactoring, but also countless moments of flow and dopamine.
For me, the release time came when I felt the overall architecture in the project would not radically move - I had identified the interfaces, and felt that is extendable.
The codebase is OK.
Most of the basic features are there, and while everything is up for improvements, it is still a base to work on.
The Aftermath and Lessons Learned
Set the scope early: Decide where to stop. Set up your project structure, documentation, releases, pipelines, and community guidelines early. Future you will thank past you.
Don't stress, enjoy the learning process: It is done when it is done.
Be persistent: Open source is a marathon, not a sprint. Don't burn out. It is a hobby, not your life. However be persistent. Do a small thing every day.
Learn, learn, learn: See everything as an opportunity for learning and improving, not as a problem.
Coding is the easy part: The main code is what will take you the least time; everything else, like documentation, tests, etc., is where time is spent.
Do the extras: They are as fun as coding. Yes, even documentation can save you hours of explaining and re-explaining. Make it fun if bores you. Docs-as-code, vim-pong, etc.
Take breaks: Burnout is real. Step back when you need to. Just like every other creative learning process, do it in batches.
Use the system: Use your own dogfood in practice and in the real world as early as possible. Even better, find a person/community to give feedback.
Enjoy the journey: It is wonderful to create.
Complete it: There are a zillions half done projects in this world. Complete it. And then realise that the project really just starts after the first release.
Use AI as a help: I save hours by delegating a bit of boring extras to it, like asking for doc structures, summarizing things, etc. However, don't ever trust it blindly. Review and criticize the answers.
Well, happy hacking and now go and think about what you want to make next!!
Links
The project: Git Provider Sync
Top comments (0)