kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

I would like to add just a little to this:  over the last few years, many
people on this list have spent a lot of time making the developer community
a friendlier place.  This is not easy, and required hard decisions by many
people.

Additionally, people have worked hard to make it easier to contribute to
KiCad.

Please do not use the tone of emails from years ago on this list as an
indication of how things work today.  We really, seriously, try to be nice
here!

Additionally, I'm seeing more and more emails that imply that the masses of
KiCad core developers are doing this or doing that.  There are not many
KiCad developers.

Every minute I spend on KiCad is only possible because my business sells
products we designed using KiCad.  I looked around, and few people were
working on KiCad, and I had most of the required skills to provide value.
That was 5 years ago, oof.

To be a core developer of KiCad, regardless of the state of the codebase,
even if it was amazing and super testable, had no bugs, had amazing
documentation, you must have a good handle on the problem domain, which is
electronics design, probably have experience using Altium or PADS or
another piece of software that costs $10k+, and be able to work on large
codebase that must work on Windows/Linux/OS X.

This probably means you're highly employable, but somehow have a philosophy
or delusions that make you give away your time. :)

Based on my experience, then you'll make a cool new thing for KiCad that
everyone wants, and you'll find out that upstream software that KiCad uses
has two different bugs on two different platforms that require you to learn
their software and write a patch.  Most of the developers here have code or
patches for CMake, maybe boost, probably wx...

There are exceptions to this.  Some businesses choose to pay their
employees to work on KiCad, but I don't think this is very common.

This whole paradox is one of the main reasons why I push so hard to keep
the development list friendly.  (The other is that being nicer, even at
small potential productivity hit, is something I believe is The Right Thing
To Do.). By keeping the list friendly, gradually improving code quality,
making it easier for new developers to successfully work with the code
base, and actively looking for things that non-core developers can do, we
help increase the speed of improvement and the longevity of KiCad.

(I do not speak for all developers, or even anyone else on this list.)

(Wayne, I was just discussing with someone last night, that we might want
to have a monthly email that goes out on this list, which is a devlist
FAQ... What do you think?)
On Nov 4, 2015 10:02 AM, "Wayne Stambaugh" <stambaughw@xxxxxxxxx> wrote:

> 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
> >
>
> _______________________________________________
> 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
>