
Letting things go - twampss
http://www.37signals.com/svn/posts/1611-letting-things-go
======
aaronblohowiak
Maybe the scope was too vague or the goal was too monolithic if he was
implementing patches he didn't need. It is easier to declare tight little
tools as "done." Plugability/modularity helps this as well, because it lets
those things that need to vary and evolve over time do so without threatening
the health of the core.

~~~
jamis
There was definitely an element of that, too. Most of the patches were
reasonable changes: bug fixes, or minor feature additions that improved the
usability for some large segment of the user base. There were a few that snuck
in that I later regretted, but I got better at saying "no" as time went on.

However, ultimately, if every project said "no" to every feature the developer
did not personally need, there really wouldn't be very many widely-adopted
projects. They key is balancing patches that you don't personally need against
your vision for the product: and I _did_ have a vision for Capistrano. It just
wasn't really clearly defined, especially early on, which is why I regret some
of those patches.

It was definitely a learning experience all around.

~~~
aaronblohowiak
Thanks for the reply. I can see how the definition would increase in clarity
it grows and you eat the dog-food. I'd also like to thank you for being frank
with your decision to step aside as the maintainer -- far too many projects
languish as the developer doesn't make a public declaration like you did.

------
sho
I'm surprised Buck held out so long. I don't know if many people looked at the
Capistrano ML, but it was just this giant hellish suckhole of entitled Windows
users angrily demanding someone help them with their homework. Buck doesn't
spell it out, and probably wouldn't even admit it, but I got the pretty strong
idea having to support windows was the main cause of misery.

However, I have some criticism over the way it's been handled, and I'd like to
point out before saying it that it's not a personal attack, just some
observations. I don't use Cap but I do use net/ssh and I'm very grateful for
Buck's contributions. However ...

It's his right to walk away, and as he points out, he owes the community
nothing. But it's still a bit weird and passive-aggresive, the way he's done
it. Healthy human interaction in a situation like this would be polite but
insistent assertiveness; defining your limits and consistently sticking to
them, not holding it in, getting silently angrier and more pissed off, then
quitting in a blaze of defensiveness.

There are techniques for dealing with users/contributors, distributing the
load so no one person is overwhelmed. Capistrano's documentation, for example,
was/is awful. The website has almost nothing useful. The way to learn how to
use it is to perform any number of searches for people talking about how they
did it on their blogs, and then doing it yourself by trial and error. Or the
entitled newbie way, which is to pile on the mailing list, where their
questions were foolishly answered, attracting ever more entitled newbies
looking to have their problems solved for them, causing stress. Decent
documentation would have solved a lot of that.

And overloaded with feature requests/patches? There are websites for handling
feature requests, and the developer should have insisted on nothing but
properly tested patches fixing a known bug. Wouldn't that have gotten the
situation more under control? Or hell, why not roll cap into Rails proper and
spread the load that way?

It's all just a bit suboptimal, is all. Oh well. Good luck to the dev.
Hopefully other projects can also learn from the experience.

~~~
jamis
You're right, of course, about the documentation being awful. I was actually
working on fixing that at the end, but every time I'd spend a few evenings
writing docs (which was a few more evenings where I didn't get to do what I
wanted to do), people would ask questions on the list not covered by what I'd
just documented...and I'd get discouraged all over again. Docs help, for sure,
and I painted myself into a corner where there was too much to document in the
amount of time I could afford to spend on it. My fault.

I actually used a website for handling feature requests and patches
(lighthouseapp.com), and it worked great. But even the best tested patch for a
known bug still needs review. It needs to be applied and tested locally. It
needs an update to the ChangeLog. And eventually it needs to be bundled and
released, each new release requiring (at minimum) some release notes and a
blog post announcing it.

It was a bunch of little things that got more and more annoying. I would have
loved to distribute the load across more devs, but aside from a few who would
review patches on specific topics (Scott Chacon, for instance, helped with git
issues), it was all me, all the time.

~~~
sho
_"It was a bunch of little things that got more and more annoying."_

What you need to do is write a script to automate those small but repetitive
tasks! I heard about this great bit of software to do that for you called
Capi.. oh.

I was going to add, I think a factor contributing to the lack of ongoing
support you received is simply capistrano's place in the stack. Unlike Rails
or other libraries, it very much has a "deal with it once then forget about
it" usage pattern, which would seem to discourage ongoing participation. Or if
there was some kind of missing feature "blocking" the envisaged deploy
scenario, that would create a pressing need to "get this in NOW!" - and then
forget about it.

The simple position of Capistrano as the deploy mechanism - a critical
"bottleneck" through which one must pass but then safely forgotten - could be
the reason for the "all me, all the time" dynamic.

Anyway, glad to see you don't seem bitter. Good luck and looking forward to
future projects.

