kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 03/14/2014 11:03 AM, Marco Serantoni wrote:
> I strongly agree with Tomasz, helping the user just firsts steps just after the download
> is the key for a quick adoption.
> When someone downloads Kicad for the first time is because have an idea in mind that wish
> to trasfer in the reality or just to comparate its software with the OpenSource one.
> 
> My humble opinion is that this programmer-centric approach to the GUI is the one that
> hasn't permitted Linux to be a new reference for the desktop systems.
> 
> Wayne, at the DOS time the default interface was the CLI, so was cooerent for an user
> being able to set those, like now could be coerent on windows for an user handle the
> registry keys.
> 
> If really we wish being able in the future to try a port to a Tablet, also if only as "a
> reader", we can't require users to set enviroment variables by hand, they could not be
> able to do it.
> 
> I personally think that "Preferences" could be the old good standard way to place the
> variables now stored in the enviroment, then those could be stored in the .pro files,
> Easy, straight and following a KISS approach.
> 
> Mac has enviroment variables but those are thinked to be used for command line commands in
> a terminal and there isn't a standard way to make them set, as anything not directly
> stated by Apple, each interface you use, can change between releases or also with a
> patchset, OSX users/programmers know that and are strict to follow the guidelines, this is
> a cathedral approach.
> 
> I personally think also that the Tomasz interface should be done in C++, the first setup
> should be rock solid and failsafe:
> is the first fly, we can reasonably expect issues with python on the first fly, probably
> is the place where we could test and exercize the enviroment before leaving the control to
> the User.
> Is the first place we could fail and loose a new adopter.
> 
> I know, there is a new toy python and all us are happy of that and wish play a bit, but i
> personally think that the "first setup interface" is the homeworks that prepare to go to
> play after quietly.
> 
> 
> 
> --
> Marco



We don't need environment variables in the fp-lib-table.for-github, since it only contains
stock libraries which will not be moved.  (Unless the user forks those repos.
That is an advanced task, and that advanced user can add environment variables in if
he/she wants.)



Generally, I am now in this to make the package easier for *me* to use.  It's awesome that
we have a user centric attitude.  That is critical in a private sector enterprise.

But I think its important to recognize that contributors like Jean-Samuel and others are
the new life of KiCad, not one or two users who are simply pains in the ass.

That latter type will come if you put out the free goodies no matter what.  They want the
free stuff, and if its good, they will come in greater numbers.  But that is not why I am
doing this.

I am not working for users here, I do that in my capitalistic private enterprise
vigorously.  I want KiCad to be optimally useable *for me*.  That constitutes the balance
of my motivation.

The users will come when you put out the free ice cream.  Screaming or kicking, they will
come, because good free stuff is attractive, period.

When Jean-Samuel writes a python plugin, I benefit.  It was awesome.  When he puts out a
PPA, that is cool for Ubuntu user's I know.

When 100 users pick up KiCad wanting new features, I do not benefit as much as when a
contributor adds something.

Yes, I suppose new users can be put up on the scoreboard, but if you want to increase that
number, we have to value contributions and contributors, more than new users.

Otherwise you are watching the scoreboard during the game, and not feeding and nurturing
your players, keeping them healthy, and letting them focus on the ball.

To be honest, I was hoping for a better apology when Jean-Samuel was smacked down for the
PPA being offline.  Simply justifying a smack down because "fictitious new users" would be
put off when they cannot get their free stuff, is inconsistent with what I am saying here.

You incur a far greater loss when you lose a key developer than you incur when 10 users
whine about environment variables and threaten to go somewhere else.

All are not equal.  Continuously challenge your priorities and goals.  Users, if they are
not contributors, are not particularly valuable to the project.  And yes, it is not
necessary to remind me that contributors will scale in proportion to users.  But I am
talking about the scaling factor here, not the total number of users.


Dick