Incompatibilities between Incompatibilities between patenting and distributed patenting and distributed

software inventingsoftware inventing

Eric von Hippel

MIT Sloan School of Management Phone: (617) 253-7155, Email: Evhippel@mit.edu,

http://mit.edu/evhippel/www

Outline of my talkOutline of my talk

Rapid, collaborative work with ad-hoc contributors and much Rapid, collaborative work with ad-hoc contributors and much information reuse is a better way to invent in the Internet age. information reuse is a better way to invent in the Internet age.

In my view ad hoc distributed invention is NOT a good fit to the In my view ad hoc distributed invention is NOT a good fit to the practical realities of patenting (eager to hear YOUR view!).practical realities of patenting (eager to hear YOUR view!).

Market pressure towards invention efficiency means that patent-Market pressure towards invention efficiency means that patent-relevant inventing conditions will only persist in niches like relevant inventing conditions will only persist in niches like pharma (and sunshine will therefore return to the earth… :)pharma (and sunshine will therefore return to the earth… :)

The core activity of invention is problem-solvingThe core activity of invention is problem-solvingProblem solving is carried out viaProblem solving is carried out via

“directed” trial and error “directed” trial and error

Design

Build

Run

Analyze

Done

• Design a possible solution

• Develop models prototypes

• Test model/prototype In real or simulated use environment

• Analyze findings previous step

Distribution of invention development across Distribution of invention development across many contributors is increasingly efficient in many contributors is increasingly efficient in our Internet age – because search and our Internet age – because search and interaction is getting steadily cheaper…interaction is getting steadily cheaper…

“ “Given enough eyeballs, all bugs are shallow.”Given enough eyeballs, all bugs are shallow.”- Linus’ Law (Eric Raymond, - Linus’ Law (Eric Raymond,

1999)1999)

““Given a large enough beta tester and co-developer Given a large enough beta tester and co-developer base, almost every problem will be characterized base, almost every problem will be characterized quickly and the fix obvious to someone… Each [user] quickly and the fix obvious to someone… Each [user] approaches the task of bug characterization with a approaches the task of bug characterization with a slightly different perceptual set and analytical toolkit, a slightly different perceptual set and analytical toolkit, a different angle on the problem. So adding more beta-different angle on the problem. So adding more beta-testers . . . increases the probability that someone’s testers . . . increases the probability that someone’s toolkit will be matched to the problem in such a way toolkit will be matched to the problem in such a way that the bug is shallow to that the bug is shallow to that personthat person.”.”

Software innovation is at the leading edge Software innovation is at the leading edge of the trend towards distributed inventionof the trend towards distributed invention

Consider the invention process culminating in a new software Consider the invention process culminating in a new software feature in the PostgreSQL Community – “intelligent” data feature in the PostgreSQL Community – “intelligent” data vacuuming. vacuuming. (Voted the most useful new feature in Release 7.4)(Voted the most useful new feature in Release 7.4)

M. Weilguni (Germany)Outlines vacuum problem with

very large databasesProposes “simple” solution

(Bit field in tables)

9/3/2002

Example source: Karim LakhaniExample source: Karim Lakhani

- 6 -

The Sept 3 message from Mario that starts things off The Sept 3 message from Mario that starts things off

Mario Weilguni (periphery) outlines a problem that he faces with database vacuuming (Sept 3, 2002)

I know everyone is busy with the 7.3beta, but maybe this is something to think of before releasing the beta. Currently VACUUM will vacuum every table, but sometimes it's desireable to leave tables untouched because the're mostly static or protocol tables. In my case this would be the pg_largeobject which is around 4GB of data, while the other tables are ~40MB. Vacuuming the data is important, the large object table however rarely changes. The same goes for a protocol table which is around 1GB and never is changed beside INSERTS, so it's just growing, but never needs vacuum. VACUUM on the 4GB table needs a long long time and no improvements, it just hurts performance and fills OS buffers.

If pg_class would have a field for storing misc flags (e.g. a bitfield). This would allow to set a flag like NO_AUTO_VACUUM and modify the vacuum code to leave that tables untouched if not specified by hand. Maybe there are other uses for such a bitfield too, and will help prevent an initdb for simple improvements. Any comments? Best regards, Mario Weilguni

M. Weilguni (Germany)Outlines vacuum problem with

very large databasesProposes “simple” solution

(Bit field in tables)

9/3/2002

S. Daithankar (India)

