Open Source Profit

When it comes to turning a profit on open-source software, I’d like to think that the majority of developers follow the same set of ethics. I’m my experience, it’s true – though, as with anything, there are outliers.

As I continue to work to introduce a premium level of support for my WordPress-related work, one of the things that I’ve found myself wrestling with is turning a profit on work to which others have contributed.

But are open source ethics that complicated?

A Quick Word About Licensing

This post is by no means meant to be a discussion about the GPL and its various interpretations.

When it comes to releasing my own work, I’m perfectly fine releasing all of the code and the various assets that go into the product under the GPL.

But enough about that.

The False Dilemma of Source Control

I’m a big fan of GitHub – in fact, I would store every single one of my projects on the site if I was willing to drop coin to afford such a high number of private repositories.

But this raises the question: In the case of GPL-based projects, why would I need private repositories?

GitHub To Subversion

So here’s where I find myself: WordPress.org offers free Subversion hosting. It’s relatively easy to get up and running with it, but I prefer the experience of git as well as GitHub’s issue tracking, tagging, and general user experience.

With tools like Evan Solomon’s Scatter, it’s trivial to deploy a git-based repository to a Subversion repository. This means that I can easily manage all of my plugins on GitHub and then deploy them to WordPress.org’s repository.

Awesome, right? I mean, it’s one less thing to manage by allowing me to keep everything in a single source control system. Simplification win.

GitHub vs. Subversion

But there is a dilemma in dealing with source control for WordPress projects (though I admit that this is predicated on the idea that most developers are becoming more and more comfortable with git and GitHub):

  • GitHub makes it easier for others to contribute to the plugin, so it makes it easier for a product to grow under the commits of a larger set of developers.
  • Subversion makes it a bit more difficult for others to contribute to the plugin so it makes it easier for the lead developer to control what gets pulled into the plugin.

But I see this as a false dilemma:

  • Subversion may make it more difficult for others to contribute to the plugin, but the lead developer can simply reject pull requests on GitHub.
  • Making it difficult for others to contribute to open source projects is against the very nature of open source.

So with that said, I don’t think it’s a problem of source control. Compensation, on the other hand, is a whole other issue.

A Question Of Compensation

Here are the points to which it boils down:

  1. Customers are paying for support. I am supporting the plugin. I should receive compensation for providing the support.
  2. Developers are spending their time contributing code. Developers should get paid for their time. I should pay the developers.
  3. Developers volunteer their time to contribute code. Volunteering is predicated on a non-compensation basis. I should not pay the developers.

The first case is generally the most popular policy that I see used. Personally, I favor this approach, too.

The second case is a purely personal opinion. I like rewarding people for their good work, but the truth is that there’s no reasonable expectation that this should happen in the open source ecosystem (is there?).

The third case seems to be the most logical as it aligns both with volunteering time both online and offline, so I’m apt to adopt this as my stance should I move all of my plugins to GitHub.

Ultimately, I find myself arriving at the conclusion that because customers are paying for support, compensation should be paid to those who help provide support – not those who write code for the plugin.

Level-Setting Expectations

But does this align with the expectation of other developers? For example, I’ve contributed code (and thus, time) to open-source projects, but I’ve never expected to be compensated for it.

That said, I’m using my own use case is a hasty generalization for the rest of the community. That’s no good.

So for those of you who have experimented with this model, follow this model, or simply have an opinion on it, where do you fall?

Category:
Articles
Tags:

Join the conversation! 3 Comments

  1. Those providing the support get compensated. That makes the most sense to me.

    The one exception I’d make to that is if you allow users to donate to the project, then perhaps split it among contributors.

  2. Completely agree with your conclusions.

    On another note, consider BitBucket; they allow unlimited private repos but instead have a user limit. And you can create either Git or Mercurial repos, and I greatly prefer the latter when I’m not using the repo for social reasons where GitHub is king.

  3. Starting from the point that you (any WP developer) get a huge and perfect base as WordPress for creating your work, I always think: “Hey, I get this beautiful starting point for free, I must give some love back !”.

    So contributing to other plugins when I have time/need to fix or improve something, and see my contribution merged to the source, it’s for me enough compensation.

    I think that is the spirit of GPL. I you benefit from it, you must contribute for the benefit of others too.

Leave a Reply

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