[this article is available online at https://s.apache.org/4pjM ]
by Daniel Gruno In many respects, The Apache Software Foundation is like a dog. Some people like dogs, some like cats. The ASF doesn't care, it still loves you. Some people are female, some are male, some don't share the narrow dichotomy of the masses. The ASF doesn't care, it still loves you. Some people have cool parents, and a car, and money, and are connected with the right friends, and some are "strange" loners that can count their friends on one hand (sometimes you don't even need a hand!). The ASF doesn't care, it loves you anyway...as long as you feed it some code or documentation (or any of the other valuable contributions), you get love and respect in return. But before I start telling my story about a dog named Apache, I should probably tell you a little about myself. I've been involved with Apache (both the foundation and the good ol' HTTP Server) for five years now. I am a Member of the foundation, and the Chair of the Apache STeVe project. The reason I got involved and why I'm still here, working for the ASF as an infrastructure architect, is that I had an itch (several in fact) to scratch and a yearning to show the world that I could...do stuff! I came to Apache from an academic background. I had been studying at various universities in Denmark, initially Statistics and Business Administration, and later on Human Resource Management, so my assumptions about how Open Source worked were that it probably worked like academia works: You have an idea, you present it, ask for feedback, start a collaborative process and have your peers review it, then implement said idea once they all say it's okay. Now, in some regards, this is accurate, but the method of execution is vastly different. Academia is built around a mix of healthy and unhealthy inherent mistrust (in many respects akin to the notion of original sin in some beliefs). The healthy part was in my experience --and in very(!) simple terms-- attributed to critical thoughts of Karl Popper and like-minded science philosophers who, argue against _proof_ as a means of advancing science, but rather seek out a _lack of evidence against_ as the proper way to corroborate a theory (and in doing so removing things like "is there a god?" or "are gnomes real?" from the sphere of academic theories, as you cannot disprove the existence of said figures, thus they are categorized as meta-theories and philosophical conundrums instead --the question of "do we really deserve dogs?" however is still valid!). Instead of proving that the sun does indeed rise every day, one would instead say "I have a theory that the sun won't rise tomorrow" and then debunk that. While proving that the sun rises tomorrow is a nigh impossible task (even with a 99.999% chance of it rising tomorrow, that means there's only a 16% chance of it rising in 500 years time), proving you were wrong tomorrow when the sun rises yet again is a simpler and more attainable goal that _has practical value_. Now, while this works well in academia, the notion of having to _prove your code doesn’t work_ can be a bit much for someone just trying to fix a typo in a script. Still, things such as unit tests and fuzzing can be compared to the notion of _proving by failing to disprove_, in that we too in Open Source employ a notion of "if we can't break it, it must be working". This calculated and practical mistrust in our work is healthy. The unhealthy part stems from our fellow human beings being human beings...and not dogs. Unlike Open Source communities like Apache, universities are, in my experience, just high school all over, with fancier charts and bigger books. It matters who you know, how well you can network, who foots the bills. While some schools do make you feel at home, in most cases you are left to fend for yourself and build up a network, both socially and scientific. If you did not have the proper social skill-sets, you were alone. There was no sense of inherent belonging, it was --in a sense-- the capitalist dream turned to a nightmare. Your future was yours to create, and yours alone. If you lacked the skills or mental capacity for socializing, you were simply left behind. A Dog Named Apache Looking back at my experiences with education institutes, imagine my surprise when I --the classic loner type with limited social skills-- asked if I could get some patches applied, and five minutes later, they were! The response was, to me, an overwhelming acceptance of the work I had done, and people saying "please do contribute more, we value this immensely". More than that, it was a sense of being invited to a community that didn't have any other reasons to invite me than "I have some patches". At Apache, it didn't matter who you had known for years, or what your social standing was, what you looked like or any other generic measurement we generally use in the outside world. If you have something to contribute, and it makes sense, you are welcomed with open arms. >From the very beginning, I was gently nudged to contribute what I thought was >interesting --not what THEY thought they needed, but what I had an interest in >solving-- and I saw a profound interest in my skill-set and ideas. I saw >people thinking what I did was cool, and I was cool, even though they had no >idea who I was. It was like suddenly making friends in a platonic speed-dating >séance where all that matters was being interested in doing SOMETHING --didn't >matter what it was, as long as it made sense. There is a general notion that Apache is a meritocracy: You contribute, and through your contributions earn merit that in turn affords you leverage and say in matters. I'll posit that not only is this true, but it's also a positive sum game with "original merit" applied. People are inherently trusted to have good intentions and are afforded an initial goodwill that you might not afford people in other circumstances. I didn't know these people, they didn't know me --and none of that mattered here. Fast-tracking ideas Within a week(!) of contributing patches to the HTTP Server project, I was voted in as an Apache Committer, much to my surprise. Even more surprising was the attitude at Apache, especially the Infrastructure Team: If you want to do something, go ahead and do it (with minimal supervision). Here's a server you can hack on, here's a place you can put your code, here's someone who will help review it! I had an idea of making a comment system for the HTTPd documentation, and (again) politely asked if it was at all possible that I could write it. At this point in time, I was expecting a bureaucratic NO, with some explanation of how they didn't know me (and thus, why would they entrust me with their hardware?). The answer was a very terse "JFDI, here's a FreeBSD jail for you". While I felt a bit scared of the general tone at the time, the notion that you could just do something without having to spend time gaining trust, requisitioning things, getting reviews prior to implementation and so on, was exhilarating to me: I could hack on something, I HAD A BOX TO EXPERIMENT ON, no strings attached! Again, the notion that you were inherently trusted was present. It didn't matter that I hadn't worked with infrastructure before, I had an idea that could solve a problem, and to them, that was all that mattered. Welcome to the team! And so I wrote a comment system for our documentation. It got implemented in the documentation, other projects saw it and said "can we please use this too?". Not long after, I was neck deep in infrastructure business, having discovered that Apache was not only the HTTP Server...It was a plethora of interconnected projects all sharing the same notion of coming together to solve problems and help make the world a better place through advancing computer science. Everywhere I looked inside Apache, the notion seemed the same: If you can help us, you're one of us. Don't care who you are, where you come from, as long as you can contribute in some way, you're welcome in our community as a valued member. Fast-forward So I joined another project, and another, and another. Today I am an official part of 10 Apache projects, on the Project Management Committee (PMC) in 8 of them. Do I know about these projects in extreme detail? Heck no! I can barely tell you what some of them really do, but that really doesn't matter at Apache. What matters is your willingness to contribute, no matter what your expertise level is, no matter what field of expertise is. If you have something to contribute, Apache will accept and love you. Just like a dog. So put down your phone, stop facetweeting, and most importantly, stop thinking you can't possibly help or become a part of Apache. If you can write an email, you can help out. If you can fix typos, you can help out. If you can *sort* of code in a programming language, you can help out. If you can write newsletters, know how to fix a configuration error, help people on IRC, you can help out...and Apache will love you for it. And before you know it, you'll be a deeply integrated part of the Apache community. If you are in doubt as to what project you would or could contribute to, Apache has an awesome Community Development project that helps mentor and engage people in projects, as well as teach about how the foundation and projects work. For more information, head on over to https://community.apache.org and check out the resources available to you. You can also check out https://projects.apache.org and see if you know one of Apache’s projects, or perhaps discover a new project that fits what you are interested in --welcome aboard! # # # "Success at Apache" is a new monthly blog series that focuses on the processes behind why the ASF "just works": 1) Project Independence https://s.apache.org/CE0V 2) All Carrot and No Stick https://s.apache.org/ykoG 3) Asynchronous Decision Making https://s.apache.org/PMvk 4) Rule of the Makers https://s.apache.org/yFgQ = = = NOTE: you are receiving this message because you are subscribed to the [email protected] distribution list. To unsubscribe, send email from the recipient account to [email protected] with the word "Unsubscribe" in the subject line.
