OCS poster, wiki

It just occurred to me that I never actually put up the final, fixed version of the OCS poster. So, ta dah!

Also worth mentioning is the OCS presence on the Create wiki. It comes with a flashy new domain name for OCS: opencolour.org. Eventually, I want to get a more permanent site up at that address, but for now, it's pointing to the wiki, where the future of Open Colour is being discussed.

New Site

Up and running, at a temporary address, the main OCS website. It's a little bare bones at the moment, but should be getting more content in the near future.

OCS site

OCS Open Source poster round two

OCS Open Source poster

Four versions of an OCS/Open Source for Designers poster promoting Open Source alternatives to closed industry standards.

OCS Action Plan

I've worked up a bit of a strategic plan for the future of the Open Colour Standard, based on conclusions from the research report mentioned earlier.

Areas outlined in the action plan: major problems, low-hanging fruit, actions that can be taken to advance the Open Colour Standard and actions to support Open Source for designers.

Download the action plan as a PDF

Research Report: release 1.0

After yesterday's post of the beta version of this report, it's now time to roll out version 1.0. Changes since the last version include a newly added bibliography and table of contents, changes to the inline citation style and new content added to the section on Open Source and designers.

Download version 1.0 as a PDF

Research Report on Colour, Open Source and Designers

A taste of the report:

"The purpose of the following research report is to create context for the Open Colour Standard project. To that end, this report discusses issues of colour, commercial and non-commercial colour spaces, the use of colour in industry, the Pantone colour space and the business behind it, Open Source projects, their adoption and the possibility of Open Source design."

Full report, as a PDF

Problems with Open Source Adoption Among Designers

I've been hunting around, trying to figure out just why it is that more designers don't use Open Source software. I've isolated a few candidates:

• Designers are set in their ways: Most designers already know some permutation of the Adobe Creative Suite. Why bother learning something new?
• Employability: Creative Suite is taught in design schools, most every job a design grad can hope to get post school will involve Creative Suite. It just doesn't make sense to learn anything but Creative Suite if Creative Suite is what employers install on their computers.
• Print shops: Because Creative Suite is the industry standard, print shops take the proprietary Adobe file formats. Sure, you could just send them a .pdf, but what if something goes wrong?
• Open Source optics: Most designers see Open Source programs as poor cousins to proprietary equivalents. They view programs like The GIMP as Photoshop clones instead of programs in their own rite. As long as the Creative Suite monopoly exists, it will be quite difficult for Open Source programs to gain traction.

In short, Open Source is faced by a cyclical problem: Everyone learns Creative Suite in school because the whole industry uses Creative Suite. Printers use Creative Suite because their clients do and their clients use it because the printers do. Because Creative Suite is an industry standard, snobbish or blinkered designers continue to perceive it as something hobbyists use. If designers never start using Open Source software, it will be a self-fulfilling prophecy: Open Source graphics programs will be for hobbyists.

How does this impact Open Colour Standard? Replace the words Creative Suite with PANTONE. Replace Open Source software with Open Colour Standard. Gaining a foothold in such a closed industry is going to be difficult.

On Open Source Organization

"play is the most economically efficient mode of creative work." (Raymond, 1997)

In his 1998 essay, "Homesteading the Noosphere," Eric Raymond outlines several different management structures used in Open Source projects. These structures are:

• sole maintainer
• multiple maintainers under one benevolent dictator
• democracy with developers as voting members
• rotating dictatorship among senior developers

In the Open Source community, the term "benevolent dictator" refers to the leader/overseer of a project. The benevolent dictator effectively acts as a gatekeeper for the project, providing vision and oversight. The most notable example of a benevolent dictator is Linus Torvalds, who safeguards the integrity of the Linux kernel. A maintainer is less managerial and more technical. Instead of dealing with the vision of a project, in models with both dictators and maintainers, maintainers are tasked with responsibility over one section of the project. In a model that has both maintainers and a benevolent dictator, multiple maintainers work under the benevolent dictator at individual tasks with the goal of fulfilling the vision as set out by the benevolent dictator.

Important factors in community building around software development, according to Raymond, are having "something runnable and testable to play with" (1997) to offer your contributors, as well as having a "plausible promise" (1997).

Worth quoting in full, on the topic of what contiributors like to do: "Human beings generally take pleasure in a task when it falls in a sort of optimal-challenge zone; not so easy as to be boring, not too hard to achieve. A happy programmer is one who is neither underutilized nor weighed down with ill-formulated goals and stressful process friction. Enjoyment predicts efficiency" (1997).