Proposes alternative solution(Usage,Triggers,Threads)

9/3/2002

M. WeilguniS.D. proposal not practical

for his situation

9/3/2002

R.Taylor (Canada)M.W is mistaken

Provides sample script for S.D proposal

9/3/2002

T. Lane (USA)Acknowledges problemCalls it: “auto vaccum”

Proposes server implementation

9/3/2002

S. DaithankarAnnounces intention to create solution

Provides details on his approach - asks for feedback

(Usage,Triggers,Threads)

9/3/2002

Others – typically users of PostgreSQL “at the periphery” of the community (not core members) - quickly start to respondand to collaboratively build a solution

On the left is the mail sent the same day in response to Mario’s suggestion

- 8 -

Contributions to the “invention” that results come from Contributions to the “invention” that results come from many sources…many sources…

Sounds like a nice idea. I would do that by this week end, once I finalise the details about it. Give me couple of days to finish it. Will come back soon with that..

7 hours later...

OK, I plan to work on this. Here is my brief idea 1)Create a table (vacuum_info) that stores table name and auto vacuum defaults. Since I am planning this in contrib, I would not touch pg_class. <snip> I need to know the following.. 1)Is this sounds like a workable solution? 2)Is this as simple as I have put here or am I missing some vital components? 3)Is there some kind of rework involved? 4)Is use of threads sounds portable enough?<snip> 6)such a 'daemon' would be on per back-end basis if I am guessing correctly. Would locking things in transactions for vacuum_info be sufficient? I hope I am making a sensible proposal/design(My first attempt to contribute to postgres). Please let me know your comments. Bye Shridhar

Shridhar Dahitankar (periphery) announces that he is going to work on this but needs some information (Sept 3, 2002)

M. Weilguni (Germany)Outlines vacuum problem with

very large databasesProposes “simple” solution

(Bit field in tables)

9/3/2002

S. Daithankar (India)Proposes alternative solution

(Usage,Triggers,Threads)

9/3/2002

M. WeilguniS.D. proposal not practical

for his situation

9/3/2002

R.Taylor (Canada)M.W is mistaken

Provides sample script for S.D proposal

9/3/2002

T. Lane (USA)Acknowledges problemCalls it: “auto vaccum”

Proposes server implementation

9/3/2002

S. DaithankarAnnounces intention to cerate solution

Provides details on his approach - asks for feedback

(Usage,Triggers,Threads)

9/3/2002

T. LaneS.D’s approach will never work(Use Free Space Map(FSM)

in server instead)

9/3/2002

R.TaylorProposes an additional

component to T.L’s ideas(Use DB Analyze)

9/3/2002

T. LaneGood idea! - Interesting

implications for performance

9/3/2002

B.Lind (USA)Proposes new design

(Partial vacuum only - createDirty Space Map?)

9/3/2002

M. WeilguniProposes using “Stats Collector” (already in PG) instead of FSM

Provides URL to show sample output

(Use Stats Collector)

9/3/2002

T. LaneStats Collector approach

is also good(Has questions on details)

9/3/2002

M. O’Connor (USA)Announces intention to

create solutionAnswers T.L’s quesitons

(Stats Collector)

9/3/2002

- 10 -

Contributions to the “invention” that results come from Contributions to the “invention” that results come from many sources…many sources…

Shridhar Dahitankar – announces that the code is ready based on prior discussion (Sept 23, 2002)

Hello All, I have written a small daemon that can automatically vacuum PostgreSQL database, depending upon activity per table. It sits on top of postgres statistics collector. The postgres installation should have per row statistics collection enabled. Features are, * Vacuuming based on activity on the table * Per table vacuum. So only heavily updated tables are vacuumed. * multiple databases supported * Performs 'vacuum analyze' only, so it will not block the database The project location is http://gborg.postgresql.org/project/pgavd/projdisplay.php Let me know for bugs/improvements and comments.. I am sure real world postgres installations has some sort of scripts doing similar thing. This is an attempt to provide a generic interface to periodic vacuum. Bye

- 11 -

Contributions to the “invention” that results come from Contributions to the “invention” that results come from many sources…many sources…

Matthew O’Connor asks Shridhar some coding questions (September 24, 2002)

Matthew: Hello Shridhar, sorry I didn't respond to the email you sent me a while back. > Anyway, I saw this post, and just started taking a look a it. I wasn't > thinking of doing this as a totally separate executable / code base, but > perhaps that has advantages I need to think more. > > A couple of quick questions, you are using C++, but all postgres source code > is in C, do you want this to eventually be included as part of the postgres > distribution? If so, I think that C might be a better choice.

