By their nature, WordPress themes are open source. Whether or not you want to be is kind of a moot point because anything work that is a derivative of a GPL-based work must be licensed as GPL, as well.

WordPress is GPL, thus plugins, themes, and any other work that’s built on top of it should be GPL’d, as well.

When you’re working on a plugin or a theme or any other project, this doesn’t mean that you have to have the repository open. By that, I mean you can work on the code in a private repository on GitHub and, when the product is ready, have it released as GPL and then share it with users, customers, and so on.

Such a great open source contributor.

Such a great open source contributor.

Honestly, though, unless you’re running some type of hosting platform where people sign up for the service and install themes (think WordPress.com or Evermore), then they have to get the source code anyway in order to install the theme on their server.

Nonetheless, I still feel like there’s a little resistance when it comes to working on a theme (or a plugin, even) in a public repository where anyone and everyone has the ability to fork it, open issues, offer suggestions, issue pull requests, and so on.

The Challenge of Open Source Development

When it comes to talking about this resistance of working out of a public repository, I’m talking about this more from having an internal level of resistance (versus having resistance from some other third-party source).

It normally goes something like this:

Sure, I’m fine working on my theme in a public repository. It’s open source after all.

On the other hand, I have a verify specific vision that I’m trying to work on with this theme and I don’t want to have to deal with the pull requests, raised issues, and other questions that come with having to work on a theme.

And yes, some of the pull requests and issues will be something that’s valuable if they are related to a bug or something that doesn’t follow a best practice, but it also means that I’ve got to field input from other people who are using their knowledge to influence the theme without actually knowing what the purpose of the theme is.

So I can benefit from having others issues some fixes, but I’ve also got to manage the rest of the input and the rest of the feedback that comes in a portion of which may not have anything to do with what I’m trying to accomplish with a theme.

So that’s a lengthly internal monologue, isn’t it? Maybe I’m the only one that has it. Then again, knowing other programmers, I seriously doubt it. At least I hope :).

On a more serious note, this is something that shouldn’t be dismissed lightly: Having other people peer review your code, issue pull requests, and raise issues that you may not have thought of can all go into making a more resilient product.

On the flip side, having to field all of this input from other people – especially that which isn’t relevant to the project itself – can be a time suck that ends up being more distracting from development than anything else. And that’s lost time.

Ultimately, this all boils down to the question of: When is it a good idea to do open source theme development?

  • Is it always? That is, from day one, should we begin working on themes in public repositories and just let others open their issues and pull requests as they want and simply field them based on if they contribute or not?
  • Is it never? Since others aren’t familiar with the goal that we’re trying to achieve with the theme, does it make sense to allow others to peek at the theme while we’re working on it?
  • Is it sometimes? And if that’s the case, when does it make sense and when does it not?

Honestly, I’m not a fan of absolutes so I think there are times where it makes sense and times when it doesn’t, but even then I’m not sure of when the open source development should actually happen. From the beginning? After the first stable release? Or when else?

So that’s my question: For those of you who have done open source WordPress theme development, when you find it best to work on your in a public setting?

Legitimately curious to know your thoughts, so share ’em if you’ve got ’em.

Category:
Articles
Tags:

Join the conversation! 2 Comments

  1. I’ve put together a few themes and pretty much every one of them is on GitHub. I used to make this decision in pretty simple absolutes – free themes are in public repos and paid themes are in private repos. I’ve grown, though.

    What I’ve found, and you’ve pointed out, is that the themes are open source anyway. Once they’re out in the wild, people can do whatever they want with them being GPL. What I do now is [still keep my free themes in public repos and] constantly ask the community (Twitter, Google+, email, etc.) who wants to give their two cents as I develop my new premium theme. Anyone who wants to be helpful gets access to my private repo, just like that.

    As of now, I haven’t had any negative experiences with that approach. People help because they want to. Here’s a screenshot of my last premium theme’s closed issues on GitHub: http://glui.me/?i=92vuktw58edqymy/2014-11-04_at_11.42_AM.png/ I learned some pretty awesome stuff from a few guys that I’ve even gone back and implemented in my old themes.

    While I think keeping everything public is still a solid choice, you don’t have to be closed off from the world if you have reason to make it private. Just keep the door cracked. Those who want in will come in. Those who don’t won’t even notice. Too easy.

    • I’ve put together a few themes and pretty much every one of them is on GitHub. I used to make this decision in pretty simple absolutes – free themes are in public repos and paid themes are in private repos. I’ve grown, though.

      I think that this is a relatively common mindset (you mention as being “grown up” and I think that some people do change their mind based on their experience – either way, all is fine).

      Anyone who wants to be helpful gets access to my private repo, just like that.

      I think that’s a really good idea – haven’t actually bothered trying to do something like that.

      Another thing that I also have to juggle – but this is really more of a topic for another blog post – is dealing for a .com version of a theme and a .org version of a theme. No, there aren’t massive differences, but there are enough to where I think having separate repositories and, thus, ticketing systems matter.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.