Open Invention

Invention plays a large part in any composition space. As one of the traditional five canons of rhetoric, invention is the starting point for many composers: it’s where the ideas happen; it’s where inspiration begins. There are many ways in which composition instructors teach invention in the traditional writing classroom: brainstorming, mind maps, free association, and so on. Yet in this drive to come up with the perfect tool for teaching invention we often forget to put the focus back where it belongs: on the people. After all, it’s not the mind map or hand-drawn idea cluster that generates ideas; it’s the people coming up with them.

What a focus on standardized invention tools does is provide an avoidance of judgment that is often necessary to the invention process. When a writer uses a mind map, brainstorming outline, or other invention tool, it’s typically to get all ideas – any ideas – down on paper, without judgment, so she can sift through the bad to get to the good. This may work for some, but isn’t this ultimately counter-intuitive to the goals of invention? Who can say that one idea is "bad" and another is "good"? When we try to categorize ideas into good vs. bad, and force invention to conform to one side or another of a rigid binary, we begin to break down the very qualities of trust, freedom, and lack of judgment that these invention strategies are supposed to create. Thus, in order to create an encouraging environment for invention, we need to find a way to harness this safe, productive feeling for the classroom. We need to nurture invention and creativity without judgment – to move beyond mere tools and instead focus on the people. By this I mean that we can't find the heart of composition through the tools and technologies we use to create our texts; the heart of composition is created by the people: the writers, the students, and the instructors that work together to compose works, build knowledge, and create meaning.

"Open Invention" Begins with Trust and Problem-Solving

How many times have we said to our students (or even to ourselves as writers): "It may not be good writing, but at least it’s writing!"? As composition instructors we naturally encourage the creation of writing in all its forms: from publishable work to doodles, free writes to self-reflective journaling. Writing is a creative process and creative people know that invention takes time; a "good" idea doesn’t always come right away and composition is a difficult, often soul-searching process.

Because so much of our self identities are wrapped up in our compositions, the invention process is often difficult to share with others. We hesitate before showing that "rough draft" to a friend or colleague; instead, we wait until the work is "perfect" or until we’ve built up enough trust with our readers to hand over the reins. And yet, we expect our students to allow us into their own processes of composition from the very beginning stages of invention, and assume that the trust and safety net is already in place. What we forget, however, is that especially at the beginning of a class year or term when we’re still getting to know students, we expect them to invent from the start. What we’re asking for is enormous: we want them to invent – to expose their ideas, their inspirations (the "good" ones, the "bad" ones, and even the ugly ones) – to people they barely know. We ask for brainstorming and idea generation first and then attempt to win over trust later. In my experience, that isn’t necessarily the best way to encourage invention.

Yet there are lessons to be learned here from open source culture. After all, most open source project "inventors" are likewise strangers to one another: coding, composing, and otherwise contributing to the project efforts sometimes from thousands of miles away from one another. They’ve never met; they seemingly have no basis upon which to form bonds of trust. So how does open source culture deal with invention in the presence of strangers? How do they build trust, form a community, and invent together toward a common goal? The short answer, I believe, is: problem-solving.

In open source culture, invention is triggered by problem-solving. An issue is presented or necessitated and then acted upon in order to find a solution. Weber refers to this as a desire to “scratch your own itch,” and acknowledges that the primary reason for invention in open source culture is an attempt “to solve a problem” (Weber 2004, p. 137). In that sense, invention in open source communities is driven by a desire, a need to accomplish an immediate goal. For instance, the problem might be that a free or open source product doesn’t exist for a certain market; as a result, someone may try to create one. Then, in the creation process, an issue or bug will arise and suddenly there is yet another need for invention: for the original author to come up with a solution or perhaps for another programmer to step in and assist. Users of the new open source software solution may then come up with a wish list of items they want developers to implement or even fix; those items once again get added to the invention to-do list. Nearly every open source project has an ongoing, never-ending list of problems waiting to be solved. It’s up to the individual developers to step in, access the code, and pitch in to the overall invention process.

Software projects of any kind typically have at least three ongoing lists in need of invention: a bug list, wherein users and developers list known issues that need to be addressed; a feature or "wish" list from users of things they’d love to have or wish could be a bit different; and a change list, which outlines all of the differences and attempts that have been made to "fix" or enhance the software. In open source projects, these lists are made freely available to the public in the hopes that many minds will work together to problem-solve and invent. The beauty of open source culture is that this system – of invention out of a need or desire to solve a problem – almost always works.

Just one such example of this can be found within the community for the GNU Image Manipulation Program (GIMP), a free and open source image manipulation software program that has similar functionality to programs such as Photoshop. Lead inventors for the project, Spencer Kimball and Peter Mattis, say that “GIMP is our answer to the current lack of free (or at least reasonably priced) image manipulation software” (“GIMP - Frequently Asked Questions” n.d.). In other words, GIMP was "invented" because there was a problem that Kimball and Mattis believed needed to be solved. On the official GIMP website, project team members have provided installation files, documentation, frequently asked questions, and – for those interested in inventing and problem-solving alongside the project – the source code, so that programmers can jump right in to help solve commonly known issues or perhaps scratch an itch of their own. In fact, the GIMP team overtly appeals to other open inventors, asking for help in a variety of areas of the project: from composing code to writing tutorials, or even simply pointing out new problems to solve. As they astutely point out, “In the free software world, there is generally no distinction between users and developers. As in a friendly neighborhood, everybody pitches in to help their neighbors” (“GIMP – Getting Involved” n.d.). According to the GIMP website there are more than 200 individuals who have contributed to the open source project, including coders, artists, web developers, and writers – and that doesn’t even count the users who report bugs, work on issues, and help one another troubleshoot the program. That is, more than 200 individuals compose and invent together, each and every day, on various aspects of this project without formal hierarchies, complicated management systems, or even issues of authorship, as the names of contributors are merely listed on the GIMP website. And guess what? It works. So far, the GIMP project has released 12 versions of its software, with documentation in 13 languages, and it’s still in active development. To get started composing for the GIMP project, all that is required is a desire and a capacity for programming, writing, art, or web design; the code is there for you to invent, modify, and compose as you will.

So how do we take this information and apply it to an Open Source Composition Space? We begin by considering the needs of an open source community to solve problems – and then design ways to create problems in our classrooms that our students actually want to solve. We do that by taking a look at our classrooms and identifying the two motivating factors that propel open invention: desire and skill.1

1 For an interesting discussion on ‘problem-posing’ as a pedagogical methodology for open invention, see Freire (2000).

<< Previous: What Is "Open Source"?

>> Next: Inventing Through "Desire" and "Skill"