The code base of the open source technology you want to build your business on is rock solid. Releases are rolling out early and often. The test suite is comprehensive and running regularly. Code is well performing without any glitches. Everything is in place that defines a successful open source project—or isn't it?
This talk tries to highlight some of the key business questions when dealing with open source. In addition to coding skills, topics like people management, naming, trademark enforcement, licensing, patents, PR, and more become topics that even the most tech-centric open source products have to deal with. The way these topics are dealt with defines how stable the technology you are looking at today will be in years to come. The Apache Software Foundation has a ton of wisdom in running open source projects targeting long term success.
After years of using open source projects, running my own projects, founding meetups and conferences, watching others thrive or fail, I believe that coding skills alone aren't sufficient to turn a "private playground code base" into an open source project that others can rely on.
Inspired by 140 characters of truth published here, the talk will focus on what topics that are usually not taught as part of programming courses will cross your way when dealing with open source—either as a user or as a contributor:
• People: Is the project willing and able to attract more contributors? Is it able to survive if the leader loses interest or time to continue contributing? How does the project deal with requests coming from the user base? How easy is it for users to get their issues fixed?
• Trademarks: Why should you care about trademarks from the beginning? How do you deal with others infringing on your trademarks?
• Copyright: Why should you care exactly which license you choose?
• PR: While writing release notes is common practice and composing changelogs is pretty easy, the resulting documents are hard to grok for editors and won't get you on the front page of any magazine. Nor will they help you get visibility on common social media systems that might be key in informing your users about recent releases.
While being excellent at all topics isn't vital from the start, answers to governance questions decide what a project looks like a few years from its start. This talk will start with a brief overview of the history of The Apache Software Foundation, diving into what the ominous thing called "The Apache Way" means, why the slogan "community over code" is not just a slogan, and why every user of the foundation's projects is invited and treated as a potential future developer of the software they use. We will look at some of the criteria every software engineer should be aware of who has to make a decision on which open source project to use.
Speaker
Isabel Drost-Fromm, Open Source Strategist, Europace AG
Open Source is just about the source code—isn’t it?
1. Open source is just about the source, isn't it?
“The Apache Way – 19 years of OSS experience in 40 minutes”
Slides licensed under CC-By-NC-SA 4.0
2. Based on a talk I first gave at FrOSCon 2016, Apache Way talks by
Lars Eilebrecht, Justin Ehrenkrantz, Brett Porter, Nick Burch, Rich
Bowen, feedback from Shane Curcuru, input from Bertrand Delacretaz,
Pieter Hintjens, Zaheda Bhorat, corrections from Sally Khudairi,
Mark Thomas, Phil Steitz, Daniel Ruggeri, stuff I read in “Producing
Open Source Software” by Karl Fogel, stuff I read in “Building
successful online communities” by Kraut/ Resnick, stuff I read
in “Social Architecture” by Pieter Hintjens, and numerous conversations
on Apache mailing lists.
And most likely many I forgot to mention above.
3. Isabel Drost-Fromm
Open Source Strategist Europace AG
http://www.europace.de
(Board) Member Apache Software Foundation
http://www.apache.org
Co-founder Apache Mahout
http://mahout.apache.org
Co-founder Berlin Buzzwords
http://www.berlinbuzzwords.de
Co-founder FOSS Backstage
http://www.foss-backstage.de
Image by Thilo Fromm.
4. Image taken shortely before FOSS Backstage Microssumit Berlin @ Europace AG
Batches were printed based on the names ppl used for registration.
5. Mission: Provide software for the public good by providing
services and support for many like-minded software project
communities of individuals who choose to join the ASF.
Funding: Individual donations + corporate sponsorships.
US 501(c)(3) nonprofit charitable organization
Established in 1999.
https://www.apache.org/foundation/
7. Project users
Yonik’s law of Patches: A half-baked patch in Jira, with no
documentation, no tests and no backwards compatibility is
better than no patch at all.
https://wiki.apache.org/solr/HowToContribute
Image based on graphic by Brett Porter.
9. Project users
Project committers
Project Management Committees
Project Management Committees
Project Management Committees
Image based on graphic by Brett Porter.
10. Project users
Project committers
Project Management Committees
Project Management Committees
Project Management Committees
Apache Software Foundation
Members
Image based on graphic by Brett Porter.
11. Project users
Project committers
Project Management Committees
Project Management Committees
Project Management Committees
Board of Directors
Apache Software Foundation
Members
Image based on graphic by Brett Porter.
12. Project users
Project committers
Project Management Committees
Project Management Committees
Project Management Committees
Board of DirectorsOfficers Comittees
Apache Software Foundation
Members
Image based on graphic by Brett Porter.
13. Image taken at Open Source Summit 2017, Prague; talk by Zaheda Bhorat,
https://osseu17.sched.com/event/ByN2/love-what-you-do-everyday-zaheda-bhorat-aws.
14. Image “Swiss Flag” by crackers93
https://www.flickr.com/photos/crackers93/2832784903 (CC-By-2.0)
https://blogs.apache.org/foundation/entry/success_at_apache_project_independence
15. Image “Copyright, Patent, or Trademark” by BusinessSarah
https://www.flickr.com/photos/businesssarah/5977958263 (CC-By-2.0)
16. Image “Copyright, Patent, or Trademark” by BusinessSarah
https://www.flickr.com/photos/businesssarah/5977958263 (CC-By-2.0)
17. Inspired by https://www.gnu.org/licenses/license-recommendations.en.html
Copyleft OSS Non-Copyleft OSS
Small enough so you don't care
Libraries to push standards forward
LGPL for libraries, especially if
there are other similar libraries
AGPL for server software
GPL for everything else
Projects to change established
economics.
I care about any and all of my
downstream users to have all
of “use”, “study”, “share”, “improve”:
All I want to ensure is that my very own project gives
the “use”, “study”, “share”, “improve” freedoms:
18. Inspired by https://www.gnu.org/licenses/license-recommendations.en.html
Non-Copyleft OSS
Small enough so you don't care
Libraries to push standards forward
Projects to change established
economics.
All I want to ensure is that my very own project gives
the “use”, “study”, “share”, “improve” freedoms:
Apache License 2.0
https://www.apache.org/licenses/LICENSE-2.0
19. Image “Copyright, Patent, or Trademark” by BusinessSarah
https://www.flickr.com/photos/businesssarah/5977958263 (CC-By-2.0)
20. Image “Dragon” by Joseph Wu
https://www.flickr.com/photos/josephwuorigami/1367278646 (CC BY-NC-ND 2.0)
21. Image “Copyright, Patent, or Trademark” by BusinessSarah
https://www.flickr.com/photos/businesssarah/5977958263 (CC-By-2.0)
24. Apache: Community over code.
“A project without people is a dead project (or at least deep asleep).”
25. Project users
Project committers
Project Management Committees
Project Management Committees
Project Management Committees
Board of DirectorsOfficers Comittees
Apache Software Foundation
Members
Image based on graphic by Brett Porter.
26.
27. Image “Newspaper colour” by NS Newsflash https://www.flickr.com/photos/62693815@N03/6277336776 (CC-By 2.0)
44. “Thank you card” (CC-By-NC-SA 2.0)
“ThankYou_rush's” (CC-By-SA 2.0)
“merci” (CC-By 2.0)
“Thank You Note” (CC-By-NC-SA 2.0)
45. Contributions include not only source code, but also
documentation, constructive bug reports, constructive
discussions, marketing and generally anything
that adds value to the project.
https://community.apache.org/apache-way/apache-project-maturity-model.html
46. Merit does not go away.
https://www.apache.org/dev/committers.html#committer-set-term
47. Image “Money” (CC-By 2.0) by Tax Credits
https://www.flickr.com/photos/76657755@N04/7027604401
54. Machines to host infrastructure.
People to take care of these machines.
Press, Legal, Admin, Travel support, Trademarks.
Image “Server” (CC-By-2.0) by dariorug
https://www.flickr.com/photos/darioruglioni/2613279524
61. Image “QR-Code” (CC-By-NC 2.0) by Daniele Devoti
https://www.flickr.com/photos/dadevoti/8024176011/
People
Licensing
Trademarks
Patents
Marketing
Education
Documentation
Design
Event management
Social media
Support
Funding
Motivation
Communication
Why should I care?
All I want is to launch my business.
Get the product out while I still have enough runway.
You are betting your core business on a piece of technology.
How are decisions around it’s direction made?
How timely are bugs being fixed?
Can you get involved in it’s decision making process?
What can I learn from participating – even if just reading?
The foundation exists to provide software for the public good by supporting it’s projects.
If you are a user of our projects – the goal is to pull you in and turn you into an active supporter.
Does what projects don’t like doing: Legal, finance, infra and administrative support for projects.
Board has no say in technical direction.
It does have a say in project governance.
It ensures the running of the foundation.
Born out of NCSA HTTPd development
Apache group took up development where NCSA was ceasing support.
From the beginning international, globally distributed, volunteer based.
A lot – but not all – of what is done at Apache is done on a volunteer basis.
This does not mean nobody is paying for it.
This does not mean it is all altruisitc w/o commercial interest.
Provides a neutral space for players to collaborate.
How does that work?
Let's start with the easy to understand legal aspects
Typical set of choices.
At Apache there’s just one:
Easy for downstream users.
Think dependencies pulled into our projects.
Think legal provenance of code donations.
Think people contributing significant amounts of code and how that relates to their local employment status.
Mixture of volunteers, pro bono support, paid services, knowledge within projects.
Sorry, I personally won't go into any details here.
As a user you want to be certain that what is sold as Apache X actually contains project x – instead of some viruses, malware, modified versions incompatible with upstream.
Name should be unique, easy to remember, not conflict with existing projects/ products.
Trademarks should be enforced.
Annecdote about Hadoop/ Nutch: Kids are good in coming up with these names.
Again mixture of volunteers, pro bono support, paid support and education for individual projects.
Let's continue with the messier people aspects
Projects go to where their users are.
but they will pull them back into official channels.
Apache projects use the press:
Press Releases, articles, books.
Often paid support is available – but from third parties.
Honest invitation though: Joining one of the project communication channels is a great way to get help and support from those who built the software.
Why: Grow community from users.
Projects should be easy to get started – look for “how to contribute” pages, build system should be standard, version control should be standard, easy issues should be flagged as such, look for where the project communicates.
Mailing lists:
Public
Searchable
Linkable
Archived.
Issue Trackers with additional structure.
“Public” has exceptions:People related discussions are private.
Security related discussions are private.
Security team: Covers reporting, dealing with issues, getting CVE numbers, communications.
The typical answer would be “patches welcome”
Explicit help request – Mahout example.
Get started issues in Hadoop project.
Expectation management – Feature promise in all volunteer is hard.
Lazy consensus
Those who do the work are the ones taking the decision.
Scratch your own itch.
Taken to the extreme: I organise meetups. If you want to make sure the next meetup happens at a date and time that works for you, volunteer as a speaker.
Here's the patch.
Often to scratch the your own own itch.
With Patch submission the clock starts ticking.
There's only so much time you can dedicate to the patch esp. when done during working hours.
Context switching takes time, so long back and forth switches aren't good.
Often first feedback is automated.
Often existing committers are helpful.
In general the intention is to pull you in.
Don’t work for hours and days – share early versions.
Look for what the project actually wants.
Chocolate works: Swiss chocolate for me, Winterfeld Schokoladen for a certain Mahout PMC member.
I got a mention + thank you in the JIRA issue related to the patch (which I didn't even have to create), a thank you in the commit message, a thank you in the next release notes. None of that cost anything. All of that made the whole thing great and worthwhile – even for my employer who could then go and brag with their contribution.
Thank you is cheap. And very common in OSS projects.
Better yet – in good cases you get a qualified thank you that motivates further contributions.
Merit does not go away.
But merit does not buy influence.
It buys further priviledges (often called karma).
It buys further responsibilities.
Merit only goes so far.
Risk: Having people contribute a lot – after hours.
Be transparent about your motivation, about what you need next – talk if you need support getting paid for what you do for a project:
Consulting
Getting hired
Giving Trainings
Speaking of finding money:
You will end up wearing multiple hats.
Be sure not to confuse them.
Be sure to tell others which hat you are wearing at which time.
Anecdote: A keynote at Berlin Buzzwords.
Link to volunteeritis mail by Roy
Hosting – code, communication, website.
All communication since the beginning of the foundation.
Without lockin.
Machines and people to take care of them are paid for their work by the foundation.
Poisonous ppl by Brian Fitzpatrick/ Ben Collin Susman
Dealing with flamewars by Kristian Köhntopp.
Anecdote: Berlin Buzzwords handover
Document – not only how things are done, but also what has to be done for what reason.
Delegate.
Great way to get started: Try out getting started docs and show where they don’t work.
It’s more than just code.
This was the manual.
Go out there, get your hands dirty and get involved.
Learn more about Apache and other foundations here in Berlin in Summer