David Duffett's CommCon 2019 Keynote Speech The founders of 10 Open Source projects were asked to complete a survey. This talk was based on the results of that survey.

1. Open Source:
Beyond the Bottom Line
David Duffett
Let the Geek Speak
@dduffett

2. Our Agenda
• The Plan
• My Aims
• The Projects
• The Questions
• The Answers
• Conclusions

3. Background
• Who is David Duffett
– Author, Speaker, Trainer
– In Telecoms for over 30 years
– In Open Source Comms for over 15 years
– Former Worldwide Community Director, Asterisk
(2012-2019)
– Friend of many Open Source Comms projects
• Current project is a book and training program
Let the Geek Speak

4. The Plan
• Enquire through the connections and friendships
that I am blessed to have built up over the last
15 years within the world of Open Source
Communications
• Ask some questions with a view to gaining
insights to pass on to you
• Note: Responses are not be attributed to
individuals

5. My Aim
• To use the information that I have collected to:
– Raise questions
– Start conversations
– Build empathy
– Inform any future Open Source start-ups, or
optimisations of existing projects
– Help us all to be better “Open Source Citizens”

6. The Projects

7. Motivation
• Why did you start your Open Source project?

8. Money
• Did you have initial ideas/strategies about
how you might make money from your Open
Source project?
– If yes, what were those ideas/strategies?
• What proved to be the ways that you actually
ended up monetising around your Open
Source project?

9. Metrics
• Do you, or did you, collect any metrics about
your Open Source project?
– If yes, what were those metrics both in terms of
what you measured and the (rough)
measurements themselves?

10. Hindsight
• If you could go back in time (knowing what
you know now), would you make your project
Open Source?
• Regardless of your answer to the above
question, what would you do differently next
time around?

11. Blessings Curses
• What are the best things about a project being Open
Source?
• What are the worst things about a project being Open
Source?
• What are your thoughts about those people or
companies that have been successful simply by using
your Open Source project without contributing back
to it (do you have different feelings about individual
people and companies)?

12. Sitting Back…
• What are your proudest of about your Open
Source project?
• What are you most grateful for in your Open
Source project?

13. Not Always Easy
• What were the 'bumps in the road' of your
Open Source project?

14. Best Advice
• What questions would you ask and/or what
advice would you have for anyone thinking of
starting an Open Source project?

15. Looking Ahead
• What are your thoughts about the future of
Open Source?

16. Responses left me…
• Humbled
– That these people would take the time and trouble to complete
my survey.
• Grateful
– For the openness and honesty that was evident in the replies.
• Inspired
– By the generosity of spirit, faith in humanity and depth of
thought that was shown.
Some of the answers are truly profound.

17. The Answers
• Interesting angles
• General Consensus
• Personal favourites J

18. Motivation
• Why did you start your Open Source project?
– “I had more problems and ideas than I did existing
solutions for them.”
– “I had a lot of years experience building a commercial
product, and in competing against open source I saw the
power of building a community that can occur when price
is not a barrier to customer acquisition. I looked at what
was available for the product/service I had in mind, and
felt that I had a lot that I could contribute based on the
existing tools and frameworks that were available.”

19. Motivation
• Why did you start your Open Source project?
– “Cost saving measure”
– “It seemed like the most convenient way to build
up and eventually demonstrate work experience
without needing to go through tedious
internships.”

20. Money
• Did you have initial ideas/strategies about
how you might make money from your Open
Source project?

21. Money
• If yes, what were those ideas/strategies?
– “Prove Open Source is a business and provide
solutions to companies not just hobbits.”
– “Consultancy”
– “…maybe additional consulting, but not much more
than that. We did pick the dependencies carefully
since the very beginning, though, choosing the ones
with relatively permissive licenses that wouldn't have
an impact on ours.”

22. Money
• If yes, what were those ideas/strategies?
– “By selling knowledge, as services or embedded
in products built on the Open Source project.”
– “The redhat model -- sell services around a free
product. The service was basically me helping
people build apps, if they wanted to pay vs doing
themselves.”

