1 / 29

Incompatibilities between patenting and distributed software inventing

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.

pmckinnon
Download Presentation

Incompatibilities between patenting and distributed software inventing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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… :)

  3. The core activity of invention is problem-solvingProblem solving is carried out via “directed” trial and error Design • Design a possible solution • Develop models prototypes • Test model/prototype In real or simulated use environment • Analyze findings previous step Build Run Analyze Done

  4. 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.”

  5. 9/3/2002 M. Weilguni (Germany) Outlines vacuum problem with very large databases Proposes “simple” solution (Bit field in tables) Software innovation is at the leading edge of the trend towards distributed inventionConsider 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) Example source: Karim Lakhani

  6. The Sept 3 message from Mario that starts things off 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 Mario Weilguni (periphery) outlines a problem that he faces with database vacuuming (Sept 3, 2002) - 6 -

  7. 9/3/2002 9/3/2002 9/3/2002 9/3/2002 9/3/2002 S. Daithankar (India) Proposes alternative solution (Usage,Triggers,Threads) M. Weilguni S.D. proposal not practical for his situation R.Taylor (Canada) M.W is mistaken Provides sample script for S.D proposal T. Lane (USA) Acknowledges problem Calls it: “auto vaccum” Proposes server implementation S. Daithankar Announces intention to create solution Provides details on his approach - asks for feedback (Usage,Triggers,Threads) 9/3/2002 M. Weilguni (Germany) Outlines vacuum problem with very large databases Proposes “simple” solution (Bit field in tables) 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 dayin response to Mario’s suggestion

  8. Contributions to the “invention” that results come from many sources… Shridhar Dahitankar (periphery) announces that he is going to work on this but needs some information (Sept 3, 2002) 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 - 8 -

  9. 9/3/2002 9/3/2002 9/3/2002 9/3/2002 9/3/2002 9/3/2002 9/3/2002 9/3/2002 9/3/2002 9/3/2002 9/3/2002 9/3/2002 T. Lane (USA) Acknowledges problem Calls it: “auto vaccum” Proposes server implementation R.Taylor Proposes an additional component to T.L’s ideas (Use DB Analyze) S. Daithankar (India) Proposes alternative solution (Usage,Triggers,Threads) M. Weilguni S.D. proposal not practical for his situation R.Taylor (Canada) M.W is mistaken Provides sample script for S.D proposal S. Daithankar Announces intention to cerate solution Provides details on his approach - asks for feedback (Usage,Triggers,Threads) T. Lane Stats Collector approach is also good (Has questions on details) T. Lane S.D’s approach will never work (Use Free Space Map(FSM) in server instead) T. Lane Good idea! - Interesting implications for performance B.Lind (USA) Proposes new design (Partial vacuum only - create Dirty Space Map?) M. Weilguni Proposes using “Stats Collector” (already in PG) instead of FSM Provides URL to show sample output (Use Stats Collector) M. O’Connor (USA) Announces intention to create solution Answers T.L’s quesitons (Stats Collector) 9/3/2002 M. Weilguni (Germany) Outlines vacuum problem with very large databases Proposes “simple” solution (Bit field in tables)

  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/projdisplay.phpLet 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 - 10 -

  11. Contributions to the “invention” that results come from many sources… 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 Matthew O’Connor asks Shridhar some coding questions (September 24, 2002) - 11 -

  12. 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)

  13. 3/20/2003 2/11/2003 9/23/2002 2/11/2003 3/11/2003 9/24/2002 11/26/2002 B. Momjian (USA) Commits code to repository - now official part of PG M. O’Connor Submits V2 based on feedback from developers M. Neusland (Germany) “I have been using S.D’s code in Production for months!” M. O’Connor Submits V3 based on feedback from developers 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) S. Daithankar Posts questions from M.O on his approach + his answers S. Daithankar Announces solution is ready Based on: Stats Collector and Table Activity DB Analyze Client daemon - not server based (Abandoned previous approach) 11/26/2002 S. Daithankar Thanks for doing the work! 9/3/2002 9/3/2002 9/3/2002 9/3/2002 9/3/2002 9/3/2002 9/3/2002 9/3/2002 9/3/2002 9/3/2002 9/3/2002 9/3/2002 9/24/2002 T. Lane Stats Collector approach is also good (Has questions on details) T. Lane (USA) Acknowledges problem Calls it: “auto vaccum” Proposes server implementation B.Lind (USA) Proposes new design (Partial vacuum only - create Dirty Space Map?) T. Lane Good idea! - Interesting implications for performance M. O’Connor (USA) Announces intention to create solution Answers T.L’s quesitons (Stats Collector) R.Taylor Proposes an additional component to T.L’s ideas (Use DB Analyze) S. Daithankar Announces intention to cerate solution Provides details on his approach - asks for feedback (Usage,Triggers,Threads) M. Weilguni Finds issues with S.D’s implementation R.Taylor (Canada) M.W is mistaken Provides sample script for S.D proposal M. Weilguni S.D. proposal not practical for his situation S. Daithankar (India) Proposes alternative solution (Usage,Triggers,Threads) M. Weilguni Proposes using “Stats Collector” (already in PG) instead of FSM Provides URL to show sample output (Use Stats Collector) T. Lane S.D’s approach will never work (Use Free Space Map(FSM) in server instead) 9/3/2002 M. Weilguni (Germany) Outlines vacuum problem with very large databases Proposes “simple” solution (Bit field in tables) 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

  14. 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

  15. 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 # of users perceiving need Target Market Time Time

  16. Industrial products n % innovating The pattern of “distributed invention” extends far beyond software 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%

  17. Users will collaboratively innovate without “product / patent owner” permission Mindstorms robot kit • 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

  18. Lego mindstorms user communities grew rapidly- without company involvement Members 900 800 700 600 500 Robots become widely available August 1998 400 Lego robots announced January 1998 300 200 100 Nov1997 Jun1998 Feb1999 Oct1999 Jun2000 Jan2001 Aug2001 Apr2002 (1) Lego Users Group NETwork. An independent discussion site for Lego enthusiasts Source: Russel Nelson, administrator of lego-robotics (russnelson.com)

  19. Within 3 weeks of commercial introduction of Lego Mindstorms system, users had improved it significantly The rules The results • 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 • 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 Source: Italian Lego Users Group (http://www.itlug.org/). Contact Mario Ferrari [mario.ferrari@edis.it] Lego firmware

  20. Mindstorm sales greatly surpassed Lego expectations Adults drove increased sales Sales in 1998(1) • 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 $905 million(2) $20 million % Realized Expectedbeforerelease • First year toys were offered • Lego sales include theme parks, retail outlets and other non-core businesses • Source: Business 2.0, BCG Analysis Source: Karim Lakhani and BCG team

  21. Lego was not sure how to respond - for several years • “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 Source: BCG interviews

  22. Brick Wars Star ship GLUG: The Game- LEGO Users Group 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? … … … Informa- tional Official ILTCO website … Market place Yahoo! Group … Yahoo! Group … Everything LEGO ILTCO: International LEGO Train Club Organization 500 links Educa- tional EJLTC … Yahoo! Group … Train Organizations Robotics FGLTC … … Yahoo! Group … Off topic … … Dear LEGO Castle clubs/ organizations Yahoo! Group News groups FAQ Space … Local usergroups DK US NELUG Israel Chile Source, Yun Mi Antorini

  23. 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

  24. Free revealing is essential to make user-centered innovation an economically-efficient solution Users IN COMMUNITIES can innovate more cheaply here Manufacturers can innovate more cheaply here # of users perceiving need Time Time

  25. 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…

  26. 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?

  27. 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

  28. 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.

  29. BOOK AVAILABLE • FREE ON WEB • http://mit.edu/evhippel/www/democ.htm

More Related