Well, I wrote it in C++ because I like it. I have lost habit of writing pure C code. Nothing else. <snip> It enjoys all the isolation provided by postgresql. <snip> Less code, less bugs is my thinking. I wanted this functionality out fast. I didn't want to invest in learning postgresql source code because I didn't have time. So I wrote a separate app. <snip>. I am Cc'ing this to Hackers because I am sure some people might have same doubts. Bye Shridhar

Invention is complete and effectiveness is Invention is complete and effectiveness is demonstrated less than 2 months from the first demonstrated less than 2 months from the first message on the need for improved data vacuumingmessage on the need for improved data vacuuming

Matthew O’Connor announces a “new & improved” version of Shridhar’s code (November 26, 2002)

M. Weilguni (Germany)Outlines vacuum problem with

very large databasesProposes “simple” solution

(Bit field in tables)

9/3/2002

S. Daithankar (India)Proposes alternative solution

(Usage,Triggers,Threads)

9/3/2002

M. WeilguniS.D. proposal not practical

for his situation

9/3/2002

R.Taylor (Canada)M.W is mistaken

Provides sample script for S.D proposal

9/3/2002

T. Lane (USA)Acknowledges problemCalls it: “auto vaccum”

Proposes server implementation

9/3/2002

S. DaithankarAnnounces intention to cerate solution

Provides details on his approach - asks for feedback

(Usage,Triggers,Threads)

9/3/2002

T. LaneS.D’s approach will never work(Use Free Space Map(FSM)

in server instead)

9/3/2002

R.TaylorProposes an additional

component to T.L’s ideas(Use DB Analyze)

9/3/2002

T. LaneGood idea! - Interesting

implications for performance

9/3/2002

B.Lind (USA)Proposes new design

(Partial vacuum only - createDirty Space Map?)

9/3/2002

M. WeilguniProposes using “Stats Collector” (already in PG) instead of FSM

Provides URL to show sample output

(Use Stats Collector)

9/3/2002

T. LaneStats Collector approach

is also good(Has questions on details)

9/3/2002

M. O’Connor (USA)Announces intention to

create solutionAnswers T.L’s quesitons

(Stats Collector)

9/3/2002

S. DaithankarAnnounces solution is ready

Based on:Stats Collector and Table Activity

DB AnalyzeClient daemon - not server based(Abandoned previous approach)

9/23/2002

S. DaithankarPosts questions from M.O

on his approach+ his answers

9/24/2002

M. WeilguniFinds issues with S.D’s

implementation

9/24/2002

M. O’ConnorAnnounces new solution based on SD submission

Similar to S.D.’s client daemon design

Written in C instead of C++(Abandoned previous approach)

11/26/2002

M. O’ConnorSubmits V3 based on

feedback from developers

3/11/2003

M. Neusland (Germany)“I have been using S.D’s code in

Production for months!”

2/11/2003

M. O’ConnorSubmits V2 based on

feedback from developers

2/11/2003

B. Momjian (USA)

Commits code to repository - now official part of PG

3/20/2003

S. DaithankarThanks for doing the work!

11/26/2002

A total of 23 people contributed to this development – 4 core, 19 “ad hoc”

3 Coders (Periphery), 1 Reviewer (Periphery), 2 Testers (Periphery), 17 Discussants (13 Periphery)

Auto Vacuum Voted “Best New Feature” in 7.4 PostGres Release

Open - distributed innovation will Open - distributed innovation will probablyprobably be be proven faster / better than protected - internalproven faster / better than protected - internal

-- Ned Gulley, Mathworks, Karim Lakhani Ned Gulley, Mathworks, Karim Lakhani and Eric von Hippel, MIT and Eric von Hippel, MIT research in progressresearch in progress

# of usersperceiving need

TimeTime

Traditional, Manufacturer-Centered Innovation ParadigmManufacturers identify user needs, develop products at private expense,And profit by protecting and selling what they have developed.

User-Centered (Democratized) Innovation ParadigmLead Users innovate to solve their own needs at private expense - and then freely reveal their innovations

Users innovate here

First manufacturer product appears here

Target Market

Industrial products  n  % innovating

Printed Circuit CAD Urban and vH

136 24.3%

Pipe Hanger Hardware Herstatt and vH

74 36%

