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: [email protected],
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 [[email protected]]
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