Tag Archives: apache

Software Morghulis

In George R R Martin’s books “A Song of Fire and Ice” (which you may know by the name “A Game of Thrones”), the people of Braavos,
have a saying – “Valar Morghulis” – which means “All men must die.” As you follow the story, you quickly realize that this statement is not made in a morbid, or defeatist sense, but reflects on what we must do while alive so that the death, while inevitable, isn’t meaningless. Thus, the traditional response is “Valar Dohaeris” – all men must serve – to give meaning to their life.

So it is with software. All software must die. And this should be viewed as a natural part of the life cycle of software development, not as a blight, or something to be embarrassed about.

Software is about solving problems – whether that problem is calculating launch trajectories, optimizing your financial investments, or entertaining your kids. And problems evolve over time. In the short term, this leads to the evolution of the software solving them. Eventually, however, it may lead to the death of the software. It’s important what you choose to do next.

You win, or you die

One of the often-cited advantages of open source is that anybody can pick up a project and carry it forward, even if the original developers have given up on it. While this is, of course, true, the reality is more complicated.

As we say at the Apache Software Foundation, “Community > Code”. Which is to say, software is more than just lines of source code in a text file. It’s a community of users, and a community of developers. It’s documentation, tutorial videos, and local meetups. It’s conferences, business deals and interpersonal relationships. And it’s real people solving real-world problems, while trying to beat deadlines and get home to their families.

So, yes, you can pick up the source code, and you can make your changes and solve your own problems – scratch your itch, as the saying goes. But a software project, as a whole, cannot necessarily be kept on life support just because someone publishes the code publicly. One must also plan for the support of the ecosystem that grows up around any successful software project.

Eric Raymond just recently released the source code for the 1970s
computer game Colossal Cave Adventure on Github. This is cool, for us greybeard geeks, and also for computer historians. It remains to be seen whether the software actually becomes an active open source project, or if it has merely moved to its final resting place.

The problem that the software solved – people want to be entertained – still exists, but that problem has greatly evolved over the years, as new and different games have emerged, and our expectations of computer games have radically changed. The software itself is still an enjoyable game, and has a huge nostalgia factor for those of us who played it on greenscreens all those years ago. But it doesn’t measure up to the alternatives that are now available.

Software Morghulis. Not because it’s awful, but because its time has
passed.

Winter is coming

The words of the house of Stark in “A Song of Fire and Ice”, are “Winter is coming.” As with “Valar Morghulis,” this is about planning ahead for the inevitable, and not being caught surprised and unprepared.

How we plan for our own death, with insurance, wills, and data backups, isn’t morbid or defeatist. Rather, it is looking out for those that will survive us. We try to ensure continuity of those things which are possible, and closure for those things which are not.

Similarly, Planning ahead for the inevitable death of a project isn’t defeatist. Rather, it shows concern for the community. When a software project winds down, there will often be a number of people who will continue to use it. This may be because they have built a business around it. It may be because it perfectly solves their particular problem. And it may be that they simply can’t afford the time, or cost, of migrating to something else.

How we plan for the death of the project prioritizes the needs of this community, rather than focusing merely on the fact that we, the developers, are no longer interested in working on it, and have moved on to something else.

At Apache, we have established the Attic as a place for software projects to come to rest once the developer community has dwindled. While the project itself may reach a point where they can no longer adequately shepherd the project, the Foundation as a whole still has a responsibility to the users, companies, and customers, who rely on the software itself.

The Apache Attic provides a place for the code, downloadable releases, documentation, and archived mailing lists, for projects that are no longer actively developed.

In some cases, these projects are picked up and rejuvenated by a new community of developers and users. However, this is uncommon, since there’s usually a very good reason that a project has ceased operation. In many cases, it’s because a newer, better solution has been developed for the problem that the project solved. And in many cases, it’s because, with the evolution of technology, the problem is no longer important to a large enough audience.

However, if you do rely on a particular piece of software, you can rely on it always being available there.

