When I started doing electronics (~2005), I looked around and tested a few different tools. Since I am clearly a hardcore UNIX fan, command line junkie, and I require my software to be open source, I quickly settled with gEDA.
I was a more or less happy user of gschem and PCB for many years. Also subscribed to the gEDA mailing lists and tried to contribute. As years went by, developers were coming and going, each generation of developers steering the project in a specific direction.
Honestly, I never really liked some of the fundamental decisions of gschem, but I was very happy with PCB... until about 2008, when I started to see that the project is increasingly going in a direction I really disliked. It also made using PCB harder for me.
Around 2013 I finally decided to fix this up by rolling my own Debian package of PCB, first with only different ./configure settings, then with some patches merged that upstream did not want to merge but I used daily. Back then I did not have longer term plans and I was real busy with other projects so I thought this would always be just "PCB and a set of random changes", hence pcb-rnd.
Then by 2015 upstream PCB was hitting a low point and meanwhile I've made so many changes in my "personal fork" that I figured overseeing the whole code base is not impossible. So I decided to make my fork public.
For the first years, I tried to make changes so that upstream could merge them back easily. I still did not know to what extent pcb-rnd would be just an upgraded pcb or a new editor. Meanwhile I kept communicating with PCB developers, to see if merging back was an option and whether cooperation would benefit both projects.
It was in 2016 when it finally became clear to me that PCB is a hopeless case and it is worth simply "burning the bridges". In practice this meant I stopped worrying about whether any of my changes could be merged back. This enabled me to work on some larger scale subprojects, like the data model upgrade and own file format which allows pcb-rnd to edit any layer and have footprints with any object-type/layer in them. Plus a real, working back annotation. And loading boards and footprints alien formats, like kicad's or eagle's. All while keeping 100% backward compatibility but without having to worry if PCB can deal with it.
For a few years I focused on pcb-rnd because the backlog was huge: about 15 years of unfulfilled user feature requests and unfixed bugs. And as these problems got fixed with pcb-rnd, while gschem did not progress resolving similar (or even worse) problems, the contrast became more and more appearant. To a point that I was considering doing the same to the schematics capture part that I did to the PCB editing part
Meanwhile I also had a lot of problems with gerbv. Since the code base is much smaller than PCB's, and at the time it was with no active maintainers, I thought I would just fork it and do a gerbv-rnd the same way. However, after looking at the code, I quickly realized it's cheaper to rewrite it from scratch.
The expensive part was, however, GUI. And that's something that was rather good in PCB, since 2005, when the whole GUI moved behind a HID API and core (more or less) got properly separated from frontend. So I thought it's best if I just reuse the GUI part of pcb-rnd for a gerber viewer.
So I refactored and separated the code, first within pcb-rnd, then into a separate project, called librnd. And meanwhile sat down and wrote camv-rnd.
Camv-rnd happened in 2019. When I first had a working camv-rnd based on early librnd, I figured where this all really lead to: I will eventually end up with my own EDA suite...
Back a few years, to 2016: the back annotation went easy on pcb-rnd side, but I couldn't convince gschem developers to implement it (or to even care about the problem at all, in fact). So I decided to take a look at gschem source myself. After a few days of fiddling, I managed to implement a working version. It was not very good, but was usable for my own workflow.
However, during the process, I've learned a lot of really bad things about gschem:
Around the same time the huge conflict of xorn was also going on, which led to the lepton-eda fork. I was still lurking on the geda mailing lists and tried different methods to get PCB, gschem (and then lepton-eda) developers to cooperate.
My opinion was this: gEDA used to have a real productive decade in the 2000's because then-gschem-developers managed to cooperate enough with then-PCB-developers to have just enough interface that things mostly worked together. But this was totally lost after 2010. So my vision, and offer, was we could start a new period of gEDA, with explicit cooperation among projects to target suite-level, workflow-level bugs and features. I was trying to propagate this idea for about 2 years using different approaches and implementation, but gEDA developers, they all consistently turned this down. They were explicit about everyone wanted to work separately on their own little project, without having to think together with anyone else, without having to think in an EDA suite.
As this went on, first as a plan B, I started to ponder about writing my own sch editor (work name: cschem). After the back annotation patch on gschem, it was clear forking the code base and cleaning it up is way more work than just writing something from scratch, mostly because some suboptimal design decisions that became fundamental to gschem over its first decade.
Then as gEDA situation did not improve, plan B became plan A. I first made a public design session where the basic design of sch-rnd emerged over many months of development. This is the official design document of the project. Then I got real busy with pcb-rnd and camv-rnd for some time, but finally, in 2022, with the help of nlnet I could dedicate enough time to finally implement the code. As of April 2023, sch-rnd is entering it's final testing phase for release 1.0.0.
Around the time I decided about writing my own sch editor, I also figured it really means I will be working on my own EDA suite. By then pcb-rnd was also well known, and I did not want to rename it, so I rather found a new meaning for rnd, RiNgDove.
Ringdove tries to be the UNIX user's EDA suite. It is modular, efficient to use after a steep learning curve and does work properly from the command line instead of assuming a desktop environment.
In a sense I took the good ideas from gEDA, and advanced them some more. But in the same time I also looked at design errors and bad ideas in gEDA and tried hard to avoid them in Ringdove.
For example the toolkit approach: