Proposal

[Andrei-Pozolotin]

As seen on the user forum and the developer list:

This is a proposal to create kicad-extra organization.

The idea is to move all present kicad extensions: tools, scripts, plugins, into single location, here, and have shared project ownership, similar to https://github.com/KiCad

The intent is to have many qualified developers for any given extension project.

It is assumed that most developers are mostly sane, and can follow basic rules to be established here.

If you are a plugin developer and like this idea, you can self-register now.

Please post your reaction with only ( :+1: or :-1: ) right here to express your vote for the proposal.

Also feel free to elaborate your ideas below.

[qu1ck]

To explain my downvote: KiCad repository is not shared. It has well defined ownership and only vetted devs and librarians get write access and only to relevant repos. Both those groups have agreed on rules and practices and have means of enforcement of those. Maybe by "shared project ownership" you don't mean anyone can freely join in and commit. In that case I suggest you write up guidelines and approval process.

[Andrei-Pozolotin]

Maybe by "shared project ownership" you don't mean

Yes, I do mean "anyone can freely join in and commit", at least technically. Again, the assumption is most people are sane, know how to behave, and will follow the rules. And those who misbehave can be banned based on their actions. Nonetheless, given some "emergency", anyone can commit.

The intent is NOT to have effectively abandoned projects, when authors do not respond for a long time.

[bobc]

I'm not against the idea, I just don't think it will work. It would be nice to have plugins available in one place, and perhaps reduce the dilution effect of a lot of forks, but if developers have abandoned projects, it doesn't solve that problem. They will just become abandoned projects here.

Anyway, it seems you have done all the required actions. If there are Open Source plugins you would like to adopt, you can just fork them into kicad-extras.

Are there any particular plugins you think have been abandoned and need adopting?

[Andrei-Pozolotin]

They will just become abandoned projects here.

maybe, but chances are there will be new life in the project: based on personal experience:

• if I see org/project abandoned based on activity, I will not bother even to fork
• if see org activity and people whom I can ask, I will fork and ask

[bobc]

if I see org/project abandoned based on activity, I will not bother even to fork

if see org activity and people whom I can ask, I will fork and ask

That's weird, that is the opposite of what I would do. If you are assuming that everyone thinks like you, you might be disappointed.

However, in all the proposals I have seen, the ones that start "let's get some developers together and do something!" are the ones that get abandoned. On the other hand, the ones that just get on and do stuff might attract support later.

Right now there are just empty repos here and I can't even think why I would "join". OTOH, if you had some projects that I might use I might contribute to them. I have several plugins/scripts I don't have time to maintain, it would be nice if they were put here so they could be maintained.

As a general rule though, you get 99 people raising issues and 1 person contributing patches.

[Andrei-Pozolotin]

Are there any particular plugins you think have been abandoned and need adopting?

yes, my own plugin will need adoption pretty soon :-) https://github.com/random-builder/kicad_freerouting-plugin

[marekr]

Honestly, all this does is kill developer's individual "github" resumes by not not being directly under their own namespaces. And this is a big deal these days ;)

The intent is NOT to have effectively abandoned projects, when authors do not respond for a long time.

So? Who takes over these abandoned projects? Just because they are in a org does not mean the org will somehow magically maintain it. It's no different than forking an abandoned project. Someone has to do it. People make plugins on their free time based on their own needs or desire. Being a member of an org doesn't mean they now are going to maintain other plugins like a job.

If you are a plugin developer and like this idea, you can self-register now.

Bad idea to even allow self registration. If ever you want this promoted by upstream with the "face of authority" you are trying to put on for plugins, users must be vetted/have earned a degree of trust. Not to mention the org should 2FA turned on as mandatory for security. It doesn't take any effort for a plugin to contain very malicious and dangerous code as the python scripting system is extremely insecure due to its design (in fact python assumes all code is trusted).

[MitjaNemec]

KiCad plugin repo kicad-extra issue #1

First of all I have to state that I have zero experience regarding deployment and the only experience on the KiCad side I have is with Action plugins (but here I can say that I have some experience). I have no insight in BOM and footprint plugins whatsoever.

I kinda agree with marekr regarding resumes and namespaces, but that is not really my main concern.

If the intent is to make things easier for users then I think that just collecting the plugins under one umbrella is just not enough. And it might even cause discontent.

Right now users with a bit more experience (and thicker skin) tend to try out the plugins, and when they do, they might stumble upon some of the warts that are currently there. If they hit on one of the issues, they are less likely to be straightforwardly disappointed as they are more aware of the state of the ecosystem.

As the bar for getting the plugins will get lower the plugin user-base will get wider. And I would expect that there would be more disappointment regarding the plugins.

First issue that would have to be approached is to find some way to figure out if a given plugin can work on MacOS/Windows/plethora of different GNU/Linux distributions. From my experience I think that if the plugin works on Windows it is highly likely that it will work on MacOS and most GNU/Linux distributions. If it is also Python3 compatible then it will work on almost all Linux distributions and on those without wxpython support (due to GTK2/GTK3 issue) it can fail gracefully using tkinter and point the user in the right direction. But if the plugin works on one GNU/Linux distribution it might not work elsewhere. Especially if it requires additional python packages. Or it is only Python3 compatible. And then we come to requirements management and plugin installation becomes more than just saving the plugin file to the required folder. Furthermore on some systems (I am looking at Windows) not all packages can be installed (numpy for example).

So the common user should either be aware of this (but I think that this is too much to ask) or the plugin repository should have the option to lead the user to the proper plugin or explain why some plugins are not available for him.

For start it would be nice if there would be info available to plugin writers regarding the python used on each OS.

