← Back to team overview

kicad-developers team mailing list archive

Re: About collaboration, simulation, documentation, organisation, usability and documentation

 

My responses below are pretty well known to most of the devs that have
been here a while.  For the folks new to the mailing list, please read
on.  I should probably put a lot of this in some type of formal
developer documentation ("A Word from the Project Leader"???) so that I
do not have to keep repeating myself.

On 11/4/2015 8:32 AM, xarx@xxxxxx wrote:
> Hello,
> 
> a good topic and good ideas, in my opinion. Though it should be the core
> developers who should say that.
> 
> A few weeks ago I was performing my own small research in what EDA tools are
> available. I was looking for a schema_drawing-simulator-pcb_creator all-in-one
> app. And found none (free). I was playing a lot especially with QUCS and eSim
> (previously Oscad). Maybe I'm mistaken, but it seemed to me that the
> development in QUCS almost ceased, leaving the application in unfinished state
> with simulation stability problems. And eSim (which is basically a KiCad
> wrapper) adds very little functionality to KiCad, but creates a completely new
> project manager with very restricted functionality and a lot of bugs.

I spent a couple of days trying to get eSim to even run their examples
on Windows with no success.  This did not instill me with much
confidence.  The last time I looked, there was no OSX package.  Any
changes to KiCad, must work on linux, osx, and windows.  I don't think
that is an unreasonable expectation.

> 
> And here I'm coming to what you were writing about: All three projects (QUCS,
> eSim and KiCad) seem to suffer with lack of people willing to contribute. I
> agree with you that mutual cooperation could help all three projects,
> especially in the problem of lacking man-power. In particular, I was wondering
> why eSim went its own way instead of by contributing to KiCad. My suspicion is
> that one of the reasons may be the initial rejection by the core team
> developers to any unsolicited changes. I don't want to criticise that, I'm
> just stating that this can be seen in the history of many patches in the
> bug-tracker, where many suggestions were initially rejected, and only after a
> long discussion they found their way to the KiCad build.

To my knowledge, the eSim folks never presented anything other than here
is our simulator let's collaborate.  The fact that they went and did
their own thing would suggest that they have their own agenda.  I am all
for collaboration but that is easier said than done since it appears
that they have diverged significantly from kicad.  To be honest, I have
not looked at their source and I wont have time in the near future due
to the upcoming stable release so I do not have a good idea of how much
effort it would require.

> 
> The question is - who will be the people driving the changes? This is a free
> project, more than that - it uses GPL. And that's the reason why the
> development goes the way it does. On of the KiCad developers said in a
> discussion, that he is contributing to KiCad not make the word better, but to
> make it suit his needs. And I completely understand that... :-(

Such is the way of open source.  The problem with the lack of kicad (or
eda in general) developers stems from the fact that you have to be more
than a competent C++ programmer to hack on kicad.  You also have to
understand the problem domain which is designing schematics and laying
out printed circuit boards.  The number of developers that have this
kind of experience is very very small.  Many of them, like myself,
contribute because they actually use kicad to create printed circuit
boards and are not terribly thrilled with the idea of someone else
controlling their files which is what you get with propriety binary
(mostly) formats.  Given our limited time to contribute, it's only
fitting that we work on things that interest us.  Take that away and
you'll have even fewer contributions.

> 
> To be a little constructive: Your suggestions are good, but there has to be
> someone who takes care of them. And any such changes need an action plan/a
> roadmap. Like this one:
> http://www.ohwr.org/projects/cern-kicad/wiki/WorkPackages. (I have no idea how
> is CERN KiCad related to this KiCad.) Because it's hard to contribute to a
> project that has no idea of the way it wants to go.

We actually do have an idea where we are headed and a road map (albeit
not updated as often as I should).  The biggest issue is attracting
competent manpower that can work within the framework of the project.
We've had many developers submit their pet features with no prior
discussion with the development team.  When they are rejected or are
asked to fix something they get offended and leave.  This to is very
unique problem to open source.  If you were getting paid by your
employer to do this and you refused to cooperate with the lead
development team of your employer, you would rightfully be out of a job.
 We have no such authority over volunteers.  We do have authority over
what we allow to be committed to kicad.  That's the only leverage we
have to get developers to cooperate.

> 
>         Martin.
> 
> ----- Původní zpráva -----
> Odesílatel: timofonic timofonic <timofonic@xxxxxxxxx>
> Příjemce: "xarx@xxxxxx" <xarx@xxxxxx>
> Datum: Wed, 4 Nov 2015 04:12:42 +0100
> Předmět: About collaboration, simulation, documentation, organisation,
> usability and documentation (Was: Re: [Kicad-developers] Bug #1511552 - Fixes
> to Incorrect export of Spice net-list from EESchema)
> 
> 
>> Hello
>>
>> I'm just a lurker and still not started to contribute, but I have some
>> ideas:
>>
>> - Indian Institute of Technology Bombay: I see technological and
>> educational institutions as potential contributors at this stage of
>> development. Indian Institute of Technology Bombay developed the Oscad
>> package and showed a very good attitude towards collaboration, I think they
>> must go to FOSSDEM and talk very seriously about a long term collaboration
>> plan.

