Apache Board of Directors - a retrospective

2019-03-28 19:06
Last term I had the honour of serving on the ASF board of directors, better explained in context of the ASF governance structure. As quite a few directors (myself included) declined to run for the board this year again, I thought it would be a good idea to think about the past term, write that down and publish those thoughts. As I wanted to give every board member a chance to respond, I shared some guiding questions but left it to board members to choose the channel they deemed most appropriate to share their responses on. So far, two decided to make their answers publicly available: When posting the questions, I intented to share my own answers as well - but refrain from publishing them for as long as possible to not influence others. So here we go: For a bit of context where I'm coming from: When I was first nominated for board I didn't see that nomination coming at all. This was back in 2016. I did accept, I was voted in. Back then I was still in a technical role, even though what I had been doing in various teams and open source projects was much more on the leadership and management side oftentimes. As a matter of fact, after that one year it was time to make a shift in roles in my dayjob as well. I took a one year break in 2017, was elected as board member again in 2018. Seems like twelve months is just about the timeframe that works for me - maybe some of the answers below will explain why that is the case.
Which areas were a lot of fun for you?
What is truely the most fun part is working with excellent people who have a ton of experience and know what they are doing - even though they themselves are sometimes in a mode like "we just need to make this up as we go because there really is nobody who has been faced with these challenges before".

The other part that is really fun is that even besides the fact that there is quite a bit to do, there's always someone who keeps the morale up, who brings their humour to the team. Be it on the board members meeting IRC backchannel or other places.

If you are not subscribed to board@: Every quarter projects are supposed to submit a quarterly board report. To guide their reporting and make it easier for those parts that can be derived from project communication statistics, there's a report generation tool. It will generate a project board report template that includes headings for some sections that can only be filled by a human. Those sections come with default text - text that is entirely non-sensical - but fun to read, should projects forget to fill in the real content. Trying to remember from memory, as I'm offline for the coming weeks, it was something along the lines of

==Project health narrative
Minions took over your project and are having a party.

The last part is the chance to bring people together, work together, trust each other across large distances - to the point of sharing family stories. While face to face meetings are awesome for bonding with people, those I've encountered so far as directors were easy to work with across distances even if I had met them just a couple times for a few days years ago at an ApacheCon. An "assume best intent" kind of attitude is certainly helpful there. On a tangent that also means that typically I'm communicating with people on eye level, only to get scared for a split second weeks and months later when coming across their LinkedIn profile and reading what they do or have done for a living...

Which parts were particularly educational for you?
  • The way the Apache board runs board meetings with several dozen agenda points in very well under two hours by moving as many decisions to asynchronous channels as possible. This makes it possible to participate from many more time zones than I have seen at any other organisation. It also means that people don't have to align on when everyone has time to participate in the meeting and can do most of the discussion and decision work whenever they happen to have time for it spread out over many days. On the flip side this means the entire process feels like it's slowed down a lot - except it wouldn't be possible any other way as those know who have tried to get all nine directors in one room at one date at one time during that day.
  • I had no idea how budgeting is done at the ASF's scale before being part of that discussion. I was very glad to know that there are other directors who have experience with that topic.
  • In every board meeting we go over project board reports: Everytime there are some where I'm like: "You should totally talk about what you're doing there to a wider audience than just your project." - it's great when that advise is actually followed up on - it's even better as so far everytime such learnings were written down behind a stable URL, that URL became very popular as a reference for other going forward.


Are there any parts of being a board member that you could imagine helping with even after stepping down?
Pretty much all tasks the board does can be done by any member. One thing I seriously would like to continue doing is to build more bridges between the board of directors and projects (inviting new PMC chairs to join the board meeting and take away their fear that it might last hours is just one possibility).

If asked I will also continue answering questions on best practices, how to get involved and generally try to pull people in - both into projects as well as into the foundation itself.

With a bit of hind-sight: A few months after leaving the board of directors, what I did continue doing was make time to explain the Apache Way to other people. I'm also interested in keeping the discussion on how to get involved - and how to convince your employer to donate your time to the foundation alive. Another thing I would really love to find best practices and patterns for is how to balance full-time open source contributors with those working on projects occasionally. This isn't much different to the challenge of integrating part-time and full-time employees - something that at least in some German companies has been solved for a long time already. Time to also find a solution for Apache projects taking project neutrality one step further.

Which areas were particularly time costly for you?
We have well over 200 projects. Each is required to submit a board report on a quarterly basis. While most aren't particularly long, the content does add up. While in theory, checking private lists, following a few discussions and listening to project contributors (be they users, contributors, committers or pmc members) would be needed to spot governance issues early, the current number of projects to check for each shepherd means that issues will be discovered too late for precise, scalpel like patches. Somehow that entire process is something that in my opinion could benefit from a better collective understanding of what constitutes a healthy projects, including an understanding of just how much freedom there is in configuring your project governance best practices.