The Attic does not provide ongoing bug fixes or make additional releases. Nor does it make any attempt to restart communities. It is
merely there, like your grandmother’s attic, to provide long-term storage. And, occasionally, you’ll find something useful and reusable as you’re looking through what’s in there.

Software Dohaeris

The Apache Software Foundation exists to provide software for the public good. That’s our stated mission. And so we must always be looking out for that public good. One critical aspect of that is ensuring that software projects are able to provide adequate oversight, and continuing support.

One measure of this is that there are always (at least) three members of the Project Management Committee (PMC) who can review commits, approve releases, and ensure timely security fixes. And when that’s no longer the case, we must take action, so that the community depending on the code has clear and correct expectations of what they’re downloading.

In the end, software is a tool to accomplish a task. All software must serve. When it no longer serves, it must die.

Event report: ApacheCon North America, 2017, Miami

Event Report, ApacheCon North America 2017

May 15-19, 2017

(This is an abridged version of the report I sent to my manager.)

Last week I attended ApacheCon North America in Miami. I am the conference chair of ApacheCon, and have been for on and off for  about 15 years. Red Hat has been a sponsor of ApacheCon almost every single time since we started doing it 17 years ago. In addition to being deeply involved in specific projects, such as Tomcat, ActiveMQ, and Mesos, we are tangentially involved in many of the other projects at the Apache Software Foundation.

Presentations from ApacheCon may be found at https://www.youtube.com/playlist?list=PLbzoR-pLrL6pLDCyPxByWQwYTL-JrF5Rp (Yes, that’s the Linux Foundation’s YouTube channel – this ApacheCon was produced by the LF events team.)

I’d like to draw specific attention to Alan Gates, at Hortonworks, who has developed a course to train people at the company in how to work with upstream projects. He did this because, as the company expanded from a small group of founders who deeply understood open source, to thousands of employees who kinda sorta got it, but not always.


Also of great interest was the keynote by Sandra Matz about what your social media profile tells the world about you. It’s worth watching all the way to the end, as she doesn’t just talk about the reasons to be terrified of the interwebs, but also about how this kind of analysis can actually be used for good rather than evil.

Why I love ApacheCon 

This is the lightning talk I gave this evening at ApacheCon: 

ApacheCon is a high point of my year, every year, going back to March of 2000.

In late 1999, Ken Coar told me I should submit a talk for ApacheCon. Astonishingly, my talks were all accepted, and I found myself in Orlando speaking in front of a few hundred people who thought I knew what I was talking about. I have since made a career out of that particular game.

This is the 28th ApacheCon since the creation of the Apache Software Foundation. 29 if you count the event in 1998 before there was a Foundation. I don’t count it, because I missed it. I also missed the ApacheCon in Sinsheim, Germany, in 2012, for which I will never forgive my boss at the time. But I *think* I have been to more ApacheCons than anyone else. 27 of them.

I love being on stage. With hundreds of people looking at me, hanging on my every word, believing I know what I’m talking about.

But there’s other reasons I love ApacheCon. It’s the place I go to see some of my oldest friends – many of whom I first met at ApacheCon, including some new ones this week.

I love ApacheCon because it shows me that I’m not alone. As C. S. Lewis said, we read to know that we’re not alone. Except that he didn’t say it. It’s actually just a quote from a movie about him.

I love ApacheCon because I love Apache. And Hawaiian shirts. Shane’s lightning talks are another high point of my year, because they are both entertaining and informational. Except I hear he’s not giving one this year.

I love ApacheCon because of the passion that I see in the people that attend. People that love Apache, and also love solving actual real world problems. The sessions here at ApacheCon range from the esoteric and philosophical to the deeply practical, but at the heart of each one is a desire to solve problems in the real world. To scratch your own itch, as the saying goes.