For windows (7, 8.0, 8.1, 10) I know that KiCad uses python that is packaged with KiCad and is currently on 2.7. For ubuntu 18.04 I know that the KiCad uses system install python which can be either 2.7 or 3.5. For everything else I'm in the dark.

Then it be nice to have the option for plugins to test the KiCad installation if they can even run the plugin (see https://bugs.launchpad.net/kicad/+bug/1815349)

In the long run it would be phenomenal if the developers manage to switch to wxwidgets4, as then even on windows we should get Python3 compatibility and if the official KiCad installation switches to MSVC build (which I believe is experimental at this point) we should be even able to install all the packages.

[paulvdhoeven]

I give the initative a thumbs up, even though I do not know if it will work in this form.

I also do not know if it is a good idea to put all the "extra's" together, or just a list of which extra's there are, with a short description of their intention and use.

It seems that if there is documentation on plugins it is a detailed technical descripton with details, while when searching for a plugin, you want a short description of the intended use of such plugins.

[Andrei-Pozolotin]

@marekr Marek:

So? Who takes over these abandoned projects? Just because they are in a org does not mean the org will somehow magically maintain it.

From own experience: @qu1ck was kind enough to review my work; now if am asked to return the favor on some other repo, I will gladly do that. So if the community has 10 or 20 people, perhaps it might start to work - when I am asked by an org member, since we implicitly agreed for cross-support.

... bad idea to even allow self registration ... python scripting system is extremely insecure ...

Well, "trusting people" and "trusting code" are separate concerns. Approach proposed here is: lets try to start trusting people, for a change. And regarding the code: all code should really be untrusted, with practical solutions via vm isolation, such as linux firejail, windows sandbox, etc

[Andrei-Pozolotin]

FYI: asking to vote present github developers

[kuro68k]

When you say "tools, scripts, plugins", I'm the author of a C# app that converts the XML BOM output to various pretty formats. I don't have a huge amount of spare time but it does get updated when I find issues or need new features. I'm not really interested in providing support for it.

So how would this affect me, if at all?

[Andrei-Pozolotin]

@kuro68k:

So how would this affect me, if at all?

Apart from project visibility, I think if your interests keep staying around kicad, over time there can grow a critical mass of people here who can help with your project and vise versa.

[kuro68k]

@Andrei-Pozolotin In that case there may be better ways for people like me to get visibility and exposure I think. Shouldn't repos and GitHub projects be more about the process of development?

[DKrepsky]

Hello guys.

First of all, congratulations for the initiative @Andrei-Pozolotin, it is really important that we have people to start such projects.

As others pointed out, there are several problems regarding the way this project is elaborated and to be honest I still don't know what is being proposed exactly. If the goal is to have all plugins and etc into one place and allow developers to publish new plugins (like the "anyone commits" as you said) I think that github search and google already do an amazing job in gathering all the individual repos out there into a single page.

On the other hand, if you wish to put together some developers to create and maintain useful plugins that are well written and documented, well, I can see the value in that and would enjoy helping out. But that requires some organization and management, specially because people tend to feel uncomfortable in too loose projects.

Another way I can see this is something like NPM, put together some guys to create a tool that handles plugin installation and management and use the repo to allow developers to publish their work. As someone else said, handling the deployment of plugins, tools and etc on multiple platforms is really tricky and there will be value in a tool like this.

Another thing, please don't use the kicad brand like this, my first thought was that this was related with the original maintainers of kicad, which it is not. This can cause confusion and generate some discomfort with the guys maintaining the software.

My final thought is that there is some healthy critics in this thread and you should really consider the problems pointed out. I'll give a thumbs up for now and keep an eye on this.

Regards.

[bobc]

Approach proposed here is: lets try to start trusting people, for a change. And regarding the code: all code should really be untrusted, with practical solutions via vm isolation

That approach is naive and irresponsible. I've been on the internet before it was called the internet, and we tried trusting people. Collective experience over several decades shows that trust WILL be abused. Any vector to run code on users PCs will be exploited by spammers and hackers.

A developer knowingly providing an open attack vector is downright irresponsible. I've come to the conclusion that your proposal is not just unworkable but harmless, but your approach is stupid and dangerous.

If you were suggesting a repo where contributions are vetted and signed, that would at least be a good idea. But I shall be recommending users NOT to download any untrusted code from this repo.

[Lavikjo]

I agree with @DKrepsky with creating a tool for plugin installation and management which could utilize plugins verified and bundled in this repo.

[autoiue]

Hi, I'm just pasting here what I answered to the issue you opened in my repo :

I'm willing to register and/or use plugins from a global repository (à la https://packagecontrol.io/ like for Sublime text), but I don't see a need for a global Development repo. If I do not maintain the work I choose to publish on GitHub, people are free to fork the repo and add their own modifications.

Regards, Antoine

[stambaughw]

I thought I should weigh in on this topic. While understand and sympathize with the issues that are trying to be resolved, from a project management standpoint, I really don't think it's a good idea. Only code officially supported by the KiCad project belongs in the official KiCad repositories. All third party scripts should reside in their own repos. We already get far too many bug reports for scripts that are not installed with KiCad. Something like this will only make that problem much worse because it will give the appearance that they are endorsed and maintained by the project.

[paulvdhoeven]

Parallel to this there is: https://forum.kicad.info/t/a-plugin-category-similar-to-the-way-the-faq-is-handled/16972

The idea is to make a sticky thread on the user forum with links to plugins and side projects. This keeps these plugins further away from the developers and "offical" part of KiCad, while (hopefully) still giving users an overview of available plugins and where to find them.