KiCad development policy questions

I came in to Kicad at V4.9 and I remember saving and moving the netlist every time :scream:
I was using a laptop then, I still have a ‘track pad’ imprint on my forehead.
:mouse:

1 Like

Running on three very different OS is challenging for the KiCad roadmap, shifts in the infrastructure like Wayland get in the way.

" … to provide the best possible cross platform electronics design application for professional electronics designers."

You seem put out, so I will emphasise again that I intend no disrespect. But, that statement isn’t really useful as a vision - as a means to set a direction of travel. “Best possible” has no meaning, because “best” is totally subjective and every single user will have their own idea of what “best” means to them. And how will you know when you’ve achieved it? Also, I see you’ve built in a caveat: “best possible”, instead of simply “best”.

I’m talking about something different. The approach is to sit down and define exactly what “best possible” looks like, in as much detail as you can. The functionality, the work flow, the user interface, etc. You need something more solid and tangible than “best possible” - something you can measure your progress against. That’s the key thing. Once you have that vision, then you can create a roadmap of all the steps you will take to reach it. And yes, that vision will inevitably develop, change and adapt as the world changes, but at any given moment it embodies the essence of the “perfect” KiCAD and a roadmap of how you will reach it.

Exactly. Hashing out which parts to build each year is what I’m talking about. Essentially you are deciding on a year-by-year basis what to do, presumably based primarily on user requests, without reference to a longer term plan or roadmap other than “best possible”, which I’ve already said cannot be defined so cannot be used to set a direction of travel.

I take your point about Torvalds. Probably a better example would be Steve Jobs. He knew exactly what each Apple product would do, what it would look like, how it would work, etc. He had a clear vision of what “Appleness” was and he produced by far the most coherent ecosystem of products, with consistent modus operandi, in the computing world. Look how Microsoft struggles in comparison. We’ve ended up with the half-baked mess of Windows 11, after endless false starts, blind alleys, changes of direction. All because they kept putting different people in charge of Windows, different people working on it. No long term vision.

Again, I don’t want anyone to see criticism here. Your work on KiCAD is improving it a lot every year, and personally I’m extremely grateful for it. The fact that KiCAD doesn’t have its own Steve Jobs is simply an observation of the obvious, not a criticism. The same is true of most open source software.

I’ve re-quoted @paulvdh here, because he expresses a similar argument, albeit with far fewer words than me. :grin:

And please - we’re just mulling it over here. Nobody should feel criticised.

There is a lot more planning and long-term discussion that goes in to it than you presume, and if we had a lot more time we could probably fix this by spending a lot of time to document and publish this for the general public to consume. But for the moment, we do not, so I can understand why it seems like maybe there is not enough long-term planning.

This is not really true. What does happen year-by-year is that the volunteer developers have more or less time, new developers are added to the team, etc. This causes changes to what gets done more often than deciding one year that what KiCad needs is different than we decided last year.

The point of a mission statement is not to include all that detail. Because that detail is missing from the mission statement, you assume that we don’t think about such things? There are many ways we can measure progress. To give one example, we regularly talk to professional users who are familiar with KiCad but who use other tools because KiCad is not currently the best for them.

In my opinion it would be a fool’s errand to try to do this up front, globally. KiCad is a well-established product, we’re not starting from the ground up. We do what you say, but at a smaller scope: when considering adding or changing a feature, we look at that kind of detail.

If I read between the lines, it seems like you wish there were a publicly-accessible real-time roadmap for KiCad that you could look at and decide whether or not you agree with. For various reasons, we don’t currently publish such a thing (we did in the past, and discontinued it because it was neither helpful to the team nor to the community). Because of this, you’ll just have to take our word for it (or not) that significantly more long-term planning goes into KiCad than you seem to assume.

6 Likes

It isn’t so much what I assume, as what I can find evidence for. Thanks for such a helpful reply.

1 Like

Well, you can’t be blamed for interpreting the evidence you have found in a certain way. On the other hand, you assumed that lack of evidence is evidence of lack, which is a logical fallacy.

For what it’s worth, I once followed the development cycle very closely, maybe as closely as one can without being a developer. I started and updated the “post-v5 new features and development news” thread which became one of the longest here. I quoted the roadmap which existed back then. I read the git logs almost daily and followed the development mailing list. Yet I noticed, especially later, that I didn’t know everything which was happening, and afterward in the later development cycles “behind the scenes” planning has only increased, if I have interpreted the clues correctly.

