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.
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.