open source: lessons learned (2006)

22
1 Open Source: Lessons Learned Matt Asay VP, Business Development

Upload: mjasay

Post on 10-May-2015

269 views

Category:

Technology


1 download

DESCRIPTION

A presentation I regularly gave in 2005/2006, yet still relevant today

TRANSCRIPT

Page 1: Open Source: Lessons Learned (2006)

1

Open Source: Lessons Learned

Matt Asay VP, Business Development

Page 2: Open Source: Lessons Learned (2006)

225 Jan 2006

Decades of disruption:Learning from the entertainment industry

“At present…severe economic damage [is being done] to the property rights of owners of copyrights in sound recordings and musical composition.…Unless something meaningful is done to respond to the…problem, the industry itself is at risk.”

Alan Greenspan. Testimony before Congress, 1983.

“The VCR is to the American film producer and the American public as the Boston Strangler is to a woman alone.”

Jack Valenti, President of the MPAA. Testimony before Congress, 1982.

“As the majority of hobbyists must be aware, most of you steal your software…. [Y]ou…prevent good software from being written…. I would appreciate letters from any one who wants to pay up.”

Bill Gates, “An Open Letter to Hobbyists,” 1976.

Page 3: Open Source: Lessons Learned (2006)

325 Jan 2006

What we’ve learned:How does open source work?

Page 4: Open Source: Lessons Learned (2006)

425 Jan 2006

What we thought open source was…

Page 5: Open Source: Lessons Learned (2006)

525 Jan 2006

How open source works

The Internet: A network of networks

Open Source– A community of communities

~ Small core development team (10-15 people do 80% of development)

Note: Most projects are much smaller than this - 84% have fewer than 10 developers

73% have only one active developer (85% not actively developed); 80% have less than 10 active users (downloads)

~ Larger circle of bug fixers and still larger group of bug finders/beta users (Big value)

– Facilitated by licensing that generally requires:~ Right to access the source code (plus the right to modify it)~ Right to distribute modified code (“derivatives”)~ Requirement to distribute derivative works under same

license [NOTE: This is only triggered if you distribute the code]

Sources: Andrea Capiluppi et al., 2003; Mockus et al., 2004.

Page 6: Open Source: Lessons Learned (2006)

625 Jan 2006

Recipe for open source (comm/unity/ercial) success

Code attributes– Modularity - Easier to build plug-ins, facilitates casual,

drive-by development/bug fixes (Lowers the bar to contribution, as does good documentation)

– Great initial code base– Degree of applicability - Need a large user/developer

population from which to draw

