The document discusses various ways that open source projects can generate revenue to support ongoing development. It notes that directly making money from open source is difficult, but projects can build businesses around supporting the project. Common revenue strategies mentioned include offering paid support, custom development services, training, certification programs, and donations. The document warns against approaches that won't engage communities like expecting free labor or having the wrong motivations. It provides examples of both successful and unsuccessful open source business models.

1. The business behind open source

2. Graham Weldon
• PHP developer, 10 years
• Once-was-a-java-developer
• @predominant
• http://grahamweldon.com
• Working: CakeDC
• http://cakedc.com

3. Money
The primary motivator

4. What can generate
revenue?
Often project specific

5. Indirectly
• Making money directly from open source is
difficult
• Make money by operating your business
along side your project
• Allow the project to grow and evolve with the
community

6. Support
• The most obvious
• Premium support for businesses and
individuals
• Utilise high speed Internet for video sessions
and screen sharing

7. Development
• Build in and around your project, for clients
• Custom software
• Closed source (Yes, I said it)

8. Training
• Educate users
• Leads to better use, more contributors
• Provide courses aimed at various levels
• Again use high speed Internet to perform
remotely

9. Certification
• Might not suit all projects
• Offer professional structured testing systems
to qualify users of a high standard
• Offer certification as a "badge of merit"
publicly
Achievement Unlocked
Zend Certified Engineer
Achievement Unlocked
Certification for CakePHP 1.3

10. Donations
• Its not begging
• Method of giving back to the project for
people that can't contribute
• Encourages others to donate
• Optionally allow donors to publicly list
themselves
I Donated to CakePHP!

11. What doesn't work?
Common mistakes

12. People code for me,
for free
• Not going to happen if that's the "attitude"
• If the focus is more on your business
acquiring free developers, than making a
great product that will entice developers you
may need to rethink your motives
• Open source != free labour

13. Wrong Approach
“Communities donʼt rally around closed
source companies to prolong the existence of
failed companies or projects”

14. Wrong Approach
“No-one wants to be a lackey to a commercial
open source project, contributing their time to
further some companies interests.”

15. The idea is enough
• I have a great idea
• Someone will help me bring it to fruition
• This is not how to get people interested
• Everyone had great ideas
• What separates us, is some have the drive to
realise those ideas

16. Nightingale

17. Examples
• Nightingale http://getnightingale.com
• Ideas only
• Focused on processes and orgnaisation
• Still failing to produce anything
• No focus, no direction

18. Example: Xara

19. Examples
• Xara Xtreme http://www.xaraxtreme.org/
• Initially commercial
• Wanted community help for port to Linux
• Not all the source released
• Not always an issue, but was in this case

20. Examples
• Xaraʼs approach
• We provided the source code
• You provide us with your developer time
• Communities donʼt work this way

21. Examples
• Xaraʼs response
• Community complained about missing CDraw
source
• Xara persisted with CDraw closed source
• Essentially telling the potential community that
their concerns were wrong
• Xara is considered “stagnant” since 2008

22. How an open source
project starts
... or more correctly,
how it has always existed, and you identify it

23. How a project starts
• Successful projects
• Existing implementation, open up to
community
• Start working on a solution to a problem
• Some application/project that motivates you

24. Important Milestones
• Have a product for people to download
• Roadmap to show where you want to go
• Source code from the beginning
• Simplify feedback and input mechanisms

25. Bootstrap
• Have “something” available
• Something useful
• Even something wrong
• Its a place to begin, and comment

26. Resources
• Website
• Mailing List
• Bug tracker
• Wiki, or similar
• Source view / download
• Realtime Chat (IRC)

27. Generating interest
Building hype

28. Social
• Get out and talk to people about what you are
doing
• Don't be afraid to share an unpublished idea
• Get people interested
• Get feedback first hand
• User Groups

29. Social
• People retain interest in a topic if they can
associate a real life relationship with it
• Easier to communicate complex ideas

30. Playing fair
Don't alienate the volunteers

31. Money can't buy me
love
• Play by the same rules as volunteers
• Motivate people to contribute through paying
salaries
• Don't let that get confused with control rights

32. Separate the entities
• Operate the open source effort as a separate
entity
• Provides visible business separation
• Gives confidence and assurance to those not
working for the business

33. Example: CakePHP
• Product: CakePHP, under MIT License
• Cake Software Foundation "owns" CakePHP
• Contributed to by a group of volunteers
• CakeDC is a commercial business that hires
some of the volunteers for work on client projects
• CakeDC provides code back to CakePHP

34. Careful balance
• Make it known what "hat" you are wearing
• Business cannot be the key motivating factor
for the projects development
• There are many ways to support a project
beyond code

35. What Project?
Choosing a project

36. Useful, engaging,
interesting, innovative
• The project should be something useful to
some business need
• You should have a personal interest in the
projects goal
• Solve an existing problem, or solve an old
problem in an interesting way
• Create something new

37. Types of projects
• CakePHP
• MySQL
• Subversion
• Linux

38. Community and
public image
(it's almost "marketing"... *shudder*)

39. Community appeal
• Your project should fill a need that people
have, and can build on.
• Allow them to take ownership of something
• Credit where credit is due
• Kudos where kudos is due

40. You're being watched
• The world is watching
• Don't say negative things about your
competitors
• But... Benchmarks and facts are okay

41. Participate and engage
• Visit your community
• If its larger enough, consider starting a user
group
• If its going global, consider a conference
• Its difficult to measure the benefits gained from
people that meet and talk about your project in
person.. Almost invaluable

42. Communicate
• Learning to communicate effectively can be a
better long term goal than programming
• A good communicator can effectively
coordinate developers and manage a project
• Don't just talk lots. Learn to speak and write
correctly

43. Communicate
• Commit messages
• Social media
• Mailing lists
• Blog posts
• Documentation

44. Bad communication
• 1337 speak / Trendy short form
• Vague
• Aggressive
• Dismissive

45. Good communication
• Appreciative
• Correct punctuation
• Correct spelling
• Correct grammar

46. Questions,
Comments?