Archive for the '6. The 10 Commandments' Category

I’m excited to tell everyone that my book is now available! It comes in hardcover, paperback, Kindle, and eBook through Amazon.com, Synopsys Press, and other book outlets. Rick Jamison, who created amusing cartoons for the book, and I are blatantly proud of our accomplishment. If you’ll be at the Design Automation Conference, stop by The Standards Booth for a complimentary copy.

“The Ten Commandments for Effective Standards” is a short book that expands upon my blog posts of the same name. I also wove in ideas from my blog readers’ comments on those posts. I included chapters on why I believe standards are important and what I think effective standards are. The book summarizes what I learned over many years (how did that happen?) of participating in creating EDA standards.

I’m quite sure that the challenges we face in the EDA industry when we standardize are similar to those in other technical fields. I found countless examples of challenges in other standardization efforts and included some interesting ones in the book. I hope my book will be of value to people involved in standards everywhere.

As I say in the Introduction, I realized that writing a book about how to create effective standards is like writing a book on parenting. There’s no single right way to do it and opinions abound. I look forward to lively discussions about my book.

In writing my short book, “The Ten Commandments for Effective Standards”, which will be published in a few months, I received much feedback with a variety of perspectives. A lot of it centered around the 2nd commandment: don’t mix patents and standards.

When I first wrote about patents and standards, my experience was that they simply don’t mix. There was too much risk for holders of (potentially) essential patents to participate in related standardization activities. Crazy cross-licensing schemes served only to delay progress on completing standards – no one in my industry had figured out how to make them work. Everyone wanted to play junior lawyer, citing all kinds of things that may or may not have been law.

Today, there is still much scrutiny on essential patents and standards. (An “essential” patent is one that will necessarily be infringed upon by anyone implementing the standard.) Possibly, there is even more focus now. As several of my book’s reviewers pointed out, however, there are some workable solutions in place that address the challenge of implementing a standard that has an essential patent associated with it.

One such effective solution is known as a “patent pool”. Essentially, all the holders of essential patents throw them into the ring, allowing others to license the patents. With a patent license in hand, implementers are free to create products that support the standard – without fear of lawsuits from the patent holders.The basic requirement is that the licenses must adhere to RAND (Reasonable And Non-Discriminatory) terms. It’s not acceptable to charge exorbitant fees nor refuse licenses to competitors.

A good example of a standard that employs a patent pool is USB. Adopters and promoters of the USB standard sign an agreement to license their patents to each other under RAND (Reasonable and Non-Discriminatory) terms and without royalties. Further, they agree to not assert their patent rights against others who have signed the agreement. The well-adopted and widely-used USB standard has taken advantage of the patent pool concept to successfully (so far) mix patents and standards.

Thus, I have changed the 2nd commandment to: use caution when mixing patents and standards. While I still think it’s safer to avoid producing standards that read on essential patents, diving into a patent pool can be the right approach. Just be careful, please.

I’m starting the new year by finishing a project, and it feels great. I posted the first of my “10 Commandments for Effective Standards” way back in February of 2008. Today, I’m completing the series with a concept that summarizes what I’ve learned about the standards game.

The 10th Commandment for Effective Standards is: Know That Standards Have Technical and Business Aspects.

When you think about a standard, the first thing that might come to mind is its technical nature. How can a standard’s working group piece together formats donated from several companies into a single, cohesive standard? How will the standard be implemented into existing algorithms and code? How will customers be able to plug together products that support the standard from different vendors? Which features of the standard must be included in the first version and which can be saved for future revisions?

These are vital questions to be answered, of course. But addressing only the technical aspects of a standard does not ensure that an effective standard will be produced. The business elements have to be considered as well.

Practical questions should be settled during the standardization process – if  not by the working group members, at least within the participants’ own organizations. For instance, how much will modifications to current products cost in order to support the proposed standard? Can new products be developed quickly enough to make use of the standard? Will it be economically feasible for customers to switch to a new standard?

To create an effective standard, not just a technically elegant one, the people working on a standardization effort need to realize – and be able to address – business concerns equally as much as technical concerns. I can think of four ways to meet this requirement.

First, a company can find an employee who has both technical expertise and business savvy to represent the company in the standard’s working group. This person is someone who can navigate his or her way through challenging technical issues as well as complex commercial constraints. It’s true, I know, that individuals who are skilled in two clearly different areas can be hard to find.

A second way to address both technical and business elements of a standard is through “on the job training”. A person working on a standards project can gain expertise in the area that’s not their specialty by watching and learning from others who are part of the project. I admit I learned a lot about the business side of standards by watching my competitors’ behavior.

A third approach is for companies to consciously and actively train their employees who are destined to work on standards projects before they start participating in standards development. This sounds like common sense, of course, but it does require forethought and investment in a training program.

A fourth way to balance technological and business considerations is for companies to send more than one representative to the standard’s working committee. This does mean additional resources must be invested, but it can certainly pay off.

Realizing the technical and business aspects of the standards game will help you be as effective as you can in the standards game. Happy New Year!

P.S. Watch for my upcoming book, “The 10 Commandments for Effective Standards”, from Synopsys Press. I hope it will be published in a few months.

I’m nearing the end of my series, “The 10 Commandments for Effective Standards”. Here is the 9th installment. It looks at how the standardization process can be accelerated and how standards can have a better chance of being adopted by industry.

The 9th Commandment for Effective Standards is: Start With Donations, Not From Scratch.

In the fast-paced EDA industry, spending too many years producing a standard can cause the standard to be pretty much obsolete by the time it’s finished. A sure way to speed up the standards process is to start with donations of already-proven formats, technology, and methods. Creating a foundation for a standard with techniques that have been shown to be useful gives a working committee a big head start. It also means that bugs or limitations may have already been addressed, lightening the load for the committee.

It’s important for the working committee – and its parent organization –  to allow donations to come from more than one source. Limiting contributions to a single company can be met with skepticism. It can also make committee members suspicious that a single company’s agenda is being pushed or that the standardization process isn’t open.

Of course, if a single solution is so elegant and welcomed by the committee that it’s not interested in other donations, it’s fine to proceed. However, this sense should be widely accepted, and committee members shouldn’t be blocked from making donations if they wish to.

On the other hand, if only one donation is made and no other donations are forthcoming, it could indicate that there’s no real need for a standard. In this case, even if much time and effort are put into producing the standard, it could end up sitting on a shelf, unadopted.

Donations can be made in a variety of ways, and established standards-setting and standards-development organizations have policies governing them. At times, owners can contribute their solutions through licensing schemes, but it’s critical that the terms be reasonable and non-discriminatory. Also known as RAND terms, this insures that all interested parties will have access to the standard for use in their products and services.

I know that some industries have to create standards from scratch before products can be developed. Yet, in my industry I’ve found that donations of proven technology result in highly effective standards.