Maybe the Apache maturity model would be a good starting point for spotting best practices. Maybe it would be helpful to also come up with project anti patterns to watch out for to take the guess-work out of the process of writing a board report.

Which areas were energy costly for you - didn't necessarily take a lot of time but were definitely not fun to deal with?
There's just one example that's standing out for this one: Occasions where the board needed to delegate tasks to a new role. The main reason here was that typically the discussions quickly dissolved into mixing role name, role accountabilities, person to fill the role and budget for the role all into one discussion.

While for the final result all four perspectives need to come together, in my experience, it helps to first think about the actual accountabilities that should be delegated. Only after that look for a name that fits, otherwise people will associate accountabilities because of the name, believe that those accountabiities aren't needed and reject the need for the role entirely.

Only after having exact accountabilities start discussing budget - it's much easier to talk about money, once it's clear exactly what the purpose looks like that the money is going to be spent on. Once that is out of the way, start looking for a human to fill the role. Even if there is an obvious choice popping up, make your need for that role to be filled known and go looking for volunteers. You'd be surprised to hear how many new faces we've seen speak up and get active - lowering the load on any usual suspects.

"I wish I had known this before joining the board"
The ASF is really good at hiding where it was incorporated in it's daily operations. Being a director that suddenly moves a lot closer: It's becomes much more likely that your communication becomes of interest in a suppeona (luckily, there's an archive for pretty much everything, so the relevant communication can be handed over fairly quickly). For me this lesson moved the ASF a whole lot closer to a regular company with a BYOD policy though.

In terms of how to run a US Delaware law incorporated 501.c3 foundation I was lucky insofar as there were still several long term directors as well as former directors around that knew about and were happy to talk about the constraints of what could be done and what couldn't be done - and why so.

In your opinion - what are the strengths of the ASF board?
  • They have developed an awesome model of collaboration with an asynchronous decision making process that does scale.
  • The people I had the honour to serve with remained human beings, including the humor and including their private family background.
  • The ones I have seen serve in their individual capacity leaving corporate interests at the door - or announcing when discussions are started because of what they observed at dayjob.
  • They bring a ton of experience from all sorts of backgrounds - both, culturally but also in terms of which companies they've seen from the inside - trying to learn from all of that experience to build a better world that is much more flexible and light weight than your average large scale enterprise.


In your opinion - what are areas for potential improvement for the ASF board?
A lot of the things that I think of reading that question really are things that could be improved even without being a director: Documentation on how the foundation works at the project, and at the operational level; documentation of expectations of projects, making purpose and actual content of previous decsions easier to discover...

The only thing that comes to my mind that the board could watch out for is to have discussions in such a way as to keep all relevant people in the loop, facilitating a dialogue with people instead of about them. For contentious discussions it might also help to have a set of moderation techniques that have proven helpful in asynchronous communcation handy.

In your opinion - what changes should be made to the way the ASF board operates, interacts with communities, interacts with the wider ASF ecosystem, interacts with the public?
While at the ASF we are very good at thinking about inward facing communication, I believe we can become much better at communicating to the non-ASF world. As we grow, I believe that perspective becomes ever more important - we cannot rely on people to just "get" how we work from simply following our projects and becoming ever more involved.

Being community over code to me implies counting the user/customer of our projects as part of that community. They are the ones who have the fresh eyes to spot flaws in our argumentation of why we are doing things the way we do - and spot advantages. However they can only do that by understanding what goal and purpose we want to work towards.

Any advice for new board members - where to look first, what legal implications to keep in mind, what PR implications to keep in mind etc.?
While being a director can be done even with little time available, there are others on the board that dedicate a lot more time to the task than you will have available. Don't let that stress you out. For some discussions it helps to wait a day before writing an answer - either someone else will have writting what you wanted to say after that - or you'll be in a much better state of mind to make your statement without it being hidden behind a cloud of emotions that stop you from thinking clearly.

While being an ASF director may mean little to the people you work with - even if your dayjob builds their entire business on top of an Apache project - it does bear a lot of weight to many other people worldwide: ASF internal, or ASF external (e.g. press representatives). With that power comes a call for using it responsibly: The statements you make, even if they were only meant as a basis for discussions, will have the power to cause fear if not marked as such.

People will seek you out with the issues they are having in their community. Instead of jumping in yourself which does not scale long term, try to figure out how to help them in a sustainable way - e.g. by helping to find the right more public space to talk about the issues they have encountered and discuss a solution in public.

Remember that the board at the ASF is designed to move slowly. As a result do not expect to make ground breaking changes within just one board term. However do expect that the little changes you do make will make a big difference in the long run. Essentially that's a side effect of a foundation that's build on the goal of longevity.

One thing that is different at the director level (as well as the operational level): While in a lot of positions we have setup process that allow for people to take a break without announcement for any amount of time, director and operational positions do mean that there is a need for dependability and reliability - you will need to make time for that position regularly for at least one year.

What are the tasks and time commitment?
That totally depends on how much time and energy you want to commit. At the bare minimum if it's only about oversight a couple hours a week and maybe two days running up to board meetings could be sufficient (that's where projects submitting reports early make life easier for directors).