So, I could have commented shortly and in general level, based on instinct and feeling, something similar to what Seth and Jon wrote in detail. But I couldn’t have said it’s a fact or that I know. It’s mostly opaque and I understand even those who have spent time reading information about the project don’t understand details about what’s really happening. Therefore Seth’s and Jon’s posts are especially valuable.

I said that " … to provide the best possible cross platform electronics design application for professional electronics designers" doesn’t constitute a useful vision because: a/ it is totally subjective; b/ progress against it cannot be measured; c/ it contains nothing from which a long-term plan or roadmap could be generated.

The mission statement goes on to say " … when determining the direction of the project and the priority of new features, the needs of professional users take precedence." This implies that the development work is more reactive (demand-driven) than proactive. Not entirely, just “takes precedence”. That’s fair enough - nothing wrong with it as a policy. Most open-source software seems to be the same.

@craftyjon tells us that there is something of a long-term vision or plan behind the scenes, it’s just invisible to us ordinary users. Again, I’m happy to take that as read.

I fear we are well down a rabbit hole here. I’m happy to continue with it, but we have drifted away somewhat from the original question and people are probably pretty bored with it. :grin:

1 Like

In case I was misinterpreted: we’re not trying to hide anything, we’re just also not putting effort into publishing some kind of plan (because it takes a lot of effort to do so, and we’d rather spend that time coding).

1 Like

Understood. Thanks @craftyjon .

It would be easier if you stayed off the forum and getting pushed around by user requests. :wink:

1 Like

Please, for one version run, don’t push a mass of new functionality but concentate on UI and a valid help system!
Additionally, implement a policy moving forward, that whomever codes a new function or whatever they MUST write their own entry into the help system and not rely on others to sort out. They would know how something works so they would be the nest person to exain it to others! It’s all very well RTF manual if it is up-to-date!

Each release includes UI improvements. We balance these changes against large UI overalls that are disruptive to people who make their living on KiCad and are accustomed to certain workflows. I think that our current process of incremental improvements is currently yielding benefits. We have yet to put out the equivalent of MS Bob or Netscape 6 and avoiding the siren song of “Just scrap it and start over” is pretty key to that.

A strong help system is certainly an idea worth exploring. We have decided that our best course of action is to leave the documentation on the web (PDF for offline) instead of also trying to maintain a built-in documentation engine. We might eventually integrate that by using offline HTML files but so far it would seem that the relative utility of that vs other things that we might add to the code is small.

Exactly which part of the manual is out of date?

Tell me how the development stage has changed between versions 8 and 9? Should we expect a global update once a year? Changes in library format and file format? Thank you

The skill set for coding does not necessarily translate into writing good documentation though and requiring people to do things they don’t enjoy (when they are not being paid) could be off putting.

3 Likes

In addition to that in my opinion having three different actors on the scene, one writes the code, one test the code, one writes the documentation, in the long run leads to a better overall quality.

2 Likes

Software Design and Coding are two different tasks, it may be separated into different job functions.
Help functions could also be mouse-over “bubble help”.
Already done in KiCAD, user interfaces can and should be configurable. Have identical “hot-keys” for the same functions between programs is extremely helpful.
RTF manual is an old idea, intuitiveness is better.
Right-click context menus are great, and configurable, like menu bars in Firefox and Open Office, is even better.

I think a long term published roadmap for Kicad is too much pressure on those with the skillsets to offer contributions.

Kicad is a FOS product created and maintained by voluntary labour. Placing any restrictions on those willing to participate is folly.

For those who have never been here. This is item number six in the Base Guidelines:

We prioritize our families, our health and our offline lives ahead of KiCad.

Suggestions for changes are always welcome, but otherwise, users should just enjoy and appreciate what is on the screen in front of them.

3 Likes

We currently plan on releasing a new major KiCad version each year. The major release will typically include additions to the library and file formats.

This quite a silly discussion imho, and I am surprised that there are so many replies to give it traction.

The people who donate big wads of cash to KiCad, or actually pay money to KiCad Services for professional support, have a somewhat appropriate right to voice some development direction requests.
Pay your money here:
https://www.kipro-pcb.com/

Everyone who uses KiCad for free, mind your own business. KiCad is an awesome frickin’ program.

1 Like

I don’t understand. Is there some problem here?

1 Like