23. Money
• What proved to be the ways that you actually ended
up monetising around your Open Source project?
– “Dual licensing”
– “Investing a lot of time into listening to the market and
providing solutions far beyond just code.”
– “Top notch Support, Commercial Extensions,
Partnerships”
– “Many years later, working for the new owners”

24. Money
• What proved to be the ways that you actually ended up
monetising around your Open Source project?
– “Hardware products mostly”
– “Consulting did indeed become one of our main lines of
business thanks to the project, but it didn't stop there. We now
also provide commercial support and, for those that need it,
commercial licensing as an alternative to the GPLv3 the
project is licensed under. A couple of products based on the
project are available as well, mainly in the realm of the remote
participation support for live conferences.”

25. Money
• What proved to be the ways that you actually
ended up monetising around your Open Source
project?
– DD Observation:
Another strategy is studying the commercial
ecosystem built up around the project, and then
buying parts of it based on technical excellence
AND/OR commercial strength

26. • Do you, or did you, collect any metrics about
your Open Source project?
– Lines of Code, Github Repo stats
Downloads, Size of Mailing List, Module use
Full blown usage stats to track engagement
Metrics

27. Hindsight
• If you could go back in time (knowing what
you know now), would you make your project
Open Source?

28. Hindsight
• Regardless of your answer to the above
question, what would you do differently next
time around?
– I can't think of anything
– Better align monetization strategy with development
strategy.
– Expand the team sooner. It's a large burden to have
such a small team responsible for the future of so
many companies.

29. Hindsight
• Regardless of your answer to the above question,
what would you do differently next time around?
– We would probably better clarify the licencing aspects
from the very beginning, CLA included.
– Choose a suitable license for each project component
early on.
– I might examine some of the newer license models, which
aim to prevent someone from taking an open source
product and monetizing as a service without adding
anything of value to it.

30. Hindsight
• Regardless of your answer to the above question,
what would you do differently next time around?
– Pay more attention to community and try as much as
possible to get it involved in all the steps/cycles of the
project.
– Not do consulting. Concentrate on a specific problem,
build out a service to solve it and sell that through a self-
service portal.
– Coordinate the business ecosystem better

31. Blessings Curses
• What is the best thing about a project being
Open Source?
– The Community!
• What is the worst thing about a project being
Open Source?
– The Community!

32. Blessings Curses
• What are the best things about a project being Open
Source?
– The product being known and used by large number of people
– Community involvement in improving the product
– Honest feedback and rapid discovery of what the world needs
as a solution.
– The potential for a dedicated community and the power to
inspire others
– Getting people to use your product, and getting your product
known

33. Blessings Curses
• What are the best things about a project being Open Source?
– Definitely the community. At the time, we were really not sure whether or not to release the
project as open source or not: why not do a product instead and sell it, taking advantage of
the novelty factor? I think we did the best choice of our business career, instead. Open
source projects get a visibility closed source projects rarely have: everyone is free to play
with them, break them, fix them, and it got us under a lot of radars. And we received A LOT
of amazing contributions: fixes to problems we would never have found out just by
ourselves, new features, enhancements, feedback on custom deployments, performance and
other stuff, etc. And the project is also what brought me to the RTC community in general:
while I had contributed to Asterisk and other projects in the past (especially IETF related
activities), none had the range and scope of the project, and so I was relatively unknown. It
was when I presented the project for the first at FOSDEM that I met many of the great
people I know today (Saul, Lorenzo from QXIP, Daniel, etc.), and it's those people that
convinced me to participate at other events too (OpenSIPS, Kamailio, Astricon, etc.) where I
met many others (you included!), something I'll always be grateful to them for.

34. Blessings Curses
• What are the best things about a project being Open Source?
– The circled relation with the community: the project provides code to
the community, but the community provides many resources and
assistance back to the project (docs, reports, tests, fixes, etc)
– You never lose your work as you change employers. It is always
yours to show and reuse.
– It is significantly easier to talk about your work when it is open
source. Feels much less like shameless plugging and people are more
willing to listen.
– You never worry about keeping your work a secret. Same goes for
your team so logistics around code access are *MUCH* simpler.

