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

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.

On Fri, Mar 9, 2012 at 4:23 AM, Godmar Back <[log in to unmask]> wrote:

> On Thu, Mar 8, 2012 at 3:53 PM, Mark A. Matienzo <[log in to unmask]>
> wrote:
>
> > On Thu, Mar 8, 2012 at 3:32 PM, Godmar Back <[log in to unmask]> wrote:
> >
> > > One side comment here; while smart handling/automatic detection of
> > > encodings would be a nice feature to have, it would help if pymarc
> could
> > > operate in an 'agnostic', or 'raw' mode where it would simply preserve
> > the
> > > encoding that's there after a record has been read when writing the
> > record.
> > >
> > > [ Right now, pymarc does not have such a mode - if leader[9] == 'a',
> the
> > > data is unconditionally utf8 encoded on output as per mbklein's patch.
> ]
> >
> > Please feel free to write a patch and submit a pull request if you're
> > able to contribute code to do this.
> >
> >
> Mark, while I would be able to contribute code to pymarc, I probably won't
> (unless my collaborators' needs in respect to pymarc become urgent.)
>
> I've been contributing to open source for over 15 years, my first major
> contribution having been the ext2fs filesystem code in the FreeBSD kernel (
>
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/filesystems-linux.html
> )
> and I'm a bit confused by how the spirit in the community has changed.  The
> phrase "patches welcome" used to be reserved for when there was a feature
> request somebody wanted, but you (the owner/maintainer of the software)
> didn't have the time or considered the problem not important.
>
> Back then, it used to be that all suggestions were welcome. For instance,
> if a user pointed out a typo, you'd fix it. Similarly, if a user or fellow
> developer pointed out a potential design flaw, you'd understand that you
> don't ask for patches, but that you go back to the drawing board and think
> about your software's design. In pymarc's case, what's needed is not more
> code (it already has a moderately confusing set of almost a dozen switches
> for reading/writing), but a requirement analysis where you think about use
> cases you want to support. For instance, whether you want to support
> reading/writing real world records in batches (without touching them) even
> if they have flaws or not. And/Or whether you insist on interpreting a
> record's data in terms of encoding, always. That's something occasional
> contributors cannot do, it requires work by the core team, in discussion
> with frequent users. (I would have liked to take this discussion to a
> pymarc-users list, but didn't find any.)
>
>  - Godmar
>