WordPress.org vs. GitHub For Hosting WordPress Plugins and Themes

There are many factors that come into play when deciding where to host your open source WordPress plugin or theme. Who is your target audience? How much support do you want to offer? Is the project open for collaboration? For many developers this choice often comes down to WordPress.org vs. GitHub.

In the past, hosting with WordPress.org was the only option that would allow developers to push out updates to their plugin or theme via the WordPress admin. The GitHub Updater plugin, created by Andy Fragen and added to GitHub in July of 2013, makes it possible to ship updates to Github-hosted plugins and themes. This makes it convenient for developers who prefer GitHub to stay within their preferred workflow while continuing to provide updates. Incidentally, this plugin is banned from the WordPress.org repository.

updater

Of course there are a number of other places that you can host your project, i.e. your own website or another code sharing site. We’re looking at GitHub vs. WordPress.org for the purposes of this comparison, since the two are among the most popular.

Advantages of Hosting Your Project on WordPress.org

By far, one of the best reasons to host a plugin or theme on WordPress.org is the increased exposure that it will offer for your work. Your extension is just a couple clicks away when a user performs a search within the WordPress admin, giving you an audience of millions of potential users.

wporg

A summary of the advantages includes:

  • Maximum exposure: Your extension can be searched for within the WP admin
  • Built-in trac and support forums
  • Easily push out updates to users
  • Ratings, reviews and download stats
  • Extensions are more trusted due to the WordPress.org review process and guidelines

Of course, some of these same “advantages” could also be considered disadvantages. For example, if you’re not willing to offer free support, having your plugin or theme on WordPress.org with such a wide audience may send you a flood of support requests. If you don’t have the time to provide updates or support, the resulting star ratings and reviews may hurt your extension’s reputation.

Disadvantages:

One of the primary disadvantages of hosting a project on WordPress.org alone is that it can severely limit collaboration. Themes and plugins on WordPress.org are simply not geared for collaborative development. Most developers find it easier to collaborate via Git. Hosting on WordPress.org also requires a basic knowledge of SVN, which is not very popular these days. In summary, the disadvantages include:

  • SVN
  • Does not encourage collaboration
  • Possible massive influx of support requests

Advantages of Hosting Your Project on GitHub

Where a lack of collaboration is probably the strongest disadvantage of hosting on WordPress.org, it’s also the biggest advantage to hosting your extension on GitHub. The barrier of entry for participation on GitHub is much higher, which significantly lessens the likelihood of you becoming inundated with support requests.

github-social-coding

Other advantages include:

  • Easy for others to contribute to your project
  • Built-in wiki and issues queue available
  • Fewer support requests
  • Can easily push out updates w/ use of GitHub Updater
  • Fewer restrictions – No code review process or extra guidelines for compliance
  • Traffic analytics – GitHub recently introduced analytics data for repositories

Disadvantages:

  • Likely a smaller audience
  • Will need to bundle the Git Updater with your extension or ask users to install it in order to ship updates
  • Does not include the same level of user trust as projects hosed on WordPress.org

If you don’t want to have to mess with SVN and don’t mind losing out on the audience you get hosting on WordPress.org, then hosting your project on GitHub might be a strong option for you.

The Best of Both Worlds

wpvsgithub
There’s no clear winner in the comparison between hosting on WordPress.org vs. Github. It depends entirely on your workflow and your goals for the extension. Of course, many projects do a mixture of both, either through maintaining git mirrors or synchronizing via a script. Since every GitHub repository is also a Subversion repository, you can use SVN tools to checkout, branch, and commit to GitHub repositories if you are so inclined.

Brent Shepherd has a script that will deploy a WordPress plugin from within Git to WordPress.org’s SVN repository. “Since running the script for my plugins, I’ve not suffered the frustrations of minor errors – like having version numbers in the readme.txt & plugin file differ,” Shepherd said. “I’ve lost less time deploying, so I’ve released more frequently, which means fewer bugs in the wild.”

Here are some other resources you might want to check out for learning more about working between Git and SVN for WordPress extensions.

Every developer has a different workflow, but there’s a good option for however you choose to develop and maintain your WordPress plugin or theme. After reviewing the advantages and disadvantages of each, which of these factors is the most important for you when making a decision about where to host an extension?

