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.

OCS style: colour

OCS blue is #0099cc for web and CMYK 78 24 0 0 for print.

If grey must be used instead of blue, use #7c7c7c (CMYK 0 0 0 51).

Headers and links on the OCS website are always #0099cc.

Logotype, when in colour is black and OCS blue. When in greyscale, it is black and OCS grey.

OCS Collateral Strategy

why collateral?

• marketing collateral for OCS needs to be developed in order to raise awareness of the issues behind colour and colour standards
• help designers realize what they are buying into
• inform designers that they have the power to have options
• get designers interested in helping to develop new options
• get them thinking about why they use Pantone when they could have something authored by themselves and accessible to everyone

what collateral?

• posters for use at design schools, offices and other places where designers congregate
• postcards for use at events like conferences where many transient designers are in attendance
• website for providing more in depth information on alternatives to Pantone
• ads, similar in intent to the posters, for use in design-centric magazines like Print and Azure

where collateral?

• anywhere designers can be found in large quantities, in physical space, internet space and media space

how collateral?

• target designers where they congregate
• engage them with some kind of hook
• feed them new information that they may never even have considered before
• drive them to find out more
• mobilize them, with hopes of creating community around OCS

who collateral?

• designers, largely those who deal in print media, but also others
• print professionals
• those who deal in textiles, plastics, markers, paints and so on...

conclusion
I have some serious market research to do. Who are these people? Where can I find them? Do they have any interest at all in community built systems, or are they just loners content to buy Pantone chip books every year? Can they be harnessed? How much do they already know about colour? Do they have any spare time? Do they know anything at all about Open Source? Would they be interested if they did? Can they be made to care?

OCS style: logo and typography

The OCS logo, without typography, has a 1:1 aspect ratio, with typography, it becomes 100:79.5.
Logo with type looks like this:
Logo without type looks like this:
Type alone looks like this:
OCS uses FreeSans, bold and all caps for logotype.
OCS uses FreeSans for all non-HTML typography.

Introduction to the OCS style book

Why does the Open Colour Standard need a book of style guidelines? It needs a defined style for the same reasons any other Open Source project should have one. A style book helps to define and create a unified look in a decentralized project. It helps new community members create on-message collateral and identity elements. It prevents the OCS look from becoming diffuse and meaningless. It prevents the misuse of OCS identity elements. What's more, it answer questions about the OCS look and guidelines.

In decentralized undertakings like Open Source projects, having something to tie contributors together is especially important. Since OCS has no physical culture or ties between community members, it must rely on tools like the style book to create and encourage unity.

Light and Colour

The human eye has four kinds of sensors: rods, which detect black and white; a cone for red; a cone for green; and a cone for blue. Our perception of colour relies on these sensors.

White light is made up of all the colours of the visible light spectrum. This can be seen when a beam of white light is refracted by a prism. Apparently, Newton had a lot to say about this, as he was the first to prove that white light is made of the rest of the visible light spectrum. More on this once I've had a better look at Opticks. Goethe also had a lot to say about the physics of light and colour perception. Again, more once I've read Theory of Colours.

The Purpose of the Open Colour Standard

Brief words about the Open Colour Standard: OCS is a union of colour theory and large scale information organization. OCS will be executed within an open source framework.

Open Colour Standard Goals

• Create an Open Colour Standard to rival proprietary colour spaces
• study colour for commercial and artistic uses in an open and transparent way, within the spirit of FLOSS
• educate designers, creators, businesses about the importance and benefits of open standards
• grow a community of open source colour developers
• take the prohibitive costs out of getting precise colour in print media

The mission of the Open Colour Standard will be to:

• educate the populous about colour
• democratize the precise use of colour in real world applications
• encourage experimentation and development with colour
• make colour accessible

New Letterhead, Almost the Same as the Old Letterhead

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).