kicad-developers team mailing list archive

[timofonic timofonic <timofonic@xxxxxxxxx>]

Hello.

I wrote this as a very early draft in order to understand KiCad better and
the planning of the project.

I'm sure it's highly inaccurate, full of mistakes and written in a not so
good English.

This is part of my personal project to understand KiCad, some inaccurate
research notes and personal ideas I would like to refine.

Any feedback (corrections, suggestions, information sources...) will be
very welcomed.

I would like to know opinions about it, inconsistencies and other ideas. I
would like to research about KiCad history and involved developers in a
detailed way too, if the KiCad Team agree on it.

I plan even to persuade the teachers in my vocational school to make this
possible Spanish/English article as homework.

It will be about:

- Software: KiCad, other useful tools such as QUCS.
- FOSS: Importance in society and what can provide to electronics.
- OSHW: Explaining historical roots, such as homebrew computers and the
classic hacker culture, plus current trends.
- Advantages in learning electronics by using: Copyleft learning material,
FOSS/OSHW communities, forums and mailing lists, videoblogs.
- Active Learning in electronics.

My basic understanding about the development of KiCad:
----------------------------------------------

I see KiCad is manpower limited and needs to complete certain goals and not
waste resources.

I think to understand KiCad have very important tasks to be done to be
future proof:

- I understand KiCad needs desperately a massive and careful refactoring.
* Maybe there's still too much cowboy coding and stuff to clean before
implementing important but complex features.
* Maybe part of that refactoring could help making the code easier to
understand to new developers.
** This would mean following somewhat strict and defined coding practices,
very documented code and other stuff developers are aware of it for sure.

My understanding about potential KiCad sectors
-----------------------------------

- Hackers: People very enthusiastically interested and active in
electronics and programming field that just would like to participate in a
community project.
* They can be programmers with interest in electronics, even being very
skilled professional programmers donating part of their spare time.
* They can be in the electronics field but interested in programming too as
a secondary field to explore.

- Hobbyists/Makers: Some already switched from Eagle to KiCad, but many of
them switched to free but vendor lock-in alternatives or may encounter some
barriers: Interoperability, UX, performance on low end computers.

- EEs: They are used to many high end solutions such as Cadence Allegro,
Altium, OrCad and others.
* They might be very used to certain features and/or workflows, probably
more in very complex designs.
* Reach these goals are very difficult to do, but not impossible if the
project grows.

- Companies, educational sector, NGOs:
* Organizations don't wanting to spend big sums of money in EDA software or
unable to afford it, even using old versions or illegitimate ones.
* They might have developers in their organization. In other cases like
certain countries, they could hire one for less than the license cost.
** This way they may be able to contribute to make KiCad match their needs
and even finally reduce costs. And avoid illegitimate practices, too.

Some goals I personally consider important:
----------------------------------------------

* Advanced and reliable file format interoperability: Deal with it, the
situation is even worse than Office suites and needing to redo projects
might unmotivate many people.
* Usability: People are already extremely used to common practices and
features in popular propietary software.
** I don't see pragmatic to be the small guy in town fighting against the
big ones, I believe a different strategy should be done.
** I think  behaving more like them and not look too different might be
better in a logic and comprehensive way by "copying" the good usable stuff
and avoid the bad ones.
*** Maybe it could make transition easier. I think LibreOffice does it in a
smart way.

* Very powerful scripting capabilities and a central repository, even
trying to surpass capabilities of high end and mid end EDA software.

* Easy collaborative Edition, providing visual diffs and other stuff.

My defense on "Release early, release often"
------------------------------

- Release incremental releases with minor and less bug prone but useful
changes could give more sense of activity.
* This could provide more stimulation to users about the project, having
new things to use and explore.
** You can think about it as giving small gifts to keep interest in
following new versions.
* I think this could enhance the community feeling and promote a more
active participation.
* People like to see new things, it's something wired in our brains.
* Because of these minor but interesting releases, there could be more
media exposure and work as a form of marketing.

- Having two branches: stable and experimental
* This could be done until the refactoring gets done. The stable one would
just provide these small updates as minor improvements.
* Would this require too much extra work?
* Can it be done without interrupting the mainline important future proof
branch?

Thanks in advance.

Kind regards.