35. Blessings Curses
• What are the best things about a project being Open
Source?
– Lower adoption friction: You can tell your customers that they
are never fully locked in with you as a service provider, they
can always take the code and run with it. There's less risk for
customers to invest in your project.
– Transparency on security: if anyone has doubts as to what
happens to their data/media, they can always go and check if
the security is at the level they need it. Very few people
actually do it, but the fact that they can is powerful

36. Blessings Curses
• What are the best things about a project being Open
Source?
– The following two are often waved around as the major
advantages of open source. I don't think they are the
main ones but they still hold true to a smaller extent.
• You get validation and free testing from your community
• You get some free work (this one specifically is often overrated
for most projects and it often neglects the fact that for every 10
units of free work, maintainers have to often spend 5 to 7 units of
coaching, hand holding, co-designing and reviewing of
contributions ... but overall it is still a net positive).

37. Blessings Curses
• What are the best things about a project
being Open Source?
– 1. Loads of people using (i.e testing) your product
for you. 2. The community. 3. The freedom of not
having to deal with things like raising money, corp
b*llsh*t, etc which take away from creating useful
code.

38. Blessings Curses
• What are the worst things about a project being Open Source?
– Having a spat with nasty internet user
– People using your project to build businesses to compete with you
– Everyone thinks it’s all about Free Beer.
– For non-sponsored projects this might include lack of contributions,
lack of donations, lack of respect for those involved
– People using the open source software expecting their bugs/requests
to be treated as if they were paying per-hour for it.

39. Blessings Curses
• What are the worst things about a project being Open Source?
– I'd say a couple of things. One is definitely the people taking
advantage of your work and not giving anything back (more on that
later). The other is that, with all the good contributions, you get a lot
of noise as well. As a small team, it's hard for us to track everything
and be able to help everyone properly, especially in cases where
feedback is sparse and people are just not disciplined enough to
participate in what is meant to be a community, rather than free
support. As a result, we sometimes have to prioritise what brings
bread to the table (commercial support, consulting activities,
streaming of events), which can at times impact the quality of help
we're able to provide publicly instead (e.g., pointers to documentation
and/or just nudges in the right direction).

40. Blessings Curses
• What are the worst things about a project being Open Source?
– The visibility (which is good but also bad) and the complexity when comes
to monetizing it for a living.
– Ruthless ungrateful expectations for continued service and evolution.
– People treat all their software providers the same way regardless of how
much they paid. So if the software doesn't live up to someone's
expectations, you will be treated the same as vendors who charge for it.
– The attitude: You gave me this thing, now go and make it do what I need or
you are an useless a**hole!
– You are open to the free rider problem, of people using your product and
not giving anything back. You want to do great work, but you don't want to
be taken advantage of it.

41. Blessings Curses
• What are your thoughts about those people
or companies that have been successful
simply by using your Open Source project
without contributing back to it (do you have
different feelings about individual people and
companies)?

42. Blessings Curses
– Our dual licensing approach (GPL v2 and proprietary) has been
very good in protecting us against this. If a party actually does
that in ways that violate GPL, we could go after them and we
did couple of times.
– It's the nature of the beast.
– I am excited for them and proud to have made it possible. I do
get more annoyed if they are successful, don't contribute back
but also need help and either try to get it from someone they
hire who doesn't really know what they are doing or from our
founding team for free. Our professional services coming from
the source are invaluable.

43. Blessings Curses
– They are all equally guilty for the rise of
commercial usage restrictions.
– I have no real concerns about it. I didn't make it
to make money, and I (relatively recently) made
sure most of it was relicenced under the AGPL
to avoid the bypassing of the GPL by not
distributing.
– Ignore them, otherwise can be a waste of time

