Let me explain…

No, there is too much. Let me sum up what’s been happening in the past 1081 days of March since the pandemic started back in 2020. Meme image from Princess Bride, featuring Indigo Montoya saying: "Let me explain... no there is too much."

The pandemic brought it’s own special challenges here, since we have complicating health factors that meant we essentially stopped going out for several months until we better understood the issues our situation presented. Luckily, we all could do work and school remotely for a while, so it was a far easier time here than for many folks.

Besides all the obvious things – seeing friends, going shopping, eating out, and just plain socializing – the other rotten thing about the pandemic was missing all my friends in the open source world. My two must-attend conferences were both cancelled in person: ApacheCon and Monktoberfest. Since I have a 20+ year career in open source technology, many of my friends are scattered around the world, and I only get to see them at conferences, which I’ve really missed, travel hassles and all.

Twitter and other social media sites have been a kind of lifeline, both for keeping up with the FOSS world and just with friends. That makes it all the more devastating to see the current $44B trajectory of turning that flawed-but-great tweetstream into the world’s most expensive billboard for a cheezy techbro. It’s currently a testament to the skills of Twitter’s past engineering staff (mostly fired or laid off now) at their skill to build a robust enough system to survive this long after a… ‘hostile’ management takeover.

My Pandemic Projects

At various times during the past two years I’ve turned to doing volunteer work or building websites to get by. I’ve also gone through a handful of wicked awesome games (and a couple of new game consoles) along the way.

  • Mutual Aid When times get tough, does your neighborhood have neighbors who help each other out? So many places in our modern (US East Coast suburban, which I admit is very first world problems) neighborhood didn’t really have that. So I worked on local social media and built Mutual Aid Arlington to try to connect people.
  • I ran for political office! Yes, it’s true, I ran for local town government during the pandemic – really bad timing for campaigning, I can tell you! In New England we have something called “Town Meeting” which is truly local democracy. To help people understand how hyper-local politics worked, I created Menotomy Matters.
  • I did NOT run for ASF Board. After getting elected again right in March 2020, I decided in 2021 (and 2022) to not run for the board again. Time with family and friends suddenly became so much more important – plus we had plenty of great new candidates for the board. It was a welcome time off, even as I continued to serve as the Vice Chair (since technically, the Vice Chair doesn’t need to be a director!)
  • I bought more domain names. It’s an occupational hazard, especially for anyone in tech who also has ADHD. Start with https://tldrfoss.com/
  • I got diagnosed with ADHD. Much to no-one’s surprise, I got an official diagnosis of ADHD, which explains a lot of my past history. If only this had happened… oh, 30 years ago, what might have I ended up becoming?
  • My remaining ancestor died. Mom deserves a separate post, but she was my last living ancestor. There was yet more paperwork.
  • We played video games. I mean, who didn’t? Along with a new Playstation, I played The Last Of Us (remaster, and 2), Horizon Zero Dawn, and Horizon Forbidden West. Each of them was an awesome experience, highly recommended.
  • I missed two years of conferences. Many of us did, as most conferences were cancelled. For those of us with open source friends, this was doubly hard, since that’s the only time we all gather together.

How Is This About Open Source?

It’s about community, which is the most important part of any open source project. Code is easy. People are hard. Especially groups of people from scattered backgrounds. Optimize your work for the people you interact with.

For those interested in more Shane, I use my real name on various social networks, find me out there!

Apache How-To: Communicating Effectively

How can you be effective at asking questions or proposing changes at Apache or in an Apache project?  Besides making sure you use the right mailing list, and asking smart questions or following the several email etiquette guidelines and tips at Apache, what should you do to be effective at communicating your ideas?

There are plenty of times you’ve been polite and formulated a good question, but you either don’t get useful responses – or you get too many responses and tangents and complaints and and and…  What are some of the other factors to consider in being effective at communicating with Apache’s many communities?

Is this a question about one Apache project?

If your question or idea is just about a single Apache project, that’s pretty easy: write your thoughtful email to the dev@projectname mailing list; that’s where the primary community for most projects does their work.  Sometimes you may want to email the user@ mailing list if it’s a question about functionality, events, or user-based questions instead.

Make sure to understand that project’s expectations for discussions: do they use [SUBJECT-TAGS], or perhaps use JIRAs for organizing technical work?  Do they expect all proposals to be spelled out in your email, or do they often write up a proposal in their wiki, and then point to it from the email?  Following the project’s normal way of working is important to have maximum chance that other project volunteers will see and respond to your message.  Be sure to reply to any questions as well!

I can’t get a final decision on my question! What next?

