Excuse me, I reformatted your message to make a structured reply.
gEDA and KiCAD are two different philosophies about how to solve this problem:
- gEDA uses the unix mentality of multiple single function tools the users decides to combined for different work flows.
I agree about it. That kind of mentality seems obsolete by a major number of people, that's why things like systemd. I'm not sure what one is better than other, but I'm more comfortable with one of them depending on the task.
Anyway, I have been using 20+ Operating Systems as a OCD hobby (I'm usually an apprentice of everything, master of nothing), but I like command line and streamlined GUIs without ribbons on top, maybe a mix would be nice (I like the Eagle cli, despite it's very limited).
Modern GUIs influenced from other Operating Systems are morphing the UNIX world into something different, with a mix of both monolithic and modular approachs.
The big problem of gEDA is stagnation, because different reasons:
- There are highly skilled people in the gEDA community that is able to develop their own forks for their own needs. Unfortunately, most of them don't care at all about merging code to mainline, they are mostly quite conservative.
- The project is considered mature and "good enough". There's little interest in innovation, but fortunately some rebels want to change that.
- They use Lisp a over there (Guile). Despite it can be cool, it's a dead language for mostly all programmers. These days is C, C++, Java (don't enter into this trap owned by Oracle), .NET/C# (another trap), Python, Lua.
- It's practically not multiplatform, Guile has portability issues on Windows at least.
- Instead investing their efforts in development and merging back forks or improve stuff in a constructive way, they just do their own stuff or waste it on massive flamewars.
* They make endless discussions about what to do and unable to make agreements, even resulting in not polite attitudes to others.
* They even critic about other projects such as KiCad.
- Delorie seems to not have a strong leadership in this project to make it progress. I'm not sure why, but he finally wasn't able to manage the situation in a way to have a sane community.
KiCAD is more monolithic for people who want everything in one integrated tool.
You are right, but there are other interesting stuff about this project:
- They are a multiplatform project, so more users and developers could be more interested in it.
- They are a more open project to contributions, novice users and innovation.
* They don't act in an elitist way, despite some past flaws. These days they reply all questions and encourage the submitting of patches and bugfixes.
* The contributions from CERN are revitalizing the project and improved the interest in the project.
* OSHW community, "makers" and students are getting interested in KiCad as an alternative to Eagle.
* Their community is more friendly to novices and new developers,
- They even have a new and better website.
* I miss a news section on the main page.
- Differential pair, 32 layers support and PNS routing are very interesting stuff that got added.
* They have more stuff they want to improve after the upcoming release:
** User Interface improvements
** File format interoperability.
** Back annotation.
** Better integration between Eeschema and NewPCB, changing many parts of the current application design.
** They plan to use by default their new and better OpenGL/Cairo graphics backend as default (GAL).
*** Currently some features are only available in GAL and others in the "legacy" backbend. They plan to improve this and have the possibility to use a nice Hardware accelerated graphics environment.
** Better Python scripting: There's some stuff already done, but they need to improve things.
*** I hope they are able to archive the flexibility and diversity of Eagle's ULP, but providing a centralized scripting repository.
To me, it's a lot more than the UNIX vs Integrated approach:
- One project has better management and a sane community.
- The other project have lots of flamewars and against innovations.
It's a shame the EdaCore initiative didn't get enough momentum: it's a brilliant idea to share source code and component libraries between Open Source EDA tools.