I love ApacheCon because of our sponsors. Talking to sponsors about why they are here at ApacheCon has the effect of re-centering us. Sure, open source is about having fun and tinkering, but it’s also about solving problems for real people that rely on us. People that depend on Apache because we have a reputation for vendor-neutral, high-quality software which is sustainable because of those esoteric philosophies that we cling to even in the face of practical realities.

I love ApacheCon because of the time I’ve put into it. I’ve worked on ApacheCon for 18 years now. I often refer to ApacheCon as my life’s work. I spend hundreds of hours on it, and so do many other people, including our amazing producers, our numerous volunteers, our tireless Infra contractors, our beloved Melissa, and our supportive board of directors. ApacheCon is my sweat and tears, literally and figuratively. It’s older than two of my kids, and the oldest kid grew up knowing that Dad loves ApacheCon. The wall in my office is covered with ApacheCon attendee badges – 27 of them. And ApacheCon has become a part of my identity.

So as we look forward to the next ApacheCon (details coming very, very soon, I hope) we need to figure out what *you* want ApacheCon to be, and make it that, rather than doing it just because it’s what we do, and what we’ve always done. ApacheCon is about building community, more than it’s about anything else, and that’s really why I love ApacheCon. I love seeing communities come together around a common goal, and believing that I was a catalyst in making that happen.

So, thank you so much for coming to ApacheCon, my friends. I hope you’ll come again, and I hope that you’ll come to love it as much as I do. But that might not be possible.

No, Apache did not send you spam

Today, the ASF received yet another complaint from a distraught individual who had, in their opinion, received spam from the Apache Software Foundation. This time, via our Facebook page. As always, this is because someone sent email, and in that email is a link to a website – in this case, www125.forcetwo.men , which is displaying a default (ie, incorrectly configured) Apache web server, running on CentOS.

This distraught individual threatened legal action against the ASF, and against CentOS, under FBI, Swedish, and International law, for sending them spam.

No, Apache didn’t send you spam. Not only that, but Apache software wasn’t used to send you spam. Unfortunately, the spammer happened to be running a misconfigured copy of software we produced. That’s the extent of the connection. Also, they aren’t even compentent enough to correctly configure their web server.

It would be like holding  a shovel company liable because someone dug a hole in your yard.

Or, better yet, holding a shovel company liable because someone crashed into your car, and also happened to have a shovel in their trunk at the time.

We get these complaints daily, to various email addresses at the Foundation, and via various websites and twitter accounts. While I understand that people are irritated at receiving spam, there’s absolutely nothing we can do about it.

And, what’s more, it’s pretty central to the philosophy of open source that we don’t put restrictions on what people use our software for – even if they *had* used our software to send that email. Which they didn’t.

So stop it.

 

Apache Board

This time last year, I was nominated for the Apache Board of Directors, and I wasn’t very keen on it. I was on the down-swing of getting burned out with ASF stuff, which comes every few years of any volunteer effort, no matter how much you believe in the mission of the organization. It does one good to step back from it every few years.

I made a rather half-hearted position statement that basically said: “all of the people on the ballot are great, and any board chosen randomly from this slate will be great.” I wasn’t elected to the board.

However, midway through the term, there were some resignations, and I found myself on the board again.

This time around, I am much more passionate about it and have actually made an attempt to state what I think the board needs. In short, it’s more delegation.

We have arrived at the size where we must delegate, trust those to whom we delegate, and resist the urge to tinker in the minutiae. This is very, very hard, and is especially hard for our current slate of directors, because we are all so deeply passionate about the mission of the Foundation.

Non-profit and volunteer-based organizations have the tendency to rely on heroes – people who take on 90% of the work, rather than delegating. The thing with heroes is that they are awesome as long as they are around. But eventually, they burn out, or retire, or move on to other things, and then suddenly you have a crisis. We need to find a way to identify areas where one person is doing a disproportionate amount of the work, and find a way to delegate that work to several other people, and then be willing to let them do the work, even when we think they’re not doing it exactly the way we’d do it ourselves.