The first thing is to be a little patient, and see if you can work out a good enough consensus.  That often takes time, because various other project participants may not see this as their urgent priority; you need to allow sufficient time for feedback.  You may need to adjust plans and make it clear that you’ve taken feedback and changed your proposal.

Sometimes, you need to call for a [VOTE].  The ASF has some very broad requirements around voting,  but really most of the details of votes are up to each individual PMC.  In most cases, a majority of +1 votes carries the day, unless -1 voters have a technically valid veto that can be shown to make the project worse (for a code modification).

Sometimes, if there is a larger issue at stake – where the dev@ list isn’t helping you at least get closure (even if it’s not necessarily agreement), you may want to escalate the issue to the PMC.  Every Apache project has a private@projectname mailing list – that’s privately archived – where the PMC discusses only issues that require privacy – typically security issues, voting in new committers, and rarely personnel issues or code of conduct type issues.

What if I have a question about the ASF itself?

The Apache Community Development project – with its own PMC and everything – is here to help guide newcomers and guide unusual questions to the right place.  If you have a public question about where to find someting, or that crosses multiple projects, start on the dev@community.apache.org mailing list.

Apache has a handful of other cross-project mailing lists as well for conferences, infrastructure, and legal questions.  Note that those lists are also publicly archived unless they specifically state otherwise.  Any potential security vulnerabilities should go directly to the Security Team, which obviously uses private archives.

What if an Apache project is not responding to me? How do I escalate concerns?

The ASF is designed to give project PMCs maximum freedom in governing their own projects.  While the board does expect to see a certain set of behaviors – especially working by consensus and welcoming any newcomers with good work, regardless of employer – the board of the ASF rarely gets involved directly in project operations.

However, if there is a serious governance or community issue that a PMC is not addressing, you can work to contact the ASF Board of DirectorsPMCs report quarterly directly to the board, separately from other corporate operations (infra, legal, trademarks, accounting, etc.)

Vulnerability escalations go to the Security team; and legal issues or communications from counsel go to the Legal Affairs committee.

How do I ask about Foundation governance and corporate affairs?

Most corporate organization happens on privately archived mailing lists.  While project work is done in the open as much as possible, internal corporate work like paying the bills, signing legal documents, and the like are done either by volunteers or in a few cases by paid staff or contractors.  The Membership of the ASF has oversight and visibility to these processes, and it’s usually Members who are volunteering to help with the work.

For Members, the first thing to remember is to use the right list!  Each area of corporate operations has their own mailing lists: legal, trademarks@, infrastructure, treasurer, fundraising, or secretary.  There’s also an overall operations mailing list that’s a great place to ask where you should take your question since the operations volunteers there usually have helpful answers.

PMC Members and committers don’t have access to those list archives, but we certainly accept emails from them. Be sure to send in a clear question, so we know you’re waiting for an answer, and we’ll get back to you.  If your question is about a specific Apache project, it’s a best practice to always cc: private@projectname as well, so the whole PMC there is aware.

If your question doesn’t require privacy, then the best bet is to ask Community Development to point you in the right direction.

What else can I do to be effective at communicating at Apache?

Remember: Apache mailing lists often have hundreds of subscribers – so you’re sending email to a lot of people, all of whom are (for Apache purposes) part-time volunteers.  Knowing your audience is one of the key points when writing – and that’s doubly true when communicating with so many people from different backgrounds.

  • Write helpful and descriptive subject lines; make sure list readers understand if they need to read your email – or not.
  • Keep email threads on topic – preferably, a single topic per email thread.  If you need to add a new topic or feel the urge to hijack someone’s thread, please don’t – start a new thread, or at least change the Subject line.
  • Pause. Take your time. Most project decisions should not be made in a rush, and overwhelming the list with your posts in a short period often backfires when other community members get overwhelmed and stop participating.
  • Keep focused on the issues, and the value to the project or to the ASF as a whole. Even about code we can sometimes feel emotional; keep it based on facts and focused on the big picture.
  • For significant decisions, re-post a recap of the final consensus.  This is best done with a new email or at least a changed Subject.
  • For complex issues, lay out the big picture very clearly.  Sometimes it’s best to post “Hey, I/we are thinking of $big_change_like_X.  If anyone already knows they’ll want to veto it, let us know before we investigate!”  Then write up a detailed proposal, and send that to the list for discussion.  Similarly: start a [DISCUSS] thread with the expectation to gauge interest and possible consensus, before doing lots of coding or planning work and assuming the project will accept it.

Still wondering where to ask something?  See my FAQ of FAQs about everything Apache too!

The battle for the SOFTWARE FREEDOM name

