www-announce mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sally Khudairi ...@apache.org>
Subject Success at Apache: "All Carrot and No Stick"
Date Mon, 09 Jan 2017 10:51:55 GMT
By Danny Angus

When the ASF launched their "Success at Apache" series I offered to share my own experiences.
If you read on, remember that this is my personal experience and that others may disagree
with me, but as you'll see, that's really part of the fun. 

For a bit background I’m currently the Project Management Committee (PMC) Chair of Apache
Labs and in my day job I’m a "Divisional CTO" for a FTSE250 technology company. I first
came to the ASF around 2000 when I was part of a startup - I was a CTO then too, it was the
dot com boom, and it was just me and a couple of guys. We were considering a partnership with
some researchers who wanted to commercialise their work, and were looking for a bit of software
that we could use as the foundation for a product because a) we couldn’t afford to write
it or buy it, and b) we didn’t have the knowledge anyway. What I found was Apache James
http://james.apache.org , so I downloaded it, got it up and running, and did some prototyping,
but we quickly realised that it needed work if we were going to be able to use it in production.
I dug into it a little, subscribed to the mailing lists, asked questions and figured out what
needed to be done to fix and extend what was already there, then started to modify it locally.
Meantime I found myself answering other users’ questions on the user list, and one day noticed
that I was actually answering more questions that I was asking. Shortly after that, that I
was answering more questions than anyone else. Then I started submitting patches to the developer
list (this was in the days of CVS: long before git!), which were reviewed and committed for
me by the committers … but eventually they got bored with that and decided to extend commit
privileges to me so I could do it all myself. 

My experience illustrates an important characteristic of Apache projects: the fact that you
can just turn up and get involved. Another very other important characteristic is that we
are a meritocracy: demonstrating your capability is all you need to do in order to gain more
responsibility; demonstrating your willingness and trustworthiness should be enough to get
you the job. "Karma" is a word that is used to mean "access permission" in many Open Source
projects, and we used to say that if you knew how to ask for karma properly, that was itself
a sign that you could be trusted with it. Of course we were a much different organisation
in those days, but the principles of a community built on merit and trust are still core to
our identity. It's no coincidence that organisations cannot be part of our community: only
individuals. Organisations are an important part of the world in which we exist, but we don't
exist for their benefit, we only exist at all because as individuals we each bother to turn
up and do stuff, from the guy who one time downloads and installs the Apache HTTP Web Server
to Sam Ruby, our current (and can I just say excellent) President, everyone is contributing
in their own way to the life of Apache and achieving benefits suited to their own, personal,
motivations. So it was OK for me to focus on my own and my employer's priorities, which meant
that I could learn from my new friends, develop the software we needed at work and become
part of this amazing community all at the same time.

My experience of Apache is that it is what I would call "all carrot and no stick". I think
that is the most healthy model of Open Source, as it is predicated on the fact that every
participant will benefit from their participation without the need to contribute more than
they are prepared to do. For me, focusing my contribution on the things I knew about was not
only the most efficient use of my time, in terms of meeting our company's product goals, but
it also allowed me to learn from others who had, and continue to have, way more knowledge
and experience than I, and to benefit from their work. Mixing with these amazing people, many
of whom are now real friends of mine, has taught me more than I would ever have learned any
other way.

At this point in my involvement Apache went through a bit of what has diplomatically been
described as "navel gazing", and settled on the idea that the organisational structure should
be very very flat, and there should be no limit to our growth. As long as our standards were
met by projects and people, we would welcome them both into our community. Those standards
are partly about merit, partly about legal protection, one of the key roles Apache plays is
to provide a degree of protection to projects and the people contributing to them, from the
threat of bullies, trolls, and gorillas with expensive lawyers; and partly about ensuring
that the behaviours and practices that define our identity and have contributed to the survival
and the success of our organisation are continued by new generations of people in new projects
using and creating technologies that we could hardly have dreamed about 16 years ago. 

Before long the dust settled and I found myself voted to chair the Apache James Project http://apache.org/foundation/governance/pmcs.html
, which was a whole new dimension of interesting. Chairing a project using only positive motivation
teaches you a lot about people, including yourself, and I have a few observations about successful
collaboration that I have found to be helpful both at work, where I strive to implement bottom-up
decision making, and at the ASF where I want to make a positive contribution and see our communities

 - Free your mind.The collective sense of direction may not be what you expect, there have
been times when I have been very sceptical about the reality of great sounding ideas, but
I have also learned that it’s OK to go down the wrong road because most of the time it makes
little difference in the end, usually you learn a lot regardless, and if people are really
behind it you stand a much better chance of success than if the really good idea has all the
fun of a death march. One phrase which is often used to summarise the spirit of Apache is
“Community over code”, put the community first, and the code will follow.

 - Listen, and be supportive. There are a lot of different people involved in our projects
