delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2017/02/14/23:39:03

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]" <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: <CAC4O8c-xVjckET_giRMujnG2gbCtPGPXrEQF_3oVq18Y=Qy6VQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1702150413430.7286@igor2priv>
References: <alpine DOT DEB DOT 2 DOT 11 DOT 1702141710390 DOT 14019 AT nimbus> <s6nefz0a72x DOT fsf AT blaulicht DOT dmz DOT brux> <1bab2e83-fc06-10c9-7dee-8fd88af6be7d AT s5tehnika DOT net> <6978404a-1dcf-3691-bcdf-233d24cdf8d2 AT neurotica DOT com>
<CAC4O8c-xVjckET_giRMujnG2gbCtPGPXrEQF_3oVq18Y=Qy6VQ AT mail DOT gmail DOT com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
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

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


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019