Forking and re-releasing plugins

#1

So now what we need to do is set proper rules…
The ones about plugin adoptions are very good in my opinion. I think we need rules also for submission of new plugins.
Some questions:

  • are we allowing people to submit what I call rebranded clones (plugins that have a little difference from the original)? This in part is avoided limiting plugin abandon, no need to fork an old plugin and tweak it if the original can be adopted. Is it better to have a variety of options or should we have only one plugin doing something?
    Are we allowing devs to change business model? A free plugin can be transformed in a freemium or premium one?
    What about extensions and add-ons? Should we allow devs to serve them through their own servers?
    While I wait for your opinions I will study wp submission guidelines in depth…
Plugin Directory Rules
Limitation of Liability
#2

I don’t think it would be right to prevent developers from forking other plugins. However, we should add some restrictions for forked plugins. For example, forked plugins should either include new features and/or fix bugs in the original plugin. It can’t be simple clone of the original plugin.

#3

How would we enforce this?

#4

@ElisabettaCarrara I’ve created a new thread about forking plugins here, and I’ve copied these other two questions over to the main rules thread to try to keep each discussion on topic.

#5

Would the plugin directory even know it was a fork?

#6

No, and that’s part of the problem. The other part is that each forked plugin would need to be manually reviewed to determine whether it includes new features and/or fixes bugs in the original plugin.

#7

I think that allowing adoption and takeovers of old un-maintained plugins will reduce the forking which happens with WP plugins now.

Adoption/takeover needs to be more obvious to developers than it is on WordPress.

#8

It probably won’t be 100%, but we can do a few things to minimize unnecessary forks:

  • During submission of new plugin, ask them if it’s a fork of another plugin
  • If they forked GitHub repo, we’ll be able to see it on the GitHub page
  • If they say it’s a fork, we can remind them about abandoned plugin and plugin forking policies
  • We could ask them how different it is from the original plugin: Bug Fixes, New Features, Both
  • We could use a tool like codequiry.com to see if the code is available somewhere else

The goal is to minimize unnecessary forking with minimal effort on the CP’s part.