Good Open Source/Bad Open Source

On May 25, 2010, in Research, by Chris Prom

At the Practical E-Records Seminar last week, I tried to make the point that if an archives really wants to begin a program for accessioning, preserving, and providing access to born-digital records, the responsible staff member should get involved in an open source software (OSS) project.  In my experience, there really is no substitute for taking active part in software development , either as a product tester, contributor, or preferably an active commiter.  It will really help you understand how computers and programming work and working on OSS illustrates the challenges of managing even a project.  It forces you to quickly separate your wants (“wouldn’t it be great if this software did ‘X'”) from your wants (“. . .but we absolutely need it to do ‘Y'”) and to realize that developing software is all about encouraging people to work together for the common good.

But, which open source software project should you get involved in? I certainly can’t pick your project for you.  And listing off specific projects to shame might be a bit unseemly. So, based on my experience over the past ten months (reading documentation for more projects than you care to image and nearly falling into depression over yet another failed installation procedure ), I’d like to offer a nice table of factors you might refer to when considering which software project you might want to get involved with:

Open Source Software Projects

GoodBad
Serves a defined purpose or need, has a 'vision' which is stated concisely on project websitePurpose of software is unclear, possibly replicates existing tools or project is lacking overall vision/has conflicted vision.
Can be installed on widely implemented and readily accessible hardware/server combinations.Requires hardware/server configurations that are not widely available to the target user community.
Uses the least complex programming language/framework suitable for the taskUses a more complex language/framework than is really necessary to accomplish the job.
Uses all of the following tools to encourage community participation in application design and implementation: project listserv or bulletin board, CVS code repository, bug and issue tracking, project roadmapDoes not use appropriate tools to encourage community collaboration, or implements them in a half-hearted fashion.
Lets you know where they are going (project roadmap)Does not bother telling anyone which features or general areas they are getting ready for release.
Project has an outlined and transparent decision-making process. Decisions made and announced in timely fashion.Decision making process is obscure or overly complicated by administrative considerations.
Code and trademark ownership is clearCode and trademark ownership is contested and or split among many institutions
Project announcements are clear and timely.Project announcements raise questions or make promises that are not delivered.
Follows 'Release Early, Release Often' philosophy, or announces release target dates or apologizes/provides reason when they miss it.Does not have release targets or lets them pass without notice.
Documentation exists and is concise/clearly-written. Basic areas such as installation and simple configuration are treated in a non-technical fashion. A separate developer documentation (function and variable reference) is provided.Documentation is either incomplete or so filled with technical jargon that only project developers can understand it.
Software includes auto update feature or alerts you when it is out of date and provides link to upgrade scriptOut of date software continues to run w/out an upgrade note; requires manual upgrades or reinstallation
Relies on other OSS for code libraries, but only includes well supported libraries or very stable librariesRelies on bleeding edge libraries or local code that replicates functions of available OSS.
Program is modular; additional functional areas can be added to core modules without breaking them.Spaghetti code (mixes code for distinct functional areas in core or files dedicated to other functional areas)
Project is announced with call for community participation and or working copy of codeProject is announced with big fanfare but no code and no announcement of how community participate will be managed
Software specifications/ diagrams are shared/posted on website or wikiSoftware specifications have not been developed or posted.
Directory and file structure of code is logically consistentDirectory and file naming/organization is opaque--undestanding it requires reference to documentation
Integrated, incremental process for writing specifications and coding the application. "Waterfall" development model; specifications developed without reference to proposed technical architecture or dumped on programmers.
Installation packet includes all required softwareRequires manual installation of other open-source libraries and/or modification of the host system.

Any other points to add??? Let me know in the comments.

Additional Resources

Roy Tennent and Sibyl Schaffer have recently offered advice concerning OSS projects, and everyone should be familiar with Karl Fogel’s book, which I just discovered myself.

Tagged with:  
  • andyj

    I think, or hope, that you’ve got the columns the wrong way around on row 14. I suspect you do not think that a big fanfare with no code is a good thing.

  • Chris Prom

    Thanks for the catch–I did indeed have those columns reversed, and just fixed it.

  • David Thompson

    Thanks for sharing information concerning open source software project. Great tips too!

  • Pingback: Create open source project – advise needed closed | Code and Programming()