kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

Markus,

I appreciate your enthusiasm, but I do not think saying "KiCad works on
computers" is going to help our users or our developers.  I think this is
actually a question of opportunity cost and focus, similar to your other
posts from the last few days.

I've come to learn a lot of things during the last 5 years on the KiCad
list, and I hope this email can help explain how I view things.

KiCad has a lack of qualified developer time, and many of our decisions are
made with opportunity cost in mind.

KiCad has a large number of users, and a small number of developer-hours.
This has been a concern for a while.  There are a variety of things that
can be done (and are being done), like lowering the barriers to entry,
being nicer on the mailing lists, increasing the quality of KiCad, and
making it easier for people to get up-to-date builds.  All of these are
things that attract developers, help them get good at developing on KiCad,
and also help keep the developers that are working on KiCad already, happy
and not burned out.  (Coincidentally, all of these things directly help
KiCad's users as well, how convenient!)  I think we're actually doing a
pretty good job of that, especially historically speaking.

However, it is 2015, and we only have the barest of automated testing.
This has been on my list for quite some time, and is at the top of my list
for after KiCad 4.0.0.  Why isn't it done, if I've been around for 5+ years
and have had this as a priority?

Opportunity cost and focus, mostly.

I have a wife, a kid, a day job and a side business, and I choose to give
away my time to make KiCad better, nearly every single day, because I think
KiCad is really, seriously, important.  On the other hand, I can only spend
a little bit of time each day.

I try to balance my time between user support and KiCad quality
improvement.  I think it's very important for developers to maintain a good
connection with users.  It's easy to do things "the developer way" and miss
huge usability issues for users.   At the same point, it is very easy for
me to spend 100% of my KiCad time dealing with support, at which point I
cannot contribute to any sort of longer-term KiCad strategy.

For instance, yesterday, I spent almost an hour talking with a user trying
to figure out why he thought the 4.0.0 release was out, searching through
the website, seeing if I can fix the misunderstanding at the source,
drafting an email to the list...

I haven't seen any way in which we actively stop users or developers from
doing anything, and I don't see that changing.  With that in mind,
minimizing the support emails and questions means I have more time to make
KiCad better, and presumably other people do as well.  Designing KiCad with
focus means that we have more developer time to make KiCad better.

If we have to design KiCad so it works great on 800x600 screens, for
example, is that extra *manual* testing on every single GUI change for
developers?  (today, yes.)  Does that help or hurt the KiCad effort, if we
go out of our way to support and maintain a quality GUI that works well at
 800x600, *at the expense of other things those developers could be doing
with that time?*

If we say "KiCad supports computers with operating systems" are we going to
have happier users and am I going to get more or less email than if we have
a webpage that says "KiCad tries to work on most systems, but it is
packaged and has been nominally tested on Windows X-Y, OS X 10.X-10.Z, and
many Linux distributions, like Fancy Feast and Candy Corn"

On the other hand, if we put up a webpage that says, "KiCad tries to work
with every configuration, but we suggest you use a 1024x768 graphical
display for best results", does that help or hurt the support load?

Does it help or hurt if we say "KiCad can use the GPU to make PCB editing
of larger boards more responsive.  Nicer GPUs, like the Frobnitz Zorkmid
EXTREME, work better than software GPUs like the Foobar H3."

To me, I think statements like that would help establish user expectations,
lower the developer support load, and ultimately make KiCad better.

The effort to "just" maintain a graphical, user-oriented program suite
(that never changes) on new versions of Windows, Mac and Linux should not
be underestimated.  Add in the fact that we're trying to fix bugs and add
new features, and it becomes an actual serious effort.  I think almost all
the devs here that have been around for any length of time have found,
patched, and reported bugs in our dependencies.

This might just be my proverbial neckbeard or getting old, but I really do
try to think of the opportunity cost, focus, and support load when
evaluating pretty much anything related to KiCad.  If I end up spending
100% of my time supporting users who expect KiCad will work amazingly on
their 200 mhz Cyrix, they're going to have a bad time, and I'm going to
have a bad time.  If the dev mailing list is full of people yelling at each
other, like it used to be quite often, personally, I'm going to find less
time to spend on making KiCad better.  If the required dependencies change
all the time and I have to spend all my dev time getting my builds working,
once again, that's more time I can't spend on making KiCad better.

(I am not the Lorax, I do not speak for all the devs, but I've been around
for quite a while and help out where I can.)

Adam Wolf
Cofounder and Engineer
W&L

On Thu, Oct 15, 2015 at 9:58 AM, Markus Hitter <mah@xxxxxxxxxxx> wrote:

> Am 14.10.2015 um 19:47 schrieb Wayne Stambaugh:
> >> As for 1024 x 768 and lower resolutions, are we kidding? Who has a 1024
> x 768 monitor that gets regular use? That’s crazy. After all, the second
> syllable of Kicad is CAD, and CAD applications want as much screen real
> estate as possible! You’re a masochist if you’re trying to run Kicad on an
> 800 x 600 display. Gotta draw a line in the concrete somewhere.
> >
> > Thank you!  I could not have said it any better myself.
>
> With all this boasting about screen resolutions I start to wonder wether
> moving to KiCad was a wise move.
>
>
> Am 14.10.2015 um 21:54 schrieb Marco Ciampa:
> > I just want to compile a _reasonable_ system-requirements list,
> > nothing more, nothing less.
>
> Good point.
>
>
> > - Up to 500 MB available hard disk space;
>
> Likely not sufficient. All these libraries take a lot of space. Recently
> my package manager reported 1.4 GB required space for the packages. Half
> the 3D models I currently have add 1.1 GB on top.
>
> 2 GB without 3D and 5 GB with 3D is probably closer to the truth.
>
>
> > - 1280x1024 resolution (higher resolution recommended), with at least
> 16K colors.
>
> I just tried with a small window on a larger screen, sizes around
> 1024x768 work ok. It's not ample, of course, but perfectly usable.
>
> Even 800x600 basically works, but about half the toolbar buttons
> disappear then. One can use the regular menus, of course, still not good
> for a "recommended" setup.
>
> > - Graphic card with at least OpenGL 2.0, with hardware shaders. Check
> > the opengl specs of the card:
> >
> > - Intel: Intel cards are reported working from model HD2000 and higher.
> > No pre-HD models.
>
> A pre-HD model works just fine. With the default/Cairo canvas and with
> software emulated OpenGL canvas. The latter is simple, just run with
> LIBGL_ALWAYS_SOFTWARE=1.
>
> BTW., the OpenGL canvas asks for v2.1, not v2.0.
>
>
> Minimum system requirements? Uhm, how about simply stating "A computer
> running one of the supported OS's, see the download section".
>
>
> Markus
>
> --
> - - - - - - - - - - - - - - - - - - -
> Dipl. Ing. (FH) Markus Hitter
> http://www.jump-ing.de/
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>