Tell us about a moment from your time on the ASF board that is most precious to you.
I tried to think of one - except there wasn't. While it does take time and energy, it's also a great source of positive inspiration, including tons of chances to learn from others.

FrOSCon 2018

2018-08-29 16:34

A more general summary: https://tech.europace.de/froscon-2018/ of the conference written in German. Below a more detailed summary of the keynote by Lorena Jaume-Palasi.

In her keynote "Blessed by the algorithm - the computer says no!" Lorena detailed the intersection of ethics and technology when it comes to automated decision making systems. As much as humans with a technical training shy away from questions related to ethics, humans trained in ethics often shy away from topics that involve a technical layer. However as technology becomes more and more ingrained in everyday life we need people who understand both - tech and ethical questions.

Lorena started her talk detailing how one typical property of human decision making involves inconsistency, otherwise known as noise: Where machine made decisions can be either accurate and consistent or biased and consistent, human decisions are either inconsistent but more or less accurate or inconsistent and biased. Experiments that showed this level of inconsistency are plenty, ranging from time estimates for tasks being different depending on weather, mood, time of day, being hungry or not up to judges being influenced by similar factors in court.

One interesting aspect: While in order to measure bias, we need to be aware of the right answer, this is not necessary for measuring inconsistency. Here's where monitoring decisions can be helpful to palliate human inconsistencies.

In order to understand the impact of automated decision making on society one needs a framework to evaluate that - the field of ethics provides multiple such frameworks. Ethics comes in three flavours: Meta ethics dealing with what is good, what are ethical requests? Normative ethics deals with standards and principles. Applied ethics deals with applying ethics to concrete situations.

In western societies there are some common approaches to answering ethics related questions: Utilitarian ethics asks which outputs we want to achieve. Human rights based ethics asks which inputs are permissible - what obligations do we have, what things should never be done? Virtue ethics asks what kind of human being one wants to be, what does behaviour say about one's character? These approaches are being used by standardisation groups at e.g. DIN and ISO to answer ethical questions related to automation.

For tackling ethics and automation today there are a couple viewpoints, looking at questions like finding criteria within the context of designing and processing of data (think GDPR), algorithmic transparency, prohibiting the use of certain data points for decision making. The importance of those questions is amplified now because automated decision making makes it's way into medicine, information sharing, politics - often separating the point of decision making from the point of acting. One key assumption in ethics is that you should always be able to state why you took a certain action - except for actions taken by mentally ill people, so far this was generally true. Now there are many more players in the decision making process: People collecting data, coders, people preparing data, people generating data, users of the systems developed. For regulators this setup is confusing: If something goes wrong, who is to be held accountable? Often the problem isn't even in the implementation of the system but in how it's being used and deployed. This confusion leads to challenges for society: Democracy does not understand collectives, it understands individuals acting. Algorithms however do not understand individuals, but instead base decisions on comparing individuals to collectives and inferring how to move forward from there. This property does impact individuals as well as society.

For understanding which types of biases make it into algorithmic decision making systems that are built on top of human generated training data one needs to understand where bias can come from:

The uncertainty bias is born out of a lack of training data for specific groups amplifying outlier behaviour, as well as the risk for over-fitting. One-sided criteria can serve to reinforce a bias that is generated by society: Even ruling out gender, names and images from hiring decisions a focus on years of leadership experience gives an advantage to those more likely exposed to leadership roles - typically neither people of colour, nor people from poorer districts. One-sided hardware can make interaction harder - think face recognition systems having trouble identifying non-white humans, having trouble identifying non-male humans.

In the EU we focus on the precautionary principle where launching new technology means showing it's not harmful. This though proves more and more complex as technology becomes entrenched in everyday life.