I think they need to improve the quality of their product and port it to
osx first.  Then they need to draft a sane plan to merge the simulator
into kicad.  Using another launcher on top of the kicad launcher doesn't
make sense to me.  I would prefer that their simulation apps launch from
the current kicad launcher although I'm not opposed to replacing the
current kicad launcher with something better.  The key word is "better".
 Different != better.

>> - Improving usability: I think UX should be taken under a very serious
>> objective analysis by an independent group to make KiCad more popular,
>> OpenUsability.org seems a good candidate. Old schoolers and some developers
>> might resist to change, but KiCad's UX is one of the things that still make
>> people uncomfortable to use it.

I am not interest in making kicad popular.  I am interest in making
kicad better.  There is a significant difference between these two
objectives.  For example: there are some folks who think clicking on an
object to highlight it then right clicking to get a context menu of
operation to perform on that object is better (more intuitive) than
simply hovering over the object and hitting the appropriate hot key
(simpler but with a learning curve).  It may be more intuitive but it's
also a lot more steps to perform the exact same operation.  Is this
better?  We can do both but I will not bow down to the usability gods
who make it take longer to lay out a schematic and/or board (think
gnome2 to gnome3 changes).  I actually use kicad at my real job to get
work done.  For me, kicad is a productivity tool not a way to stroke my
ego.  Anything that makes my life more difficult will be met with
resistance.  I don't think this unreasonable.  I'm always willing to
listen to suggestions on how your idea is going to make my life easier
as a board designer as long as your willing to listen to my suggestions
on usability.

>> - QUCS: It seems a great project with innovation in their core ideas. I
>> think there should be some collaboration. It seems there are issues about
>> SPICE models being copyrighted so they have to use script downloaders, this
>> would make a future KiCad library with all components available in
>> SPICE/Verilog-A a very hard challenge until solved.
>> - Organization: Are there clear roles in KiCad? Wayne is the project
>> manager and there are translators, that's all I know. Are there main or
>> specific roles in the team? What about a fast voting process to take
>> decisions? Are there a formal meritocratic core team?

KiCad is a meritocracy in that you earn status by contributing and a
willingness to work respectfully with the current development teams.
This means contributing code, documentation, libraries, scripts, etc.
It also means discussing those changes openly with the dev team and
respecting the input of others and the lead devs.  As long as I am the
project leader or there is a huge shift in human enlightenment, kicad
will never be a pure democracy.  Pure democracies are mob rules and
highly volatile.  Do some history research on the ancient Athenians and
some of bad laws that came to pass due to pure democratic rule.
Hysteria does not make for good governance.  Maybe in 1000 years (which
I think is highly optimistic) when humanity becomes a bit more
enlightened, pure democracies may be a viable way to govern.  Since I
wont be alive then, it be a problem someone else will have to solve. :)

>> - Wiki: What about using a wiki for documentation? It provides an easier to
>> use environment,  it can be customized for i18n and even parsing KiCad
>> files to show them  as SVG if someone writes a plugin for it. The
>> documentation could be exported and shipped in each release, too.

I would suggest that you discuss this with our documentation developers
on github.  I doubt they would be too keen on moving to a wiki based
platform.  We just recently converted from odt files to asciidoc which
is automatically regenerated to translated html, epub, and pdf formats
when a pull request is made on github and linked to the kicad website.
I really like what documentation and website dev teams have done and
they have my full support and thanks for their efforts.  I'm not
convinced a wiki is a good idea.  You would have to convince both me and
more importantly the documentation team that that using a wiki makes sense.

Cheers,

Wayne

>>
>>
>>
>> Relevant links:
>> https://forum.kicad.info/t/simulating-kicad-schematics-in-spice/
>> http://mithatkonar.com/wiki/doku.php/kicad/kicad_spice_quick_guide
>> http://esim.fossee.in
>> https://github.com/Oscad
>> http://www.iitb.ac.in
>>
>> Kind regards.
>>
> 
> ______________________________________________________________________
> Vystup z řady a zřiď si taky originální email! @bigboss.cz, @dablik.cz, @potvurka.cz, @tajny.cz... zdarma na http://email.sms.cz
> COMDOM Antispam - www.comdomsoft.com
> 
> 
> 
> 
> _______________________________________________
> 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
> 


Follow ups

References