with a lot of very different motivations. They are mostly all valid, and mostly all equally
important if that even has an absolute scale. There are students studying our code, asking
questions using our software and maybe fixing defects so that they can learn, there are employees
of corporations who are being paid to protect their investment, to implement the product roadmap
and maintain some predictable velocity, there are researchers who are pushing the boundaries
of their chosen topic, there are people whose livelihood and success depends on a project,
and those who are involved because it is a release from the pressure of things with names
like "impact", "benefits", "deadlines" and "goals". Moderate or steer the discussion to ensure
that all sides are heard, a meritocracy needs to listen to everyone not just the most vocal
or assertive, and when I say listen that doesn’t mean formulating your own response while
someone else is talking. Support people who you agree with, help to realise other people’s
ideas, collaboration is only achieved by being truly committed to each other’s success,
not just your own.

 - "A's hire A's B's hire C's". Find, support, and mentor the next generation, when your success
depends upon the community it makes sense for you to put some effort into creating the best
community you can.

 - Use Positive Language. When I was a kid being mean to my sister, adults used to say, "If
you don't have anything nice to say, don't say anything at all". That's great advice if you’re
involved in any collaborative venture, but doubly so when it is something like an Open Source
project where you are usually communicating using written English, with people you don't know
well, who might not have the same language skills as you do, who live in a different time
zone and sometimes have very different cultural background than you. On top of all that you"re
often debating the details of highly abstract technical concepts. The communication barrier
itself can cause a kind of baseline of frustration so go easy on the negativity, one thing
I like to do when I strongly disagree with someone is to write how I feel, then try to reword
it using only positive language, it might sound like touchy-feely hippy nonsense to you, but
you will be surprised how effective changing "I think you’re wrong and here’s why..."
into "You have clearly thought a lot about this, I wonder if you have considered...". Alienating
people is not the way to get your point across.

 - Learn to be a good loser. You don't own your projects, not here, and you're not the smartest
person here either (OK so that’s not going to be 100% true, but there are 5,938 Committers
today which makes it about 99.98%) recognising that and learning to embrace the collective
view is hard for some people, but being able to step outside your subjective point of view
and make a success of something you didn't believe in is a lesson in leadership that is definitely
worth learning, because if not, your growth will be limited by the ideas that come from your
own head, not accelerated by other people.

 - We are making it up as we go along http://apache.org/foundation/how-it-works.html . Yes,
it sometimes seems from the outside like we have it all sorted and nailed down, and that we
want to lawyer up and suck the life out of every fun thing (I mean we have a major software
licence with our name on it, how grown up is that for goodness sakes?)  But the truth is that
Apache, The Apache Software Foundation is, and probably always will be, a work in progress,
hopefully will be at-least-good-enough to survive the next unexpected storm, and there have
been several of those already, but the only way we ever find that out is when it hits us.
Over a relatively long period we have figured out, adopted, borrowed, adapted, had donations
of, and thunk out with nothing but our own brains, a whole load of ideas about effective Open
Source collaboration, governance, legal shenanigans, marketing, community building, and so
on. Things that work well, some that mostly work, and some that are sometimes rubbish, but
better than nothing. We write these things down and propagate this good practice amongst projects
because it is the bedrock on which our foundation rests, but that doesn’t mean that it can’t
change, we correct, adapt and evolve our best practices all the time, this is how we adapt,
this is how we have survived and remained relevant in a field that seems to change almost
beyond recognition every four or five years. And, being a meritocracy, if you don’t agree
with the way things are, if you think it is out of date or ineffective or pointless, don’t
complain, stay and fix it. We have another saying which is that "you can scratch your own
itch" - don’t be passive, if you care about it, do it.

  The important point about Apache is not that we have rules and committees but that we have
these things because they have been shown to help us do the right thing, to help us to live
by our principles and to provide a home for Open Source projects that will equip them to survive
amongst the commercial sharks in the ocean of the software industry.

 - Finally: Define your own achievements. Whether you are doing it because you need some software,
or because, like me, you just found it and it wasn't quite ready, whether you want to make
friends, or to learn something new, whether it is because you are being paid to promote your
employer's best interest, because you want to explore new ideas, or because you always wanted
to write a book, Success at Apache is yours to define. Create your own measure of success
and let us achieve it together.

# # #

"Success at Apache" is a new monthly blog series that focuses on the processes behind why
The Apache Software Foundation (ASF) "just works". First article: Project Independence https://s.apache.org/CE0V

= = =

NOTE: you are receiving this message because you are subscribed to the announce@apache.org
distribution list. To unsubscribe, send email from the recipient account to announce-unsubscribe@apache.org
with the word "Unsubscribe" in the subject line. 

View raw message