This year's keynote speaker at Texas Linux Fest is Joan Touzet of the Apache Software Foundation. Joan's talk is Evolve or perish! Improving OSS communities the Apache way. She graciously agreed to this interview in the midst of her busy schedule.
Joan is a committer and PMC member for Apache CouchDB, and acts as an independent consultant.
Tell us about yourself.
I'm not sure where to start! I went to school to become an electrical engineer and ended up in software development. I've spent the better part of my career facilitating development: as a manager of development teams, as a facilitating consultant in development methodology and tooling, by building and running support teams that feed into development, and occasionally directly by coding. Outside of my professional career, I'm a musician and gaming aficionado, and I enjoy piloting small aircraft and vintage motorcycles. I currently call Toronto, Canada home.
I noticed from reading your website that among other accomplishments you are a private pilot. How has that skill contributed to overall success in your career? Has it given you a unique perspective?
I learned to fly in 2000 at a small New Jersey airport. The Northeast Corridor of the US has the busiest air traffic in the world, and learning how to handle radio communications while continuing to fly the aircraft legally within that highly regulated airspace is a challenge. I think software development is similar to VFR (Visual Flight Rules) in the Northeast Corridor: controlled chaos, with certain rules to follow, people to speak to, but generally a whole lot of freedom and beauty along the way.
How did you get into open source?
The first open source program I downloaded was elm, a UNIX-based mail reader with a text user interface similar to software I'd used on my PC. It was such an improvement on the built-in mail program that I got intrigued: How can they just give this away? I get the source code, too? While I'm not sure I submitted any patches to elm, I did with my next download, ircd (the Internet Relay Chat server daemon), and eventually became a team member, then team leader. That gradual progression inspired me to do more and get more involved over time.
Did you have a mentor? How has that helped your career? Are you a mentor for others?
I've had many mentors over the years, people who have helped me with different aspects of my career. It's difficult for me to describe the direct impact of a mentor. They're less about inspiration and more about being a solid counselor or coach. Often they've helped me navigate the murky corporate political landscape at my places of employment, something they neglect to teach you about in engineering school. Other times they've been sounding boards for the big decisions I've made in my life, such as living abroad or changing professional roles. Yes, I mentor for others, within corporate-sponsored programs and independently. I find the most fruitful mentorships are those with people with whom I already work, and that mentoring is just formalizing the relationship we were already building.
On the CouchDB website it says "Our primary goal is to build a welcoming, supporting, inclusive, and diverse community." How do you do that?
First, you have to be polite and patient beyond belief to everyone who comes through the door. That means answering every question on IRC, every email on the mailing list, every tweet the same way you would answer a question at a conference. It's certainly not a job for everyone, but we feel strongly that a welcoming, friendly face gathers more potential users than a gruff pointer to the documentation and a request to leave us alone because we're busy.
It also means not giving up on the negative and offensive people who come through the door, and doing everything you can to get them "on-side." Ultimately, it may mean having the fortitude to show them the door when differences of opinion become too extreme. What good is having a goal statement or code of conduct like ours if it is not also enforced?
Within Apache CouchDB, we also work extra hard to bring in non-traditional contributors and committers within open source: graphic designers, documentation writers, translators, marketers, testers, users with novel use cases—the list goes on. After making some contributions, we are eager to formalize them as official Apache CouchDB contributors, which often accelerates and energizes their work. It is surprising how much positive impact this has had on our project, and how we've been able to use it to build momentum.
One of the things that impressed me about your website was your diversity statement: "No matter how you identify yourself or how others perceive you: we welcome you. Though no list can hope to be comprehensive, we explicitly honor diversity in: age, culture, ethnicity, genotype, gender identity or expression, language, national origin, neurotype, phenotype, political beliefs, profession, race, religion, sexual orientation, socioeconomic status, subculture, and technical ability." Do you have metrics that ensure that diversity? How is that working for the project?
When I proposed to the PMC (Project Management Committee) that we add this text to the nascent Code of Conduct, together we looked at the CouchDB team and identified a subset of diversity from this list that were already present in the extended CouchDB family—about 50% of the list in its final form—especially taking our cue from individuals who had expressed in private to the PMC that they felt restrained from full engagement with the project because of discrimination against them. For instance, technical ability is on the list because you don't have to be a strong Erlang coder to be a valuable committer to the project—and people were seriously worried about having to become a code committer to be recognized as a formal contributor and help with things like documentation and marketing!
By building the "laundry list" and ensuring that people understood the PMC's intent to engage contributors regardless of these aspects, we went a long way to ensuring our existing base of contributors felt comfortable to continue in a more positive climate. It is such a simple task, and created such goodwill within the community, that it seems ridiculous that we didn't do it sooner. And contrary to the minority of nay-sayers, there have been zero negative repercussions. To wit, shortly after it became the Apache CouchDB diversity statement, it was adopted as the Apache diversity statement, verbatim—something I'm personally very proud of.
Like any project that has recently started a diversity journey, we still have a ways to go, and we continue to cast our net wider to encourage contributors of all shapes, sizes, colors, and backgrounds. Rolling out a formalized metrics effort is still on the drawing board.
Recently Jim Whitehurst, Red Hat CEO, published the book, The Open Organization. How important is openness to your project?
Crucial and indispensable. Our bylaws state that all official decisions of the project are taken on our mailing lists. The bylaws then go on to outline who can participate in various decisions, what mechanism we use to make that decision, where the decision is formalized, who can participate, and, when necessary, the timeframe we use to execute a formal vote. As any open source project thrives on change, we give an interested party everything they need to be successful in effecting change in Apache CouchDB.
Without this kind of guarantee, decisions can still be made out of the public view for reasons that may run counter to the project's spirit. They may favor a commercial interest, or personal ego. In the open we can review, analyze, and validate motivations as well as the technical merit of a decision we're making, and take action that benefits the greatest number of stakeholders. To me, open source is fundamentally about being open in all efforts, not just in the source code itself; those of us who run OSS projects owe it to our members to propagate that way of working.
One of the earliest Apache projects, Apache Tomcat, ran into a deadly snag when a decision was made in a back room, one that caused a lot of consternation with their 3.0 release. You can read about the aftermath if you'd like to know more.
In the preview of your talk on the Texas Linux Fest website there is the following statement: "The Apache Way and turned a toxic environment into a positive, supporting place for positive change." What is The Apache Way? How is it similar and/or different from other organizational strategies?
There is no one, simple definition of The Apache Way—more a set of guiding principles that help ensure projects are run in the best way possible. Some people will point to Apache's "multiple +1 votes, no -1 votes" voting rules as the core of the Apache Way, but I think that overlooks some of the more important aspects, and not all projects use the same voting restrictions either.
Shane Curcuru, a vice president at the Apache Software Foundation (ASF), summarizes the Apache Way as "Community, Merit, and Openness, backed up by Pragmatism and Charity." If you've worked in open source software, you're probably familiar with the concept of merit (those that can do, get to do), openness (decisions made publicly), pragmatism, and charity (free as in beer, and free as in freedom). But have you thought about your community?
I like to think that what sets The Apache Way apart from other open source philosophies is valuing community over code—something you read often when you look through the ASF's website and mailing lists. Think about that phrase for a moment. If all else is equal, are you prepared in your project to make decisions that might put the needs of your community members over those of the software itself? What impact might that have? Do you think that people using and writing your software will be more or less engaged?
It's key to remember that many people coming to open source choose to work on those projects, and many are not primarily making their living doing so. They're here because they want to be. Of course, it also includes people who work at companies, many of whom are in direct competition, who choose to collaborate on Apache's neutral ground because they know they will be assured a fair voice at the table. These people may also want to help build standards, but charge for value-added features and services. We (Apache projects) need all of these voices to help our projects succeed; thinking about that bigger picture when conflict arises helps us focus on that peer-to-peer relationship.
And that's just one component of The Apache Way. If you want to learn more, my best recommendation is to find an Apache project that interests you and get involved.
I noticed that Twitter is part of your marketing plan and that you yourself are very active on Twitter. How important is social media to your success and to the success of the CouchDB project?
Perhaps not in the way you think! Technologies like CouchDB power social media websites in ways that traditional SQL databases have a hard time managing. It is precisely the flexibility of data storage provided by a document-oriented store like CouchDB and the ease with which a system can store and replicate large volumes of data that defines the quality of service that can be provided. With CouchDB 2.0, we have merged the bigcouch fork that added clustering support to CouchDB, bringing us in line with similar AP-style databases such as Apache Cassandra.
Technology underpinnings aside, our weekly news updates that we promote on Twitter and our work with Influitive AdvocateHub have helped get the word out about our technology faster than we've been able to do through word of mouth or corporate partnerships. Open source is often a bottom-up effort, and social media plays to the strengths of bottom-up initiatives very well.
Is there something that I have failed to mention that you would like our readers to know about you or about CouchDB?
Please visit https://couchdb.apache.org/ to learn more about Apache CouchDB: "The Database That Replicates." It's a simple-to-use, web-based database that stores data in many configurations, allows deep querying, and replicates to other users or servers with a single command—making peer-to-peer or clustering architectures a snap.
Speaker Interview
This article is part of the Speaker Interview Series for Texas Linux Fest. Texas Linux Fest is the first state-wide, annual, community-run conference for Linux and open source software users and enthusiasts from around the Lone Star State.
Comments are closed.