As some of you may know, I adopted a WordPress plugin called WP Plugin Info Card by Brice CAPOBIANCO a few months ago. I’ll go over the initial contact, the plugin adoption process, and the mistakes I made.
The Adoption Process
It started with a simple e-mail. I contacted Brice via email.
Hi. I’ve seen that your plugin hasn’t been updated in a few years.
I’m interested in contributing to the plugin to make sure it’s up to date and maybe add a Gutenberg block to it so it doesn’t have to use a shortcode.
Please let me know if you’re interested.
Ronald
Brice responded saying he’s never put a plugin up for adoption and wanted to know what the process was. I showed him my video on WordPress.tv on how to take over a plugin.
He gratefully gave me access to his BitBucket repo and I moved it over to GitHub.
New Features
I added two Gutenberg blocks that limited the need for the shortcodes used in the plugin. The plugin was sitting at 300+ installs, so it was a small plugin user base, but I figured Gutenberg might increase adoption and make it easier for the audience to add the cards to their website.
Mistake 1 – Assuming the Original Plugin Author Wasn’t Interested in the Future of the Plugin
I changed the plugin name and author, moved the documentation to my own website, and basically erased all existence of the original author. This was a huge mistake. The original author still wanted credit, which he communicated in a later email. He found my changes unethical and was appalled that I moved the documentation and changed the plugin name without his permission.
This was totally my fault. I should have asked permission to make these changes. I wrongly assumed that since I was now the owner of the plugin, I could do what I wanted with it. I still used the author’s branding and existing user base as pawns so-to-speak. The original author felt I stole his work.
This was corrected after numerous emails and a new agreement that we would effectively both be co-owners of the plugin, even though the author had limited time to contribute to the plugin.
Mistake 2: Breaking Existing Functionality
In some features I added, I broke some core functionality of the plugin mostly because I wasn’t familiar with the complexities and intricacies of the original plugin. I broke the card layout of the plugin when I introduced a new layout option. Some of the CSS was broken. Some was because I had WP_DEBUG on and wasn’t using the minified CSS and I forgot to minify the CSS again when I deployed an update to the plugin.
Lesson learned: test the freakin’ bastard with and without WP_DEBUG on and test all layouts before committing the code.
Mistake 3: Communication
I should have communicated with the original author my intentions of the plugin and its growth and what I planned for it. Brice was surprised by some of my changes. As a result. I added him to my GitHub as a collaborator and will run any changes by him as appropriate.
We agreed that the documentation could point to my site as long as I linked to the French version on his site. I also updated the readme to give him accurate credit for the plugin.
I removed the donation links that pointed to my site to being non-existent, as we both agreed that we don’t want donations for the plugin.
I also updated the documentation inside the plugin to point to both our sites.
Summary
When adopting a plugin, be sure there are open lines of communication between both you and the original plugin author. Come up with an agreement about the future of the plugin, what you plan to do with it, and where credit should be shared.
Don’t get that nasty email that you effectively stole the plugin author’s work. That wasn’t a good email and it was an awakening experience.
Test the new plugin so it doesn’t break existing functionality for its users. And keep it up to date.
Thanks for reading.