There’s a conflict happening right now over the future of what SOFTWARE FREEDOM means that you’re probably not aware of. Like many conflicts over trademarks, it’s complicated – but it’s critically important to any open source project that wants to keep their own name and branding.

By Mari Helin-Tuominen on Unsplash

Why does this matter?  Because it may affect who can call themselves SOFTWARE FREEDOM® in the marketplace.

Continue reading The battle for the SOFTWARE FREEDOM name

How Apache *really* works

How much do you know about the Apache Software Foundation (ASF) and the many Apache projects we host? Did you know we’re holding our annual Members meeting to elect our board of directors and new Members in just a few days?

I’m often surprised by the variety of basic questions and misunderstandings I hear in the software world about how the ASF really works. We’ve written plenty of documentation about the Apache Way and our governance, but let’s try a different approach. I’d like to interview myself to try to explain some things. Continue reading How Apache *really* works

Three key elements defining any open source project

Open source has come a long way in the past 30 years and is entering the consciousness of most modern cultures. When thinking of open source projects, people categorize them several ways: governance structure, type of product platform, programming language, utility, technical details (language written in), industry sponsored or fully independent, and more.

But what truly defines any open source project, making it a unique entity different from all other open source projects? I would propose that there are three key elements of any open source project that frame, define, and differentiate that project from all others: the code, the community, and the brand.

Continue reading Three key elements defining any open source project

It’s Groovy to join a Foundation

The contributors behind the awesome Groovy project are looking for a new home. It’s bad news that the project and some of its core contributors will no longer be sponsored (paid for) by Pivotal, but it’s great that the core contributors are organized and serious about moving their project to an existing Foundation.

As a long time Apache Member (among other things), I have a few suggestions for the Groovy community.

Continue reading It’s Groovy to join a Foundation

ApacheCon Europe 2014 Blog Roundup

As our intrepid conference master and ASF’s EVP Rich Bowen Notes in the Margin,
we recently held a spectacular 24th ApacheCon at the beautiful
Corinthia Hotel in Budapest, Hungary – followed by the CloudStackCollab
conference focused on the fast-growing Apache CloudStack project.

Rich, LinuxFoundation production staff, and an array of Apache volunteers put
together a great set of talks with some very focused
tracks on specific days – both for technology as well as for community
and business interests around Apache projects. As Rich notes: if your are an
Apache committer and want to speak, or see your project represented at
the next ApacheCon US April 13-17th, 2015, in Austin, Texas then sign up to help organize!

Here’s a roundup of Apache folk’s blogs about the event:

Unfortunately we don’t have video for talks this year. That means that folks
who couldn’t attend are missing out on an inspiring keynote from this year’s
conference: David Nalley talking about the Value Of The ASF. This is one
of those talks where the slides don’t make sense without hearing about it.
David came up with various figures representing the “value” of the code that
all Apache projects provide – and they’re massive numbers. More importantly,
the larger value of the ASF is the proven Apache Way of organizing
large-scale, long-lived collaborative activities between heterogeneous
groups of individuals – and making it work in a way that allows companies to
invest their resources (employee time and sponsorship) without impinging on
the independent governance of Apache projects.

Matching our inspiring talks was the friendliness of the
staff at the beautiful Corinthia Hotel Budapest, along with the beauty, history,
and warmth of the city of Budapest and the people of Hungary. A week alone
is not enough to see the sights of the city, and it’s no where near long
enough to enjoy all the wonderful food and drink there! Here’s hoping that we’ll
be able to come back next year!

Thanks to the Apache CloudStack community!

Apache CloudStack graduated to become a top level project at the ASF last month, and a number of community members have been blogging about their experience. CloudStack started with a company called Cloud.com, was purchased by Citrix, and then was submitted to the Apache Incubator last year to now become a full Apache project.

Along with the great CloudStack software that Apache can now provide that allows you to manage your own public or private IaaS clouds, the Apache community has gained a great new community of committers, users, and PMC members.

In reading the several blog posts by key CloudStack contributors, I reminded myself that kudos were in order as well.

Having watched Citrix bring their code and developers to the Apache Incubator, and having watched (and commented on and answered many questions from!) the podling as it grew it’s community and graduated, I’ve been struck by how well the core Citrix contributors and their many other participants really took to the Apache Way.

Both Citrix as an organization (which employs some of the CloudStack committers), and especially the many contributors to the CloudStack project took the incubation process seriously, and have really gone above and beyond to ensure their podling proposal and march to graduation have been about Apache CloudStack, as well as being about an inclusive and meritocratic project.

