Author: Shane

FOSSBackstage in Berlin this year was AMAZING! The quality and importance of the talks to the FOSS ecosystem was surpassed only by the interesting hallway and after conference discussions. Having recovered from jet lag, I figured I’d better start writing down all the contacts I met and collaboration ideas we thought of before I forgot them!

I’m so excited to be in the opening keynote at ApacheCon – or rather, what we now call Community Over Code (COC), the conference where all our project communities across the ASF gather, learn, eat and drink together, and maintain all the personal relationships that truly build communities. For many of us who’ve been working on ASF projects for years, this is truly a conference where we spend time not just with our friends, but folks who have become like family to us in our communities here.

If you’ve never been to an ApacheCon in the past, it’s not like your traditional tech conference. When we rebranded the conference as Community Over Code, it was intentional – because the point of our events are the people. So much of open source work is done online, without direct human contact. ASF events have plenty of technical content, but the real value to the ASF as a foundation are the personal connections people make and strengthen, and the community building that happens. That’s also why we always have a number of non-technical tracks, like Community and Sustainability to really help our contributors better understand how to manage their own communities across the ASF.

I’m doubly, no, triply excited to be back at COC after the long lonely days of COVID in the past few years. It wasn’t just the excitement and learning that I find at ASF events; it was missing all of my friends and family. While many conferences have hallway tracks and evening events, the strength of community in many ASF communities means something different. There are so many different relationships we each have in different projects, and so many truly strong friends to be found here. And it’s not just the folks you have drinks with after dinner; it’s all those people who have become friends in real life, outside of technology – all the people who say “Hey, I’m vacationing in Boston, are you around?” and I get to host them.

For those here at COC, I’m excited to meet you (or see you again, dear friend) at the event. I’m easy to find, I’m wearing a Hawaiian shirt. For those not at COC this year in Halifax, we’ll see you in Europe next fall!

For more about the event named Community Over Code, head over to the .org domain!

❤️

Are you opnionated about Apache projects? Do you like great tech conferences with no commercial puff pieces, just focused technical and community content about real projects? Do YOU have great things to talk about your project at the ASF?

Submit your talks to the ApacheCon CFP now! CFP is ending in just two weeks, and the conference will be 7-10 October in beautiful Halifax, Canada.

Wait – did I say ApacheCon? Oh, sorry! ApacheCon is now called Community Over Code – The ASF Conference. To better reflect the emphasis ASF projects have on active communities, the ASF’s annual conferences have rebranded to the slogan for ASF processes overall: Community Over Code.

This year, Community Over Code will feature four days of sessions, with tracks focusing on Search, Big Data, Internet of Things, Community, Geospatial, Cassandra, Financial Tech, and many other topics. Each evening will also feature Birds of a Feather (BoF) sessions, where communities will have an opportunity for free-form discussion and planning around our various projects.

I’ll be attending and hopefully speaking at Community Over Code this fall, and hope to see folks there – it’s been a long few years of travel limits due to the pandemic. I’m really looking forward to spending time with my larger ASF family again.

Just a reminder: this blog at a .com domain is Shane’s personal content. The ASF’s official conferences can now be found at https://communityovercode.org/. I’ve worked with the ASF’s VP, Brand Management to ensure that we can each continue to use the Community Over Code phrase in complimentary ways to each other.

I hope to see you in Halifax this October!

I’ve been reading papers on “sustainability” frameworks of shared definitions, and was struck in many of the sections on Stakeholders. We think about the various FOSS projects, about the big industry players, about the rest of the user base commercial companies, and even about public policy. And yes, we do talk about “pay the maintainers”, and there are several organizations solidly devoted to that problem.

But what about volunteer individual coders as a class?

Much of open source contribution is done in small chunks by individuals “scratching their own itch” to fix a bug or add a new feature they happen to need. While some of this is done in conjunction with a job or a college class, some of it still done just because the coder wanted to get it done, not necessarily to get paid or a better grade.

A poor definition of this class is “everyone who’s contributed to open source without directly getting paid for it”, which doesn’t help much, but does give perspective on the scale. And most people working in software are likely to go back and forth from paid work to some kind of volunteer work (either piecemeal fixes or as part of a larger effort) many times in their career.

How can we classify all these individuals?

• Software industry career workers, who will likely have many different roles in a career. They may sometimes lead projects, and often will make significant investments over time. They may often have a holistic perspective on FOSS components in relation to their business, so often are very conscious of what they open source, and what is proprietary.
• Software industry-adjacent workers, who will work on specific bugs or features their industry needs from time to time, but primarily focus their work on custom features internally (i.e. possibly not contributions).
• Academic, scientific, and policy/government workers who build software. When they open source something – depending on institution policies – they are more likely to be careful to ensure an entire package is included, so that their work can be easily reproduced elsewhere.
• College and high school students looking for learning opportunities or connections in industry. Only part of the driver here comes from curriculum; much of the drive likely comes from where the students first feel they can make contributions and get some feedback or recognition.
• Hobbyist hackers who have a passion for their work. Yes, they still exist, although it’s certainly a rare individual here who truly drives an entire project these days. But where hobbyists show up, they can be an important part of maintenance and quality control. Hobbyists are likely software industry professionals who truly do open source at night, separately (in some cases deliberately) from their day jobs.
• Who am I missing? I know there will be a handful of other sub-groupings that could be useful to consider tracking.

