Slides - Research on Innovation

obtainablerabbiΔιαχείριση Δεδομένων

31 Ιαν 2013 (πριν από 4 χρόνια και 5 μήνες)

118 εμφανίσεις

Incompatibilities between
patenting and distributed
software 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 talk



Rapid, collaborative work with ad
-
hoc contributors and much
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
practical realities of patenting (eager to hear YOUR view!).



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

The core activity of invention is problem
-
solving

Problem solving is carried out via


“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
many contributors is increasingly efficient in
our Internet age


because search and
interaction is getting steadily cheaper…



“Given enough eyeballs, all bugs are shallow.”





-

Linus’ Law (Eric Raymond, 1999)



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

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






Consider the invention process culminating in a new software
feature in the PostgreSQL Community


“intelligent” data
vacuuming.

(Voted the most useful new feature in Release 7.4)



M. Weilguni (Germany)

Outlines vacuum problem with

very large databases

Proposes “simple” solution

(Bit field in tables)

9/3/2002

Example source: Karim Lakhani

-

6

-

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 databases

Proposes “simple” solution

(Bit field in tables)

9/3/2002

S. Daithankar (India)

Proposes alternative solution

(Usage,Triggers,Threads)

9/3/2002

M. Weilguni

S.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 problem

Calls it: “auto vaccum”

Proposes server

implementation

9/3/2002

S. Daithankar

Announces 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 respond

and 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
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 databases

Proposes “simple” solution

(Bit field in tables)

9/3/2002

S. Daithankar (India)

Proposes alternative solution

(Usage,Triggers,Threads)

9/3/2002

M. Weilguni

S.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 problem

Calls it: “auto vaccum”

Proposes server

implementation

9/3/2002

S. Daithankar

Announces intention to cerate solution

Provides details on

his approach
-

asks for feedback

(Usage,Triggers,Threads)

9/3/2002

T. Lane

S.D’s approach will never work

(Use Free Space Map(FSM)

in server instead)

9/3/2002

R.Taylor

Proposes an additional

component to T.L’s ideas

(Use DB Analyze)

9/3/2002

T. Lane

Good idea!
-

Interesting

implications for performance

9/3/2002

B.Lind (USA)

Proposes new design

(Partial vacuum only
-

create

Dirty Space Map?)

9/3/2002

M. Weilguni

Proposes using “Stats Collector”

(already in PG) instead of FSM

Provides URL to show

sample output

(Use Stats Collector)

9/3/2002

T. Lane

Stats Collector approach


is also good

(Has questions on details)

9/3/2002

M. O’Connor (USA)

Announces intention to

create solution

Answers T.L’s quesitons

(Stats Collector)

9/3/2002

-

10

-

Contributions to the “invention” that results come from
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/projdis
play.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
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
demonstrated less than 2 months from the first
message 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 databases

Proposes “simple” solution

(Bit field in tables)

9/3/2002

S. Daithankar (India)

Proposes alternative solution

(Usage,Triggers,Threads)

9/3/2002

M. Weilguni

S.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 problem

Calls it: “auto vaccum”

Proposes server

implementation

9/3/2002

S. Daithankar

Announces intention to cerate solution

Provides details on

his approach
-

asks for feedback

(Usage,Triggers,Threads)

9/3/2002

T. Lane

S.D’s approach will never work

(Use Free Space Map(FSM)

in server instead)

9/3/2002

R.Taylor

Proposes an additional

component to T.L’s ideas

(Use DB Analyze)

9/3/2002

T. Lane

Good idea!
-

Interesting

implications for performance

9/3/2002

B.Lind (USA)

Proposes new design

(Partial vacuum only
-

create

Dirty Space Map?)

9/3/2002

M. Weilguni

Proposes using “Stats Collector”

(already in PG) instead of FSM

Provides URL to show

sample output

(Use Stats Collector)

9/3/2002

T. Lane

Stats Collector approach


is also good

(Has questions on details)

9/3/2002

M. O’Connor (USA)

Announces intention to

create solution

