TL;DR I consider i3-gaps to be complete and focus on keeping it up to date with upstream.
The Past
A long time ago, I wanted to try out a tiling window manager, because I heard so many great things about them. At the time I was pretty new to Linux still. Having started out with i3, I quickly discovered communities focused around making things "pretty", and so I came across i3-gaps. Back then, i3-gaps was a no longer maintained standalone patch to i3 4.7. Since I don't like using old software, I decided to take it upon myself to rebase the patch to (then current) i3 4.8. My Reddit post about this became quite popular, so I created this repository, and it quickly accumulated some fans. I started actually improving on the original patch, both in fixing bugs and adding more features. Eventually I started to send some fixes to upstream instead, and before I knew it, I was a contributor at (upstream) i3, and ultimately became a maintainer there.
This was an incredible journey, and it is why I love open source so much. I barely knew (know?) anything about C, I just wanted some pretty colors, and suddenly (well, some years later) I find myself as the maintainer of both i3 and its most popular fork, i3-gaps. But life continues, responsibilities grow, and interests shift. I still use i3-gaps as my daily driver, but I don't really contribute code to either i3 or i3-gaps anymore. As a window manager, i3 has become very stable and about as feature-complete as it should be.
The Future
Luckily, the difference between i3 and i3-gaps isn't all that big. This allows me to keep i3-gaps up to date with upstream fairly easily, and it is about 99.5% of what I have been doing with i3-gaps for a couple years now. This is also the most important thing for me: not letting i3-gaps "fall behind" as it did when I first discovered it. However, with limited resources this means that any further addition to i3-gaps puts this at risk by making it more complicated to merge in upstream changes.
This means: I don't want to make further changes to i3-gaps, but I do want to continue merging in upstream.
Airblader
commented
2 years ago
TL;DR I consider i3-gaps to be complete and focus on keeping it up to date with upstream.
The Past
A long time ago, I wanted to try out a tiling window manager, because I heard so many great things about them. At the time I was pretty new to Linux still. Having started out with i3, I quickly discovered communities focused around making things "pretty", and so I came across i3-gaps. Back then, i3-gaps was a no longer maintained standalone patch to i3 4.7. Since I don't like using old software, I decided to take it upon myself to rebase the patch to (then current) i3 4.8. My Reddit post about this became quite popular, so I created this repository, and it quickly accumulated some fans. I started actually improving on the original patch, both in fixing bugs and adding more features. Eventually I started to send some fixes to upstream instead, and before I knew it, I was a contributor at (upstream) i3, and ultimately became a maintainer there.
This was an incredible journey, and it is why I love open source so much. I barely knew (know?) anything about C, I just wanted some pretty colors, and suddenly (well, some years later) I find myself as the maintainer of both i3 and its most popular fork, i3-gaps. But life continues, responsibilities grow, and interests shift. I still use i3-gaps as my daily driver, but I don't really contribute code to either i3 or i3-gaps anymore. As a window manager, i3 has become very stable and about as feature-complete as it should be.
The Future
Luckily, the difference between i3 and i3-gaps isn't all that big. This allows me to keep i3-gaps up to date with upstream fairly easily, and it is about 99.5% of what I have been doing with i3-gaps for a couple years now. This is also the most important thing for me: not letting i3-gaps "fall behind" as it did when I first discovered it. However, with limited resources this means that any further addition to i3-gaps puts this at risk by making it more complicated to merge in upstream changes.
This means: I don't want to make further changes to i3-gaps, but I do want to continue merging in upstream.