When to Fork and When to Spoon
smorrey at gmail.com
Tue Mar 7 07:55:48 MST 2006
So you mean to say you don't want to tell him to just "Fork off!" ;)
On 3/7/06, Hans Fugal <hans at fugal.net> wrote:
> Here's a philosophical question for you to chew on today.
> I need an OSC library for ruby. OSC is OpenSoundControl and it's
> basically a nifty little lightweight transport-independent protocol. The
> spec is also lightweight and a decent programmer could implement it
> in a few hours time. But laziness trumps even a few hours so I looked
> for an existing lib and found one.
> The existing lib is good. It has the basic functionality. But I had a
> different usage pattern in mind than what the author provides. To get
> it to behave the way I want it to, I would have to basically refactor
> much of the 375-line codebase.
> So here's the two-part dilemna. First, his design will be harder to
> wrangle for my needs than a fresh design would be. So I'm faced with the
> technical decision to rewrite and cannibalize, or refactor. Second, I'd
> like to not fork but let this be a natural evolution of the code, but
> how do you tactfully send a guy a total refactoring of his code?
> Especially when his English and my Japanese aren't so good. OTOH
> how do you tactfully fork?
> I look forward to hearing everyone's thoughts on this.
> 1. http://www.cnmat.berkeley.edu/OpenSoundControl/
> 2. http://www.cnmat.berkeley.edu/OpenSoundControl/OSC-spec.html
> 3. http://www.funaba.org/en/ruby.html#osc
> Hans Fugal ; http://hans.fugal.net
> There's nothing remarkable about it. All one has to do is hit the
> right keys at the right time and the instrument plays itself.
> -- Johann Sebastian Bach
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
More information about the PLUG