Comments on: “Forking” vs open source success

By: jrochkind

jrochkind — Wed, 07 Jan 2009 20:16:11 +0000

A better example than Fac-Bac-OPAC may have been VuFind. It is my understanding that most VuFind implementers customize the VuFind code to meet local needs, directly customizing the original shared codebase, essentially creating a local fork.

Some ideas for how you architect code to avoid this can be found in a more recent post: http://bibwild.wordpress.com/2009/01/06/how-to-build-shared-open-source/

By: Robert Copelan

Robert Copelan — Wed, 24 Dec 2008 16:28:01 +0000

“…Next steps would, in my opinion, involve major libraries realizing that they need to have actual software development expertise in-house if they are going to participate in a sustainable non-vendor-supported open source development.”

I would contend that in any industry (I work in automotive) we need to move back to having a core group of in-house development expertise. BUT unlike the 70s and 80s where the group did it all, the development groups of the 21st century are there to quickly meed the organizations innovation requirements and to coordinate with the larger community. If, as is seen in the successful Open Source projects, these developers understand the power of “community” then there will be a tremendous advantage to the software as knowledge and improvements are SHARED. The major Enterprise systems of today exist based on “knowledge is power and money”. That will NOT be the future.

By: More on doing open source right « Bibliographic Wilderness

More on doing open source right « Bibliographic Wilderness — Tue, 23 Dec 2008 23:18:54 +0000

[...] in General. trackback Okay, struck out the apparently incorrect slur against fac-bac-opac in my previous post. I still have a different perspective than Karen on libraryland’s historical approach to open [...]

By: K.G. Schneider

K.G. Schneider — Tue, 23 Dec 2008 21:21:50 +0000

I’m with Dan… in reading this post, I wondered where these instances of Fac-Back-OPAC were, as well as all of this forking in LibraryLand. Did the forks run away with the spoons?

I’d say an awful lot — the majority — of library OSS hews to the correct OSS ethos… many chefs, one kitchen.

Still, it’s good to have a long ruminative post about the value of OSS. Thank you for that!

By: jrochkind

jrochkind — Tue, 23 Dec 2008 04:41:16 +0000

Huh, maybe I got the wrong idea about that one then.

By: Dan Scott

Dan Scott — Tue, 23 Dec 2008 04:23:08 +0000

Eh? Where are all these forks of “Fac-Back-OPAC” and its ilk? Casey’s original “OSS Endekwa” throwaway code formed the base of the work that I did with Michael Beccaria. The original commit represented the code Casey handed off at code4lib 2007 (http://code.google.com/p/fac-back-opac/source/list?start=2). We merged our changes into the code base. Gabriel Farrell and Mark Matienzo became more active on the project and introduced the pymarc indexing code in a feature branch, Kate Lynch committed various enhancements, and Casey contributed his more serious effort as another branch – all part of the same repository. Over time, Gabriel merged the features from the various branches into trunk and did a hell of a lot of work improving the code base. Recently, Ross Singer committed some Jangle integration code. All of this is in the same repository; the mature features are merged together in trunk. So… where are all these forks? How is this a “prime example” of not having “regard for maintaining a common codebase”?