Burt Beckwith, one of the major contributors to the Groovy/Grails community, posted a rather serious critique to my Dear User of My Open Source Project post. It’s definitely worth a read. Although I didn’t see it (I haven’t read any RSS feeds since starting my next book), the post was good enough that the Grails podcast picked it up, and I found my way over to it through their show notes.
Since he’s apparently not even deigning to link to the post or call me out by name (maybe he’s trying to be nice, maybe he’s trying to keep the Google juice from flowing my direction, maybe he’s trying to be sneaky, whatever), I figured I would post a response here instead of there.
Burt—
I think you’re attacking a position I don’t actually hold: I’m not a monster. If my users want to give back, that’s great. If they don’t, then that’s fine. I don’t “demand” or “half-demand” anything, and I release my projects for the same reasons you do: I like it when people can skip ahead and be more productive because I’ve helped out.
My issue was with people who used my code and then expected me to be a de facto member of their team because they used it, and expected me to work quickly and for free on their project. How am I supposed to pay my bills if I spend all my time working for free? I tried that approach (right after the initial release of Autobase), and it doesn’t work for my finances. And it didn’t lead to jobs or any of the other vague promises of indirect funding that some open source enthusiasts put out there. You may have gotten benefits that “far outweighed the costs”, but my pocketbook hasn’t, and so I have to have a day job. After that day job is done, I can’t spend all my remaining time maintaining and building in the extensions to my open source projects that other people ask for. If I did (and I’ve tried), I’d burn out completely and simply stop releasing anything, and how is that good for the community?
I think our approaches are fundamentally different, and the key difference between us is shown in these quotes of yours:
Those included half-demanding that others fix his bugs for him or pay him to fix bugs in his software.
I’ve talked to other Grails users about writing and supporting Grails plugins and I half-jokingly caution them to not release them. It’s work. It’s a product.
When I release a Grails plugin, I’m releasing code. I’m releasing a jumpstart for you to build off of and things to learn from. I’m not releasing “a product”, I’m releasing a work-in-process that I’m welcoming the community’s engagement in. I don’t see code that I release as my software. It’s the community’s software: I’m releasing it not like Microsoft releases Windows, but like people release doves at weddings. It’s not a matter of “supporting it” vs. not. If something works well enough for me, then I’m happy with it, and I like to share it with the wider community. When I encounter something I’m not happy with it, I fix it (this is why I do so many Grails plugins). I expect other people to approach my projects with the same attitude, and a lot of people do, which is great.
The whole “free toilet” thing was satirical: an exaggeration of relationships to reveal a deeper truth in a humorous way. Taking it to mean that I’m hostile to any feedback or request for help from people who use code I’ve released is false to fact: I’ve got an established track record of engaging and working with the community, including adapting projects I’ve released, contributing to other projects, and helping people on the mailing list. One of the deeper truths I was trying to get at is that people who use an open source project are taking some ownership of it (akin to taking ownership of the free toilet): the underlying message was more that I expect people to be eager and willing to help themselves, even when using other open source projects. This is in line with how I see the basic Grails philosophy: that’s why it has such an extensible architecture, accessible source code, a dev mailing list, and an open JIRA.
BTW, which plugins/open source projects of mine don’t have licenses? I’ll fix that.
9 Comments
Robert,
Using the WTFPL might be working against you. It may make you appear more coarse than you want to be.
…except that I haven’t found another license that accurately communicates the level of freedom I want people to have with that code. A certain amount of shock is necessary, because people need to be jarred out of their comfy way of thinking: people are so trained to be consumers and have such a sense of entitlement that they need to get hit in the face with a charge to be DIY. And yes, that chafes and irritates people who view themselves as consuming a product. It’s supposed to.
If you’ve got another license that has the same effect without being as “coarse”, I’m open to switching to it.
Keep using the WTFPL; Real freedom for the the win.
I like the MIT license for simple stuff like this. It isn’t coarse, and is a bit longer, but effectively reads as a “do anything except claim you wrote it.” It also includes a disclaimer of warranty.
My problem with the MIT/X11 and BSD license (which both basically take the same tact) is that they require people to move their license around with the used code. This basically means that people can’t take just pieces of the code and use it wherever they’d like without some kind of funny finagling. Both those licenses imply a boundary that defines “the library”, which is a concept that I don’t much like.
If the WTFPL is “coarse”…you could have a WTHPPL = Do whatever the heck you want with it please. License text: see WTFPL.
Alicia, that is closer to what I meant; A not-as-offensive version. A re-branded version that has the same stipulations minus the F.
Is Creative Commons Zero close enough to what you want? I find the WTFPL license attractive myself, but CC0 might meet the not-as-offensive criterion.
CC0 is actually a winner.
3 Trackbacks
[...] 2 Here’s the original “Free Toilet” post, and my response to Burt’s post. [...]
[...] people know that I have contributed a lot of Grails plugin work, even if my take on contributing is somewhat controversial. Well, I’m continuing on with that approach of plugin contributions, but now for Gradle, the [...]
[...] on my frustration with the Grails plugin culturebecause of differing cultural assumptions about open source works, and based on my lack of [...]