Feedback requested on a Writer's Guide to go in the press kit

This short guide below is one of many short documents that we'll hopefully be putting inside the KDE 4.0 Press Kit to send to brick and mortar media outlets. Inside the press kit, it will appear as a single sheet with formatting that is different than the official KDE related materials in order to make it stand out in the reverse sense. I'm soliciting feedback on any items that this short document is missing, or need corrected.

[begin document]

An Informal Guide to Dealing with Open Source Culture (for
Writers)
This document is designed to provide a few informal tips to media outlets that
are new to writing about Open Source Software in general, and KDE more
specifically. Seasoned veterans may still find a few of these tips to be
useful.

• Search out the defining features, rather than comparing to commercial
  products. Many people in the commercial world view open source projects
  exclusively as replacements for their Windows equivalents. While some
  projects exist that do precisely this, the vast majority have unique
  features that help to identify the program. Focusing on what makes the
  program unique will produce a better response.
• Don't hesitate to contact the program developers directly.
  Direct contact often produces the best answers. Usually programs will
  have an "About" screen (in KDE, it's under the help menu) that lists the
  contact information for the programmers that were actually involved in the
  creation of that software. Most programmers are very happy to answer
  press questions, or will redirect your questions to someone who can better
  deal with the specific questions.
• Informal language is best. Most open source programmers do not
  have a degree in business, journalism, etc. and will respond faster and with
  more details if they are approached as though the interview was taking place
  in a coffee house. If you ask formal questions, do not be put off by
  the informal response you may get in return. Ask for definitions of
  any jargon that you do not understand as some words, especially the word
  "Hacker", have very different meaning in the open source context.
• Don't expect immediate responses. Many open source programmers
  are coding in their spare time and work elsewhere to pay the bills.
  They will usually respond, but you need to give them time.
• Discover people's motivations. While some people work on free
  software for altruistic reasons, you will find that many do not. Many
  people are paid by a company to implement features that this company would
  find useful. Others simply find it an enjoyable hobby, and like being
  a part of the community. A person's motivation will often dictate what
  sort of programming they will do. If you discover what motivates a
  person or project, you will better understand their goals, which isn't
  always to compete with commercial software offerings...
• Play up collaboration, not division. While arguments between Linus
  Torvalds and Sun's CEO may make the rounds in popular press, cooperation is
  the prevalent mode of operation within the open source world. Free
  software projects cover a wide range of applications, from web servers to
  games, and quite often there is more than one product being developed under
  so called 'co-opetition'. Since the source code is available, projects
  readily and freely borrow ideas from one another, and even though the
  implementation details may be different, standards are developed for
  communications, data formats, and so forth. Open source projects are
  often stricter adherents to interoperability standards than their commercial
  counterparts.