Sorry for the off-topic
This is what I do too: my designs are divided in blocks, each block in its sheet even if there is not any hierarchy and all the sheets are at the same leve but the top level sheet. For example, SMPS has individual sheets for Input, pwm driver, transformer, output and feedback. Usually I place the feedback optocouplers on the top level sheet just for clarity.
Yes. Quoted directly from: Priority Development
KiPro brings additional developer resources to the KiCad project. Our time is driven by the features most requested by our active subscriber base. A KiPro subscription adds your needs and priorities to our list.
We don’t direct the KiCad development. We make it happen faster.
All KiCad users get lots of new features for free each year because of all the wonderful volunteers working on KiCad, but when you pay for support, you also get priority development. And I guess that if you want special features implemented, you can negotiate of the price to get it a high priority. But (very likely) your feature has to fit within KiCad’s philosophy, but you really have to talk to KiPro for such things.
I have also seen several bug reports on gitlab go confidential, because companies uploaded a proprietary design t help with the bug fixing. After that happens, the whole topic disappears for regular folks such as me.
1 Like
From what I read, they’ll also implement special features just for you if these don’t fit into the main KiCad application, or at least they’ve done so historically, and then send you a private plug-in or a patched version. But this might be more expensive than just implementing it as a mainline feature.
Paying for development of specific features could be cheaper than the old system in the long run. The question becomes total budget? Future direction is harder to sort out.
Straying off topic just a bit, but a decision maker would expose himself to a career-limiting risk if he chose something non-standard like KiCad and it didn’t work out. But if it did provide benefits (lowered costs, improved productivity), these would accrue to the company and not to him directly. So the default decision is usually to resort to the status quo until the potential reward is so large and such a sure thing that it can’t be ignored.
3 Likes
General consensus/popular saying/whatever:
‘Nobody ever got fired for choosing Microsoft/Cisco.’
My take? Maybe they should. 
EDIT: It sounds like Kicad was considered too late in the process here. It is freely available for testing to determine suitability for purpose.
3 Likes
So in practical realization, do you need to have the root sheet? Or…am I (once again) full of sheet? I guess that does not sound too bad, but I think it requires what would otherwise be a two page schematic to be a three page schematic? Then that root sheet is kind of a “duh” in that situation. Not much useful information. I can see that if you have a larger bunch of sheets that the root sheet might be more helpful.
Well spotted and so true 
afaik there is always a root sheet aka main schematic sheet. This is where the hierarchiel sheets lie.
If you have only sheets without hierarchial labels, than the front page is just a blank page with some square boxes drawn on them which does not provide much information. So you don’t really need it, but I guess it has to exist for practical reasons. I use the front panel to simply make new sheets on which lead to new schematic files. Other than that I ignore it.
I guess you can move the sheet boxes outside of the title block so you don’t see them 
Than you can use the front panel as one of your sheets.
Bas
1 Like
I worry that by just playing around with KiCad, I will not be able to apprehend all the advanced topics like … version control …
We want to start over with everything. A big factor is collaborative and version controlled workflows. We want to move from (local) file based storage to a VCS with all the features that you expect. Also automatic creation of manufacturing data is a big issue.
Maybe somewhat OT. Version control doesn’t belong inside the EDA program, and KiCad doesn’t have integrated version control. But it doesn’t need to: The files are text based and work very well with version control software. Most people use git for KiCad for version controlling and this works well, there where even some patches making the files more VCS-friendly.
You basically need to know a VCS, such as git, and then you can use version control with your KiCad projects.
2 Likes
KiCAD can be used for small Teams up to 3 people. This limit is due to the lack of database for parts. The latest version (v7) did start implementing databases but in its current state due to the dependance of local symbols, it is utterly useless. If you define that only one person does integrate new parts, you are fine and you can deploy library with Git, footprints, 3D models and datasheets by share or Git as well.
KiCAD projects can and probably should be used with Git for version control. One major issue there is the cache of symbols to be sure older schematics can always be opened in a useful way. This is something you should test because if its not corretly in the repo if you find out its too late.
KiCAD by its current nature is NOT equiped for collaborating work styles.
That’s exactly how Altium works, you point those database entries in Altium to network shares or SVN to find the files.
This is not true. This workflow can and is being used on larger teams, and KiCad is not the only tool that works this way as Mark points out.
This is also not true since 6.0, please update your biases for recent versions of KiCad 
Altium is the one tool I don’t really know. But the issue with KiCAD symbols-libaries is that it is one file containing multiple symbols. If edited by more than one person if not locked, you are destined to get in trouble. If under Git while normally being a good idea, merging library files is a nightmare. If every symbol would be one file, then the current DB implementation could work (in conjunction with a shared folder).
This is just a silly remark. If you want to work with database libraries, you always have to setup the database yourself and fill it with parts and other meta info, such as ordering numbers, stock, pricing, prefered parts vendors, substitutes and whatever other info you want to put in the database. KiCad as a generic EDA suite can never do that for you. It can only deliver the mechanism to integrate with such a database.
KiCad is also not the only tool that stores entire libraries in one file. This workflow can and does work in larger teams. All you need is a specific workflow that handles this (either use a VCS that supports file locking, or use some external method for file locking if using a VCS like Git that does not). If you have some mechanism, whether it is software or policy, that prevents two people from trying to edit the library at the same time, you will have no problems. I have seen this working in production for a long time.
Any software, no matter how bad, can be handled with a proper workflow. I already pointed that out. But if you implement something why not make it useful… But hey, that is only my personal experience.
I am a donating user that pushed KiCAD into production environment and over all I am happy with it.
Your assumption, that the current workflow is not useful and can’t be used on a larger team, is false.
Not an assumption. We tried and failed. But then it could be us.
It would be better to explain more detail of what you tried and why you failed, and then perhaps other people that haven’t failed can point out the differences in their own experiences in case it’s helpful.
In general it might have been a better original post to say “we tried this and it didn’t work out for us for reasons X, y, Z, but maybe it will work out for you” rather than just saying “this doesn’t work and is useless”