Right, but you also have to see that KiCad is now partly commercially driven (donations just reached $100k recently), so there is some responsibility where the developers spend their time. They presented their focus, and donors basically approved it… So, hard to change direction…
I wholeheartedly agree with that. I switched to Linux exclusively some 7 years ago, and needed a new PCB design program. There were quite a few puzzle pieces in KiCad missing at that time (For example Library management just did not work at all, it was extremely buggy), but I saw it’s potential back then and started using it anyway. And quite a chunk of it’s potential has already been realized. Now it is a very usable program. In my opinion it has surpassed the “hobby level” EDA programs, and it’s starting to compete with the middle market, and getting some “high end” features such as the database library system. But it’s also still lacking in some other areas. (and yes, the lack of this “forward compatibility” is one of those).
I do not really see donations as “commercially driven”.
KiCad itself is a fully open source project. Everyone can use it for free, get the sourcecode from gitlab for free and compile it themselves, work on the code, make suggestions or even do some coding and make merge requests.
But the KiCad project is surely growing, and doing so quite fast in the last few years. Donations are also rising. Both the yearly fund drive and regular contributions. There are lots of small donations from users, and several regular companies who make quite large donations. Both Aisler and Oshpark have been making quite substantial monthly donations. Digikey made an USD15000 donation as part of the yearly fund drive on 2022-12-21 via The Linux Foundation. Other donations such as via https://donate.kicad.org/ or CERN do not show detailed statistics. (Gosh, Cern still shows a KiCad V5 (Or V4?) screenshot ) There also was an EUR50000 grant from NL net on 2022-09-06.
I don’t know much about how the KiCad money is spent. I do know a developer was hired to redo all the Icons for KiCad V6. It’s quite a bummer that KiCad was rejected for FOSDEM last february. An update about current issues, near feature goals and how to spend the money would be nice. I think KiCad is getting into the area which has the potential to become awkward. Donations are becoming a serious amount of money, and if that is not spend wisely, it can create internal friction, and this can even be detrimental, for example by developers stopping because this friction makes them loose the fun in contributing to KiCad. Blender seems to handle this really well. They get around 2M in donations annually.
There is this 2022 End-of-year Recap! on Youtube It is just as the title says, The first hour is the development that has gone into V7, and then about thirty minutes of question answers. There is not much about strategy and future directions and goals.
Dear Paul. I mostly agree with you. Kicad is a tool, is above “only for curios” level, reach the level where the chip manufacturer take seriously providing footprints. At this moment for new footprint i am using snapeda or ultralibrarian, if embeded will be great (this is another topic).
In my job i am trying to switch to kicad. As all we know there are many options and each employee have their own option. Half use kicad, another half use Orcad but almost all preffer use altium. Because this the “standard” when any search for a Job and all want have experience with altium in their resume.
So, as altium open kicad 6 files, kicad can be an excellent friend of the altium world but for this we need the compatibility layer.
In my opinion there are can be file format reasons that make very difficult to save the files in older versions.
As an example, rectangular pads with rounded corners were not supported in v4. I do not remember when a circle was exported as a whole circle instead of as two semi-circles.
This kind of items are hard to export to versions not supporting them.
That is all true, but I do not consider it a valid argument.
At the moment KiCad looks at the date stamp at the beginning of a file, and if it’s in the future it just refuses to open the file. This is “safe” and simple,but it is also very dumb.
Having an import filter that just dumps everything it does not understand in a text window (with a save option) puts the user in control. If the older version does not support rectangular pads with rounded corners, then it’s easy enough to replace some footprints with whatever that older version does support. If a few circles are missing, so what? As long as you have some Idea of what is missing, then it’s very likely easy to repair manually. Being able to port 95% is much better then KiCad just giving a big finger to the user, especially if the other 5% is dumped in a text file, so you know what is missing and where you need to go to fix issues.
Some time ago I wrote:
And it’s a valid and useful method. The concept of a “footprint” does not exist in a gerber file at all, but it’s easy enough to just delete all the pads, and then place a new footprint on top of the existing track ends. With a back import from Gerbers you get about 80% to 90% of the PCB from any project which has gerbers available. Reconstructing the schematic was a lot more work. It was mostly a manual re-creation from a .PDF file, but by updating the PCB regularly and DRC which flags connection errors it’s still much better then “nothing”. I made a few mistakes by re-creating a KiCad schematic from the pdf, and those were caught by the DRC because all tracks were preserved from the Gerber file, and they implicitly define the netlist.
Dear Pedro. I know that is hard, but i think that software industries have a lot of experience on this and will help on it. I can start a big list that sofware that allow save on old format, from Altium in the last version that i use some years ago to Libreoffice in open source world.
This is no the discussion, the discussion is “What we are loosing because the incompatibilities?”. I agree: is hard to do, is boring, and the resources always are fewer.
As i said in previous post in my company 2 providers refuse work with the files on kicad because he cant open in altium the kicad 7 files.
Today some happens in my job, one provider meet with my boss and tell directly: “Purchase Altium we can not work with the PDF file”. This have no place to doubt, was a clear and direct message and is the real point of this thread. I am sharing my experience here, but i will let this question: “inside of how many companies we have (and loose) the same discussion” and we never know. I have faith that Kicad can break the crystal roof.
There are plenty of commercial apps that do not export to old versions, forcing sales of new versions.
At least installing a new KiCad version is free and allows you to keep older versions in parallel
@OP if you are aiming to get more migrants from Altium, then surely this is the wrong way. The way would be to write converters from Altium to KiCad 7,8,9,10, etc. Surely making it easier to export to Altium will entrench Altium usage? In fact a measure of success is if Altium develops a KiCad7 to Altium importer. Or some large organisation decides that KiCad N is good enough and sponsors an Altium importer for their work.
But I think focusing on Altium is myopic. KiCad should aim to be the best Open Source PCB CAD program.
@paulvdh , @schlabs
Paul, Christian, I have thought the issue was saving in v6 format the projects designed with v7 in order to share those projects and continue the work on v6. All the intereactive process working with v6 and v7.
Porting 95% of the work is better than porting none only if we know what is the missing 5%. At least is risky.
The situation is different if the people with v6 version is not going to work in the project.
About the providers refusing to work with kicad files, this is a completely different question. In our company, a small one, I have to fight with some people that do no want to migrate from MS-Office to LibreOffice only because the menu is different, but they do not have any problem changing from MSOffice to a newer version that has indeed a different menu. Or they do not want Freecad because they have a pirate copy of AutoCad at home.
I agree it should be easier to create a v7 to v6 converter than an altium, cadstar or eagle to v6 one. As usually, it is a question of priorities or needs. And it is not likely that someone who does not need the feature will programme it. Unfortunately this is not a perfect world.
I understand the sentiment.
It is however a bit hard to do this now. It should have been a feature designed up front. In many cases applications that can do this have a method to explode items into fundamental building blocks. Here you get into problems in KiCad generally as the software does not really have a full suite of underlying primitives to work with.
Mostly CAD applications generally implement rational b-splines and desktop publication applications bezer splines. These are general enough that you can later explode any other construct into pieces since these can generally describe mostly anything. Everything in application is built out of these primitives. So if you made a interactive feature it internally builds the base primitives you can just drop the interactive features and just dump the geometry.
But as said KiCad does not have this for many things, so there is no generic path for doing backwards compatibility, other than turning everything to lines*. But these can not describe everything that has been added.
However there is an alternative, instead of sharing files. Share the entire software. Nobody has to install anything.
* being able to explode stuff even in application is often super useful.
That is not always a valid option.
For example, it’s quite common for companies to stay with older versions if their income depends on stable software. That is more important then the latest features. But I only have the current stable version (V7 at the moment), so if someone attaches a V6 version to a forum question, I can “upgrade” the project to V7, but they can’t get back. (Also having older versions installed on Linux is a real nuisance for the package management).
And there are other reasons too. As Schlabs noted, Altium apparently only imports KiCad V6 or older at the moment, and nobody know how long it takes them to update their importers.
Yeah i understand that there are valid issues. Its just not something you can bolt on to an application, you frequently need to redesign the whole thing. This is a normal thing with applications that needed to grow organically and had not enough up front investment.
Exporting to an older version can be more complete then importing from a future version, because the new version has knowledge of it’s own internals and can attempt to translate to some approximation for the old version, or make other intelligent decisions, but this takes effort and constant maintenance.
Importing from a future version, may only get you 80% to 95% (depending on the relative differences of course) but the needed effort for the programmers is much less. It’s mostly a one time effort to add some code to dump unrecognized constructs into some text file. This can also be a useful tools for debugging during development. Such a partial conversion would be annoying between collaboration in a group, but it is quite usable for one time conversions.
Dear Everyone:
I have official ms-Office, but i use LibreOffice, i share files, open docx, doc, and ms-office open the odt files. So all employees are happy sharing office files, some with Ms, other use libre. But Libreoffice is excellent opening CSV files ( bill of materials) best than MS so in I+D the 90% use LibreOffice. LibreOffice is wining space.
In my job i do not want expose some that compromise my job. The company have more than 10 years and we have project in older orcad, in ltspice, another in kicad with a copy on orcad. Is very important keep the possibility of open every projects because the first projects still is on production (is long of explain why and is completely off topic, but say that we cannot change nothing to the project). As part of company politics we made the schema, and external contractor draw the PCB.
The contractor open the kicad files on Altium and generate work with the files. Here is the problem.
Why the contractor use Altium? Of course all other customer send the files on altium. They dont will download kicad, and is my responsibility that do the required things to get the prototype.
In the same way that i write in English to allow everyone understand to me because i want to be listened. Obviously i can write on Spanish and say you can learn it, but the result will be the opposite, everyone will pass, my idea simply will be discarded or worst someone answer in another language that i cant understand and i need learn.
I will explain again, the idea of this post is a positive feedback, some that improve the software. Not now, i didn’t hope that someone say “Right now i will start make…”.
If the topic legacy is “this will help to kicad to grow” i am happy. If the kicad 8 have a kicad 7 format save is great, if 7.1 have save kicad 6 is “Fabulous”.
If the answer is kicad never will do a compatibility layer, then i will be forced to talk the provider language on my job, and kicad will let for experimental at home.
I think that is more easy think about new changes when you are making it. If implemented this will make think twice any change, or even group the changes so make one porting tool.
The reality is that nobody has (to date) been interested in this functionality enough to pay for it. As many people have pointed out many times, any sort of implementation of “save in old version” would be extremely time-consuming to maintain, because of the pace of new features being added to KiCad. It does not make sense to compare KiCad to tools like Word/Excel where the basic feature set has been stable for decades. Every year we add stuff to KiCad that was not possible to do at all in previous versions. So it is not practical to “export to old version” without just throwing data away.
So then the people who are suggesting that this function should exist anyway and they are fine with throwing away 20% of the data: even implementing this imperfect converter would add a multiplier to the cost of developing every new feature from that point forward. And there is nobody that excited about paying for that multiplier in cost, either by hiring a developer to make it happen or by conceding that features will take that much longer to get developed.
The time to revisit this topic is when we go a year without making serious changes to the file format, because we’ve finally run out of major feature requests that require adding new functionality to the file format to implement.
I have official ms-Office, but i use LibreOffice, i share files, open docx, doc, and ms-office open the odt files
Even this approach doesn’t works if some of the more advanced MS-office or Libreoffice features are used:
- integrated drawings?
- pictures with automatic textflow around?
- automatic table of contents?
- integrated animated pictures (powerpoint on ms-office versus presentation on libreoffice)
Have fun with converting these things back and forth. Everything more complex than simple text doesn’t works reliable. (Had this exactly this week: got powerpoint presentation for teaching a course the next 16weeks - tried 1…2 days to get it acceptable (==not100%) working with libre, lastly ended up buying a ms office license)
And for Altium: We tried to share projects between Altium circuitstudio and complete Altium Studio. No chance to get that reliable and flawlessly working. It was ok for a one-way conversion, but using it as a constant forth<–> back conversion for normal work (schematic in circuitstudio , pcb in full Altium, like in your description) was a real pain.
My summary (from long years): working with different tools on the same project is one of the worst ideas. Creates only friction and problems, and offers no benefit. I’m open to change my mind if someone proves that it works on real world projects, but until that time my point of view is fixed.
yes? as a developer working for free, would I rather implement missing features in KiCad or do the same thing but 3x slower, to appease the small fraction of users looking to be able to get those missing features working in an old file format version?
I mostly agree, except for this part:
Adding a simple filter, so KiCad just interprets what it can, and dumps on screen or in a text file what it does not understand would be a quite simple feature to add, and it would be useful enough to be a “nice to have”.
I won’t say “never”, but it does seem likely that it would take several years before:
Also, if the start of such a simple filter is implemented, then it’s more likely that some part time developer who needs this is willing to spend some time on it to improve it and probably also make a few patches or merge requests with his improvements. It’s the nature of open source development for things to change and improve incrementally. But before it can grow, there has to be a start. As long as the “official” standpoint is “Not for the next few years”, then it’s simply blocked right there.
As I see it, it would not hinder any regular users, and the code could start with a warning such as:
KiCad can not reliably import from a future version, would you like to attempt a partial import anyway?
KiCad’s file formats change so much from version to version that this would be not very useful. You would get a very broken design in almost all cases. It is wishful thinking to say that there will only be a “few missing things to clean up here and there”.
Like I said, at the point where KiCad can go a year with only minor changes, such that there really would be only a few things here and there missing, what you propose would make sense.
And maybe it should and was meant too? No use going down a path that will dead end sometimes.
Just consider it a donation if it is that important because potentially anyone would benefit.