Open Source is just about the Source, isn't it?
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 94 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/45858 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
FreewareOpen sourceoutputFeedbackArchitectureElectronic mailing listOpen sourceCollaborationismSlide rulePresentation of a groupXMLUML
00:31
Open sourceElectronic mailing listoutputFeedbackArchitectureComputer-generated imageryWhiteboardSoftwareOpen sourceWeb serviceFront and back endsIntegrated development environmentSystem administratorWeb 2.0Product (business)TelecommunicationObject-relational mappingSoftware developerMereologyPatch (Unix)Server (computing)OvalProjective planeComputer animation
02:55
Image registrationProduct (business)AreaSoftware bugStatement (computer science)Decision theoryProjective planeSoftware developerInformation securitySoftwareService (economics)DemosceneMultiplication signLecture/Conference
04:05
SoftwareService (economics)Self-organizationSoftware developerSimilarity (geometry)QuicksortDisk read-and-write headProjective planeComputer animationLecture/ConferenceMeeting/Interview
04:41
Computer-generated imagerySoftware testingPatch (Unix)Projective planePhysical lawPatch (Unix)ImplementationOpen sourceShared memoryJSONXMLUMLLecture/Conference
05:29
Computer-generated imageryDigital rights management1 (number)Order (biology)Projective planeSoftware repositoryDigital rights managementOpen sourceNumberDensity of statesXML
06:13
Basis <Mathematik>WhiteboardDecision theoryMereologyArithmetic meanLecture/Conference
06:50
Computer-generated imageryWhiteboardDigital rights managementSoftwareInstance (computer science)Office suiteWeb 2.0Group actionProjective planeServer (computing)XMLProgram flowchartLecture/ConferenceComputer animation
07:23
SoftwarePoint (geometry)Projective planeArithmetic meanControl flowDataflowFood energyBasis <Mathematik>Multiplication signMilitary baseSoftware maintenancePatch (Unix)Mobile appLecture/Conference
09:07
MaizeComputer-generated imagerySpacetimeProjective planeOpen sourceRule of inferenceLecture/ConferenceDiagram
09:42
CASE <Informatik>Matrix (mathematics)Decision theoryShared memoryArithmetic meanSource codeCodeMixture modelOpen setLocal ringService (economics)Integrated development environmentComputer animationJSONXMLLecture/Conference
11:02
Computer-generated imagerySeries (mathematics)Projective planeFilm editingPerspective (visual)WordBinary codeBounded variationOpen sourceEvolutionarily stable strategyComputer virusOffice suiteRevision controlJSONXMLLecture/Conference
12:23
CodeOpen setOpen sourceMessage passingAnalytic continuationProjective planeResultantCodeFocus (optics)Computer animationLecture/Conference
12:56
Computer-generated imageryTelecommunicationTwitterProjective planeBuffer overflowStack (abstract data type)Electronic mailing listEmailXMLProgram flowchartLecture/ConferenceUML
13:35
Theory of relativityHypermediaSoftwareRepresentation (politics)EmailRotationAreaProjective planeElectronic mailing listLecture/ConferenceComputer animation
14:16
BuildingWeb 2.0Software developerSource codeTelecommunicationOpen sourceRevision controlPhysical systemSoftwareProjective planePlastikkarteWeb pageMetreProcess (computing)Standard deviationOnline helpLecture/Conference
16:20
HypermediaScaling (geometry)TelecommunicationCategory of beingEmailElectronic mailing listMultiplication signLink (knot theory)Data structureException handlingSearch engine (computing)AdditionRight angleLecture/Conference
17:23
Decision theoryTelecommunicationEmailArithmetic meanElectronic mailing listAssembly languageVideo game consoleLecture/Conference
18:14
Electronic mailing listDecision theoryEmailFlow separationMathematicsPoint (geometry)Software developerInformation securityCommutatorOpen sourceComputer animationLecture/Conference
19:26
Electronic mailing listError messageElectronic mailing listDecision theoryInformation securityRule of inferenceException handlingMathematicsPatch (Unix)Source codeXMLLecture/ConferenceComputer animationDiagram
20:03
Online helpPatch (Unix)QuicksortProjective planePhysical systemOrder (biology)Software testingPoint (geometry)Lecture/Conference
20:55
Digital photographyDecision theorySoftware developerVotingPhysical systemDiagramComputer animation
21:42
Decision theoryPhysical systemDecision theoryDamping1 (number)Product (business)Table (information)Patch (Unix)EstimatorMultiplication signSinc functionBasis <Mathematik>Set (mathematics)Lecture/Conference
23:12
Inclusion mapView (database)Java appletFunction (mathematics)AreaWebsiteProjective planePatch (Unix)EmailElectronic mailing listService (economics)XMLProgram flowchartLecture/ConferenceSource code
23:47
Computer-generated imageryMultiplication signProjective planePatch (Unix)Unit testingShared memorySynchronizationDisk read-and-write headProgrammierstilFeedbackCodeLecture/Conference
24:42
Computer-generated imageryData storage deviceHand fanException handlingPatch (Unix)Open sourceGoodness of fitMultiplication signWordProjective planeInternetworkingMessage passingBoss CorporationUMLLecture/Conference
26:38
Data modelCapability Maturity ModelSource codeSource codeCapability Maturity Model IntegrationProjective planeLecture/Conference
27:16
Moment of inertiaWeb pageSoftware
27:54
Product (business)Multiplication signPoint (geometry)SoftwareLecture/Conference
28:33
Computer-generated imageryTable (information)Projective planeMultiplication signMereologyProduct (business)Order (biology)Right angleSlide ruleRevision controlDataflowLecture/Conference
29:55
Statement (computer science)Projective planeInformation technology consultingService (economics)Multiplication signInsertion lossLecture/Conference
30:27
Multiplication signLecture/Conference
30:59
Field (computer science)EmailWordPeer-to-peerMereologyInformation overloadLecture/Conference
31:39
Computer-generated imageryService (economics)Multiplication signWebsiteTelecommunicationCodeDecision theoryProjective planeVirtual machineArithmetic meanBackupPhysical systemSeries (mathematics)Open sourceInternet service providerRight angleVolumenvisualisierungLecture/Conference
32:58
Projective planePresentation of a groupMultiplicationPerspective (visual)Computer animation
33:42
FreewareOpen sourceSoftwareTelecommunicationOpen setLocal ringDemosceneEvent horizonData conversionInformation privacyLevel (video gaming)EmailElectronic mailing listFigurate numberMeeting/Interview
34:53
Projective planeMultiplication signSoftware developerTelecommunicationProcess (computing)QuicksortPhase transitionBasis <Mathematik>Lecture/Conference
35:32
Multiplication signSystem callPoint (geometry)Speech synthesisProcess (computing)Digital video recorderDrawingMeeting/Interview
36:11
SoftwareMultiplication signProjective planePoint (geometry)Core dumpSound effectSimilarity (geometry)Event horizonOpen sourceFigurate numberLecture/ConferenceMeeting/InterviewComputer animation
37:46
Computer-generated imageryWhiteboardSoftware developerExpert systemCausalityMultiplication signScaling (geometry)BitCurveComputer animationLecture/Conference
39:08
TelecommunicationDigital rights managementEvent horizonSocial softwareComputer-generated imageryOpen sourceSource codeFlow separationState of matterLevel (video gaming)Cone penetration test
39:41
CodePatch (Unix)Computer-generated imageryLattice (order)Point (geometry)Electronic mailing listProjective planeFile systemSearch engine (computing)Multiplication signGroup actionNetwork topologyMountain passInternetworkingComputer animationLecture/Conference
41:14
FreewareOpen sourceComputer animation
Transcript: English(auto-generated)
00:08
Welcome to my presentation on open source is just about the source, isn't it? So I'm the only one who's standing between you and dinner outside, so I try to make
00:21
it brief but interesting. The presentation isn't just based on slides that I've done, it's a collaborative effort, there's tons of other people who have been working on that. So why am I standing here telling you something about the ASF? I happen to be open source strategist at Europace in Berlin.
00:46
Apart from that I'm a member of the Apache Software Foundation, I've co-founded Apache MaHoud, Berlin Buzzwords and FOSS Backstage. So because we are only like few people, what I would like to understand is where
01:02
you are coming from. How many of you are working actively on an open source project? One? Okay. So I'm going to do an experiment which I typically do for meetups. I'll take the microphone, hand it around and you give me like a three hashtag motivation
01:24
of why you are here, who you are or what your background is. I am a backend developer working on ORMs and stuff and I am here to see how the ASF works
01:49
from the inside. So my name is Werner Krause, I come from Cologne and I have 20 years experience in
02:05
system administration for telecom or production environments and I see, yeah, Apache product most of the web service but not so much known that other products
02:23
also founded, grounded from Apache. Yeah, I'm just a user of Apache products like the web server, Hadoop, Kafka and so on. So I would like to know where it comes from.
02:56
So why should you even care about how the ASF works in the background? We've had two people here who are users or who know the ASF from their product.
03:06
If you build your business on top of Apache software, you probably want to know what's going on behind and how sustainable development happens behind the scenes and who drives it. You probably want to know how decisions are being made with respect to where a project
03:22
is going and you probably want to know how timely bugs are being fixed, how timely security issues are being fixed and how people are dealing with those security issues and last but not least how you as a user can start participating and contributing back.
03:40
So the easiest way to get started is to have a look at the mission statement which says it's there to 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. What's important here is that it's the ASF as a foundation is there to support the project
04:05
plus those people working on those projects should be following sort of a similar way of development and what's important to people working at the ASF is that those communities are composed of individuals. Some of you mentioned that you are using Kafka, there is a company behind it but those
04:26
participating in the project are supposed to participate with their committer hat on their head, not so much with their I'm employed at company X hat. So how does that work? You start as a user.
04:42
If you're anything like me it won't take you very long to find something that doesn't work quite right. Could be documentation, could be an implementation, could be some kind of issues. So there is a saying from the Lucene project actually, Lucene and Solr, which is Yannick's law of patches. A half-baked patch with no documentation, no backwards compatibility is better than no
05:06
patch at all. So if you find something, share that something very early. The biggest mistake that I ever did with getting started in open source was to polish my patch forever. It never went out.
05:23
When you do that, when you contribute back, you're being accounted for as a project contributor. If you do this enough, people will give you write access to the source repo which makes you a committer. So deciding on whether you get write access or not are being counted as project management
05:43
committee members. Those PMC members aren't the ones who are ordering others to meet for, so essentially you can't order volunteers around.
06:01
So you're the ones voting new committers in, but apart from that they are steering the discussions. On top of all that, there is a number of ASF members. So if you are involved in a couple of projects, if you get deeper into how those projects
06:24
work, you become elected as a member of the foundation. It doesn't mean that you have to pay to become part of that, it's just that the existing members vote you in. And those ASF members are then delegating certain decisions to a board of directors,
06:45
those are nine people. They are elected on a yearly basis. And they then steer what we've heard about before, that the ASF is there to serve their projects. So there are certain offices and committees like for instance dealing with legal
07:03
issues that are being established to support those projects. So where does the ASF come from? We've got a few users here who are using Apache HTTP. So there's a web server, that project was born out of a research group, NCSA.
07:24
There were a couple of customers of that project who were using it for their daily business, but at some point the original maintainer went away and didn't put any further effort into it. So those people who were depending on that software were starting to share patches. At some point they needed a legal entity which could take care of the trademark which
07:49
they could use to do certain business and that's how the foundation was created. From the beginning it was international, it was globally distributed and it was volunteer based.
08:00
Volunteer based here doesn't mean that it's work being done for free, but everyone has like zero incentive. But volunteer based means that volunteer energy comes and goes apps and flows. Depending on when you have a certain business requirement to work on a patch, you put in this effort and then you can move away and come back later.
08:24
This is fairly important to how the culture at the ASF was originally created. There is such a thing as merit doesn't go away. So once you've put effort into a project, say once you are a committer, if at some point in time you don't have the time to work on that anymore,
08:45
you can take a break of a week, a couple months, a couple years, and return back later to the project and start from where you left off. Of course volunteer basis here doesn't mean that nobody's paying for this work.
09:00
It doesn't mean that it's completely altruistic and without commercial interest. What the ASF provides today is a neutral space for players to collaborate. We've heard about Hadoop before. It's a project that's being worked on by multiple players, but which is being held at the ASF where they can collaborate.
09:23
So how does that work? Which kinds of rules are there? If you start an open source project right now, first of all, what you have to think about is the easy legal aspects. Say copyright, trademarking, and patent.
09:43
For copyright, there is a decision matrix shared by the FSF on which license you should use depending on your use case. At the ASF, it's easy. For downstream users, it's all Apache licensed.
10:01
So what does that mean? Which kind of legal support does the ASF have to give here? Think of dependencies being pulled into projects. Which license does the ASF have? Are these licenses compatible with the Apache license? Think of legal provenance for code donations.
10:20
Source code that before was developed in a proprietary environment, probably not checked as well as before. This has to be checked and brought into the foundation. Think of people contributing significant amounts of code and how that relates to their local employment status. If you are here from Germany, essentially if you are employed
10:41
at one company, everything you do belongs to that company. How does that play with open source? The legal aspects are being taken care of by a mixture of volunteers and pro bono support, also paid services, but there's also a lot of knowledge within the projects themselves.
11:02
I won't go into patent issues. There is an FSOE booth down the hallway that you can ask. What about trademarks? Why are trademarks interesting to ASF projects? As a downstream user, you want to be certain that what is offered
11:20
to you to be Apache X is actually Apache X. You don't want some binaries that contain malware, viruses, modified versions that are incompatible. So from a project perspective, the name should be unique. It should be easy to remember, and it should not conflict with existing projects.
11:41
Finding such a name and checking it is being supported by the ASF. How do I find such a name? Just an anecdote. One of the original creators of Hadoop, as well as Nutch, once said that there is a very easy source for new names.
12:01
That is, kids listen to your children by bubbling. Like, Nutch was one of the first words that Duck Cutting's children used. Hadoop was the name of the toy elephant of one of his children. Well, that's like a nice source for non-infringing names.
12:26
So let's continue with the messier aspects of open source, which is like the people aspects, the leadership aspects. There's one mantra at CASF, which is community over code, which I would translate as a project without people is a dead project,
12:43
or at least a project that's very, very deep asleep. That's why there is such a focus on community at CASF. Who do we consider to be the community? Essentially downstream users. So where ASF projects recruit new people from is the user base.
13:03
And that's how all of the communication is supposed to be set up. Typically, projects will go to where their users are, say Twitter, say Stack Overflow, but don't be surprised if people are trying to pull you back in into official project channels.
13:25
What are official project channels at the ASF? That's typically a mailing list that you subscribe to, and then you can start. ASF projects, of course, use the press. They do have a very capable press and media relations team.
13:45
However, projects are also encouraged to talk themselves to press representatives, to send out press releases for software releases, write articles as well as books.
14:00
Oftentimes, there is paid support available for you. Typically, that comes from third parties. There is an honest invitation, so if you are using any ASF project, join the user mailing list. Typically, paid people will be very helpful. They will answer your questions, and it's a great way to talk directly
14:20
to the developers themselves. Why that invitation? That's because those projects, again, grow their communities from their users. Typically, projects should be easy to get started. If you look at the project web page,
14:40
there should be some how to contribute pages. Build system should be fairly standard. Version control should be either subversion or, nowadays, Git or GitHub. And typically, you will find issues in the issue tracker which are being marked as easy. What do I mean by easy? We used to have a Hadoop hackathon like 10 years ago in Berlin,
15:03
and we had like 10 to 15 people in the room, and people were collecting ideas of what to work on during the hackathon. After that, we did a show of hands of what's the most popular issue so that we could collaborate. The issues that won the competition was a big surprise to myself.
15:24
It was, help me go through the contribution process. There was a Hadoop contributor in the room. He took those people to the issue tracker, and they were issue-smart as getting started, or very easy, or something like that.
15:40
Those were issues which were like documentation fixes, typo fixes. What this helped people do was to just understand where is the source code, how do I get the source code built, and how do I make my first contributions. What do I write in the issue, and what happens then afterwards?
16:00
Like, which kind of automated checks are being done, and what does a reviewer actually do? And this was very helpful for seasoned software developers who, however, had never contributed ever in their past. So how does this communication work? Typically, what you have on the software team,
16:21
especially if it's a two-pizza-sized team, is that everyone communicates with everyone, depending on their needs. After a certain team size, this doesn't scale anymore. So for those projects, what they typically have is mailing lists, and they've got a couple of properties which make them more effective to be used.
16:42
First of all, they are public, with one exception, which we'll get to in a second. Second, they are searchable. So there's a search engine on top, so you said you can find previous discussions. Third, they are linkable, and those links are supposed to be stable throughout time.
17:02
And fourth, they are being archived. So if you start with HTTP, right now, I would like to invite you to go to the mailing list archive, and you will find emails back from 1995, like from the very beginnings. Plus, of course, you've got issue trackers
17:21
for additional structure. So there's a mantra there. If it didn't happen on the mailing list, it didn't happen. So it doesn't mean that all communication happens on the mailing list. There are people doing face-to-face communication, but typically, what happens is that no decisions are being made there, but those decisions are being made on the mailing list.
17:40
Why on earth would one want to do that? We are here in Germany. There's probably people on the East Coast, there's people on the West Coast, and there's people in Australia. It's friggin' hard to get all of them on the same cons call, because it will mean that one of them has to get up at three a.m. So if you have a cons call, people will communicate with you, make a write-up,
18:02
take it to the mailing list, where asynchronously, then someone can gym in and tell people, hey, that's a great idea, or it's not. So what kind of lists do projects have? There's a user list. If you use a project, get subscribed to that list. If you've got any questions, they will be answered there.
18:21
Apart from that, even just reading those lists, you will find out which mistakes other people are doing so that you don't have to repeat them. There's typically a dev list where development decisions are being taken. Plus, there's typically one list where commits go to,
18:40
like every change in the resource reaper goes to commits at. Some projects have separate mailing lists where the traffic on your issue tracker is being mirrored to issues at. Plus, and this is the gotcha, there's one private list. Why is there a private list? If you're discussing to invite someone as a committer
19:02
and this doesn't work out, that's not very nice for the potential committer. So this is being discussed in private. Also, if there is a security issue, then this is being discussed in private up until the point where it's fixed and officially announced. Because you don't want your downstream users
19:20
to be vulnerable while you're working on a fix. Now, if you wanna see which lists there are, you can go to lists.apache.org. You can see which discussions are happening. You can subscribe nowadays.
19:40
And you can search through it. So that's the exception to the rules. There's all discussions and decisions have to be public. With two exceptions, people discussions and security issues. Now, if you want a change to be made,
20:02
the typical answer will be patches welcome. Is that sort of a go away, we don't want to work with you? In my experience, typically not. Typically it's an invitation. What's also being done is that people send out explicit help requests for, I have created the Apache Mahood project
20:22
and for a couple months and years, people thought that in order to become a committer or in order to be recognized, what you have to do is to submit a huge patch with large modifications. This wasn't at all what we needed. We needed more documentation. We needed more testing.
20:40
We needed support with our build system. We needed support with performance checks. So at some point, I wrote up explicitly what we needed and suddenly contributions started going up. So how are decisions being made?
21:03
Usually, so there's two ways. First of all is consensus driven development. So people will try to find a consensus about how to move forward. Now, you don't want for each decision, everyone to jump up and say, hi, I'm for it. So there's such a thing as lazy consensus.
21:22
Lazy consensus means I tell you that I'm going to do X, Y, Z within three or four days. Please speak up if you don't want me to do that. So I can move forward and you can be lazy and not answer. If that doesn't work or if you need
21:41
like an explicit decision, there's a typical voting system. Usually it's those who do the work are the ones who take the decisions. Most of these, many of these projects are, especially with HTTBD, driven by a scratch your own itch kind of contributions.
22:03
So those working on it are also using that stuff in production and they are fixing the issues that they have problems with. And these contributors also tend to be the ones that stick around. And that stick around across employment and across communities that they participate in.
22:25
To take this to the extreme, I'm pulling together an ASF Berlin, ASF members meeting on an irregular basis for food. It used to be for dinner, since many people now in the community have children, it's now breakfast or brunch.
22:41
The way it works, if you want the next meetup to happen at a certain date and time, what I tell people is to make it happen yourself. And it's fairly easy, it's just book a table and make an estimate of how many people will be there and publish that date. So that's why it's easy. It wouldn't be very nice if I said so
23:01
for a large conference like FrostCon, because that takes a lot more work to set up. Booking a table at a restaurant in Berlin, I hope that that's fairly easy. Now with the patches welcome, the sites that I showed you earlier, they list at apache.org. So that's an Apache project itself,
23:21
it's called Apache Ponymail, it's right now in the incubator, which means it's looking for new people to support them. If there's anything you don't like about these services, go to ponymail.apache.org and get involved. And people will be happy to help you out.
23:41
Now you started scratching your own itch and you submitted your first patch, what happens? For the project, the clock starts ticking, because there's only so much time that you can dedicate to a certain project. Typically, or at least sometimes, people will do that during their working hours, so there's only a certain amount of time
24:01
that they can put into it, and if they get feedback six months after they've submitted the patch, all of the knowledge of what went into it probably is out of their heads. Typically, the first checks sometimes are automated, like sync of code styles, sync of unit tests being added
24:22
or unit tests being broken. And after that, existing committers tend to be fairly helpful. One warning though, don't work for hours and days. In the dark, share what you have early, so that you get early feedback. So you will get a review and you will get
24:42
something as a reward. If you wanna reward me, I'm a huge fan of chocolate. There even was people who tried to bribe me with iTunes Store coupons,
25:01
except that I don't have an iPhone. What was much more helpful for me was to get a thank you. When I submitted my first patch, it went to JBoss, and what I got, it must have been like 10 years, 11 years ago, what I received was a mention
25:22
in the issue, a mention in the commit message, a mention in the release notes. I don't like finding my name on the internet, but it helped me to go to my boss and tell him, hey look, suddenly it's public that we know how to do open source. Well, we knew once.
25:41
But it helped him acquire new money from a research funding institution to get new projects in. So this helped me as a downstream user get more time to contribute to open source projects. So making these contributions open and public can be very helpful to convince those
26:03
who are standing between your user and your project to turn them into contributors. One good word of advice that I once learned at an ApacheCon was to not say thank you, and that's it, but to give a qualified thank you. Thank you for X because it helps me do Y better.
26:24
So this makes it more believable, but it also helps motivate which way to go further with your next contribution, because now you understand why you've been helpful to the project. So there is a Apache project maturity model
26:43
which isn't adopted by all of the projects, but which pretty much captures the best practices, and one of those that I like very well is the contributions are not only source code. They also include working with the press. They also include documentation.
27:01
They also include helping downstream users, and many, many things more. So this is something that typically should be rewarded within the project itself. We've had that already. Once you are a committer, that merit doesn't go away
27:21
unless you step up and say, hey, sorry, I don't want that anymore, bye bye. Now thank you only gets you so far. If you have a lot of people doing a lot of these stuffs after hours, there's a huge risk of people burning out.
27:40
However, those working deeply in these projects tend to have a good network. Why do they have a good network? That you probably do not see. Many of these projects have a powered by page. So those are the companies that publicly, that agree to publicly announce that they are using X, Y, Z in production.
28:02
Typically that's the tip of the iceberg. There's several more companies that are using these projects in production which don't dare to talk about it, which forget to add themselves. However, everyone within the projects knows that. So if you make your motivation clear and if you talk to these people
28:21
and those are issues that are being discussed in private or even face to face, then those people tend to have a good network to get you connected. At some point in time, you will end up wearing multiple hats. What do I mean by multiple hats? I remember a keynote speaker at Berlin Buswords
28:42
talking about Hadoop. And talking about the challenges that the community is facing. It was a very nice keynote and it was very serious and very Hadoop community oriented. Except that the slide decks that he used
29:00
always had the company logo in the lower right corner and everyone in the audience was thinking that all he does was to bash the community project in order to pitch his product at the end. He didn't do that. So after the keynote was over, everyone was happy but it was a very like tense keynote.
29:22
Ever since that happened, he makes it very explicit and very clear which hat he's wearing. Whether it's his company hat, whether it's his project hat, or when being a director, whether it's the director of the ASF hat. And that helps people understand his motivation and where he's coming from. Keeping flows apart of course isn't very hard.
29:44
Or it's fairly hard. That's why sometimes or often times you end up with people challenging whether there was a conflict of interest. So that's where we get to the mission statement where at Apache you're supposed to participate
30:01
as an individual. Where as soon as you're a committer or a PMC member you're supposed to act in the best interest of the project. Which as soon as you're being employed by someone providing consulting services for that project gets tricky.
30:22
So what do you pay with to become a member of the ASF? You pay with time and love. You dedicate time and work to the foundation and that's how you become a member. There are a few challenges by paying with time and love.
30:42
I do know people, someone is laughing here. I know people who are not laughing anymore because they have serious pain, like physical pain. So suddenly something incredibly boring like ergonomics becomes a thing that you want to think about.
31:02
There of course is a lot of experience over at the ASF with people taking on too much work and volunteering too much. If you Google the word volunteeritis you will find an email by Roy Fielding which is like ages old which explains that you shouldn't take up too much work. Which explains that you should give work back.
31:24
Trust me even those who have been part of the ASF since the beginning they aren't very good at that. So you will need peers watching over community members who are becoming overloaded.
31:40
So all of the services at Apache are being paid for with time and love, well mostly. There are a few things that the ASF actually has to put money into. One of those is hosting. For code and communication and website hosting. What they want to achieve is that all of the communication,
32:01
all of the decision making communication texts are being archived since the beginning of the foundation without render login. So for the backup systems, machines and people
32:24
have to be paid for to take care for that. So it doesn't mean that you cannot use GitHub as an Apache project, but all of the important communications that happens on GitHub is being mirrored back to ASF machines. So as soon as one provider goes away there is a backup and you can move to somewhere else.
32:43
Why are people there so picky? They are old enough to remember that once upon a time those what was very big and very like doesn't go away. Well it did, kind of. How does that work? Right now you can donate money to the ASF.
33:00
Companies donating money don't buy influence. Projects are still being run just by those committers. They also don't buy influence as in I want more money and more present marketing money to be put into project access you can't do.
33:20
So those are very simple text deductible donations. So in my perspective what is the advantage of going to the ASF? There's multiple more foundations, there's GitHub out there you can host your project anywhere you want. First and foremost for me personally
33:41
it means that you're not alone. So there's people that you can talk to who will answer questions and who will watch over you. Where can you talk about issues that you have with your community? You can go to dev at community Apache dot org which is a public mailing list. You can get started discussing there. If you've got questions that require
34:03
a certain level of privacy you go to members at Apache assuming you're a member of the foundation. What you can do as well is talk to people face to face at Apache Con because sometimes for some of those conversations you will need deniability.
34:23
It's also easy to come to an Apache road show which is like a new concept now where Apache tries to do smaller events at local places. Or you can simply come to Berlin to a conference called FOSS Backstage which is about everything. Open source, free and open source software
34:42
behind the scenes like also legal issues, communication issues, people issues, et cetera. So what kind of issues do you wanna discuss once you've got your projects here? You will have to figure out how to deal with growth. As soon as you have companies backing developers
35:00
to work on a project full time what you will have to do is to balance sort of like people wanting to contribute on a typical volunteer basis, on an off basis. I don't have a full time job to dedicate to that whereas people trying to move very quickly because they have many more hours each day
35:24
to work on that. So there is still communication how to find best practices for that. At some point in time you will have to deal with poisonous people. There is a talk by Brian Fitzpatrick in bank call assessments that you can look into.
35:42
There's another video recording on dealing with flame wars that was given by Kristian Koehn talk right here at FrostCon a couple of years ago. There is much more experience within projects that you can tap into. Speaking of community ties.
36:00
CASF of course has ties into neighboring projects as well as projects that CASF depends on as well as projects that Apache projects themselves depend on. Think OpenJDK, think Debian as someone packaging software from Apache, think Docker, think W3C3.
36:26
Something else you wanna think about as a project and something else that projects have to think about is handover. At some point in time people will either lose interest or will lose support for what they are doing
36:41
within a project. As a little anecdote, I created Berlin Buzzwords which is a conference on all things big data in Berlin back in 2009. It took me like five years to get rid of this such that the conference doesn't die because in the very first year
37:01
we did this together with an event agency but quite a few of the things that we had to do was on my desk and only on my desk. So it took education to those participating in the event that they shouldn't be using is available at apache.org if they have a question.
37:20
It took handing over contact details such that the event agency could start reaching out to sponsors themselves, could start reaching out to speakers themselves. Similar handover effects have to happen within open source projects because typically you have like a few core figures even if it's not just one figure and if one of them goes away
37:40
what they've been doing has to be handed over to someone else. One way to hand that over is by delegation of course. We don't have a white board here. When do you think is a great way to start with helping out improving documentation in your project?
38:01
Think of a time scale you're just about to start, you're becoming better or you're an expert. When do you start documenting? Hands up if you think at the beginning. Hands up if you think in the middle, more. Expert?
38:21
You know where, it was kind of a trick question. You want to document all the way during all of these times. In the beginning you will start writing great getting started docs. Cause those experts over there they don't remember what trouble you run into. You also want to continue working on the docs
38:41
when you're in the middle. Cause then you've got a bit more understanding and you also want to contribute documentation when you're an expert. Cause only then you can write about the deep down technical concepts that new developers will be interested in. So this kind of dedication happens
39:01
throughout the entire curve. So there's a couple more topics to talk about and thinking about open source that are not source code themselves. So this is my invitation to you to get your hands dirty and to get involved.
39:22
I would, if any one of you is traveling to the States there's going to be ApacheCon in Montreal in September. There's going to be several ASF people in Berlin in June 2019. And likely there's going to be an ApacheCon in Europe next year that's still in the planning stages.
39:42
However if you're a user of any Apache project what I would like to invite you to do is to join the user list. Likely also the dev list because this will help you understand the project better. Just one warning, at some point you may end up standing here.
40:01
Cause like in 2004, the way I got started and got into this funny foundation was by getting subscribed to user at nudge.apache.org. Nudge, nudge for those who don't remember
40:20
came from Apache Lucene. The goal there was to build an internet-scaled search engine. What they were working on was a nudge-distributed file system and a nudge mapper juice layer which today you know as the Hadoop-distributed file system and mapper juice layer. So it may take a while but at some point in time
40:42
like for many of the people that I know that are active within the ASF typically the way starts by subscribing to user at. With that I would like to conclude and have time for questions. Or you may want to join the group eating dinner outside.
41:07
Thank you.