What messaging can we use to encourage individuals?

These groups are obviously quite diverse in other characteristics, and include millions of people, so it’s difficult (except perhaps in public policy spheres over years) to directly influence them. But we certainly need to include this concept in discussions about sustainability.

One potentially practical task is to find ways to promote messaging that can continue to inspire newcomers to open software (or science, or government!) that yes, it is important they contribute, even in a small way. Helping FOSS organizations, projects, and communities find even slightly shared ways to both be friendly, to explain how to do things in their world, and to provide the general encouragement to newcomers seems like a useful practice area to help nudge the actual FOSS world into better sustaining itself.

Reading about open source sustainability the past few weeks, I’ve been trying to find some pithy and useful quotes to start building out my FOSS Sustainability website. I started with a listing of the obvious resources – key funding sources, some overviews about how governance and funding mesh (or don’t), and the like. But between reading industry blogs and scratching the surface of research papers on sustainability, I haven’t found great answers yet. What have I found?

More questions.

Sustainability as a concept around open source projects and communities is such an overloaded idea that I’m having a hard time finding a specific place to start. So instead, let’s start with a list of some focus areas and questions to ponder, in terms of what perspective or audience we’re starting with. Thankfully, I’m also finding out many other folks are in the same boat, and are working on figuring out how to define this in broader, more useful ways.

Who is our primary focus?

The obvious group are “Pay the maintainers”, individual coders managing widely-used independent projects. The flip side are enterprises – who might pay for the projects they use, and various funding organizers: either grantmakers, collectives working on pooling and releasing funds, or even simple sponsorship buttons you can put on your repo.

The other kinds of maintainers are in community-governed, foundation-based, or corporate-sponsored projects. Plenty of projects are written by a combination of paid employees by one or more leading corporations, plus a constellation of individual coders or smaller companies.

The enterprise perspective is an entire universe of it’s own: often the people who understand the value of software they use are disconnected from people who control funding or strategy in a company.

Governments, NGOs, standards bodies, and the like are another universe of people concered about sustainability. Their perspectives are starting to get broadened by the growning research about both FOSS software impacts, but also risks, security, supply chain issues, and all the other news we read about lately.

Oh, and of course end users.  Where do they fit in with sustainabilty? Does the average user even understand they’re using open source inside whenever they touch a smartphone or computer?

What kinds of sustainability do we mean?

How do we keep open source software secure? Heartbleed’s giant security scare eventually turned into Core Infrastructure Initiative, a foundation to help fund quality and development of OpenSSL. But what about security across the hundreds of other critical projects used everywhere?

Are we concerned with keeping certain kinds of projects alive and self-managing and making bugfixes? Or are we concerned with the core infrastructure bits that everyone uses, and keeping them as solid upstream projects – instead of one particular vendor simply making all the fixes to their version, which becomes the de facto one most folks use?

How about long-term sustainability of the code itself, physically? How long are archives guaranteed, will they be findable, include history and releases?

How about keeping tooling current to today’s versions of other software bits in the dependency chain? Is there anyone around who can even recompile Tool X that uses frequently updated Dependency Y to ensure the binaries work correctly?

Of course all these questions might be changed subtly depending on the programming languages, and how projects are architected – or documented. The kinds of long-term tweaks to a UNIX utility are very different than a bit of Java middleware.

Does money come into it?

It’s more difficult, but you can find ways to make some projects sustainable without throwing money at them. But in most cases, we need someone to make a financial investment. And while sharing code has zero cost across any sort of boundaries, sharing financing and legal relationships (of employees, contractors, service providers, or whatever!) have significant costs – and lots of asymmetry in terms of knowledge and capacity to manage transactions – or even know they could ask for transactions (or some funding).

Which organizations are we considering?

Software companies (who build something related here) behave differently than other companies. Enterprises have very different resources and constraints than midsize or smaller companies. What about nationality and local law factors in how companies use or maintain their software dependencies?

By now you can see my theme: each of these general topic areas has a whole host of sub-topics, many with very different concerns even when they might seem similar. And of course the real world is a matrix of matricies of relationships between the who, the what, the money, and the how.

Feeling a little overwhelmed? I’m right there with you. Thankfully, that’s one of the exact questions some smart folks are thinking about right now: how can we define “sustainability” with some concrete concepts and shared terms / categorizations that we can all understand and agree on?

We’ll see! But I’m meeting some people that are making this very, very interesting to work on!