Library IT Systems Morrison, Roberts, vH

102 26%

Software security features Franke and vH

131 19.1%

Surgical Equipment Luthje

262 22%

Consumer products  n  % innovating

Outdoor Products Luthje

153 9.8%

“Extreme” sports equipment Franke & Shah

197 37.8%

Mountain biking equipment Luthje, Herstatt, vH

291 19.2%

The pattern of “distributed invention” extends far beyond software

Users will collaboratively innovate without Users will collaboratively innovate without “product / patent owner” permission“product / patent owner” permission

The brain• Computer “brain” within Lego

brick

Movement• 3 stepper motors

Sensors• Light• Touch• Temperature

Teaching• Kid-friendly, graphical

programming environment• Programs downloaded from

PC via infrared

Price ~ $200Source: Karim Lakhani and BCG team

Mindstorms robot kit

Lego mindstorms user communities grew rapidlyLego mindstorms user communities grew rapidly- without company involvement- without company involvement

Robots become widely available

August 1998

800

700

600

500

400

300

200

900

Nov1997

Jun1998

Feb1999

Oct1999

Jun2000

Jan2001

Aug2001

Apr2002

100

Lego robots announced

January 1998

(1) Lego Users Group NETwork. An independent discussion site for Lego enthusiasts Source: Russel Nelson, administrator of lego-robotics (russnelson.com)

Members

Within 3 weeksWithin 3 weeks of commercial introduction of of commercial introduction of Lego Mindstorms system, Lego Mindstorms system, users had improved it significantlyusers had improved it significantly

The rules

Robots follow 7 meter “track” of tape• Light sensors detect tape • Internal software tells robot how to

move

Fastest time around track wins

About one dozen participants

The results

Winner (below left)• Used hacker-developed LegOS

software• Time under 10 seconds (73 cm/s)

Second place (below right) • Used program based on LEGO

firmware• Time of 25 seconds (28 cm/s)

Ability to rapidly sample sensors was key

Source: Karim Lakhani and BCG team

