Files
hpr-knowledge-base/hpr_transcripts/hpr1622.txt

595 lines
47 KiB
Plaintext
Raw Normal View History

Episode: 1622
Title: HPR1622: An interview with Michael Tiemann
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1622/hpr1622.mp3
Transcribed: 2025-10-18 05:59:12
---
This episode of HBR is brought to you by AnanasThost.com.
Get 15% discount on all shared hosting with the offer code HBR15.
That's HBR15.
Better web hosting that's Honest and Fair at AnanasThost.com.
Hello Hacker Public Radio.
This is Semiotic Robotic and today I'm happy to bring you a very special open source newsbreak
from OpenSource.com.
Today's episode is an interview show.
I recently sat down with Michael Teaman, vice president of open source affairs at a red
hat to discuss his history as an open source entrepreneur.
Here's a bit of background on Teaman for those of you who might need it.
In 1989, Teaman co-founded Signus Solutions, the world's first company to offer support
for open source software.
Ten years after Signus incorporated, it merged with red hat, so in 1999, Teaman became red
hat's chief technical officer.
He also served as president of the open source initiative, stepping down in 2012.
Today, he continues his work as an open source evangelist through his writing and speaking.
In fact, you'll find more of his work at opensource.com.
Teaman and I discuss the early days of the open source movement.
I actually begin the interview by asking him to take us back to 1987.
And the interview is full of anecdotes about its genesis.
He explains to me how his company took $6,000 of startup capital and the odd idea that
one might make money from so-called free software and turned it into millions.
Finally, Teaman shares his insight on the ways competition and innovation function in
the open source software market.
Chatting with him certainly was an honor and I really do hope you enjoy listening to
our conversation.
I'll see you next episode and as always, I wish you peace, love and open source.
All right.
I am here with Michael Teaman.
Michael, thanks for being with me today.
I wonder if we could start in, go all the way back.
Go back to 1987 and I'm wondering if you can describe for me the moment or maybe it was
a series of moments that led you to the realization that building an open source business might
not only be viable but lucrative as well.
Well, in 1987 it was really more just beginning to realize the potential of open source.
Richard Solomon had released the GNU Seacompiler in June of 1987.
And I was familiar with GNU EMAX, which if you've ever used EMAX is a mind-blowing experience
of that of itself and I had also become acquainted with the GNU Debugger as well.
But the release of the compiler for me was a very watershed event because first of all,
I was really interested in compilers.
I really wanted to work in the compiler field and I saw absolutely no pathway to getting
a job in that field because all the people who were employed there were far more senior
than I was.
They were tiny little companies, the charge millions of dollars and I saw no way to convince anybody
that I could be on a team of two or three people justifying these multimillion dollar price
tax along comes the GNU Seacompiler and suddenly I get a chance to actually see a recipe
for a compiler.
And the recipe is not exactly simple when I untard the files.
It was over 110,000 lines of code and my very first inclination was to print it all out
so that I could study it.
And I had more than a few people visiting my cube during the day saying, are you sure
you really want to be printing all this out?
And I said yes.
And I don't remember how many reams of paper it was.
But it was a lot and I brought it home and I just started pouring over it.
I had just bought a dining room table with two leaves and I put both leaves in a table
and I started out by just putting each of the sheets of paper belonging to individual files
in a pile.
And then as I began reading it, I began sort of making links about this refers to that
and here's this idea, et cetera.
And over the course of a long weekend, I put into my mind what those 110,000 lines of
code did.
And I started to write a machine description file and some other configuration files to
do the very first port of the compiler external to the first two that Richard Stallman had
created.
And much to my amazement, a process which normally took two to three years and cost two to
three million dollars, namely the porting of a compiler in two weeks.
I had completed a compiler port which generated code 10% faster than the vendor's compiler.
And that in and of itself sounds pretty special and I was very proud of that.
But the other little detail that really fired my imagination was that the port that I
did this, the port that I accomplished, which was to a processor called the National Semiconductor
of 32, 032, had famously been sold as a one MIPS chip.
But it did not deliver one MIPS.
It delivered about 0.8 MIPS.
And that was sort of seen as a failure in the marketplace that left the window open for
another vendor to come out with a higher performance chip and basically make nationals
effort worth nothing.
So you do a little bit of math and 10% better than 0.8 does not quite get you to that one
MIPS number.
But after publishing what I had done after two weeks, I then spent another two weeks optimizing
this port that I had done and I got it up to a full MIPS on the chip.
So what that told me was that it was possible for an independent person to accomplish by
themselves something that an entire company, an entire marketing team, an entire engineering
and development team could not do, which was to hit a target.
Right.
Exactly.
I published those results and actually one of the first invitations that I received to
talk about this compiler came from Israel, came from the development team of national
semiconductor that was in, I believe, Herzlia.
So I had no immediate plans to travel there.
But a year later, when I took a job with the French government hacking open source software
outside of Paris, that put me close enough that I was able to continue on and give a lecture.
And I had the technique on there in Nier Tel Aviv.
So that was sort of the very beginning and what excited me at that time, back in the 80s,
there was a lot of microprocessor development.
There were lots of different ideas that the Intel X86 had by no means won the war.
The Macintosh was still a relatively new sensation in the Motorola 68, O20, O30, O40,
where you must be getting their leapfrogs, Motorola and a lot of other chip companies were
heavily investing in a new technology called RISC, reduced instruction set computing.
And the microprocessor arena was about to explode with all kinds of new designs needing
all kinds of new compilers.
And later, after accomplishing this port to the national 32 or 32, I then undertook the
port to the Motorola 88,000.
And again, I beat the Motorola team by 10 percent on my first time in that.
That got a little bit of attention there.
And then I started doing other compiler ports.
And one day, a manual for the Spark processor from Sun showed up on my desk entirely anonymously.
And I sort of, you know, my first question was, who the heck sent this to me?
And my second question is, do I have enough time?
Yeah, I got it on Friday and I thought to myself, wouldn't it be cool if I could actually
get the port done before I identify who actually sent it to me?
Right.
And in fact, that is what happened.
I did a port over a weekend.
And as I was coming into the final stretch, I remembered that Wayne Rosen from Sun Microsystems,
he would later become the first CTO at Google, but Wayne Rosen had visited our facility in
Austin, Texas, had seen me doing some making some outrageous claims about the compiler.
And I think on a large, he just sent me the instruction manual and I popped out of port.
So those were the early days.
And that was just an example where, you know, if you imagine the part of the movie where,
you know, that you throw everything at the, you know, at the protagonist and somehow
they send it back, you know, with an extra 10% speed on the ball.
Right.
That's where I was in 1987.
So when you said you published the code today, people would do that by pushing code to
a repository.
That's right.
How did you publish your code?
I published both the files, the complete files themselves as well as diff files to an FTP site
in Massachusetts.
So we used FTP and back in those days, one was very, very lucky.
You know, my modem, I believe, was a 19.2 K-bode modice.
And that was special.
And that was, that was high in smoking, yeah, back in the day.
Of course, real companies had T1 lines, which we all know is a one megabit connection, but
they usually only had one.
And I actually got a visit when I was at Inlia, the institute, the translation is the National
Institute for Research and Computer Science.
But in French, it's an institute, National Poiré Shush on Infomateque, an automatic.
And I got a visit from the general administration people who were curious how it was that I
was using more bandwidth than the rest of the whole lab combined.
And I explained what I was doing and they were very happy that I was only there for the
summer.
It was the summer job.
I would be going soon.
And that problem would go with itself, yeah.
So you once described another insight that you had at this time, and you were thinking
about the notion of the commons, and you were thinking about the notion of law.
And you talked, you wrote once about the way that code and law might be related to each other
in this regard, with regard to a commons.
You said that while law is a common resource, lawyers are nevertheless fairly well paid
for the work they do with the law.
And so you made a case that software could work the same way.
You applied this thinking to the business of supporting free software.
And I'm wondering if you could elaborate on that insight for us a little bit.
Yeah, I can tell you that when I was promoting this idea that this superior technology could
absolutely move the industry forward, I got a tremendous amount of pushback from people
who basically said, look, in our capitalist environment, you cannot be successful if you
cannot exclude competitors from the marketplace.
You cannot be successful if you cannot force customers into a trap, basically.
And I really did not believe that because I saw so much potential gain for the industry
to be able to move forward without impediments, to my mind, any business whose success depended
on slowing things down, that was just a bad idea.
But it was very much counter the prevailing wisdom.
And so I began looking to a whole bunch of different industries to try to figure out
are there analogies which, if one were to understand them in a slightly different way,
they could justify that the software industry was also ripe for this transformation.
And one of the first ones I did seize on was this analogy with lawyers that the law is
not privileged information to which one needs a license.
Every precedent becomes public domain.
Yet the expertise that the lawyers have in knowing these precedents, arguing these precedents,
in having composed briefs that inform these precedents, that when you look at the difference
between the rates that are run on the middle of the lawyer can charge versus a top lobbyist
in Washington, DC, there's many, many orders of magnitude there.
And I saw an opportunity that basically said, hey, if we are more expert in being able
to adapt this software faster, apply it to a wider range of problems, et cetera, et cetera.
If we can help people move to the next field faster, then we should be able to write a ticket
based on the value that's open by that.
So that was one analogy, but there were some other analogies.
It's actually one of my favorite analogies.
Once I got the lawyer thing working, I then started thinking about banks.
One of my favorite analogies was, in the conventional world, a bank pays interest based on the amount
of money that's deposited.
Now this analogy may make absolutely no sense in 2014 where banks basically no longer pay
interest.
This is true.
Back in the day, back in the day in the 1980s, if you had a past book savings account,
you might expect to be paid for or 5% interest on your savings.
And if you were willing to commit it for longer, you could get even a better rate with a
certificate of deposit, which again today basically pays no interest.
But imagine a bank where no matter how much you deposit, the bank pays interest on the
sum total of all the assets to which you'd make the deposit to.
So if a whole bunch of my friends all put money into a communal bank account, and then we
all get paid, the total interest on that sum total, how attractive is that number one?
How attractive is it number two to go to a person who does not yet bank at that bank
and tell them, you know what, all you need is 10 bucks to open an account and you can
share in the interest on $250,000, how cool would that be?
And I began to see that that was the force multiplier of this free software ecosystem
and what later became known as the open source model, that by making small contributions
to this code, I became a member of a community which aggregated all their enhancements as
well.
And so I put in a little and I got back a lot and that seemed to me to be an outrageously
great trade.
And it seemed to everybody else that they were making a good trade too, you know, they
appreciated that Michael Teammate was handing them free compiler patches all the time.
So you found sickness in 1987 based on these ideas?
No.
In 1987, that was when I began the search for how it just started, in 1987, after really
convincing myself that this was the next big thing, I then sought to find an entrepreneur
who could found the business for me and I could be their first employee.
I wouldn't charge too much, but I would be a great worker, I'd be very dedicated and
I had this track record that I could now really trade upon.
It was, it was pretty exciting to see this reputation grow.
It was very exciting when at one point Richard Stolman came out to Stanford University
and we were talking about the hierarchy of programmers and I was paying a compliment
to somebody as being a potential wizard and Stolman called me a wizard and I just about
fell out of my chair.
But I could not find anybody who was willing to start a business around free software because
nobody could see how to exclude competitors.
We could see how to lock in customers and so for two years I struggled to find somebody
who was willing to think outside those boxes and I was simply unable to do so.
And then as I was relating these problems to a friend of mine who I happened upon in
the Stanford coffee shop in the student union as I began explaining to him how difficult
it was to find people who all agreed that this software was better than anything else
out there but similarly we're of the opinion that it would never work because nobody would
pay money for free software because I was explaining that I had this amazing epiphany
which is that if everybody thought the software was better it probably was and if nobody
thought the business would work I would have no competition.
And it was that insight that made me believe hey if I can start a company with no competition
how could I fail.
So you've got skepticism on coming at you in three different directions one for potential
customers, one from potential business partners and one from investors right.
So how can you recall at the time what some of those primary sticking points were from
those folks and you say that they're saying it's not going to work you can't exclude competitors
but is there any other points of skepticism these folks were really stuck on.
I think the real skepticism really was that because it had never been done before nobody believed
it could be done and so as soon as I had this insight and at the time I had enough money
in my bank account to make the mortgage and chip in to start a company which I believed
could go cash flow positive in time before my second rent payment.
Right.
Okay.
The great thing about starting a software company back then was that it cost almost nothing.
We had we bought a computer, we bought a telephone and then we started it in apartments.
In fact when I saw the movie The Social Network which is the story of Mark Zuckerberg
and Facebook, I had all these wicked flashbacks because apparently he started Facebook
basically in exactly the neighborhood that we started singin' back in the late 80s and
so I was intimately familiar with all those houses in Palo Alto and although we didn't
do any of the crazy stuff that they probably made up in the movie, it very much was something
that we grew very organically out of the apartments.
The original business plan called for the three founders to put in $5,000 a piece except
I didn't have $5,000, I don't know, $2,000 and so we started with an initial seed capital
of from three founders, $2,000 a piece for a total of $6,000 and in November of 1999
we negotiated with Red Hat a sale of the company for $687 million that closed in January
of 2000.
I don't want to get to that in a moment but talking about skepticism strikes me that I think
you've written about this before but I also hear this still ongoing today is this notion
of fragmentation right there's this assumption that you can't make a business on free software
you can't make a business on open source software because fragmentation is going to be a
persistent issue your platform is going to be so fragmented everybody's going to do their
own thing with the source code you're never going to be able to support it and you're
never going to be able to exert the kind of control you need to make a profit on the
product.
How did you overcome that and I think it persists today so how do you respond to that today?
Well with the benefit of hindsight what I have seen in many many cases both in the
free and open source world but also in the larger business community is that really the
key to success of an entrepreneurial business is having a vision you can execute and having
a vision that people really want to buy into because ultimately it benefits them comprehensively
it benefits not only their bottom line it solves not only their problem of the day but
it moves them forward in their life in some meaningful way and that could be up the career
ladder it could be saving the planet it could be doing a whole bunch other great things
but what I have sort of generalized from my experience is that a thing we did right
at Cygnus was by golly we built a kick ass software company there was a there was a point
in time where the VP of engineering came to me and said you know Michael I've just been
reviewing our contract deliverables over you know since I started keeping these records
about three four years ago what I have found is that in all these contract developments
remember doing custom contract software development is a complex thing right there's an industry
statistic that says 18% of all software projects are abandoned before they go into production
and 55% are either late sometimes very late missing key functionality or shipped with operational
defects that materially affect performance when you take that 18% that never ship right and the
55% that limp across the finish line you know missing an arm a leg or a head that's that's a pretty
miserable average statistic but here was ours we shipped 98.5% of all deliverables on time or
ahead of time and on budget or under budget when you read the risk report that shows the days of
risk of Red Hat Enterprise Linux and you look at how well we function in this increasingly challenging
security context and you look at how good we are at patching holes before they're publicly
disclosed right or patching holes you know in very very short amount of time if it's a zero day
exploit it's also it's a stellar stellar metric when you look at how how well defended the Linux
kernel is against mischief because of comprehensive work we've done at the runtime level at the
kernel level you know at the system level etc that again is super high quality but going back to
sickness by creating basically a perfect reputation right all these theoretical skeptical arguments
simply go by the wayside and you know people would say well you know sickness once once we started
the company and we started delivering this it well that's all well and good but you know wait
wait a Michael team and can no longer program you know because he's spending too much time selling
and managing and your whole thing is going to fall apart because there are no more Michael teammates
bullshit yeah there are so many great young talents ready to do amazing things when they can
find the right environment when they can find the right mentors you know and when they've got
enough field in front of them and they can turn on the afterburners and see what they can really do
and we recruited a lot of those people at sickness a lot of them are still here at Red Hat you know
we have a number of people who's whose years of service exceed you know the the time that Red
Hat has been in business because they got credit for their for their days at sickness so I what
I would say is that a lot of the skepticism is is a response to the abstract it's a response to
the unknown and when you bring a concrete success story with just absolutely stellar credentials
that that doesn't just outperform the field but embarrasses the field then then the skeptics begin
to look like they're on the wrong side so this is a great this is a great segue to what I wanted
to ask about next and that is the notion of competition in an open source market right so you've
written before about the nature of competition in open source and free software is different from
the nature of competition perhaps in other markets because it's not a zero sum game you've
described it and I really like this image as a sort of mobius strip right where value is always
flowing between different parties and it's never a zero sum game some morning if you could elaborate
on that or just rearticulate that because I think that's a really interesting point I think our
listeners especially would find that interesting yeah so and and let me let me preface this and I
don't want to sound arrogant by saying this but I believe it to be true you know it is easy to talk
about the positive sum gain yeah when so much is going in your direction right okay yeah you know
so I will I will be the first to say that I have enjoyed seeing the open source community developed
from a very privileged position that sickness had years of consistent growth their red had has
enjoyed years of consistent growth our ability to execute at both of those companies has been
phenomenal and I believe that a lot of the open source business value accrues to to those who
have been successful so we just get that out of the way but let me also say that there are there
are many who have tried to bring the zero sum game concepts to the open source community they
want to wall off some piece of technology at least from a positioning point of view they want
they want to force everybody into that particular world view and a lot of folks have found themselves
really really struggling by trying to be the Microsoft of X yeah where which of course doesn't
really have a valid place in in an open source world but that being said I read a book in 2005
which I recommend to everybody it's called the only sustainable edge by John Hagle and John
C. Lee Brown and although it never mentions open source by name or even implies it they tell
story after story of companies who successfully transformed their business by shifting from the
paradigm of the zero sum game to the paradigm of the positive sum game and to me the most compelling
story in that book is a story of Lee and Fung which is which was in the 1970s a textile
manufacturer in Hong Kong like 10,000 other textile manufacturers and they made the paradigmatic leap
from looking at competition as a zero sum game to looking at all of their competitors
as potential complimentary assets and more importantly and this was the key insight for their
company they saw themselves as a potential complimentary asset to their competitors and one by
one as they would lose a deal here or a deal there they would ask themselves the question if we
had been working with the competitor who won this deal instead of against them how much how could
we have done better and step by step they began building new systems new relationships and in the
book they talk about how 5,000 employees of Lee and Fung now manage 7,500 relationships with
other Asian textile manufacturers and they do 5 billion dollars a year in revenue which if you do
the math means that as a former textile company this company does a million dollars per employee
in revenue which by any measure is one of the highest revenue per employees I know of in the whole
S&P 500 it is miles ahead of probably at least 90% of that market and and they got there by
recognizing this idea of how do we make ourselves a complimentary asset and in a lot of ways the
open source community is in a perfect position to ask and answer that question how can we help
company X build a better airplane or how can we help company Y build a better factory or how can
we help companies eat create a better website or you name it so you talked a little bit about
in your response there you said about sort of creating a position of value creating a sort of
you said value accrues to those who are in successful positions so becoming successful
looks different in an open source market right becoming successful becomes more about what you
enable as opposed to what you can withhold right and it becomes more about how you can maintain
a standard right that's right as opposed to how you can monopolize something that's a big
good summary that's a great summary and another another book that I recommend to everybody is a book
called Switch by Chip and Dan Heath what I did not realize when I started sickness was that you
can't simply be different and expect to be successful if you are different enough than the status
quo you must change the status quo to be successful and Switch is all about managing that change
especially when that change is hard and and to your point about success again when I started
sickness the general measure of success which was typified by Bill Gates was your wealth
is a proxy for your intelligence your wealth is a proxy for your success and whenever Bill Gates
I went to some CEO conferences back when he was a CEO of Microsoft and he would spout all kinds
of theories about all kinds of stuff I thought was pretty much nonsense and from time to time
the press would call him on it and say well we think that's not true and Bill Gates would
gleefully say all right short the stock yeah daring them right right and and and because
Microsoft stock at that time was always on an upward trend yeah everybody sort of treated that
as the final death of argument right and and going back to how open source changes things
it's not it's not just whether we deliver on time and on budget it's not just whether or not
this particular thing works or not but changing how the customers think about and use software
to reach things that they previously may not have even imagined right and to give credit for
this dynamic flexible evolutionary software platform for being that ticket to the next level
and so getting people to understand the transformational capacity of open source was very much
part of maintaining success with these customers so 10 years after sickness incorporates
in 1989 it's 1999 and sickness merges with Red Hat yeah do you remember when those discussions
began and how speaking of value and success how both parties in that deal discuss the mutual benefit
or value that each could add to the other and what that merger meant for both companies yeah so
you've probably heard the expression no plans survives first contact with the enemy
okay and and the same may also be you know the set of business bedfellows as well I think that our
our conversations about the theories of mutual benefit ahead of time were paled in comparison
to the actual benefits that we derived but the facts are these Red Hat what sorry sickness was
the first company that venture capitalists invested in and we sort of taught the venture
capital community the the play yeah and and and I believe that Red Hat may have been the second
such company to receive a major investment from from Greylock but we were the first
and as a result of that investment the venture capitalists got substantial stakes in in both
companies and and and they began to sort of look for what their exits would be because venture
capitalists put money in in order to get 10 to 40 times that amount of money out that's their that's
their general goal and with respect to sickness the challenge that we had was that as successful as
we were in the tools space the total market opportunity of tools is just not as big as the total
market opportunity of operating systems yeah because operating systems really lead to platforms
and that's the big play and sickness missed its opportunity to get into the platform space
back in 1995 somebody had told me about this little company in North Carolina called Red Hat
which had just grown from five to fifteen employees and was it was doing Linux far better than
any of the other myriad companies also commercializing and selling Linux distributions and I was
impressed enough to try to convince my co-founders that we should take 10% of our equity and buy Red Hat
but they thought that was a waste of time and then five years later Red Hat took 10% of their
equity and bought us so so there was that but the the the the opportunities that became clear
sort of immediately after the the deal was consummated was that the sickness sales team
and the sickness engineers were very very comfortable building multi-year multi-million dollar
relationships with customers you know our our normal entry price was about six hundred thousand
dollars to to do a tool chain and and and then we also had some larger customers who would do
six million dollar deals Red Hat at that time was selling hats and t-shirts and Linux distributions
at best buy for seventy nine dollars and so Red Hat knew how to be super popular Red Hat had
more of a national brand than we did but other than other than relationships with IBM and Dell
and a couple of other companies Red Hat really did not know how to build a customer relationship
at the enterprise level and so we had this great cross pollination exercise I remember overseeing
one of these first sales integration meetings where all the signal sales guys were just
so eager to sell something so hot as Linux and all the Red Hat sales people were so eager to learn
how to sell multi hundred thousand dollar you know right enterprise support agreements and not
long after that merger we began the path of creating the world's first enterprise Linux and
enterprise Linux it's obviously it's a term you could apply to anything I mean marketing
guys will stick lipstick kind of big if they think that's what makes it prettier but
the reality is and I think history shows Red Hat did do a very legitimate job of building a
platform that had the right impedance match to the enterprise market we had the applications
support we had certifications we had a great training program that went along with it
and and and we really quickly grabbed the enterprise Linux market and then grew that market pretty
much as fast as it could be grown given how slow moving a lot of enterprise evolution actually is
right right so the merger happens you become what is it CTO CTO yeah Red Hat okay and in a few years
there's a there's a lot of change as new you know the company makes new strategic directions you
move into enterprise you know Red Hat Enterprise Linux becomes real and sort of Spadora there's a lot
of new strategic directions happening what's your day-to-day like around that time what are you
working most most heavily on at that point well around that time what we're really doing is we're
building reference customers that we're gonna that we're going to help us win the industry so
I was meeting with CIOs of Morgan Stanley and Lehman Brothers and Bear Stearns and Goldman Sachs
okay Merrill Lynch and and we were we were listening to understand what enterprise really meant
to them we were explaining what we really felt we could do and we were we're negotiating those
partnerships with a whole bunch of vendors who at that time would have been delighted to see us
actually go away yeah yeah but but we had an amazing amazing value proposition which was to
deliver the full power and efficiency of an Intel processor that by that time had completely
lapt the spark risk processor I mean we one of the reasons that customers were so willing to
move to Linux is that the Sun platform had simply run out of gas okay these these main frame style
machines had performance caps that were too low for the next generations that these banks wanted to
build and a horizontal scale out strategy trumped the scale up strategy that Sun had adopted the
cost profile was dramatically lower but even the susceptibility to improvements the the ability
to incrementally and rapidly change technologies was very very appealing to an industry that was
really chasing at the bit to to roll forward and they they had they had been happy with Sun but
they had become very dissatisfied and and we were there to pick up this like and nobody else
you know as much as they didn't like what Sun was doing nobody else in the whole market was doing
anything better yeah it was kind of a real Confederacy of DUNCES at the time and along comes
enterprise Linux some really really brilliant engineering from Red Hat from some other people
uh working on the kernel and and we were able to demonstrate performance capabilities that
just lit up the sky we you use the term innovation a couple times and that term can get pretty
buzzy get pretty vapid really quickly but you've also written extensively about the way that
innovation the character of innovation in in open source markets and in open under open source
models and sort of the motor of innovation when things are done the open source way can you
can you elaborate a little bit on the nature of innovation in open source business well uh so I think
it was Plato who said that necessity is the mother of innovation and I think that one of the things
that had really come to be devil the proprietary software industry is that people had simply
claimed far larger territories than they were willing to cultivate let alone you know they were
willing to defend the territories but they were not willing to cultivate those territories and so
to give you some examples there was a there was a time when people were looking for
building far more scalable systems than could be built out of proprietary risk architectures
and there were lots of different theories about how this could be done the great thing about
open sources we could put all those different theories into competition uh and those competitions
could allow any kind of team configuration to be built so it might be that somebody who was
developing an application of Goldman Sachs would hop on and join a given kernel team
that would that was going and pursuing a particular kind of multi-process or multi-threaded or
you know multi-programming system a different person has a different theory they join a different
team and one of the things that has been great about the way that Lena's Torvales has managed all
this is he truly has upheld this idea that the that the best ideas went he he really has
he has he has often been difficult to work with he often you know
reminds the world he's just an asshole but when a really really good solution shows up
he'll bump he'll he'll merge it in he'll bump that version number and we're and we're off to
the races and what I would say is that at that time when a company would basically say well you know
we own enterprise storage but we're not going to do this thing you want for five years because
you know it's not really correct it's it's all well and good for a company to say we're not
going to do it but it's no good at all to say and you can't yeah yeah and that's really what
open source is all about we you know numerous times during that period and since we've we've
even heard from Lena's himself saying we're never going to do that that's stupid that's ridiculous
get it out of here and then a couple of years later after after there's some some some some more time
with the idea and whatnot all of a sudden wow that's it's it's it's in the mainstream works yeah
yeah yeah you you're obviously able to glimpse this these insights very early and it sets you
up for success very early and you are able to become a sort of open source visionary and open source
evangelist very rapidly and for a number of years you've written and spoken about the power of
open source thinking open source methodologies the open source way I'm wondering if there's
ever a time that open source has disappointed you well for sure yes I try and think of some some
good illustrative examples I think that often when I was president of the open source initiative
we spent an extraordinary and I think sometimes excessive amount of time obsessing about
licensing in ways that were not necessarily all that productive one of the early ideas
that came out of the open source initiative before I joined was this idea that you know we need
to have a lot of different licenses to be able to choose which one is best okay so there's
this idea that having a lot of different licenses would would let us choose the best one and that is
a fine theoretical argument but the Mozilla public license generated dozens of mutually incompatible
licenses that really took a long time to untangle so it there there there there became sort of two
conversations that were constantly going on simultaneously the first was what is open source
and many many clever lawyers or clever programmers who are lawyer wannabes yeah we're trying to
figure how do I get just up to the edge of an open source allows on the theory that the closer you
got to the edge the better the solution would be because open source somehow is weak at the center
yeah you know which is a bizarre bizarre idea but anyway so the what is open source and the second
thing is how can I make my open source thing different than everybody else so I can prove that
I'm the smartest one and this would this would lead to a lot of of infighting or lack of
cooperation that I think was very that that was ultimately detrimental but I have seen lately I
saw a post just this past week saying that we live in a post open source world yeah and the premise
of the post the premise of the post is that with GitHub becoming a super major repository for new
open source development the some substantial percentage of code is being checked in with no
license whatsoever and so one way to read that is hey it could be licensed under any license
another way to read it is hey it's public domain another way to read it is hey all this code is a
potential feature liability that's right yep and it's and it's a big mess and one of the one of the
ideas the open source initiative was to was to make open source a safe choice to make it be
something that was well enough defined as you knew what it was you knew what you could do with it
and you knew who you could trust yeah and to have so much code being developed with no license
with no developer origin of you know a certification or anything like that it plays into many of
the fears that existed back when I was starting and we addressed those fears by being upfront
by being not only transparent but also really standing for something very specific and
and the transparency of GitHub is great yeah but the but the nebulousness of no license
is a big problem so so those are those are some things that are that are on my mind
I would say that it also has been somewhat frustrating that from time to time major players
decide that that they want to stop and turn the game into a zero sum game and it is it is
frustrating because it slows progress down for for everybody the way that some vendors have
decided to try to compete on price number one which is a good way of keeping everybody honest
but then to also put into their competitive terms and oh by the way if you use the other guy's
stuff then right right we're we're not going to sell all the rest of the stuff you depend on
so so people are using I think very traditional anti-competitive tactics against against open source
which is which is again very unhelpful yeah and and there's not a there's not a whole lot of
leverage that one happens if you if you take a step back and just look at some some big time
geopolitical problems that exist right now while it may be super courageous for a party and one
of those big fights to simply turn the other cheek you know and to and to bring peace by simply
not fighting back you you wonder just you know how many people can you can you stand and watch
getting killed before you realize or before you decide that that may not be a good strategy
and in the world of open source you know on a on a on a much more concrete layer
and and and not involve a human life but just you know the success of a given business when
when open source does not have the kind of market power that many of these proprietary guys have
and that should be a great advantage but it can be turned around to be a a disadvantage and
and the only you know the the question that always resonates in my mind is the is the question
that Abraham Lincoln asked about you know can our better angels really arise and and so far
what encourages me is is that there is a lot of positive energy from both the younger people
getting into open source as well as the older people who have seen the generational ebb and flow
of proprietary versus open systems and I think that they that there still are a lot of people
who are not as interested in seeing what can be destroyed as they are and seeing what can be built
well I'm really glad you brought up Abraham Lincoln in that last response because it allows me
to ask my final question which is a rather selfish question because it's something I've always
been curious about in your writing and now that I've had this conversation with you also in your
speech you pepper your pros with maxims with rotations from historical figures authors
popular figures and that's always struck me as an interesting sort of video synchrosy in your
in your writing in your explanation your mode of explanation and an explication and I'm wondering
if that stems at all from your pension for open source right the notion that there's eloquence in
the simplistic there there's beauty in the shortest solution to the realization of insight
or if it's if it's more about your tendency to do that is more about building on the ideas and
the work of others that's a great question any eloquence is entirely accidental okay the E
word that I would look for is evidence so because of my background in science I think that being
able to look at analogous situations and to and to sort of you know validly argue similarities
similar cause and effect mechanisms similar properties of state or motion that those those help
to discern whether the the effect being presently observed is is something that can be observed as
it more of a rule of nature or some special case earlier in this conversation I talked about how
you know people after after the initial success of sickness the the the next premise of demise
was well as soon as Michael team and stops programming then the whole thing's going to fall apart
and of course that didn't happen we know from history that it didn't happen but at that moment in time
how do we know that this whole enterprise is not really built on underpricing the you know the
product of one hacker versus being able to build a sustainable model and so from my perspective it
is important to not only be able to show here is something that's happening right now
and is real but to also reference other to reference the best analogies that we can find
not just best in terms of supporting the argument but best in terms of of really showing that the
argument is really meaningful is is really general and applies beyond the question of are you really
going to provide seven by twenty four support right you know are you really going to honor your
SLA when you when you do all this stuff and at the end of the day it is a question I'm sure keeps
our our support team up in night how do we meet the SLA right how do we make sure that the
customers are happy and want to do but a lot of you know to my mind what really makes that happen
is is the ability of the team the department the business unit the company to all be working on
some larger page which by the way includes the tens or hundreds of thousands or perhaps millions
of other contributors who are all part of that ecosystem making stuff work so that our credit is
good no matter where we go whether we're you know working deep in some defense installation or
whether we're working you know in some research lab cracking you know bosons and mesons everything
like that or or whether we are you know simply setting up an infer an intranet for some major college
campus the the ability to to to make work what we have been able to make work which continuously
requires the participation of a larger community that's that's what it's all about and I reference
these other moments of history or these other bits of sage advice because
people understand how those quotations applied to other great movements and and how they
applied to the more significant parts of our humanity right then those that decide on vendor
excerpt right right product excerpt product why it reminds me of another thing I think you once
wrote is that you differentiate your thinking on open source and free software from from folks who
think about it differently I'll just use one example it might be arbitrary but I think you've
been voted before you said folks some folks who champion free software like Richard Stahlman for
example will make the case for open source and free software on philosophical or ideological grounds
but it strikes me that you almost see open sources almost a force of nature or some kind of
universal tendency that is bigger than I don't want to say mere ideology but it's not just a world
view I am I am very very happy that those two can coexist you know I think it's it I think it's a
terrible dilemma right when one's you know where where one's ethical worldview is a direct conflict
with actual survival yes I mean it's it's great to see a movie about what kind of choices
somebody's gonna make yeah yeah between saving their girlfriend or rebooting the computer
but but honestly speaking I do believe that these two can operate in concert and I I support and
honor those who lift up the ethical behavior of free software right but I also respect and support
those who are who are making pragmatic progress making practical progress by applying these to
the day-to-day business Michael team and thank you so much for speaking with us today it's
going to be a real honor and a real pleasure thank you
you've been listening to Hacker Public Radio at Hacker Public Radio dot org
we are a community podcast network that releases shows every weekday Monday through Friday
today's show like all our shows was contributed by an HBR listener like yourself
if you ever thought of recording a podcast then click on our contribute link to find out
how easy it really is Hacker Public Radio was founded by the digital dog pound and the
infonomicum computer club and it's part of the binary revolution at binrev.com if you have
comments on today's show please email the host directly leave a comment on the website or record
a follow-up episode yourself unless otherwise status today's show is released on the creative
comments attribution share a light 3.0 license