What other biases do humans have? There's information biases, where humans tend to reason based on analogy, based on the illusion of control (overestimating oneself, downplaying risk, downplaying uncertainty), there's an escalation of committment (a tendency to stick to a decision even if it's the wrong one), there are single outcome calculations.

For cognitive biases are related to framing, criteria selection (we tend to value quantitative criteria over qualitative criteria), rationality. There's risk biases (uncertainties about positive outcomes typically aren't seen as risks, risk tends to be evaluated by magnitude rather than by a combination of magnitude and probability). There's attitude based biases: In experiments senior managers considered risk taking as part of their job. The level of risk taken depended on the amount of positive performance feedback given to a certain person: The better people believe they are, the more risk they are willing to take. Uncertainty biases relate to the difference between the information I believe I need vs. the information available - in experiments humans made worse decisions the more data and information was available to them.

General advise: Beware of your biases...

DataworksSummit Berlin - Wednesday morning

2018-04-19 06:50
Data strategy - cloud strategy - business strategy: Aligning the three was one of the main themes (initially put forward in his opening keynote by CTO of Hortonworks Scott Gnau) thoughout this weeks Dataworks Summit Berlin kindly organised and hosted by Hortonworks. The event was attended by over 1000 attendees joining from 51 countries.

The inspiration hat was put forward in the first keynote by Scott was to take a closer look at the data lifecycle - including the fact that a lot of data is being created (and made available) outside the control of those using it: Smart farming users are using a combination of weather data, information on soil conditions gathered through sensors out in the field in order to inform daily decisions. Manufacturing is moving towards closer monitoring of production lines to spot inefficiencies. Cities are starting to deploy systems that allow for better integration of public services. UX is being optimized through extensive automation.

When it comes to moving data to the cloud, the speaker gave a nice comparison: To him, explaining the difficulties that moving to the cloud brings is similar to the challenges that moving "stuff" to external storage in the garage brings: It opens questions of "Where did I put this thing?", but also about access control, security. Much the same way, cloud and on-prem integration means that questions like encryption, authorization, user tracking, data governance need to be answered. But also questions like findability, discoverability and integration for analysis purposes.

The second keynote was given by Mandy Chessell from IBM introducing Apache Atlas for metadata integration and governance.

In the third keynote, Bernard Marr talked about the five promises of big data:

  • Informing decisions based on data: The goal here should be to move towards self service platforms to remove the "we need a data scientist for that" bottleneck. That in turn needs quite some training and hand-holding for those interested in the self-service platforms.
  • Understanding customers and customer trends better: The example given was a butcher shop that would install a mobile phone tracker in his shop window in order to see which advertisement would make more people stop by and look closer. As a side effect he noticed an increase in people on the street in the middle of the night (coming from pubs nearby). A decision was made to open at that time, offer what people were searching for at that time according to Google trends - by now that one hour in the night makes a sizeable portion of the shop's income. The second example given was Disney already watching all it's Disney park visitors through wrist bands, automating line management at popular attractions - but also deploying facial recognition watching audiences watch shows in figure out how well those shows are received.
  • Improve the customer value proposition: The example given was the Royal Bank of Scotland moving closer to it's clients, informing them through automated means when interest rates are dropping, or when they are double insured - thus building trust and transparency. The other example given was that of a lift company building sensors into lifts in order to be able to predict failures and repair lifts when they are least used.
  • Automate business processes: Here the example was that of a car insurance that would offer dynamic rates if people would let themselves monitor during driving. Those adhering to speed limits, avoiding risky routes and times would get lower rates. Another example was that of automating the creation of sports reports e.g. for tennis matches based on sensors deployed, or that of automating Forbes analyst reports some of which get published without the involvement of a journalist.
  • Last but not least the speaker mentioned the obvious business case of selling data assets - e.g. selling aggregated and refined data gathered through sensors in the field back to farmers. Another example was the automatic detection of events based on sounds detected - e.g. gun shots close to public squares and selling that back to the police.


After the keynotes were over breakout sessions started - including my talk about the Apache Way. It was good to see people show up to learn how all the open source big data projects are working behind the scences - and how they themselves can get involved in contributing and shaping these projects. I'm looking forward to receiving pictures of feather shaped cookies.

During lunch there was time to listen in on how Santander operations is using data analytics to drive incident detection, as well as load prediction for capacity planning.

After lunch I had time for two more talks: The first explained how to integrate Apache MxNet with Apache NiFi to bring machine learning to the edge. The second one introduced Apache Beam - an abstraction layer above Apache Flink, Spark and Google's platform.

Both, scary and funny: Walking up to the Apache Beam speaker after his talk (having learnt at DataworksSummit that he is PMC Chair of Apache Beam) - only to be greeted with "I know who *you* are" before even getting to introduce oneself...

Apache Breakfast

2018-04-17 07:39

