Open Sauce

From secret sauce to open source,
and back again


by Peggy Aycinena


Let me admit up front, that I’m not a software guy. I’m an electrical engineer, or I used to be an electrical engineer. Now I’m an editor. In any case, last Thursday night I attended the Software Developers Forum Distinguished Speaker Series on the legendary Xerox campus in Palo Alto. That’s the place where the User Interface that Launched a 1000 Ships was supposedly developed.

The speaker that night was Jason Hunter, who spoke about "Open Source from The Inside."

I didn’t know too much about Jason Hunter before I went to his talk. I still don’t know too much about him. There were a bunch of software guys in the audience, and they clearly knew enough about him that the person who introduced Jason only congratulated him on his successes, but didn’t feel the need to catalog those successes. So, to help me accurately describe him, here’s something I found on the stylusstudio.com website:

"Jason Hunter is the author of Java Servlet Programming and co-author of Java Enterprise Best Practices (both O'Reilly Media), an original contributor to Apache Tomcat, and a member of the expert groups responsible for Servlet, JSP, JAXP, and XQJ (XQuery API for Java) development. Jason is an Apache Member, and as Apache's representative to the Java Community Process Executive Committee he established a landmark agreement for open source Java. He co-created the open source JDOM library to enable optimized Java and XML integration."

Clearly, Jason Hunter knows a thing or two about open source.

After his talk, I was of two minds.

1) Become a software developer so I, too, can get religion and be part of the world Jason described, or ...

2) Write an article linking Jason’s carefully articulated, 2-hour (!!) stream-of-consciousness talk to the panel I had moderated earlier that day at the Synopsys EDA Interoperability Developers’ Forum.

It’s too late to become a software developer, so I’ve opted instead for Door No. 2.

***********************

Last Thursday at lunch time, Karen Bartleson of Synopsys fame, Dennis Brophy of Mentor/IEEE/Accellera fame, Sean Murphy of PicoCraft fame, Rob Roy of Zenasis fame, and Greg Spirakas of Intel fame sat down with me in a ‘living room’ artfully constructed on the stage in the auditorium on the campus of Sun Microsystems, so we could talk about "The Business of Standards."

It was a cozy chat that unfolded in front of about 150 of our closest friends, and I learned a lot from engaging with these folks. But, I didn’t really learn what I had learned until I attended Jason Hunter’s talk that night.

Because what my lunch time group was discussing in our ‘living room’ was not the "Business of Standards" at all. It was the "Philosophy of Open Source." Better summarized, in my humble opinion, by my two cosmic questions:

No. 1) When do standards drive adoption and when does adoption drives standards?

No. 2) When a technology becomes widely adopted, it usually becomes a/the standard. But wide adoption of a technology can happen for two reasons: 1) the quality and effectiveness of the technology, or 2) the quality and effectiveness of the Sales and Marketing organizations of the company who owns the patents, or patent applications, on that technology.

And because two cosmic questions always lead to a third ...

No. 3) Since standards require open source, and open source seems to be the antithesis of capitalism, corporate competition, and patent applications - how can corporations support open source anything? Especially EDA companies who live and die by their proprietary secret sauce, their patents, and their ability to litigate the hell out of their brothers in the EDA Frat House.

So, here’s a summary of what the lunch time guys had to say.

Greg Spirakis cleverly delivered a mini-speech based on the acronym COPE.

C - Customer-driven standards are best.

O - There are many ways to define open, when you’re talking about standards. You need bylaws to define who controls the technology. Companies shouldn’t define their technology as "open" just because it’s "useful." Useful is not the same as open.

P - The process of developing standards needs to be a pragmatic one. It’s about the act of agreeing.

E - The process of developing standards is always an evolutionary one. Linux emerged through an evolutionary process, not because a single entity declared it’s existence and it’s predominance.

Greg went on to say that he says "Yes!!" to OpenAccess and SystemVerilog in the EDA world. He closed by changing his acronym, COPE, to a better acronym, COPES.

S - Greg says standards need to be sustainable.

Sean Murphy followed Greg. Sean said that when it comes to standards, you’ve got to pick good enough over best. That’s the only way to get on with the process of establishing standards. If you wait to get "best" to be the standard, nothing will every got done. You’ve got to go with "good enough." Sean also invoked Gorden Bell and paraphrased, "No product or technology before its time."