44. Blessings Curses
– I can't hide the fact that, when I really think about it, it enrages me: I understand it might feel unreasonable
(open source projects are meant to be shared, after all), but it's very hard for me to shake the feeling at
times. There are some very large (and rich) companies that use the project and that never contributed
anything back, where much smaller ones contribute daily or contracted us more than once for help.
Knowing that in same cases our work is a very fundamental part of the services such big companies
provide, it feels extremely unfair not to get the proper recognition. It's not always that bad, of course: *****,
for instance, never gave us a single cent, but without a doubt the very fact they were using us (and that
people knew it) gave us a visibility and credibility that no voluntary marketing campaign could ever possibly
achieve, and a lot of clients as a result; but it was an implicit benefit, nothing more than that. With the
resources they have, and the ones they spent on forking our product to tailor it to their needs, involving us
would have benefitted both. That said, there also are companies that do engage us for a bit of consulting,
but then prevent us from listing them as customers (e.g., for some ideal competitive advantage they might
have on other companies in the same space), which takes that small plus away too. Commercial licensing is
starting to help in that regard a bit, as usually larger companies are also those with the most frightened
lawyers :-) But still, if we look at the amount of money very well known companies are making out of the
sweat of out brows, and what our company is making instead (spoiler alert: not that much), I can't but feel
enraged. And it's clear that some other open source developers are feeling the same, if you see how some
of them (Redis for instance) are drastically changing their licenses to contrast this: probably the wrong
way, but if there's a right way I don't know it.

45. Blessings Curses
– Nothing is for free in this world, you will end up paying, in one way or
the other, for things you use! The question they should ask
themselves - are they paying for the right thing or not?
– And also have in mind that there might be a turning point in the
future when they will need some help, some knowledge, some
predictability in their relation with the project (or source of code :P)
– Love them all! It's the name of the game!
– Sure, it can be disappointing if you don't get back what you were
hoping for. That's fine and it is ok to (politely) ask for more.
– But never forget YOU made that choice! YOU told people to take
your stuff for free. It is schizophrenic to suddenly start sulking
because people took you up on it.

46. Blessings Curses
– Funny you should mention that. I know that one of the
largest companies in the world uses my product, and I've
heard the developers say we'd like to contribute, but
company X makes it very difficult. Really? You're one of
the most powerful companies in the world, but somehow
it's too hard to figure out how to make a contribution to a
small open source project you are making use of? This
company shall go unnamed, but on the other hand I have
incredible fondness for companies that go out of their
way to respect and honor open source - companies like
Simwood… So I guess it balances out

47. Sitting Back…
• What are your proudest of about your Open Source
project?
– It was (is?) (probably) the best project of it’s nature out
there
– Creating a cottage industry of people who were able to
create new and innovative telecommunications products!
– How globally recognized it has become.
– The true passion of the few Individuals behind it
– 2+ million active installs

48. Sitting Back…
• What are your proudest of about your Open
Source project?
– It helps many making a living for themselves and their
families as well as it helps others to connect in a
convenient way (financial or flexibility perspectives).
– The scale of its usage, and its value to the
companies/people using it.
– My team. Every single one of them. So proud!
– That many people are finding it to be of use to them

49. Sitting Back…
• What are your proudest of about your Open Source
project?
– I might sound a bit bipolar here, but the above is also what I'm
probably proudest of... Huge and very well known companies
are using our software as the foundation for some of their
services, services that are used everyday by millions of people,
and this obviously touches my heart, considering this wasn't
but a small experiment I started a few years ago! Now, if that
also made me incredibly rich that would be even better, but
just proud works for now :-D

50. Sitting Back…
• What are you most grateful for in your Open Source project?
– My team
– All the contributors and employees who faithfully worked to make the
product better, especially early on when the contributions weren't
always the features they personally needed.
– The early adopters who ran our project in production before it was
ready and never stopped believing in it for over 15 years.
– Being included by other Open-Source project and becoming part of
an ecosystem
– Developers community

