Always be aware of your own biases. While you and some others consider the clearance matrix (or something similar) to be one of the most important improvements, others might disagree. (For example somebody mainly working with flex boards would much rather see curved traces, hatched copper fills and possibly also teardrops be added. And yes parts of this are already in nightly.)
The core developers need to balance adding visible features and background work. One big example is the new file format for eeschema that will in the first instance not really add new features but will enable huge improvements in future releases. If the devs only focus on what users want right now then such huge investments will never get of the ground.
Hi @Rene_Poschl,
I don’t mean to add more confusion to the discussion, nor I am endorsing such a thing, but:
What is your personal position (or the other project leader’s/developer’s) if a bunch of people wants to pay some external developer to build a feature such as the clearance matrix? Would something like that be ok?
This way, people would get the feature they want/need and we wouldn’t be removing precious time away from kicad developer’s hands. I understand that this might increase the technical debt and would be channeling funds away from the people that have the hardest work - I think that part of the funds invested in the external developer team should be donated back to the kicad project.
I think this might be a fair compromise between both parties but I would like to know your opinion.
First of all, i am not a developer but just the head of the library team.
But i assume that i can deduce quite a bit from what i understand about the development of any product including KiCad. In such a large project any feature added must be developed in close coordination with project management. So if you hire external guys then they must communicate with the lead developers.
Otherwise, you have the danger that the work done must be rejected because it does not fit the longterm plans for KiCad. This has happened before. There were at least two attempts to add teardrop support. Both would have broken core assumptions made by the main development team so needed to be fixed up to fit the overall plan (At least one of them was build upon the old toolset that was already frozen at that point in time). In both cases the contributors ran out of resources (in this case motivation) before they could fix up their work. Both of these attempts would have resulted in a great feature added to KiCad if their developers would have more closely communicated with the core team. It would have also spared everyone involved from the bad experience that came from these additions needing to be rejected.
There is however a catch. The core team has only so much time. So getting too many external contributors added without at the same time supporting the core team will result in the core team being overwhelmed. See for example the predicament we have on the library side. There is no shortage on contributions but definitely a lack in reviewers. Resulting in a bad experience for everyone involved (The contributors get frustrated because their work is not reviewed in a timely manner and the maintainers are in danger of burnout as no matter how many hours one invests the number of open requests simply does not seem to shrink)
Personally I would consider a value driven development a way of easy user oriented software development. By making a viable business concept out of an open source software, a huge leap in technology improvement may be possible. If you get payed for your hobby, what bettet can happen?
I personally have the feeling i caused confusion. I am not planning to hire any external developper. KiPro @Seth_h are core Kicad devs and they know best what to do. I think the devs are now well aware of this feature request, which is present now for 5 years (i guess).
If @Seth_h felt this could be done at a reasonable cost and along a reasonable time line I’m sure this would happen and he would say as much. Kicad as a whole would probably fail if features were held for ransom. I’m sure it is an image he really wants/needs to avoid too.
The cost estimate reflects the dependencies that need to be implemented in order to support the feature. As we continue v6 development, more of these dependencies will be implemented and the cost to this particular feature will decrease. A drive-by coder could create something that achieves this more quickly but increases the technical debt of the project and makes future development more difficult. That would harm all users and is not the approach we take.
There are other feature development works currently in progress that businesses have funded for much less than this request. Quotes are given based on the estimated work time for the feature itself as well as the underlying technical requirements.