Lego firmwareSource: Italian Lego Users Group (http://www.itlug.org/). Contact Mario Ferrari [mario.ferrari@edis.it]

Mindstorm sales greatly surpassed Lego Mindstorm sales greatly surpassed Lego expectationsexpectations

0102030405060708090

100

Tota

l Leg

oSal

es

Min

dst

orm

sSal

es Expectedbeforerelease

$905 million(2) $20 million

Sales in 1998(1) Adults drove increased sales

70% of customers over age 18• Craze among “techie” adults• Silicon valley firms forced to ban Lego’s

at work

Online communities accelerated purchasing

Lego unable to keep up with demand• Sold out 2 weeks before Christmas 1998

Major universities built curriculum around Lego

• Hacker software allows advanced robotics using Lego’s hardware

• MIT, Duke among campuses using Mindstorms

(1) First year toys were offered(2) Lego sales include theme parks, retail outlets and other non-core businessesSource: Business 2.0, BCG Analysis

%

Realized

Source: Karim Lakhani and BCG team

“There was almost a full year without a word from Lego: Neither acknowledgement of what was going on, nor threats towards the hackers.”

-David Baum, Lego Hacker

-“Lego executives simply didn’t know what to do...”

-Internal Lego Executive

“There was almost a full year without a word from Lego: Neither acknowledgement of what was going on, nor threats towards the hackers.”

-David Baum, Lego Hacker

-“Lego executives simply didn’t know what to do...”

-Internal Lego Executive

Lego was not sure how to respond Lego was not sure how to respond - for - for several yearsseveral years

Source: BCG interviews

There are ~ 200 internal R&D people at Lego. There are ~ 200 internal R&D people at Lego. There are There are 20,000+20,000+ AFOL’s – many innovate. AFOL’s – many innovate. More Lego-related R&D More Lego-related R&D outsideoutside Lego than inside? Lego than inside?

Official ILTCO website

News groups

Localusergroups

DK

IsraelChile

US

DearLEGO

FAQ

Off topic

…

Castle clubs/

organizations

ILTCO:International

LEGO Train Club Organization

Space

TrainOrganizations

EJLTC

FGLTC

…

GLUG: The Game-

LEGO Users Group

BrickWars

Starship

Yahoo!Group

Yahoo!Group

Yahoo!Group

Everything LEGO

Educa-tional

Marketplace

Informa-tional

Robotics

…

……

…

…

…

…

…

…

…

……

500

links

Yahoo!Group

Yahoo!Group

NELUG

Source, Yun Mi Antorini

It pays for users to innovate It pays for users to innovate collaboratively in collaboratively in communitiescommunities and freely reveal their IP and freely reveal their IP

Innovating users quickly form communities and freely Innovating users quickly form communities and freely reveal their innovations – because it pays.reveal their innovations – because it pays.

– Each has a DIFFERENT low-cost innovation niche.Each has a DIFFERENT low-cost innovation niche.

– Each gains private profit from in-house use of their Each gains private profit from in-house use of their innovation – a competitor can’t take that away from innovation – a competitor can’t take that away from them. them.

– Users can benefit from others improving their innovation Users can benefit from others improving their innovation and free revealing in turn – or from manufacturers and free revealing in turn – or from manufacturers selling a better commercial version to themselling a better commercial version to them

# of usersperceiving need

Time

Users IN COMMUNITIES can innovate more cheaply here

Manufacturers can innovate more cheaply here

Time

Free revealing is essential to make user-centered Free revealing is essential to make user-centered innovation an economically-efficient solutioninnovation an economically-efficient solution

Free revealing Free revealing makes economic sensemakes economic sense for for participants in distributed inventionparticipants in distributed invention

It is typically It is typically not practicalnot practical for user innovators to protect for user innovators to protect their innovations as intellectual property and license their innovations as intellectual property and license them. (But some may turn into manufacturers and them. (But some may turn into manufacturers and benefit that way).benefit that way).

So the real choice facing user-innovators is typically to So the real choice facing user-innovators is typically to freely reveal on purpose – or to reveal grudgingly.freely reveal on purpose – or to reveal grudgingly.

Generally they reveal gladly because the alternative of Generally they reveal gladly because the alternative of free revealing offers private benefits:free revealing offers private benefits:– Enhanced reputationEnhanced reputation

– Your innovation is improved by others (for free)Your innovation is improved by others (for free)

– Network effect benefits…Network effect benefits…

Where does patenting fit in to all of this?Where does patenting fit in to all of this?

If you want to patent an invention developed via a distributed process:– How can anyone determine who the “real inventors” are?How can anyone determine who the “real inventors” are?

– How can you allocate responsibility / benefits related to How can you allocate responsibility / benefits related to licensing across many invention contributors NOT under the licensing across many invention contributors NOT under the same organizational umbrella?same organizational umbrella?

If you are a patent-holder who wants to enforce your rights against a distributed inventor-user community– How can you cost-effectively enforce your patent rights How can you cost-effectively enforce your patent rights

against many distributed users – each with only small against many distributed users – each with only small invention-related benefits, and able to quickly “invent around” invention-related benefits, and able to quickly “invent around” most claims if informed of a violation? most claims if informed of a violation?

Question: Will the increasing advantages and scope of Question: Will the increasing advantages and scope of distributed invention eventually make patenting a niche distributed invention eventually make patenting a niche phenomenon?phenomenon?

In sum…In sum…

Innovation is getting increasingly fast and collaborative and open. Trying to keep track of or charge for IP is going to get harder and harder.

Innovation is shifting increasingly to end users. It will be harder to find IP violations – and when you find them – does it pay to sue (an increasing number of) your customers?

The benefits of innovating based on open IP are increasing – so openness is becoming an increasing competitive advantage for suppliers

Many CEOs at the WEF meetings would be Many CEOs at the WEF meetings would be happy to give up patenting if others did too…happy to give up patenting if others did too…

At the WEF Davos meeting in Jan, 2006, one session At the WEF Davos meeting in Jan, 2006, one session asked CEOs to “Imagine that in 2020 that IP had been asked CEOs to “Imagine that in 2020 that IP had been abolished.” abolished.” – How would your company strategy change?How would your company strategy change?

– How would your company competitive advantage be How would your company competitive advantage be affected?affected?

Major outcomes I observed:Major outcomes I observed:– Few CEOs thought that their strategy or competitive Few CEOs thought that their strategy or competitive

advantage would be much affected – they had other advantage would be much affected – they had other competitive advantages that were more important.competitive advantages that were more important.

– Many CEOs did NOT regard IP favorably. They felt it Many CEOs did NOT regard IP favorably. They felt it forced them into expensive, defensive investments. forced them into expensive, defensive investments.

BOOK AVAILABLE

FREE ON WEB-http://mit.edu/evhippel/www/democ.htm