Wednesday, February 15, 2012

Open Source

In reviewing my work in the OER course I realized that I had failed to make the short blog entry related to our discussion and reading on open source.  I have made an earlier entry relating to the application of the principles guiding open sourcing to management strategies on business, particularly as it relates to innovation (Openness in Management Strategies linked here) and to a peer reviewed article regarding why participants contribute to an open community (Open community participants linked here).  So this is the brief summary post that I should have made following the readings and class discussion as it relates to open source software.

Chronologically I believe that this movement opened the door for the consideration of openness as it relates to other endeavors.  I believe that most of the open movements were started by someone frustrated with the restrictions related to the tool or artifact they were trying to use to accomplish a desired end.  In the beginning was the frustrated programmer Richard Stallman who became irritated that proprietary software was preventing him from making changes that would improve its use for his needs.  This frustration prompted a rebellion where he decided to write his own operating system and to license it freely so other programmers could work together to improve it.  He started the Free Software Foundation and began distributing his operating system freely to others, creating the GNU Public License to govern the modification, reuse, and redistribution of the operating system he developed.

Linus Torvalds built on the concept of the GNU Public License and the GNU operating system when he created the Linux kernal and added it to the operating system.  The renamed operating system was LINUX, although Stallman does feel strongly enough about his proprietary contributions that he refers to it as GNU/LINUX.  I was impressed in the viewing of the documentary that was part of the research with Torvalds seeming indifference to the fact that some of those repackaging LINUX and providing services and support were becoming extremely wealthy from his software that was basically free to them.

This discussion also laid a foundation that helped understand the genesis of the concept of open licensing, the evolution of the license in terms of legal protections, the extension of licensing to other areas of endeavor, and the current consolidation of licensing for OER and other applications in the Creative Commons license.

The other major impressions these readings and videos had on me came from Raymond's The Cathedral and the Bazaar.  I found it fascinating as he described the motivations and fundamentals of the open sources community.  I have reflected on his thoughts expressed in the publication in many different venues in my life (my profession, my family, and church, the civic organizations where I volunteer).  I felt compelled to make a separate list of the 19 "lessons" that he highlighted regarding software development in the open source community.  Some are readily transferable to other software projects and other areas of experience, some are specific to the particular email development project he was reviewing in the publication or software development projects only.  The lessons are:
  1. Every good work of software starts by scratching a developer's personal itch.
  2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
  3. ``Plan to throw one away; you will, anyhow.'' (Fred Brooks, The Mythical Man-Month, Chapter 11)
  4. If you have the right attitude, interesting problems will find you.
  5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
  6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
  7. Release early. Release often. And listen to your customers.
  8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
  9. Smart data structures and dumb code works a lot better than the other way around.
  10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
  11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
  12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
  13. ``Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.''
  14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
  15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
  16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
  17. A security system is only as secure as its secret. Beware of pseudo-secrets.
  18. To solve an interesting problem, start by finding a problem that is interesting to you.
  19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.
If you take a moment and substitute the term "solution" where the term software is used, or consider the references to the development process and project to the solving of issues in other settings, there are some principles of openness that would be helpful in other settings.

A final thought on the threat to general computing that Cory Doctorow.  I had never transferred the thinking about openness and proprietary licensing to the ability to use a computer, given the state of the different regulations and laws that are being proposed.  The analogy of the wheel (general purpose) and the car (specific purpose) made me think a little more deeply about the impact of these laws.  His discussion of applying a heuristic approach for regulation that says, "special purpose technologies are complex.  And you can remove features from them without doing fundamental disfiguring violence to their underlying utility" and how this approach may not apply to computers and the internet was important.  You cannot view software and websites as so general that the computer can still function by prohibiting their use.  "You cannot make a computer that will not run spreadsheets" is not a viable approach in a world where general purpose computers are becoming more prevalent and smaller (smartphones, etc.)

I considered why this Doctorow presentation was included in this discussion of open source.  I believe it is the perfect segue into the rest of the openness conversation we are having.  There are just some things about intellectual property that do not translate to the world of increasing capability and diminishing cost.  Some of the approaches and limitations are becoming anachronistic and as absurd as the DRM discussion early in the Doctorow presentation.

1 comment:

  1. Excellent summary. And your point about substituting language into the lessons of CatB is well taken, too. Many of those lessons are truths that apply broadly throughout our lives.