The election of the new board will happen at the ASF members meeting on March 28th. And whether or not I’m elected, I have my work cut out for me in the coming year at Apache. There’s just so much to do.

Living in community: Curbing your passion

1 Comment

I’ve had a very frustrating set of interactions over the last 3 days, on an open source community mailing list. Doesn’t matter which one, because I think that these things are universal.

I said “here are some ways we can make things better.” Or, at least, that’s what I thought I was saying.

Several people heard “everything is broken, and it’s your fault.”

At the end of several very heated email conversations, it became clear to me that we all agreed on (almost) everything, and were getting hung up on that initial statement. It wasn’t even that the things that I was proposing were opposed, it was that the way that I presented them was perceived as criticism of what people had done for the last few years.

Email is notoriously bad at conveying nuance. This is amplified in a multi-cultural, multi-lingual community.  Here’s some practical things that I took away from this conversation – most of which I should have already known

Suggest improvements. Don’t focus on shortcomings

Pointing out breakage is easy. Proposing solutions is where the real work is. Now, sometimes, you need someone to say “this is broken and I don’t know how to fix it.” Those situations are very tricky. Tread lightly.

Focus on what needs improving, not on who made it that way

This sounds easy, but is really hard. There’s always someone who spent hundreds, or thousands, of hours, making the thing the way that it is, and so when you point out that the thing isn’t perfect, that person might take it personally. I honestly don’t know how to avoid that, and this week has shown that very clearly. But I can look back and identify some of the things I did poorly, and apologize for them.

Curb your passion

This one is unintuitive. We need to be passionate about our community. But sometimes when you’ve been pondering something for a few months and arrive with all of that passion, people are more likely to mistake that passion for anger, criticism, and so on.

Yes, some people need to get thicker skins. Don’t read everything I’m saying as that we need to pamper everyone’s bruised feelings. But when people aren’t looking in your eyes, it’s easy to take passion as an attack. We’ve all done it.

I’ll close with one of my favorite quotes from Confucius, who said, “There is honor in the email not sent.”

Yes, he said that. I was there.

Read your email twice before you send it, and delete half of them unsent. This will lead to a better universe, and fewer three-day shouting-fest email threads.

 

Features, not lies

A colleague is attending the nginx conference in Austin this week, and shared with me several anecdotes in which a speaker preached misinformation – or if I want to be generous, grievously outdated information – about Apache httpd, to support the notion that nginx is better.

This led to the following:

 

Each time I have encountered nginx people at conferences, and attended their talks, they have compared nginx to grossly misconfigured, 10 year old installations of Apache httpd 2.2 to support their claim that nginx is leaner, faster, and easier to administer.

Here’s the thing. nginx is a solid project. I have zero beef with the software itself. I have used it myself, when the need arose. What I object to is the habit of the fans of nginx to lie (or exaggerate, or just spout uninformed opinions) to make themselves look better. If you must compare, compare our latest to your latest, and have experts correctly configure each. That way, each will show where it shines, and where it doesn’t.

It is possible to configure ANY software badly. This is why it’s almost always a bad idea for an expert on SoftwareA, who knows little or nothing about SoftwareB, to compare them head to head – they’ll invariably be comparing a well-configured A to a less than optimally configured B. And in the case of nginx vs Apache httpd, these guys almost always use 2.2 or 1.3 as an example of … well, all of the things that 2.4 fixed. 5 years ago.

Any intro to marketing class will tell you that you need to talk about your own strengths more than you talk about the other guy’s weaknesses. This is a message that nginx and presidential candidates seem to have missed. And, in the case of software, it’s even more important, because whereas Donald Trump will always be a monster, every time you point out a legitimate shortcoming in Apache httpd, we fix it.

Convert an Apache httpd password file to dbm

If you have a textfile password file, and you want to convert it to a dbm database for use with mod_authn_dbm, this can be done as follows:

htdbm -cbp passwords.dbm bogus bogus
awk ‘BEGIN { FS=”:” }; {system (“htdbm -bp passwords.dbm ” $1 ” ”  $2)}’ passwords
htdbm -x bogus

This assumes that the file `passwords` is your existing password file, and that you wish to create a dbm database `passwords.dbm`

The -b flag says that the passwords will be provided on the command line. The -p flag says not to encrypt the password – because it’s already encrypted.

This feature used to be available in the `dbmmanage` utility, as an `import` argument, but that utility is no longer included in the httpd packages for the Fedora/CentOS and Debian/Ubuntu Linux distro families, so we have to make do with htdbm.

I’m stashing this here for posterity, since I just spent a half hour getting the awk syntax right.

The first line creates a starter dbm with a single bogus entry, and the third line cleans up that bogus entry.

Festina Lente

5 Comments

FestinaLenteCorrect

On Wednesday morning I learned that my long-time friend Nóirín Plunkett has just suddenly passed away.

Update: It’s been mentioned that Nóirín stated, on their Twitter profile, a preference for the personal pronouns they/their. It’s been mentioned that I should update the below post to reflect that preference. Grief is a weird thing. We remember people as we remember them, not as other people want us to remember them. I knew Nóirín in an earlier chapter of their life, and I don’t intend any disrespect by how I recount those memories. Nóirín influenced different people in different ways. To me, Nóirín was a grammar geek, a friend, an unstoppable force, and a deep enigma. I miss the Nóirín that I knew, and I’m aware that Nóirín grew into a different person in their later years. Grief is both a very public thing and a very personal thing. I mean no disrespect of either Nóirín nor of their other friends and family. I just remember Nóirín differently than you do, and that’s probably ok.

I first “met” Nóirín on the Apache httpd documentation list, where they helped in the process of making the documentation into a literate manual, with consistent grammar, reasonable organization, and a more professional face. I then met them, in person, for the first time, at the ApacheCon planning meetings in Dublin, where they arrived with Colm and whipped things into order, imposing a great deal of organization on what had been a pretty chaotic process in previous years. I also had the great privilege of spending time in their home with her family while we were there, and these are some of the happiest memories I have of our friendship.

Nóirín contributed a great deal to the Apache Software Foundation over the years in a number of places. They continued her work on the httpd docs for a while, but began to move into community-facing things, such as ApacheCon, where they served as Conference Committee chair for a few years. They were  instrumental in making the ASF more clueful about diversity issues. They also served a year on the board of directors.

In recent years, Nóirín has been more involved with the larger effort to improve the plight of women in technology, and their direct involvement in Apache has faded, and we’ve missed them. We will now miss them even more.

Nóirín’s motto was Festina Lente – Hasten Slowly, and this embodies their approach to life. They considered things carefully, and rushed to get things done, because life is too short to get everything accomplished that we put our minds to. In the end, theirs was far, far too short.

It’s also a jarring reminder that you may never have another chance to resolve that disagreement, so you’d better do it now, before it’s too late.

Goodbye, friend.

noirin_small

If you knew Nóirín, or benefited from her work, please consider donating to St John Abulance in their name.

Twine

This week we did ApacheCon in Austin. I shipped the original Apache feather to the venue for 20th birthday of the Apache web server project, and it hung above the stage for the keynotes.

image

It’s an item that we’re very proud of, and of some historical significance.

The conference producers treated it like it was the Declaration of Independence or something. They handled it carefully and reverently.

At the end of the event the guy in charge of A/V came to me with some twine.

image

He said he had removed it from the hanging hooks on the feather in order to use black nylon that matched the stage dressing, and which would hang more securely. But he saved these scraps of twine because he knew how significant the item was to us.

Now, it’s not that the twine mattered – it was something I added years after the original was made. It’s that he cared enough, and respected our heritage enough to save it and track me down, that impressed me so very much. It really put a wonderful final touch on an almost-perfect event.

And this is why, among many other reasons, we love our conference production company, The Linux Foundation.