When to Fork and When to Spoon

Steve 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[1] and it's
> basically a nifty little lightweight transport-independent protocol. The
> spec[2] 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[3].
>
> 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 mailing list