Sean ended by saying that although EDA is not a consumer market, where you’ve got to pay attention to standards or fail, many small EDA companies try to innovate by going off on their own and ignoring standards, de facto or otherwise. But those companies often innovate themselves right out of business, because ultimately they’ve got to adhere to some of the standards or nobody’s going to be able to use their products.

Karen Bartleson was third in the batting order. She asked the audience to raise their hands if they had benefited from the standards that Synopsys has promoted. She then asked the audience to raise their hands if they considered themselves to be in competition with Synopsys. I can’t give you the actual numbers who responded in the affirmative to either of these questions, as it happened too fast for me to count, but Karen’s point was clear.

"Why would Synopsys promote standards if many of you out there are in competition with us, unless we felt that in our role as market leader, we had a responsibility to promote standards for the overall health of the industry?"

Karen finished by saying that using standards has allowed Synopsys to further their success in the marketplace. Her point, I believe, was that even market leaders, who could opt to dominate the smaller players by forcing their technology as the de facto standard, have the wisdom to see that what’s good for the overall industry is good for GM. Therefore, Synopsys supports open standards.

Dennis Brophy was next. He articulated the new vision within the IEEE regarding standards development. The new philosophy the IEEE standards committees are pursuing is more "market-driven," to use Dennis’ phrase, and therefore more nimble and responsive to the needs of industry.

The IEEE has become increasingly aware that industry standards bodies - based on the one company, one vote model - have been springing up right and left, in part because the IEEE has been slow in completing standards today to promote technology for tomorrow.

Dennis said the new IEEE processes should not be seen as democratic - one company, one vote - but will allow for far better efficiency in closing in on the standards needed by industry.

Rob Roy had the final at-bat in the inning. He said the cell phone is a perfect poster child for the needs and realities of pursing standards. The cell phone could not have come to fruition, and been improved upon so rapidly, if the companies involved in that industry had not moved quickly to establish and work to standards that were ready and able when they were needed.

Rob said that standards in EDA are problematic, particularly for small companies. There need to be standards in EDA to allow the (many) tools in the design flow to talk to each other. But, small companies are hard pressed to find the resources needed to work towards standards for two reasons.

1) It’s costly to keep your engineering staff up to date on all of the latest standards, revisions and initiatives, so that they can design to those ever-shifting specifications, and

2) It’s really costly to send personnel off to the many standards bodies meetings that are happening all the time, so the company’s voice is heard in the conversation, and details of the emerging standard can be communicated to your engineering staff back home.

***********************

Following these opening statements, there were several additional innings of conversation, and then a cogent question from the floor. The ever-articulate Joe Daniels asked the panelists why anybody should even bother with standards, especially when standards are wrapped up in controversy. It seemed liked a reasonable query.

Rob Roy said that profits and standards are linked.

Greg Spirakis said he wouldn’t touch a standard that was controversial in any way.

Dennis Brophy said that standards offer options for implementation and reduce the cost of design.

Sean Murphy said if customers don’t want a standard, vendors don’t have to use it.

***********************

At that point, the 45 minutes allotted for the panel were almost up. Panelists had a couple minutes to summarize.

Sean spoke to the financial reality, and said standards are linked to a company’s exit strategy. If you innovate and you’re alone, you’ll innovate yourself right out of business - not to mention the fact that you’ll never get acquired.

Rob said that standards are best when their linked to your customer’s needs.

Dennis said the new IEEE procedures are driving better corporate participation, and promoting increased market relevance in the standards being developed by the organization.

Karen said that standards are tied up in matters related to what and when to invest - and that open standards are about risk taking. A company’s got to know when opening up their technology to the industry is appropriate, and how to find the courage to take that risk.

Greg was up last, and commended the IEEE for their revised procedures He said he liked the overall approach the IEEE was taking with regards to establishing standards.

But, Greg ended on a somewhat somber note. He said he's concerned that there are so many standards bodies floating around out there. Those groups are taking up too much of everybody’s time, Greg said, and the EDA industry should consolidate those organizations to make things easier for EDA vendors, and their customers, to track what’s going on.

***********************