The desire to get things “right” at Apache was clear in everything the CloudStack community did, and the end result looks to be an incredibly strong project that’s quickly gathering developers from a wide variety of vendors and users. Part of this growth is about the great technology; but a lot is due to the helpful and welcoming face that the CloudStack committers put on their project.

We’ve had a lot of great projects, and many great communities come to the Apache Incubator; there are a lot of people to thank across the tremendous spectrum of no-charge software that the ASF provides for the public good. But I just wanted to mention the extra effort the CloudStack community put into fully embracing the Apache Way. Good job, and thanks!

Ask Me about FREE Apache Contributor buttons!

Back once again at ApacheCon, I’ll be giving out free Apache “Contributor” feather buttons. All you have to do to get your button is let me know that you’ve donated funds to the Apache Software Foundation. Any amount qualifies for your free button!

If you’re interested in sponsoring the ASF at a higher level, we’d love that too, and I might have a bunch of buttons for you!

You may also see a number of people at ApacheCon featuring giant “Ask Me!” buttons with the Apache feather on them. Please – follow directions, and ask us your questions! A number of knowledgeable members are wearing these buttons, and will be happy to answer your questions about what the larger ASF is all about, and why the organization behind all of our great projects is also important to support.

For those who can’t make it to ApacheCon, please feel free to contact me offline or on the mailing list for your button.

Reminder: Apache and the feather logo are trademarks of The Apache Software Foundation, along with the names of our many projects – and should be used with respect both for the ASF as a whole and for the many committers in our project communities.

Congratulations to six new Apache projects!

In last week’s monthly meeting of the Board of Directors of the ASF, we approved the creation of six new Top Level Projects (TLPs) at the ASF. This is the most new TLPs ever created at once, followed only by the meeting of November, 2008 where 5 new TLPs were created (CouchDB, Buildr, the Attic, Qpid, and Abdera).

In this particular case, much of the growth comes from within existing projects, wherein subprojects communities within Hadoop and Lucene have matured sufficiently to deserve to manage their own fates, and to create their own Project Mangement Committees (PMCs) to take charge. To put this in another perspective, this is also reflective of the ASF’s growth; before this meeting we had over 70 TLPs and over 30 Incubator podlings, so an addition of 6 new TLPs is less than 10% growth for the month.

We should congratulate the Apache Traffic Server community first, since they went through the Incubation process and successfully graduated from an Incubator Podling into their own TLP. Soon to be served (once the website migration is complete) from http://trafficserver.apache.org/, Apache Traffic Server is fast, scalable and extensible HTTP/1.1 compliant caching proxy server. Congratulations to the whole team in showing a strong and diverse community around this new product.

Next up come three subprojects within the well-known Apache Lucene project which have grown organically from modules within Lucene to be diverse and active projects within their own right. You may recognize some of these product names from the Lucene world.

  • Apache Mahout, which is building a system for creating scalable and effective machine learning libraries which can perform recommendation mining, clustering, classification, and grouping into itemsets.
  • Apache Tika is a toolkit for detecting and extracting metadata and structured text content from various documents using existing parser libraries.
  • Apache Nutch, integratable with both Lucene and Hadoop, adds web-specific crawling, fetching, and organization features.

The Apache Hadoop project – another wildly distributed computing technology – has also grown two of it’s subprojects to the point where they deserve their own fame.

  • Apache Avro is a fast data serialization system that includes rich and dynamic schemas in all it’s processing.
  • Apache HBase is the Hadoop database – designed to provide random, realtime read/write access to Big Data – billions of records – using commodity hardware.

Why did these subprojects spin out to become their own TLPs? The driving factor is not the technology, but rather the community and oversight aspects of how the ASF organizes it’s mostly self-running projects.

From the oversight perspective, the ASF Board relies on every project’s PMC to manage their project’s operations within the broad guidelines of the Apache Way, and to report their project’s progress and issues to the board. This means that there must be enough PMC members who can actively monitor and participate in their project’s activities, and can especially show due diligence and responsibility in voting on any official product releases the project makes. With the rapid growth in both community and technology areas in the Hadoop and Lucene projects, it’s a difficult job for the PMCs to truly understand and help manage all the subprojects they’ve created or added over the past two years.

While the scope of oversight may have hinted that some subprojects should be promoted to TLP status, the gating factor is community. Does a subproject have a strong and diverse enough community to provide their own, independent PMC that can manage their own affairs? Becoming a TLP is both a benefit and a responsibility: the community through it’s new, more focused PMC can better run itself; however the new PMC is also expected to provide accurate reports and responsible oversight of their community and product releases.

Congratulations to all six new projects! Please note that as the websites are updated, each project will be moving it’s home page to http://projectname.apache.org in the near future.