In case you missed it but are living in Berlin - or are visiting Berlin/ Germany this week: A handful of Apache people (committers/ members) are meeting over breakfast on Friday morning this week. If you are interested in joining, please let me know (or check yourself - in the archives of the mailing list party@apache.org)

FOSS Backstage - Schedule online

2018-04-17 07:27
In January the CfP for FOSS Backstage opened. By now reviews have been done, speakers notified and a schedule created.

I'm delighted to find both - a lot of friends from the Apache Software Foundation but also a great many speakers that aren't affiliated with the ASF among the speakers.

If you want to know how Open Source really works, if you want to get a glimpse behind the stage, do not wait for too long to grab your ticket now and join us in summer in Berlin/ Germany.

If project management is only partially of your interest, we have you covered as well: For those interested in storing, searching and scaling data analysis, Berlin Buzzwords is scheduled to take place in the same week. For those interested in Tomcat, httpd, cloud and iot, Apache Roadshow is scheduled to happen on the same days as FOSS Backstage - and your FOSS Backstage ticket grants you access to Apache Roadshow as well.

If you're still not convinced - head over to the conference website and check out the talks available yourself.

My board nomination statement 2018

2018-03-23 07:21
Two days ago the Apache Software Foundation members meeting started. One of the outcomes of each members meeting is an elected board of directors. The way that works is explained here: Annual Apache members meeting. As explained in the linked post, members accepting their nomination to become a

director are supposed to provide a nomination statement. This year they were also asked to answer a set of questions so members could better decide who to vote for.

As one of my favourite pet peeves is to make the inner workings of the foundation more transparent to outsiders (and have said so in the nomination statement) - I would like to start by publishing my own nomination statement here for others to read who don't have access to our internal communication channels:

Board statement:

Two years ago I was put on a roller coaster by being nominated as Apache board member which subsequently meant I got to serve on the board in 2016. Little did I know what kind of questions were waiting for me.

Much like back then I won't treat this position statement as a voting campaign. I don't claim to have answers to all the questions we face as we grow larger - however I believe being a board member even at our size should be something that is fun. Something that is lightweight enough so people don't outright decline their nominations just for lack of time.

One thing I learnt the hard way is scalability needs two major ingredients: Breaking dependencies and distribution of workload. Call me old-fashioned (even though chemistry can hide my gray hair, my preference for mutt as a mail client betrays my age), but I believe we already have some of the core values to achieve just that:
  • "Community over code" to me includes rewarding contributions that aren't code. I believe it is important to get people into the foundation that are committed to both our projects as well as the foundation itself - helping us in all sorts of ways, including but not limited to coding, documenting, marketing, mentoring, legal, education and more.
  • "What didn't happen on the mailing list didn't happen" to me means communicating as publicly as possible (while keeping privacy as needed) to enable others to better understand where we are, how we work, what we value and ultimately how to help us. I would like for us to think twice before sending information to private lists - both at the project and at the operational level.
  • I believe we can do better in getting those into the loop who have a vested interest in seeing that our projects are run in a vendor neutral way: Our downstream users who rely on Apache projects for their daily work.
I am married to a Linux kernel geek working for the Amazon kernel and operating systems team - I've learnt a long time ago that the Open Source world is bigger than just one project, bigger than just one foundation. Expect me to keep the bigger picture in mind during my work here that is not ASF exclusive.

Much like Bertrand I'm a European - that means I do see value in time spent offline, in being disconnected. I would like to urge others to take that liberty as well - if not for yourselves, then at least to highlight where we are still lacking in terms of number of people that can take care of a vital role.

As you may have guessed from the time it took for me to accept this nomination, I didn't take the decision lightly. For starters semi-regularly following the discussion on board@ to me feels like there are people way more capable than myself. Seeing just how active people are feels like my time budget is way too limited.

So what made me accept? I consider myself lucky seeing people nominated for the Apache board who are capable leaders that bring very diverse skills, capabilities and knowledge with them that taken together will make an awesome board of directors.

I know that with FOSS Backstage one other "pet project of mine" is in capable hands, so I don't need to be involved in it on a day-to-day basis.

Last but not least I haven't forgotten that back in autumn 2016 Lars Trieloff* told me that I am a role model: Being an ASF director, while still working in tech, with a today three year old at home. As the saying goes "Wege entstehen dadurch, dass man sie geht" - free-form translation: "paths are created by walking them." So instead of pre-emptively declining my nomination I would like to find a way to make the role of being a Director at the Apache Software Foundation something that is manageable for a volunteer. Maybe along that way we'll find a piece in the puzzle to the question of who watches the watchmen - how do we reduce the number of volunteers that we burn through, operating at a sustainable level, enabling people outside of the board of directors to take over or help with tasks.