Market attributes– Significant consolidation around 2-3 “gorillas”– Multi-billion dollar ($2B+ industry with

~ Steep license costs~ Trend toward services/maintenance revenues (50%+)

– Feature creep - Small subset of features actually required– Complex technology such that buyers will pay for open

source

Page 7: Open Source: Lessons Learned (2006)

725 Jan 2006

Reasons for involvement:Pragmatics over religion

Percent of respondentsNote: Question asked for top three motivators of F/OSS participation, n=684Source: Boston Consulting Group, 2003

Intellectually stimulating

Non-work functionality

Obligation from use

Work with team

Professional status

Other

Open Source reputation

Beat proprietary software

Work functionality

Code should be open

Improves skill

License forces me to

Page 8: Open Source: Lessons Learned (2006)

825 Jan 2006

Developers rule in open source……but how do you engage with them?

The developer imperative:– Developers are critically important– Developers will play a major if not

determining role in the success or failure of your products

– Developers, like any audience, will have things to say about your products

Are you engaging with them?

Source: Stephen O’Grady’s “Bottom-up Marketing” presentation.

Page 9: Open Source: Lessons Learned (2006)

925 Jan 2006

The reality of marketing to developers Developers have become nearly immune to

traditional marketing (Haven’t you?)

Developers spend far more time online than they do with print publications

Developers would rather talk with someone than be talked at by something, and developers would rather touch the code than to hear about it

Developers are starting their own mini communities via blogs

Developers don't just code at the office

Developers are not content to sit back and wait for updates or news; they can make their ownSource: Stephen O’Grady’s “Bottom-up Marketing” presentation.

Page 10: Open Source: Lessons Learned (2006)

1025 Jan 2006

No one cares about source code……or do they?

Microsoft survey of their customers– >60% felt access to source code was “Critical”– Yet only 5% said they planned to look at it, and a mere 1% expected

to modify it– This is not Microsoft FUD - this is analogous to MySQL, Novell, JBoss,

etc.

Modify the source and you violate your support contract with Novell, Red Hat, JBoss, MySQL, IBM, HP, etc.

So, why the interest in open source/access to the source?– You can’t do anything with it (without taking on the full support

burden)– You don’t have interest or time to do anything with it (That’s what

you’re paying the vendor to do for you - deliver value)– What’s the point?

Trust and flexibility (but mostly trust), and it’s the relevant “currency” for developers

Page 11: Open Source: Lessons Learned (2006)

1125 Jan 2006

= meaningful choice

O P E N

Page 12: Open Source: Lessons Learned (2006)

1225 Jan 2006

The choice continuum:Maximize choice by founding on open platforms

Operating System

Database

End-User Applications

Application Framework

Middleware

GPL

Closed, BSD, GPL

Closed, BSD

Closed, BSD

Closed

File Formats

Closed

Open

Open

Closed

Page 13: Open Source: Lessons Learned (2006)

1325 Jan 2006

Open source stops reinvention of the wheel:driving innovation up the stack

Page 14: Open Source: Lessons Learned (2006)

1425 Jan 2006

What We’ve Learned:How do you monetize communities?

Page 15: Open Source: Lessons Learned (2006)

1525 Jan 2006

Disruptive technologies: Disrupt adjacent markets, rather than cannibalizing your own

Per

form

ance

Time

Performance that customers

can utilize or absorb

Pace of

Technological

Progress

Sustaining innovations

Disruptive technologies

Incumbents nearly always win

Entrants nearly always win

Source: Clayton Christensen, OSBC2004

Page 16: Open Source: Lessons Learned (2006)

1625 Jan 2006

Important business considerations

The Internet grew because– Open at the core, providing an open foundation upon

which to build and– Closed at the edge of the network (promoting

copyright-induced innovation)– Open source commercial growth can be the same.

But:– First mover advantage is huge in open source– You don’t need to attract THE Community - you need to

build a vibrant user community– Open source requires a different mindset, a different

culture– Use open source licenses as a valuable weapon - they

are an opportunity to you, and a threat to your competitors

Page 17: Open Source: Lessons Learned (2006)

1725 Jan 2006

Some rules of thumb

Support is a weak business model– Hard to scale– Hard to monetize

A dual-tiered model works– Either open + less open (Fedora + RHEL) or– Open + closed (Alfresco Community vs. Enterprise)

~ Why? Gives would-be customers a clear reason to pay (You do not want to confuse them on this)

~ Ways to close off code: Certification Providing source (but not binaries - helps if the code is

complex, like an OS) Copyright

GPL is closest to traditional copyright regime, and makes it hard for competitors to rip you off

Page 18: Open Source: Lessons Learned (2006)

1825 Jan 2006

Option 1:Run the IP race

Innovation still pays…but where you innovate is paramount– Cool new technology will find a paying audience– Open source generally lags closed source in features– Open source, definitionally, may not compete well with

innovation~ Open source depends upon a large population of developers with

aptitude and interest~ Such a group cannot form until an innovation is established and

widely adopted– You want to innovate at the edges

Open source’s glass ceiling?– Some code is less likely to be replicated in the open source

community– Open source community may lack skillsets (high-end

databases?), incentive (TurboTax), or equipment to create an open source alternative (NOTE: This does not apply to commercial open source)

– Remember: most open source developers participate because they find it “intellectually stimulating” - create IP in unsexy areas

Page 19: Open Source: Lessons Learned (2006)

1925 Jan 2006

Option 2:Embrace and drive commoditization

The software industry may be maturing into a commodity industry

In commodity markets, there are three competitive differentiation points:

– Price~ Use open source to lower your costs, then sell for a lower price

Sales, marketing, distribution, and QA costs lowered through open source Development generally not)

~ Price as a loss-leader for other, value-adding IP

– Service (“Professional Open Source”)~ Huge need for open source software support~ Risk mitigation services

– Brand~ Source of code vs. source code (“Owning” project ‘committers’ gives

influence/control, which translates into margin)~ Likely that users will pay for a trusted brand (certified, etc.)***

~ ***Red Hat has an ingenious model whereby they provide source but not binaries for free - not sure this works in the embedded world, though….

Page 20: Open Source: Lessons Learned (2006)

2025 Jan 2006

Option 2.5:Dual licensing strategies

If you own the copyright, you can dual license– Provide the same body of code under two licenses, generally both open

and closed– Outside contributors (if any) assign copyright for their modifications back

to MySQL, Sleepycat, Trolltech

Why this works– Developers have an incentive to contribute– Companies have an incentive to purchase

Competitive advantage– Give customers increased control, while preventing competitors from

hijacking your code– Dramatically lower sales, marketing, distribution, and QA costs– Undermine higher-priced, closed source competitors by providing a good

enough, cheap product that insidiously works its way into the enterprise, past Procurement)

Page 21: Open Source: Lessons Learned (2006)

2125 Jan 2006

Option 3: Change the rules of the game (soft(er)ware)

Digital media entertainment and open source: Commonalities?

– Both involve industries based on intellectual property struggling to deal with an apparent devaluing of IP

– Both have failed to innovate payment mechanisms (focusing instead on protection of property)

Salesforce.com and “The End of Software” (ASP/Utility model)

– Removes the open source licensing quandary (Open source licensing restrictions are triggered by distribution, not use - so, if you’re distributing a service, not software, you’re fine)

– Removes the problem of protecting property– Refocuses the emphasis: solving business problems– Facilitates support, scalability, application development (I.e.,

overcomes the top barriers to open source adoption)– Maximizes choice (and Salesforce.com still gets paid)

Page 22: Open Source: Lessons Learned (2006)

2225 Jan 2006

Summary and conclusion

Open source software– The market’s response to vendor lock-in, inflexible & costly

IT– Imposing dramatic changes in the way software is

developed and sold– Part of the emerging “upload economy”

Have your cake. Eat it, too.– Third wave business models compatible with free culture– Where there is customer value, there will be someone

willing to pay

The world is “flattening”…. Are you ready?