X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Wed, 15 Feb 2017 05:37:21 +0100 (CET) X-X-Sender: igor2 AT igor2priv To: "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: alternatives (was Re: [geda-user] New gEDA/gaf features) In-Reply-To: Message-ID: References: <1bab2e83-fc06-10c9-7dee-8fd88af6be7d AT s5tehnika DOT net> <6978404a-1dcf-3691-bcdf-233d24cdf8d2 AT neurotica DOT com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk Guys, if you want gEDA to survive another decade, you need to realize that alternative are good, and need to figure how to make the best out of them. If you don't, and believe in your little fairy tale that "if alternatives didn't happen everyone would have worked together, on MY favorite idea" then you'll end up without having anything working long term. I know it's really hard to release optimal looking fairy tales when reality is looking much less optimal. But if you don't, you won't be able to exploit the possibilities in the actual reality while the fairy tale just won't happen. Picking one, randomly (no offense ment, it's just short and sums up the point I want to reason against): On Tue, 14 Feb 2017, Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com] wrote: > Igor might never have forked. I've said this many many times, but I am willing to repeat again and again if needed. I am only writing these down because I see the same pattern emerge on the gEDA/gaf side now, and I think most people regard this from their short term user perspective. Which is okay, still it may be worth taking a look from the other side(s)... My fork, pcb-rnd, triggered by no ONE SINGLE reason, but MULTIPLE reasons. I do admit that ONE of those reasons was the contribution processes back then. *********************************************************************** The choices were NOT me joining the project I saw going in the wrong direction (as per my opinion) vs. forking. The choices were doing a fork trying to realize the direction I think is good vs. not doing anything. I believe many forks start like that. I think the "no alternatives" people here don't seem to understand this. *********************************************************************** Fixing only ONE of the reasons probably not have avoided the fork. Maybe it would have delayed it by a few weeks. Unforking _the code_ doesn't help either. Markus tried a variety of aggressive methods to somehow force me (and maybe others) to join HIS "One True Path", while he never even considered it could be him joining mine. This pattern is common in all those "hur dur forks are bad" arguments. But the "we just force others to do what we think is good" won't work in this context. We sometimes tend to pick out one little detail (no matter how important it is for us or for developers) and try to construct the full reasoning or the possible "solutions" from that one detail. But that's not how it works. That's not how the forks happened and if you ever want to unfork for whatever reason, it's not how that could happen. You need to understand the big picture. So let's step back and look at how the forks happen initially. ************************************************************************* Please do realize: we are talking about FOS projects: developers working happily in their free time, without anyone paying a dime. They do it as long as they want. They do it the way they want. You, the other developer or the end user HAVE ABSOLUTELY ZERO MORAL BASE TO QUESTION THEIR DECISION about them working or not working on a specific project. The choice here is NOT between they do what YOU WANT vs. they do what THEY WANT. The choice is between they do what THEY WANT and you have the chance to use it vs. they DON'T DO ANYTHING. If you don't like that, go and set up a software company, hire some programmers, pay them good money and then you have the moral and legal means to FORCE them to code what YOU WANT (at least in their office hours). ************************************************************************* So how it seems to work outside of your own company. There is a project, there are two groups of developer who may have or may not have worked together before. They start to realize they have two totally different set of plans/ideas on how to proceed, where to get the project to. An important part these threads most usually just ignore: there is no physical law, a mathematical formula that reveals that one or the other direction is The One True Way, The Good Solution, The Thing We Want. There's only your own little personal opinion, which is not better or worse than anyone else's, it is only DIFFERENT. Thus from the first time the ideas emerge, one direction will be the good thing for some people (users, developers) the other direction will be the good thing for some other people (users, developers). So what can we do now: 1. We ignore any new idea popping up and don't move until everyone, all developers, all users, all contributors, past and future, literally everyone agrees on even the last little detail. I think it's needless to bring an example here. Unless there's a single developer and a at most 2..3 users, such project effectively grinds to a halt and the communication will revolve around rehashing the differences in how the little details could be handled. 2. A variant of that: in the process everyone gets demoitavted. Developers see they shouldn't invest time because someone random will undo or remove their investment. Users see they shouldn't invest time because the tool changes randomly. Remember: differnet ideas and projects are competing for developer resources. Every developer you are going to ask will say there are more interesting projects to work on than free time permits (unless you made the sw company and paid them). If your great EDA idea is NOT MORE appealing than 100 other project ideas, you won't get developers working on it. In parallel, they will work on something else. You can't blame them for this, you have no moral grounds for that. 3. People somehow select on set of ideas and do only that. The magic "leader" argument. But this has another side: developers and users backing up _the other_ idea will likely to leave or cut back on contribution, seeing that the wrong solution is being implemented. And this is true for most of use, dear reader... No offense, but when was the last time you contributed to the competing project? The one you thought was the bad idea? In a way that progressed the project in _their_ direction, in the direction you find wrong but they find so good? Ralistically that just doesn't happen too often. So a set of people go on working on the directio set, and another set of people just stop. Net result: _less_ developers working, _less_ users being happy, while the group of developers and users who prefer the idea that got the vote are slightly more happier. If you were lucky and YOUR favorite idea got selected, you can say you won. But effectively you didn't gain anything by the alternative idea NOT implemented, because thos who have worked on that WON'T work on yours. So you didn't win anyhting but made others to lose something. Next time it will be the other way around and you will lose. What you may have hoped for, that everyone accepts the decision and go on happily working on "the bad idea", won't largely work. Again, make your company, and throw in money to get that happen, the majority of the world is still doing that. 4. People realize they want to go in two totally different directions, and just do that. Everyone keeps working, and we just have two separate, different solution to similar, but usually also slightly different problems. e.g. gEDA/pcb solves a different problem than pcb-rnd, using different methods on all possible levels. Most probably the same is going to happen on tge gEDA/gaf side. Net result: much less developer effort lost, less users lost due to developers chosing wrong way (for that specific user). If this is done wrong, users and developers lost because of the confusion - this why I stress we should ACCEPT and EXPLOIT our altneratives instead of pushing the "One Good Way" that never ever worked. So let's look at the myths. I know many people tend to believe in this fairy tale: - if we didn't have forks - then every developer just worked on that one single piece of software - all the workhours just magically added up - and then spent on doing exactly what I WANT (and/or "everyone else wants exactly what I want too", because "that's the One True Path", anyway). If you truely believe in that after reading up to this point, we should stop this discussion, we are living in different worlds and won't be able to convince each-other. This is a fork too, on a higher conceptual level. And you are doing that fork (not accepting my reasoning), lol. Or if you still believe in that, then what you are going to do next? Merge kicad and geda into kida? Then merge eagle, altium, easyeda, ltspice and upverter into this mix? And who do you think would want to work on that or even use the result? And think it would mean every single EDA programmer in the wolrd would somehow magically join up and all their dev time just added up? That's not how it works, sorry. The same way as you won't go investing your own time in an idea to contribute to the "wrong" project, if you somehow force developers together to work on something they all hate simply won't work - unless it's their daytime job (and we are back at the "set up your company" idea). You really can't do much but accept that - as you see, it's happening, and as you see you can't do much about it. You can complain, you can make new flame wars, but that will not solve your fairy tale problem - we have like a decade of mailing list archive and version control logs proving that. If you don't like the direction one or another project or alternative, don't buy that software or if it's a free software, don't use it. That's the only that is useful for anyone. Trying to force YOUR IDEAS on others won't make your ideas to get realized by them. If you want your own direction to be realized, do it, or hire people to do it. Or go on and talk about "unforking" and explain how it would be better for everyone if they just worked on YOUR IDEA the way YOU WANT, for free (but don't bet too much money on this ever happening). ************************************************************************** Or, what I was trying to suggest: accept the existence of the alternatives and try to make the most out of them, turning the situation to your advantage! ************************************************************************** Regards, Igor2