After the panel was over, I struggled to understand what all we had been talking about up on stage at the Interoperability Forum. There seemed to be so many themes playing in and around that conversation, but not enough time to flush all of those themes out into the open.

There’d been zero time to ask pointed questions of the various panelist to fully understand the nature of each of their true agendas. Why had their companies encouraged them to appear on that stage?

So, as I took my seat in the Xerox auditorium that evening, I was only lending half an ear at the beginning to Jason Hunter’s talk. I was busy were rifling through the notes I had jotted down during the lunch time panel. What had we all been talking about?

Then, I began to focus on Jason’s talk.

And, then I began to understand.

We had been talking about open source, because open source is the foundation upon which standards are built. Businesses - especially EDA businesses - need standards, and hence they need open source code.

Here are a few highlights of Jason Hunter’s inspired ramblings, a talk which he called, "Open Source 101."

* Open source is a profoundly good way to produce excellent industry standards.

* An open source community has folks who are friendly, and folks who are competitive. There’s room in an open source community for both kinds.

* Why do people do open source? Never underestimate the power of a man scorned. A man scorned by his ex-wife, his ex-girlfriend, or his ex-employer has lots of time and energy to spend on furthering the cause of an open source technology. It’s cathartic.

* Other people do open source because, quite honestly, it’s a great way to get your name out there. Work done at a company may make you a highly rewarded team player. Good work done in an open source community can make you a legend.

* When a technology is evolving in an open source environment, not just anyone can make changes or improvements. Open source is not about democracy. Open source is about earning the trust of your community and therefore earning the right to submit and sponsor changes to the technology being fostered by that community.

* Forking is when somebody goes off in a different direction, because they think they see a better way. The community needs to know about it, but the community needs to encourage it. Forking forces innovation.

* Open source is not about socialism or communism. It’s not anti-capitalist. Forking within an open source technology is all about competition.

* 5 is a good number of forks to be pursuing at any one time in an open source community, but not 50. Each fork requires each community member to respond to the input of every other community member. So, the conversation - all based on "Reply All" - for each of those forks to play themselves out, increases exponentially with each new fork. Hence 5 forks, not 50, is ideal.

* Coding software in an open source community makes you code more carefully, because everything you do is scrutinized by a plethora of guys just as knowledgeable and opinionated as you are.

* Everybody’s equal in an open source community, but some people are more equal than others.

* Even if the open source technolgoy was your idea, the community may turn on you. Nobody’s guaranteed "Father For Life" status on the technology in an open source community, except maybe Linus Torvald ... and even that’s not for sure.

* Documentation in an open source community is the e-mail audit trail that suggests, tracks, and comments on changes.

* Revisions control is a mega-issue in an open source community. Each hack leads to another hack, and so forth and so on. An open source community is a leaderless community - almost, but not quite, socialist. But, there’s got to be a gatekeeper to keep track of who’s revising what, and when, and where, and why.

* There are intense, highly charged legal issues involved in anything that’s open source. Those legal issues are joined at the hip with the business issues at play in anything that’s open source.

* You can take technology that you have access to in an open source community and commercialize it, but you can’t take the name of the technology and use it as your own. And if you’re just providing a trivial fix to open source code and making it "proprietary," you’re wasting your time. Nobody’s going to buy it. You need to make a substantial change if you think you’re going to earn enough money to justify the effort.

* Companies need to ask themselves:

- Should I open source my code?
- Should I open source my propriety family jewels?
- I need to open source my code at the moment in time when it really matters, not later when nobody cares anymore. When is that moment?

* Companies shouldn’t kid themselves or others - visible source code is absolutely not the same as open source code

* Everybody tele-commutes these days. The only way to foster community is to use the "Reply All" button. You can’t have progress in a company or an open source community, if you don’t use "Reply All" to include the tele-communities. They lose the thread of the technology initiative, and even worse - they get mad.

* Open source is about who has the power. Power is about who controls the information.

* New projects that spin out of an open source community are judged not by the quality of the technology, but by the quality of the community. It’s not about the technology, it’s about the people.

* Open source is about "Reply All," because it’s about community and conversation and discourse and consensus.

Amen.



***************

October 25, 2004

Peggy Aycinena owns and operates EDA Confidential. She can be reached at peggy@aycinena.com


Copyright (c) 2004, Peggy Aycinena. All rights reserved.