My goal was offering a low-barrier open for all way to connect with loved ones. During the peak of the Covid pandemic for many people it was easier to connect with colleagues than family members or friends. So I contacted a few sysadmins and public organizations of whom I knew were running Jitsi and asked if it could be shared via our public website. A few agreed and a few dropped by and wanted to help out. After a few days a commercial hosting company decided to sponsor us with one VPS as well.

Our idea was to connect the servers and use the API to select a server with the lowest load. In the meantime we used a randomizer...we've never used the API after all, the randomizer worked well enough ;)

People told us they've used our free service for yoga classes, library book reading clubs, hackerspaces & celebrating birthdays with grandma.

Overall I'm still very proud what we've achieved in a few days with some servers, opensource software and bit of work.

Many thanks to @saghul, 8x8 and all other people contributing to Jitsi. Thank you!

All of my WordPress plugins are free & Open Source. Most are tiny plugins using functionality (filters, actions) part of WordPress core. Unless WordPress becomes backwards-incompatible they will function perfectly fine for the foreseeable future. From my perspective these plugins are feature complete & unless there's a bug, don't need any attention from me. Sadly the WordPress repository expects me to update the version number or else the plugin will be become less visible in search results and a notice will be placed above the plugin's title stating: "This plugin hasn’t been tested with the latest 3 major releases of WordPress. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress."

So for some of my plugins I occasionally 'bump' the version number to make sure people can still find it in the search & for some plugins I just leave it be because I have better things to do. However it didn't feel quite right to keep people using my work in the dark, so I've added a text to communicate this to them. This is the text from my 'Redirect To Homepage' plugin:

"Is this plugin actively being developed? Yes and no. Let me explain: I consider this plugin to be feature complete and unless bugs are found there will be no development on this plugin. In other words this plugin is in maintenance mode and will be maintained for the foreseeable future. Due to other obligations I’m not always able to keep up with WordPress version’s and updating this readme’s ‘Tested up to’ version number. However, unless WordPress significantly changes the way the login_redirect filter works it should work perfectly fine even though the ‘Tested up to’ might be of a lower version number. As always, when in doubt, test it (and when it does give you issues, feel free to leave a comment)."

I think this balances both interests, those of people using (perhaps depending on) my work as well as my own. A similar approach could be used by commercial app stores to restore autonomy & balance interests.

To give an example of my process thus far:

Someone in my team wants to see if we can use plugin X. I’m downloading the plugin to have a look at the code. Luckily this plugin has included a non-minified version of the js file. I can derive the use of npm packages from this file. Using Snyk I have a look at the first package mentioned. It’s axios. The included version is vulnerable (high & medium severity) and has been for almost a year (Note: the last version of the plugin is 3 months old and does not exclude this vulnerable version in it’s package.json which I found in a Github repo later on).

Since I have no package.json nor package-lock.json (all I have is the distributed build) I can’t easily update the npm package. I have no clue as to how this package relates to the other packages and how their version might depend on each other. Even if I would update the package, all other users of this plugin are still vulnerable. I contacted the plugin author. He tells me he will update the plugin as soon as possible. The plugin is (as of today) still not updated & has not released a new version. In the meantime there have been two new versions of the axios package released.

Every user of plugin X is still vulnerable to the issues mentioned on Snyk, but is this a real problem in this specific WordPress plugin context? I’m not sure how to interpret the high & medium severity in the context of this plugin. How exploitable are these issues & what is the impact of the exploits in the context of this plugin? Do I need to be a logged in user? Is this something which can be triggered by any visitor? What am I able to do when I can exploit these vulnerabilities? I can only try to find answers to these questions if I’m willing to invest a lot more time into this, which more or less beats the purpose of using a ‘ready-made’ WordPress plugin. And this is just one package of multiple npm packages used in this plugin. Packages which also have their own dependencies as well….

At this moment I’m wondering if any WordPress plugin using npm packages can be trusted at all.

ps: The way the npm ecosystem is structured is, in my view at least, problematic. Often packages are not like libraries as I’d expect, but look more like a function call or method call. I’d prefer to write these short pieces of code myself instead of depending on external code which also includes extra risks. The very rapid release schedules makes it even harder to trust external software (like a WordPress plugin) using npm packages as it seems they cannot keep up with it.

I’m sorry if this seems like a npm rant, but I’m seriously looking for methods on how to deal with these issues so we can use external software (like WordPress plugins) built with npm packages.