* Whom I know through the Apache Dinner/ Lunch Berlin that I used to organise what feels like ages ago. We should totally re-instate that again now that there are so many ASF affiliated people in or close to Berlin. Any volunteers? The one who organises gets to choose date and location after all ;)

Answers to questions to the board nominees:

On Thu, Mar 15, 2018 at 01:57:07PM +0100, Daniel Gruno wrote:
> Missions, Visions...and Decisions:
> - The ASF exists with a primary goal of "providing open source
> software to the public, at no charge". What do you consider to be
> the foundation's most important secondary (implicit) goal?


I learnt a lot about what is valuable to us in the following discussion:

https://s.apache.org/hadw

(and the following public thread over on dev@community with the same subject. My main take-away from there came from Bertrand: The value we are giving back to projects is by providing "A neutral space where they can operate according to our well established best practices."

The second learning I had just recently when I had the chance of thinking through some of the values that are encoded in our Bylaws that you do not find in those of other organisations: At the ASF you pay for influence with time (someone I respect a lot extended that by stating that you actually pay with time and love).

> - Looking ahead, 5 years, 10 years...what do you hope the biggest
> change (that you can conceivably contribute to) to the foundation
> will be, if any? What are your greatest concerns?


One year ago I had no idea that little over two months from now we would have something like FOSS Backstage here in Berlin: One thing the ASF has taught me is that predicting the future is futile - the community as a whole will make changes in this world that are way bigger than the individual contributions taken together.

> < - Which aspect(s) (if any) of the way the ASF operates today are you > least satisfied with? What would you do to change it?

Those are in my position statement already.

> #######################################

> Budget and Operations:
> - Which roles do you envision moving towards paid roles. Is this the
> right move, and if not, what can we do to prevent/delay this?
>

Honestly I cannot judge what's right and wrong here. I do know that burning through volunteers to me is not an option. What I would like to hear from you as a member is what you would need to step up and do operational tasks at the ASF.

Some random thoughts: - Do we have the right people in our membership that can fill these operational roles? Are we doing a good enough job in bringing people in with all sorts of backgrounds, who have done all sorts of types of contributions? - Are we doing a good enough job at making transparent where the foundation needs operational help? Are those roles small enough to be filled by one individual?

This question could be read like today work at the ASF is not paid for. This is far from true - both at the project as well as at the operational level. What I think we need is collective understanding of what the implications of various funding models are: Even if the ASF doesn't accept payment for development doesn't directly imply that projects are more independent as a result. I would assume the same to be true at the operational level.

> #######################################
>
> Membership and Governance:
> - Should the membership play a more prominent role in
> decision-making at the ASF? If so, where do you propose this be?


I may be naive but I still believe in the "those who do the work are those who take decisions". There only close to a dozen people who participated in the "ask the members questionaire" I sent around - something that was troubling for me to see was how pretty much everyone wanted

> - What would be your take on the cohesion of the ASF, the PMCs, the
> membership and the communities. Are we one big happy family, or
> just a bunch of silos? Where do you see it heading, and where do
> we need to take action, if anywhere?


If "one big happy family" conjures the picture of people with smiling faces only, than that is a very cheesy image of a family that in my experience doesn't reflect reality of what families typically look like.

This year at FOSDEM in Brussels we had a dinner table of maybe 15 people (while I did book the table, I don't remember the exact number - over-provisioning and a bit of improvisation helped a lot in making things scale) from various projects, who joined at various times. I do remember a lot of laughter at that table. If anything I think we need the help people to bump into each other face to face independently of their respective project community more often.

> - If you were in charge of overall community development (sorry,
> Sharan!), what would you focus on as your primary and secondary
> goal? How would you implement what you think is needed to achieve
> this?


I'm not in charge in that - nor would I want to be, nor should I be. The value I see in the ASF is that we rely very heavily on self organisation, so this foundation is what each individual in it makes out of it - and to me those individuals aren't limited to foundation members, PMC members or even committers. In each Apache Way talk I've seen (and everytime I explain the Apache Way to people) the explanation starts with our projects' downstream users.

> Show and Tell:

I'm not much of a show and tell person. At ApacheCon Oakland I once was seeking help with getting a press article about ApacheCon reviewed. It was easy finding a volunteer to proof-read the article. The reason for that ease given by the volunteer themselves? What they got out of their contributions to the ASF was much bigger than anything they put into it. That observation holds true for me as well - and I do hope that this is true for everyone here who is even mildly active.

An argument against proxies

2018-03-08 17:53
Proxies? In companies getting started with an upstream first concept this is what people are called who act as the only interface between their employer and an open source project: All information from any project used internally flows through them. All bug reports and patches intended as upstream contribution also flows through them - hiding entire teams producing the actual contributions.

At Apache projects I learnt to dislike this setup of having proxies act in place of the real contributors. Why so?

Apache is built on the premise of individuals working together in the best interest of their projects. Over time, people who prove to commit themselves to a project get added to that project. Work contributed to a project gets rewarded - in a merit doesn't go away kind-of sense working on an Apache project is a role independent of other work committments - in the "merit doesn't go away" sense this merit is attached to the individual making contributions, not to the entity sponsoring that individual in one way or another.

This mechanism does not work anymore if proxy committers act as gateway between employers and the open source world: While proxied employees are saved from the tax that working in the public brings by being hidden behind proxies, they will also never be able to accrue the same amount of merit with the project itself. They will not be rewarded by the project for their committment. Their contributions do not end up being attached to themselves as individuals.

From the perspective of those watching how much people contribute to open source projects the concept of proxy committers often is neither transparent nor clear. For them proxies establish a false sense of hyper productivity: The work done by many sails under the flag of one individual, potentially discouraging others with less time from participating: "I will never be able to devote that much work to that project, so why even start?"

From an employer point of view proxies turn into single point of failure roles: Once that person is gone (on vacation, to take care of a relative, found a new job) they take the bonds they made in the open source project with them - including any street cred they may have gathered.

Last but not least I believe in order to discuss a specific open source contribution the participants need a solid understanding of the project itself. Something only people in the trenches can acquire.

As a result you'll see me try and pull those actually working with a certain project to get active and involved themselves, to dedicate time to the core technology they rely on on a daily basis, to realise that working on these projects gives you a broader perspective beyond just your day job.

FOSDEM 2018 - recap

2018-02-13 06:13
Too crowded, too many queues, too little space - but also lots of friendly people, Belgian waffles, ice cream, an ASF dinner with grey beards and new people, a busy ASF booth, bumping into friends every few steps, meeting humans you see only online for an entire year or more: For me, that's the gist of this year's FOSDEM.

Note: German version of the article including images appeared in my employer's tech blog.

To my knowledge FOSDEM is the biggest gathering of free software people in Europe at least. It's free of charge, kindly hosted by ULB, organised by a large group of volunteers. Every year early February the FOSS community meets for two one weekend in Brussels to discuss all sorts of aspects of Free and Open Source Software Development - including community, legal, business and policy aspects. The event features more than 600 talks as well as several dozen booths by FOSS projects and FOSS friendly companies. There's several FOSDEM fringe events surrounding the event that are not located on campus. If you go to any random bar or restaurant in Brussels that weekend you are bound to bump into FOSDEM people.

Fortunately for those not lucky enough to have made it to the event, video recordings (unfortunately in varying quality) are available online at video.fosdem.org. Some highlights you might want to watch:



One highlight for me personally this year: I cannot help but believe that I met way more faces from The Apache Software Foundation than at any other FOSDEM before. The booth was crowded at all times - Sharan Foga did a great job explaining The ASF to people. Also it's great to hear The ASF mentioned in several talks as one of the initiatives to look at to understand how to run open source projects in a sustainable fashion with an eye on longevity. It was helpful to have at least two current Apache board members (Bertrand Delacretaz as well as Rich Bowen) on site to help answer tricky questions. Last but not least it was lovely meeting several of the Apache Grey Beards (TM) for an Apache Dinner on Saturday evening. Luckily co-located with the FOSDEM HPC speaker dinner - which took a calendar conflict out of the Apache HPC people's calendar :)

Me personally, I hope to see many more ASF people later this year in Berlin for FOSS Backstage - the advertisement sign that was located at the FOSDEM ASF booth last weekend already made it here, will you follow?

FOSS Backstage - CfP open

2018-01-23 16:21
It's almost ten years ago that I attended my first ApacheCon EU in Amsterdam. I wasn't entirely new to the topic of open source or free software. I attended several talks on Apache Lucene, Apache Solr, Hadoop, Tomcat, httpd (I still remember that the most impressive stories didn't necessarily come from the project members, but from downstream users. They were the ones authorized to talk publicly about what could be done with the project - and often became committers themselves down the road.

With "community over code" being one of the main values at Apache, ApacheCon also hosted several non-technical tracks: Open source and business, Open Development (nowadays better known as Inner Source), Open Source project management, project governance, an Apache Way talk. Over the past decade one learning survived any wave of tech buzzword: At the end of the day, success in Open Source (much like in any project) is defined by how well the project is run (read: managed). Reflecting on that the idea was born to create a space to discuss just these topics: What does it take to be "Leading the wave of open source"?

As announced on Berlin Buzzwords we (that is Isabel Drost-Fromm, Stefan Rudnitzki as well as the eventing team over at newthinking communications GmbH) are working on a new conference in summer in Berlin. The name of this new conference will be "FOSS Backstage". Backstage comprises all things FOSS governance, open collaboration and how to build and manage communities within the open source space.

Submission URL: Call for Presentations

The event will comprise presentations on all things FOSS governance, decentralised decision making, open collaboration. We invite you to submit talks on the topics: FOSS project governance, collaboration, community management. Asynchronous/ decentralised decision making. Vendor neutrality in FOSS, sustainable FOSS, cross team collaboration. Dealing with poisonous people. Project growth and hand-over. Trademarks. Strategic licensing. While it's primarily targeted at contributions from FOSS people, we would love to also learn more on how typical FOSS collaboration models work well within enterprises. Closely related topics not explicitly listed above are welcome.

Important Dates (all dates in GMT +2)

Submission deadline: February 18th, 2018.

Conference: June, 13th/14th, 2018

High quality talks are called for, ranging from principles to practice. We are looking for real world case studies, background on the social architecture of specific projects and a deep dive into cross community collaboration. Acceptance notifications will be sent out soon after the submission deadline. Please include your name, bio and email, the title of the talk, a brief abstract in English language.

We have drafted the submission form to allow for regular talks, each 45 min in length. However you are free to submit your own ideas on how to support the event: If you would like to take our attendees out to show them your favourite bar in Berlin, please submit this offer through the CfP form. If you are interested in sponsoring the event (e.g. we would be happy to provide videos after the event, free drinks for attendees as well as an after-show party), please contact us.

Schedule and further updates on the event will be published soon on the event web page.

Please re-distribute this CfP to people who might be interested.

Contact us at:
newthinking communications GmbH
Schoenhauser Allee 6/7
10119 Berlin, Germany
info@foss-backstage.de


Looking forward to meeting you all in person in summer :)

Trust and confidence

2017-12-06 05:48
One of the main principles at Apache (as in The Apache Software Foundation) is "Community over Code" - having the goal to build projects that survive single community members loosing interest or time to contribute.

In his book "Producing Open Source Software" Karl Fogel describes this model of development as Consensus-based Democracy (in contrast to benevolent dictatorship): "Consensus simply means an agreement that everyone is willing to live with. It is not an ambiguous state: a group has reached consensus on a given question when someone proposes that consensus has been reached and no one contradicts the assertion. The person proposing consensus should, of course, state specifically what the consensus is, and what actions would be taken in consequence of it, if those are not obvious."

What that means is that not only one person can take decisions but pretty much anyone can declare a final decision was made. It also means decisions can be stopped by individuals on the project.

This model of development works well if what you want for your project is resilience to people, in particular those high up in the ranks, leaving at the cost of nobody having complete control. It means you are moving slower, at the benefit of getting more people on board and carrying on with your mission after you leave.

There are a couple implications to this goal: If for whatever reason one single entity needs to retain control over the project, you better not enter the incubator like suggested here. Balancing control and longevity is particularly tricky if you or your company believes they need to own the roadmap of the project. It's also tricky if your intuitive reaction to hiring a new engineer is to give them committership to the project on their first day - think again keeping in mind that Money can't buy love. If you're still convinced they should be made committer, Apache probably isn't the right place for your project.

Once you go through the process of giving up control with the help from your mentors you will learn to trust others - trust others to pick up tasks you leave open, trust others they are taking the right decision even if you would have done things otherwise, trust others to come up with solutions where you are lost. Essentially like Sharan Foga said to Trust the water.

Even coming to the project at a later stage as an individual contributor you'll go through the same learning experience: You'll learn to trust others with the patch you wrote. You'll have to learn to trust others to take your bug report seriously. If the project is well run, people will treat you as an equal peer, with respect and with appreciation. They'll likely treat you as part of the development team with as many decisions as possible - after all that's what these people want to recruit you for: For a position as volunteer in their project. Doing that means starting to Delegate like a Pro as Deb Nicholson once explained at ApacheCon. It also means training your capability for Empathy like Leslie Hawthorn explained at FOSDEM. It also means treating all contributions alike.

There's one pre-requesite to all of this working out though: Working in the open (as in "will be crawled, indexed and made visible by the major search engine of the day"), giving control to others over your baby project and potentially over what earns your daily living means you need a lot of trust not onnly in others but also in yourself. If you're in a position where you're afraid that missteps will have negative repercussions on your daily life you won't become comfortable with all of that. For projects coming to the incubator as well as companies paying contributors to become open source developers in their projects in my personal view that's an important lesson: Unless committers already feel self confident and independent enough of your organisation as well as the team they are part of to take decisions on their own, you will run into trouble walking towards at least Apache.