 |
 |
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