Below is my offer to gEDA from early December 2017. This was my last attempt to get gEDA back on track. It was obviosuly not accepted and gEDA decided to go by a different plan. (The offer below is not valid any more.) ------------------------------------------------------------------------- Premise ~~~~~~~ First of all: I have no intention to change or take over gEDA. I am not interested in gEDA itself, my intention is to build an EDA suite that as an user I'd find the best: an EDA that could fill the niche market that I believe gEDA is more and more failing to fill. A suite that can keep up and compete with kicad - not for the desktop users but for this niche market. In this, gEDA is not a goal, just an option. This EDA suite could be gEDA 2.0 or a new suite. It's up to you. Plan A is to do this independently of gEDA - as you may know, it's already being done. Plan B: if gEDA figures they want to do exactly the same thing too, we may find a way to do it together. This post is about plan B. It's a package deal: I won't start long debates about each little detail - if you don't like any of it, just stop reading, say no and we keep on going by plan A. The plan contains drastic changes and a lot of them at once. A year ago I tried to introduce this step by step, with the smallest possible change: a mailing list where project owners would coordinate the suite effort. Exactly zero project leaders wanted to join. I figured this is not something we can do gradually - we either bite the bullet and do it at once, or we won't ever do it. I strongly believe if gEDA doesn't do it, it will just fade out in the next 5..10 years. History, current situation ~~~~~~~~~~~~~~~~~~~~~~~~~~ gEDA was very successful in the mid 2000s. The market has changed a lot since, especially with kicad becoming the big player. If we want to make _any_ open source EDA tool successful today, or even survive long term, we have two choices: 1. Make something that is in 0 overlap with kicad (including kicad's long term plans) and be prepared to complement kicad; e.g. if kicad is not doing thermal simulation today, writing a tool that does that is a good bet, especially if it can load kicad board files. 2. Make something that has overlaps with kicad then try to convince users to use this tool instead of the natural default choice, kicad. gEDA clearly falls in the 2nd category. The question is why would any new user choose gEDA over kicad. Just saying "toolkit" and "we are better" won't work. Depending on the inertia of the system (e.g. number of tutorials/examples/resources on the web, number of users already using gEDA and don't dare to change) it may seem to work today but won't tomorrow, as kicad grows and gEDA shrinks. Kicad is backed up with tons of resources (developers, users, fame, hype and even money). Looking at how their project rolls, it's pretty useless to assume they do it all randomly - instead, they do it by their plans, by their strategy. At the moment, gEDA is neither backed up with resources nor has a solid strategy. Getting resources in this state is hard, starting to execute a plan is easy. Where this can progress from here: A. gEDA goes on being inactive and unorganized - if nothing else, kicad's organization and progress will beat gEDA out of existence. Most new users won't consider (or even know about) gEDA. The few that looks around before using kicad will just looking at the "is it still alive" question and abandon gEDA before even a try. Seen with my own eyes. Happening today. B. gEDA starts mimicking kicad and big $$$ tools; I saw tendencies of this since about 2009 (this contributed a lot to the fact I forked). If you do this very well, all you end up with will be an older, less capable, slower developing version of kicad. Not because you are less capable than kicad developers, but because you have less resources available for doing the same they are doing. New users may check gEDA out and see it's basically the same, just a bit worse. Will be hard to convince them. C. gEDA works out a strategy and very consciously defines what it does and what DOES NOT do. This makes gEDA an alternative for those users that did not find some of the selected features in kicad. This is a niche market. Majority of the users _will_ go for kicad. Even gEDA will tell users to just use kicad if it turns out the user wants things that kicad is good at but gEDA isn't. On the other hand this would help gEDA to focus the sparse resources on offering something kicad can't or don't want to. I am doing strategy C with pcb-rnd in all regards. It does work. It does work much better than PCB's strategy (which seems to be a lot of A and a bit of B, looking from my seat). Just compare any quantitative measure from the past 1 year: amount of code written, number of decade old bugs and design flaws fixed, features added, new developers joining, growth of community in general, noise/signal ratio or productivity of the pcb-rnd community, keeping deadlines and release schedules, etc. My below offer is how I could implement the same plan in gEDA, if gEDA wanted it. Strategy ~~~~~~~~ 1. Strategy and leadership We clearly and explicitly define we go for strategy C. The effort is lead by a single person, backed up by a small group of gEDA 2.0 project leaders. Developers, users, contributors either join the effort and accept the strategy and obey the word of the leader about suite questions or they are left out from the effort (but not from gEDA). 2. Thinking in suite - two-tier setup We explicitly define that we are starting gEDA 2.0. This does not kill gEDA 1.0, the two exist in parallel. Each gEDA project can decide to join 2.0 or be left out (and we are explicit about it: "be left behind" and "put in the background" in many aspects). gEDA 2.0 thinks in a suite. Suite doesn't mean excess integration. It doesn't mean giving up the toolkit approach. But it does mean focusing on common goals and working _together_, e.g. implementing some glue in your project not because you want it but because gEDA 2.0 wants it. Our projects differ. We seek the common denominator instead of pushing one's technological preference. The common denominator is portable, small and simple. It doesn't have to be modern, complex, "full featured" or fashionable. But it must get implemented. Thus we prefer the simpler solution over the more expensive one, so implementation is cheaper and has more chance to happen. 3. Requirements for projects Joining 2.0 is not about words, it's about acts. Who joins must keep up. We don't put dead projects in 2.0. Who joins must cooperate with the others and the leader: 2.0 is not a random collection of GPL'd EDA tools but is a suite of GPL'd EDA tools. Joining 2.0 is easy, but falling out is just as easy too. Any project in 2.0 must be able to spend at least 3 hours a week, every week, implementing things that are important for the suite. Fail that constantly, and your project is back in 1.0. 4. Focus and tool promotion In 2.0 we focus on providing one set of actively maintained tools. It is okay to provide alternatives for a part, but _only_ if they are really alternatives, _beyond_ it is being developed by other devs or just being older. gEDA is not about telling the user what to do. gEDA 2.0 is about telling the user what's going to "trend" (development-wise) in the upcoming years. This means gEDA pushes the 2.0 tools forward and puts the 1.0 tools in the background, in all material. New users meet 2.0 first. Existing users are asked to switch to 2.0. 5. Speak clearly In the past few years trying to enforce some sort of nice talk in gEDA often masked unpopular opinions and even facts. I don't say we should be rude, but we must consider this: the actual content is 10x more important than the style/rhetoric of the speaker. Thus gEDA 2.0 doesn't mask facts with politeness. If a project is dead, it is dead; 2.0 vs 1.0 means going forward vs. staying in the past. This does not mean we want to kill 1.0 tools, but does mean we make it clear that the future is for 2.0. If you are in 1.0 and don't like it: don't find ways to blame it on the communication or rhetoric. Instead spend the same amount of time to find ways to join 2.0. Implementation ~~~~~~~~~~~~~~ 1. target audience, feature focus Target audience: the "UNIX hacker". Wants automation, scripting, command line. Wants to understand the tool under the hood. Wants to manually hack the data files or run custom scripts on it. Wants tools that execute his instructions and not one that is trying to guess his intentions. Important: Toolkit approach, flexibility, scriptablity, automation, CLI, modularity, compatibility with other tools and file formats. Especially very smooth paths between our own tools. Not important: shiny GUI, wizards, one-click solutions, "user doesn't need to learn" UI, using the latest most hyped version of gtk/qt, desktop integration, translations. 2. pcb-rnd At the moment, this is the most active thing around here and the only example for this specific strategy, so this project will lead the effort, showing good example. This makes the whole plan a bit of pcb-rnd centric. (Blame it on me if you want, but consider this: it could have been different if gEDA had _anything_ going even 20% as fast as pcb-rnd this year.) PCB is not providing an alternative and doesn't seem it would any time soon, so it's just redundancy, a source of confusion. PCB is even a blocker: blocks users from learning about the existence of pcb-rnd (I've seen this many times this year). Thus PCB is not part of gEDA 2.0, it's fate is one of these: - PCB development closes (in a publicly announced form), developers and contributors join pcb-rnd; gEDA pushes pcb-rnd as its pcb editor - same, but developers and contributors don't join pcb-rnd but get demotivated and leave. Looking at how much effort we spend at pcb-rnd and how much effort is spent on PCB, this simply won't make a noticeable difference to pcb-rnd. (Sorry, no offense meant, but really... Just do compare work hours and results in the past 1 year.) - gEDA starts promoting pcb-rnd as its pcb editor; PCB gets renamed to something more searchable and is said to be the old, obsolete, 1.0 effort; it may stay around, but it should be the editor that the user finds only after some digging. 3. schematics editor Cschem is far from being usable. If we start gEDA 2.0 with a schematics editor, we must start it with gschem and/or lepton. It's up to them if they want to join. If one or both want to join, they must sit down and code more, especially working on suite-related things, including better glue to pcb-rnd. Once we have cschem, it'll be very different from gschem/lepton. Which means it's not like the pcb-rnd vs. PCB case. We'd just have one more alternative schematics editor in 2.0. The schematics editor must understand the concept of project. This doesn't mean it can't open a single file from the command line or this feature must be used by everybody, but without offering this feature, it can't enter the suite. The project file format is the one pcb-rnd introduced (see point 2). We obsolete the old gsch2pcb project files. 4. project manager tool We throw out xgsch2pcb and finish and switch over to genxproj. Any gEDA 2.0 _must_ have an stdio control and must be embeddable in genxproj. 5. gedasymbols We throw out gedasymbols in favor of edakrill. 6. community and CoC Nice talk doesn't bring productivity. Source: gEDA-user, gEDA @ FOSDEM. Productivity and activity brings nice talk. Source: pcb-rnd. We start judging communication 90% by content and 10% by manner/style. If someone is saying useful things, expresses their own opinion, it doesn't matter if it's rude as long as it doesn't contain disinformation and lies. However, as soon as lie and misinterpretation comes in, we strike down, even if the style/manner was polite. Smiling while stabbing you in the back doesn't work. The user is shown the documented facts - if he doesn't accept and say "sorry, I was wrong, I will check my facts next time", he gets a warning. The 3rd warning is a ban. Even if he used to be a super contributor 10 years ago. 7. communication to users, web page, etc. We push gEDA 2.0. We make it explicit. We label anything related to 1.0 as old, less preferable alternative and hide it behind 2..3 clicks. New users seeing our stuff must meet a small, but well structured, _active_ project first (2.0), and learn about the slow moving, legacy projects (1.0) only later on. 8. Wait, didn't you forget non-pcb flows? Let's face it: majority of the users want the pcb or even breadboard flow. If we are not good in that, our market is so small that we end up having more developers than users. Maintaining our non-pcb-flow parts is important. We would warmly welcome any of those tools in 2.0. They are at the bottom of this list only because having them in 2.0 is much less essential than the other things described above at this stage.