There's another aspect to the question of Open Source Software in the
Digital Humanities, beyond the involvement of a wide community in
committing to the actual source code.
When your software, stylesheets, scripts or other code are not just
tools for writing or presenting material, but are part of the
analytical apparatus of your research project (as even the simplest
concordance tool or search engine is, of course), then it is essential
if you consider what you are doing to be academic that your processes
be replicable. This is a concept familiar to scientists, but
humanities scholars also eschew the "black box" that is an argument
with no references or footnotes, an ex cathedra claim or an assertion
with incomplete or withheld proof.
Just as I cannot publish an article that will be taken seriously by
classicists without including clear citations to the ancient texts or
artefacts I'm working on, references to and acknowlegement of previous
bibliography on the subject, and the logical processes by which I
reach my conclusions, I should not be taken seriously if I publish a
digital work without making both the data and software licensed Open
Access and Open Source.
An Open Source project is therefore not necessarily to be despised or
considered somehow "not really OSS" if it isn't contributed to by
anyone outside of the original project team (or single person). It may
be valuable because someone can download it for their own purposes and
make use of it without making any changes (or making only very
idiosyncratic changes that they don't commit). It may be useful for
someone wanting to know what algorithms you used or assumptions you
made in processing your data. The code may be used by someone learning
the techniques and processes you're using. I think all these are
On 28 February 2012 22:24, Scot Mcphee <[log in to unmask]> wrote:
> Henry Francis Lynam wrote:
>> Hi Leif,
>> Thanks for the response. I agree with all these points.
>> I think the phrase 'open source' is always in danger of simply
>> becoming a mantra unless careful consideration is made about how it is
>> implemented and sustained. Your examples are very pertinent. Posting a
>> project's code on a public repository will not, of itself, create and
>> sustain a viable community around it. And this is exactly what's
>> required to make the project a success. A handful of committed
>> developers in it for the long haul is much more valuable than a large
>> number of intermittent contributors.
> Hello, I just want to back this up, because, speaking as a software
> developer with two decades experience, the usual rule of 'successful'
> open source projects is that most of the committers to the source code
> tend to be paid to be committers to the source code. That is, they work
> for a company like VMWare (which owns Springsource) or Redhat, or one of
> the big vendors like Sun, Oracle, IBM. As you can see these are usually
> making software of general utility as someone else mentioned.
> Open data formats are equally important to open source code. There's
> also the question of what licence you want to put on your code. Some
> allow others to build a commercial closed-source product on it, others
> impose 'viral' condition of the same open-source licence on any
> derivative works (GPL the most famous of those).
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)
Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL
Email: [log in to unmask]
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980