Answers T.L’s quesitons

(Stats Collector)

9/3/2002

S. Daithankar

Announces solution is ready

Based on:

Stats Collector and Table Activity

DB Analyze

Client daemon
-

not server based

(Abandoned previous approach)

9/23/2002

S. Daithankar

Posts questions from M.O

on his approach

+ his answers

9/24/2002

M. Weilguni

Finds issues with S.D’s

implementation

9/24/2002

M. O’Connor

Announces 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’Connor

Submits 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’Connor

Submits 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. Daithankar

Thanks 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
probably

be
proven faster / better than protected
-

internal

-

Ned Gulley, Mathworks, Karim Lakhani



and Eric von Hippel, MIT
research in progress

# of users

perceiving
need


Time


Time

Traditional, Manufacturer
-
Centered Innovation Paradigm

Manufacturers identify user needs, develop products at private expense,

And profit by protecting and selling what they have developed.


User
-
Centered (Democratized) Innovation Paradigm

Lead 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
“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 ~ $200

Source: Karim Lakhani and BCG team

Mindstorms robot kit

Lego mindstorms user communities grew rapidly

-

without company involvement


Robots become
widely available
August 1998

800

700

600

500

400

300

200

900

Nov

1997

Jun

1998

Feb

1999

Oct

1999

Jun

2000

Jan

2001

Aug

2001

Apr

2002

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 weeks

of commercial introduction of
Lego Mindstorms system,

users 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 firmware

Source:

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

Mindstorm sales greatly surpassed Lego
expectations

0
10
20
30
40
50
60
70
80
90
100
Total Lego
Sales
Mindstorms
Sales
Expected

before

release

$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 businesses

Source: 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

Lego was not sure how to respond


-

for
several years


Source:

BCG interviews

There are ~ 200 internal R&D people at Lego.

There are
20,000+

AFOL’s


many innovate.

More Lego
-
related R&D
outside

Lego than inside?

Official

ILTCO website

News groups

Local

usergroups

DK

Israel

Chile

US

Dear

LEGO

FAQ

Off topic



Castle

clubs/

organizations

ILTCO:

International

LEGO Train Club

Organization

Space

Train

Organizations

EJLTC

FGLTC




GLUG:

The Game
-

LEGO Users

Group


Brick

Wars

Star

ship

Yahoo!

Group

Yahoo!

Group

Yahoo!

Group

Everything

LEGO

Educa
-

tional

Market

place

Informa
-

tional

Robotics

























500 links

Yahoo!

Group

Yahoo!

Group

NELUG

Source, Yun Mi Antorini

It pays for users to innovate
collaboratively in
communities

and freely reveal their IP


Innovating users quickly form communities and freely
reveal their innovations


because it pays.



Each has a DIFFERENT low
-
cost innovation niche.


Each gains private profit from in
-
house use of their
innovation


a competitor can’t take that away from
them.


Users can benefit from others improving their innovation
and free revealing in turn


or from manufacturers
selling a better commercial version to them

# of users

perceiving
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
innovation an economically
-
efficient solution


Free revealing
makes economic sense

for
participants in distributed invention

It is typically
not practical

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


So the real choice facing user
-
innovators is typically to
freely reveal on purpose


or to reveal grudgingly.



Generally they reveal gladly because the alternative of
free revealing offers private benefits:


Enhanced reputation


Your innovation is improved by others (for free)


Network effect benefits…

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 you allocate responsibility / benefits related to
licensing across many invention contributors NOT under the
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
against many distributed users


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


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


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
happy to give up patenting if others did too…


At the WEF Davos meeting in Jan, 2006, one session
asked CEOs to “Imagine that in 2020 that IP had been
abolished.”


How would your company strategy change?


How would your company competitive advantage be
affected?



Major outcomes I observed:


Few CEOs thought that their strategy or competitive
advantage would be much affected


they had other
competitive advantages that were more important.


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



BOOK AVAILABLE


FREE ON WEB

-
http://mit.edu/evhippel
/www/democ.htm