On Fri, Mar 9, 2012 at 10:37 AM, Michael B. Klein <[log in to unmask]> wrote:

> The internal discussion then becomes, "I have a need, and I've written
> something that satisfies it. I think it could also be useful to others, but
> I'm not going to have time to make major changes or implement features
> others need. Should I open source this or keep it to myself? Does freeing
> my code come with an implicit requirement to maintain and support it?
> Should it?"
>
>
It used to be that way, at least it was this way when I grew up in open
source (in the 90s, before Eric Raymond invented the term). And it makes
sense, for successful projects that have at least a moderate number of
users.  Just dumping your code on github helps very few people.


> I'd vote open source just about every time. If someone sees the need and
> has the time to do a functional/requirements analysis and develop a "core
> team" around pymarc, more power to them. The code that's already there will
> give them a head start. Or they can start from scratch.
>
> Until then, it will remain a fork-patch-and-pull, community-supported
> project.
>

It's not just an agreement on design goals the core team must reach, it's
also the issue of maintaining a record (in email discussions/posts and in
the developer's minds) of what issues arose, what legacy decisions were
made, where backwards compatibility is required. That's something
maintainers do, it enables them to reason about future design
decisions. People who feel a sense of ownership and mental
investment. Sure, I could throw in a flag 'dont_utf8_encode' to make the
code work for my case. But it wouldn't improve the software.  (In pymarc's
case, I'd also recommend a discussion about data structures. For instance,
what should the type of the elements of the subfield array be that's passed
to a Field constructor? 8-bit string or unicode objects? The thread you
link to shows ambiguity here.)

Staying with fork-patch-and-pull may help individual people meet their
individual needs, but can prevent wide-spread adoption - and creates
frustration for users who may lack the expertise to track down encoding
errors or who are even unable to understand where the code they're using
lives on their machine. Once a piece of software has reached the stage
where it's distributed as a package (which pymarc, I believe, is), the
distributors have taken on a piece of responsibility. Related, being
unwilling to fix even documentation typos unless someone clones the
repository and delivers a pull request (on a silver platter?) seems unusual
to me, but - perhaps I'm just too old and culturally out of tune with
today's open source movement. (I'm not being ironic here, maybe there has
been a shift and I should just get with it.)

 - Godmar