51. Sitting Back…
• What are you most grateful for in your Open Source
project?
– As I was saying before, being able to engage the RTC
community and the great people in it (you included) the way I
now do, and being recognised as a part of it, is something that
would never have happened without the project.
– The relation and the trust in regards to the community.
– Support from our employer. Our growing user community!
– To be able to deploy my skills in a way that they are of use to
many people.

52. Not Always Easy
• What were the 'bumps in the road' of your Open
Source project?
– Having to implement new standards (RFCs) that are
incompatible with our implementation.
– Figuring out monetization, proper tooling, avoiding burning
out people in the process of managing contributions.
– Lack of contributions, lack of donations, lack of respect
for those involved

53. Not Always Easy
• What were the 'bumps in the road' of your Open
Source project?
– Having to give it up (and hand it to someone else)
because real-world money was beckoning.
– Forks and trolls
– Finding time to spend on it in the early days, when
every hour spent on it was a non-billable event with
significant opportunity cost

54. Not Always Easy
• What were the 'bumps in the road' of your Open
Source project?
– There are 2 kinds of bumps, IMHO. The first one is
about trying to keep the project afloat and on a path
of interest of the people using it - at the end of the
day it makes no sense to work on a project that no-
one sees a use for. The second one is the struggle to
find and allocate resources for it .

55. Not Always Easy
• What were the 'bumps in the road' of your Open Source project?
– See the CLA introduction I mentioned before: not really a bump in
the road, more of a ripple, but it affected me personally a bit and I
still think of if and how it might have been handled better. And there
were times, especially at the beginning, that we weren't taken very
seriously by a few experts that had some influence in the RTC
business space, which sometimes made it harder to find customers.
Apart from that, the project is relatively young so we've basically just
grown year after year since we started. I'm well aware it won't be
always just roses, and that we'll hit a wall someday: there are more
and more WebRTC solutions out there everyday, and competing will
become even harder.

56. Not Always Easy
• What were the 'bumps in the road' of your Open
Source project?
– Finding time to spend on it in the early days, when
every hour spent on it was a non-billable event with
significant opportunity cost
– It's not so much about the bumps in the road ... it's
more about the driver who doesn't know how to
navigate them.

57. Best Advice
• What questions would you ask and/or what advice
would you have for anyone thinking of starting an
Open Source project?
– Do it as a hobby or do it as a business, don't do it half
way
– Select a project that is very personal to you and focus on
the importance of the community contribution
– Are you ready to build a community? Its much harder
than writing code.

58. Best Advice
• What questions would you ask and/or what advice
would you have for anyone thinking of starting an
Open Source project?
– Don't wait for anyone's approval to start, use your very
own motivation, and don't forget to make a plan in case
you succeed, too!
– Only do it if you love it. You will get burned out, and you
need to be able to look back at it and go 'I really enjoy it'
and go back to it.
– Don't do Open Source for marketing purposes only

59. Best Advice
• What questions would you ask and/or what advice would
you have for anyone thinking of starting an Open Source
project?
– If the plan is to possibly monetise it as well, make sure you
pick the right license and how you can retain control of the
project. Apart from that, don't overthink it: if it's useful, people
will engage you, and it will be a great experience!
– Be sure it is more than a hobby and be sure you see the whole
picture when comes to closing the circle: the need - project -
resources - the need -....

60. Best Advice
• What questions would you ask and/or what
advice would you have for anyone thinking of
starting an Open Source project?
– Your contributors are your GREATEST asset! They
owe you nothing, you owe them everything. Treat
them right.
– Think through business models, but don't do it unless
you have a love for what you do, because that will be
the main return.

61. Looking Ahead
• What are your thoughts about the future of Open Source?
– Nowadays everyone has realized that OS works and it's the
best way to gather a lot of developers to contribute in a
project and make things better, and I think it will continue to be
that way
– It is the long term best development model for projects with
sufficiently wide audiences and without technical objections.
– Open-Source is here to stay, but may see fluctuations due to
SaaS players abuse.