24 Comments


  1. I personally prefer using WordPress.org for anything public-facing due to the amount of exposure, as well as the simple search from within WordPress to install it. Github is the better option for something that isn’t quite polished though.

    Report


  2. Sarah, thanks so much for the shout out to GitHub Updater. I can honestly say that developing on GitHub has made me better and made eat his plugin better. I couldn’t have done it myself and I’ve had lots of help from the ubiquitous Gary Jones and Seth Carstens.

    There are reasons it wasn’t allowed in the WP repo and it mostly has to do with promoting an outside repository. As you pointed out, there is no code review or the ability to pull a plugin/theme out of the repo on GitHub. In the end I believe the WP repo maintainers were just looking for the safest experience for the majority of users.

    Thanks again for the shout out.

    Report


  3. Nice article Sarah, thanks. Another advantage of Github is that you can make branches.

    I host my plugins on both WordPress.org and Github and use the latter to develop the next versions on. In the WordPress Repo I also mention explicitly that I only offer support via Github, not on the forums there. Some people don’t like that (the comments I get is “yet another login”), but it just works much better for me.

    Although I am aware of their existence, I haven’t yet used any of the git to svn scripts you mentioned in the article. Must check them out again now.

    Report


      1. I guess that’s why there is a branches folder ;)
        Is it actually being used by many plugin developers?

        Report


      2. I’ve used it before. I mostly just upload zip files to my site though, since the people I want to access the branches are usually not developers and hence don’t know how to access the branch via SVN.

        Report


    1. I do the same, except I offer support via a forum hosted on my site. Support on Github is not a good idea, it’s mostly used for developers for submitting bugs/ideas. It’s hard to ask a question like “How to do this?”.

      Report


  4. It depends on the audience for the plugin. From a normal end user perspective WordPress.org is what is needed. Confidence in the code and ease of use of finding and installing etc. are key.

    GitHub is great for geeks designing for other geeks.

    Report


  5. There are so few collaborative projects, that I don’t see there being much use for Github in hosting WordPress plugins (obviously many people disagree with me on this). The only thing I use GIthub for, is hosting plugins before they’re ready to shunt onto WordPress.org.

    Report


  6. Sensible approach i see some developers are using is to keep beta version on GitHub so any power-user can take advantage of it, and additionally stable version (for anyone) in WordPress repository.

    Report


  7. I’m finally starting the process of moving my plugin code to GitHub. But, this is to foster collaboration, if anyone is interested.

    The end plan is to always upload the stable release version to WordPress.org.

    Report


  8. I use Patrick Rauland’s version of the deploy script: https://gist.github.com/3767319 otherwise I don’t think I’d have plugins in the repo… or wouldn’t update them. I can’t seem to get my head around SVN, but sort-of understand Git. I’ve been able to easily submit features or bugfixes to other github-hosted plugins and have had a few people do the same with mine; something I haven’t done with SVN. It is just a matter of personal preference.. and probably what you use first.

    If you want lots of people to find and use your plugin, then the repo is the place to be. Of course, that also means a ton more support issues will crop up.

    Report



  9. WP.org has some more disadvantages than listed here:
    1. If you are doing any promotion of your plugin, there is NO way of checking if it is working or how well. Number of downloads in the ‘stats’ section is a joke, not a metric.
    2. Doing support on WP.org is inconvenient to put it mildly. I just keep missing support requests because the only way I can be notified is through RSS, which I don’t use for anything else. There is no convenient way of marking progress on issues, etc.

    Report


    1. > the only way I can be notified is through RSS

      Or email. There are email subscriptions available for almost everywhere that there are those RSS feeds. Including the various plugin support forums.

      Report


  10. Incidentally, this plugin is banned from the WordPress.org repository.

    Why is that?
    Is there anything wrong with its code? ‘Cause I can’t find anything wrong with it…
    Is there a policy for plugins hosted on w.org that forbids what this plugin is doing?

    Report


      1. True, it is explicitly stated in the guidelines:

        Use of third-party systems is acceptable in a service-client type of model, but sending actual PHP or other executable code over the network is considered a security risk. Executing outside code like this is not allowed except for specific and very carefully considered cases

        I’m not saying the decision to ban this plugin was wrong, I’m simply trying to understand why, and to be honest I’m hoping that some day that ban will be lifted.

        There’s the letter of the guidelines and then there’s the spirit of them.
        Perhaps this should be one of those “specific and carefully considered cases”?

        Report


      2. And besides if I’m not mistaken the plugin itself doesn’t “download” anything.
        It simply connects to the github API and then hooks to the WordPress Core updater. :)

        Report


      3. We’re not going to allow plugins in the directory that install other plugins from outside of the directory. That is simply a method by which to try to bypass our rules and guidelines, and it is not going to be allowed.

        If you want your plugin in the directory, then simply fill out the form to add it there. We’ll review it and voila, you too can put a plugin in the directory. It’s not particularly complicated. Happens hundreds of times a week.

        Report

Comments are closed.