As I pondered a solution, I had some initial thoughts that others would find such a tool useful. The ability to disable plugin and theme updates would be an awesome tool in a developer's arsenal.
I began coding the plugin and released the code to GitHub. I was proud of the result.
The next step was releasing the plugin on .org. I figured others would find the plugin useful. Then I did my due diligence before releasing the plugin: I searched for similar plugins.
There was a plugin I found called Disable Updates Manager by Matthew Sparrow. It was very close to my plugin, but it did not work in multisite.
I made a crucial decision at this point. The plugin already had ten thousand installs and an established user base. The owner was also very active in support, so I figured I would contact Matthew and see if I can help make it multisite compatible.
Matthew released Stops Core Theme and Plugin Updates when he was 13. He was brand new to coding and originally released the plugin to stop plugin and theme updates.
In the summer months of 2014, Matthew added the settings page for the plugin.
In the fall of 2014, Matthew put the plugin on GitHub to get some help from the open source community. He remembers getting help.
In February of 2015, Matthew and I crossed paths.
It was around February of 2015 when I emailed Matthew through a contact form on his site.
I saw your plugin on .org and was very impressed. I was looking for a good GUI for disabling individual plugin/theme updates.
The main issue I ran into was lack of multisite support, so I decided to use some of your code in a custom plugin I wrote last night.
Instead of releasing my version on .org as a competing plugin, I was wondering if there was a possibility of collaboration to bring multisite support in with your plugin.
If you feel multisite support is out-of-scope, perhaps we can agree on a plugin/theme header to support that we can read on activation and automatically mark a theme/plugin as not upgradable.
I'm on skype (ronalfy) if you'd like to chat. If you do add me, please include a note you're from mpswp so that I don't block you (I get a lot of spam contact requests).
From my perspective, Matthew was very willing to take on help. He saw my GitHub plugin, installed it, and saw the future of the plugin.
He gave me free reign to recode the plugin, and adding a plethora of features to make it the first of its class.
We decided based on the features to rename the plugin Easy Updates Manager, create a YouTube channel, create a wiki full of documentation, and continue with support.
The main thing I was concerned with, multisite support, was highly emphasized in the plugin architecture.
Matthew describes the current success of Easy Updates Manager, which currently has over 300,000 downloads and 80,000 installs.
[The history of Easy Updates Manager is] how it went from a fun summer project to an epic WordPress plugin.
Easy Updates Manager is a success story on how two developers collaborated to turn a dying plugin into a successful one.
I asked Matthew what kept him from putting Easy Updates Manager up for adoption or just flat out abandoning the plugin.
I made about 10 other plugins that all failed and that I put up for adoption. No one adopted them so I got them deleted off of the WordPress Directory. So since Easy Updates Manager was the best plugin out of them all, I sort of wanted to hold on to it. I also wanted to learn more coding so that I could hopefully come back to the plugin and continue development.
Before you came though, abandoning the plugin was an option that I was seriously considering.
If you have a good plugin idea, code it how you like it. You'll learn development that way. Then when you are ready to release, find out if there are similar plugins. If there is something similar, see if you can contribute to the plugin. I would argue most successful development relationships start with a pull request.
First of all, never give up on your plugin. I sort of wish that I didn't get rid of all those other plugins. You don't just create a plugin and it magically gets thousands of downloads. Just like how you don't create a website and expect to get thousands of views on the first day. It takes work to get downloads. It may also take a few plugins before you finally get one that hits off.
Also, make sure that you are able to continue to support the plugin. If you just create the plugin and then don't answer any support questions and don't update it every once in a while, then the plugin will go next to nowhere.
For people contributing to an existing plugin… look for a GitHub page or something that the author is active on. If it is not a professional company who is making the plugin and trying to make money off of it, they will most likely be more then willing to add you as a contributor. If there is no GitHub page, don't post in the support forum [sic], instead, look on the authors profile page or website for contact information (like you did). Also if you are contributing, don't be pushy about getting your name put down as a contributor on your first pull request. Be patient and then they will add [sic] build up more trust and add you.
Do You Have Your Own Plugin Success Story?
Please leave a comment. I'd love to hear from you. Write your own plugin success story. I welcome links in the comments.
Thank you for your presentation and useful information on this plug-in you developed at our OKC WordPress Users Group.