62. Looking Ahead
• What are your thoughts about the future of Open Source?
– Almost everything is going towards open source. Even Microsoft, the
bastion of closed source, is switching to Open Source. Oracle are
also moving their entire company to focus on cloud computing (which
is ALSO based around open source). Open source is the future
– Open Source is the norm these days, even for the giants out there,
the difficulty will be in selecting among the myriad of alternatives.
Diversity is good, but when done for the purpose of evolution.
– It's bright. Even companies that historically antagonised it, like
Microsoft, have now fully embraced it.

63. Looking Ahead
• What are your thoughts about the future of Open Source?
– IMHO, the Open Sources is still struggling to find the perfect
survival model, to combine the spirit of the Open Source with
the need of paying the bill. We see several models and hybrids
there, but there is not perfect, guaranteed receipt .
– It will never be the only way. It will always be a major way.
– It is the easiest way for individuals, teams and organizations to
collaborate and as such it will always be common option.
– It is by no means a mandatory requirement for success.
Live and let live.

64. Looking Ahead
• What are your thoughts about the future of
Open Source?
– Open Source is finally emerging as a real business
model. Its important that we have diverse sub models
that allow companies to benefit from using the
software without risk. If there is a goal in mind to
generate revenue be sure to provide that value and
allow that revenue to foster the core elements of the
software.

65. Looking Ahead
• What are your thoughts about the future of Open
Source?
– We need to create more of a community in order to
sustain the ecosystem. Business models are economic
solutions to the underlying free rider problem, but what
is a more promising approach to me are social solutions
that involve creating community that encompasses those
who make open source as well as those who use and
deploy it, and which infers a set of normative behavior on
all that leads to a strengthened ecosystem.

66. Anything Else?
• What else would you like to say?
– Open source is the future. But making MONEY
out of open source is hard. You need recurring
revenue. This is support agreements, or
microtransactions, or something that makes it
easy for lots of people to give you small amounts
of money.

67. Anything Else?
• What else would you like to say?
– I like to think of open source software as sacred. Open
source software is unique and very different than
commercial software in this one way: it asks nothing from
you, and seeks nothing other than to be of greatest use.
This is quite different from commercial software, which --
yes, while it seeks to be of use -- is essentially paraded
out as a means to an end, that being the profit motive.
Open source software seeks only and ever to be put to
best use. Full stop.

68. Conclusions
• Consider MONEY at the outset
• Metrics matter!
• Licensing model (including the CLA) is very,
very important
• Community is key

69. Conclusions
• Given the multiple dimensions of any Open
Source project, are the Software Engineers
that create the code necessarily the right
people to orchestrate, maintain and promote
the other elements of the project?
• Enlightened Software Engineers will seek help
from outside of their own sphere.

70. Massive Thanks
• Benny Prijono, PJSIP
• Mark Spencer, Asterisk
• Anthony Minessale, FreeSWITCH
• Lorenzo Mangani, Homer
• Rob Thomas, FreePBX
• Daniel-Constantin Mierla, Kamailio
• Lorenzo Miniero, Janus
• Bogdan-Andrei Iancu, OpenSIPS
• Emil Ivov, Jitsi
• Dave Horton, Drachtio

71. In closing
• When we make something sacred, we are really just creating a trigger for our
own best behavior. In the same way, I would like to see the open source telecom
community form over a respect and reverence for open source software, with the
understanding of the obligations that it confers on all of us -- both makers and
users. Those of us who make open source need to understand that our code is
nothing but dry words on a page until someone comes along and breathes life into
them by deploying it. And those who use open source need to understand that
they are participating in an ecosystem and by their actions are always either
destroying or re-generating it. There are a hundred ways to help the ecosystem
grow; unfortunately, it is often presented to users as only one way: pay me
something for my software. We need to be more thoughtful about how to sustain
the ecosystem, and I believe a set of self-reinforcing norms governing community
behavior is required for virtuous success.

72. Thank you
• The survey is still live:
– http://bit.ly/duffett-oss-survey
• Find me on LinkedIn: davidduffett
• Twitter: @dduffett