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