All posts by rbowen

Knife costs

I posted on Facebook a few days ago that I’m available to make custom knife handles for folks who are interested. This post is to give an idea of what this would cost.

Note that I do *not* forge blades. At least not yet. Just handles, on blades I purchase elsewhere.

So, here’s how you figure out cost. There are FOUR components.

First, the blade, which I get from Premium Knife Supply. Typically from the kitchen knife section. So have a look at this collection, and if you just want one of those knives, you can find the model number in the listing, and get the price of just that one knife. For example, my favorite of that set is the PSK11, which goes for $18.

Next select the handle. There are a virtually unlimited number of possible handles. I like to buy from Texas Knife Supply, which has handle materials in wood, bone, antler, and acrylic, among other materials. But there are also dozens of vendors on Etsy that have knife handle materials, or “scales” as they’re called in the lingo. Knife handles range from a couple dollars all the way as much as you want to spend, depending on many factors. I prefer to work with exotic woods, and look for woods with prominent grains, but this is completely a matter of preference. A lot of the options on TexasKnife are one of a kind, so it’s hard to link to a generic product, but for example, right now I’m looking at a Desert Ironwood set of scales and it’s $27.

Third, there’s the knife pin. This is optional, but I like to use what are called mosaic pins, and you can find a million different styles on Etsy and You can go with an existing style, or get a custom-made pin. Custom is, of course, more expensive and takes longer. For some reason, I’ve gotten the best results from vendors in Turkey. My most recent custom pin was from EMAForge, which says it’s in Kentucky, but the actual product shipped from Turkey and took 4 weeks. Pins cost anywhere from a few dollars for a standard design up to $50 or so for custom. I favor 8mm pins, because they’re large enough to actually see what the design is.

The final cost is just getting it done and shipped. I’m not looking to make a lot of money off of this, but I do want to cover costs and make a little bit as incentive. I figure 10% markup, plus shipping, is reasonable.

So, if you were to do exactly the above, you’d be looking at about $80 in expenses, plus $10’ish in markup, plus $20 in shipping, so $110 for a the whole deal. And about 6 weeks for the entire process – most of which is just receiving materials. It generally takes me 2 days to actually make the thing.


The word for world is forest

The word for world is forest, by Ursula Le Guin.

It took me awhile to get into it. It’s kind of slow building. But by the end I was completely hooked. It’s one of those stories where there’s no good guys. Just complicated people. And it’s definitely a product of its time, but still stands up.

There were a few moments where it was very clear when this was written. For example there was a reference at one point to children playing blacks versus Rhodesians. Which puts it firmly in the early 80s.

But other than that the themes were universal. Racism, slavery, and toxic masculinity.

It’s a quick read, and worthwhile if you like interplanetary sci-fi.

Why “open source” still matters

Stephen O’Grady expresses very clearly what I was trying to articulate earlier this week.

This is in response to Matt Asay asserting earlier in the week that it no longer matters whether software is actually open source, because it’s “open enough” or whatever.

Arguing that the definition of open source doesn’t matter because developers don’t care about it is like arguing that climate change doesn’t matter because citizens don’t care.

Thoughts on open source community and “giving back”

[Note: This is really two articles that I’ve smooshed together into one. At some point, I need to tease them apart and publish them separately to avoid muddling the ideas.]

If you hang around open source for more than a few minutes, you’ll hear someone talking about “giving back to the community,” as though it is some kind of moral obligation or repayment. And while contributing to open source purely out of a sense of altruism is great for philosophy students, the reality of open source contribution is very different.

Open source software is pragmatic. People contribute to it, primarily, for practical reasons. For example, most people contribute a change to an open source project in order to improve it for their own benefit, or the benefit of their company or customers. This has historically been called “scratching your own itch.” And you contribute that change to the project, rather than keeping it to yourself, not out of generosity, but so that you don’t have to maintain a separate version of the software with your change in it. It’s also to ensure the sustainability of a piece of software that you rely on. Making it better ensures that it will have happier users (or customers), and thus be more successful and last longer.

The other side of this misnomer is that one contributes changes “to the community.” Open source contribution, done properly, makes you part of the community. The contribution is to yourself, not to some other group of people that you’re not a part of. Contributing to the project is a step towards earning trust and gaining ownership of the project.

Projects which do not immediately attempt to capture contributors by welcoming them into the community are similarly misguided. This is often done for seemingly sensible reasons, but in the long run, it’s always a case of giving up the long-term health of the project for dubious short-term benefits.

The most common of these short term benefits is control. I, or my company, want to have more say in the direction of the project than any outsider. And the more control you strive to have, the greater chance that contributors will get frustrated and go away, or that users will choose an alternative where they have greater say in the project’s choices.

A lot of this has to do with a mistaken definition of “community.” A community is not a gleeful band of friends dancing around a campfire. A community is nothing more or less than a group of people with a common mission. If you are unsure what the mission is, then you’re not a member of the community. Similarly, a “community” which is unsure of their mission isn’t likely to last very long.

As it happens, friendship is often a side-effect of strong communities. This is simply because you’ve found your people – people who share your mission – and so friendships are easier to form. But friendship is not the goal of effective communities, just a happy outcome.

As always, I encourage everyone to read Charles Vogl’s book “The Art of Community.”

“Community > Code” doesn’t mean that the code is unimportant. Rather, it means that the code is a means to the end – the end being the mission of the community. The community (ie, the mission) is more important than the code, because it is the mission that drives the community. The code is a vehicle. The code serves the community (ie, the mission).

Open source projects should give a lot more thought to their mission. Not the function of the software, so much as what problem they are trying to solve. Communities that lose sight of their goal, or who never clearly understood it in the first place, tend to spend a lot of time casting about for things to do, because they’re not sure what they’re trying to accomplish.

The Apache Software Foundation’s mission isn’t “software for the public good” – that’s just a phrase for legal documents. The mission of the ASF is to provide a vendor-neutral place where important software can be developed without the threat of corporate capture. This is why the httpd project was created in 1995 – to ensure that the vendor capture that happened to the NCSA web server wouldn’t be likely again. And it’s why the ASF was formed – to ensure that one vendor didn’t get outsized influence in the projects.

All of our rules serve that goal. If a rule seems unmotivated by that goal, then perhaps it’s time to reconsider the rule. And losing track of that mission results in us being unsure how to enforce community mores that serve that mission. (Like single-vendor projects, for example, or too-high bars to inviting committers.)

Upgrading your external drive on a PS4

If you have a Playstation4, you’ll eventually run out of drive space. You’ll want to use an external USB drive. And then that will eventually run out of space. You’ll want to get a larger one, and then you’ll be stuck with the question of how to copy the data from the old one to the new, larger one.

While the official answer is “no, you can’t do that”, here’s how you actually do it. (Yes, amazingly, this is actually not something you can do with any on-board tools. You will find many wrong answers from well-meaning people online.)

  1. Find your geeky friend who runs Linux. Bribe them with pizza.

  2. Run `df -h` to list what drives are already connected.

  3. Plug in old drive, and run `df -h` again to see where it attached. This will probably be `/dev/sdb` unless there were already additional drives. Trust your Linux geek friend.

  4. Plug in new drive. It will probably land at `/dev/sdc

  5. `sudo dd status=progress if=/dev/sdb of=/dev/sdc` (Replace sdb and sdc with wherever those drives landed, if they are somewhere else.)

  6. Wait for ages while the copy completes. This will make an exact bit-for-bit copy of the old drive onto the new drive. As it copies it will show you how much data has been copied, so that you can get a general idea of how long it will take. I get about 40 to 50 MB/s across a USB connection, so do the math. It’ll take a few hours.

  7. When you plug the new drive into your PS4, it will probably complain and say that it needs to repair it. Don’t panic. Let it do its thing. All will be well.

  8. I am reasonably sure that this process will also work for the PS5 filesystem. Would be happy for someone to buy me a PS5 so I can test.

Since PS4 uses a custom filesystem, you can’t just mount the drive on Windows or Mac and copy, but `dd` doesn’t care about filesystem format, it’s just a low-level data copy, and will gladly copy whatever is there. As long as the target drive is as large, or larger, than the source, it’ll Just Work.

And that’s why everyone needs a geeky friend who runs Linux.

whosthat: Minimal command-line Rolodex

I have a hard time keeping track of the cast of characters in my job. There’s so many projects, and so many people who work on each. A dozen times a day I have two questions: who’s that, and who works on XYZ.

I’ve been looking for a solution for this that works with how I work and think, and everything that I found suffered from one or more of the following problems:

  • Windows-only
  • Doesn’t sync between my machines
  • Data hosted somewhere that corporate security would frown on
  • Expensive

I finally decided that what I needed was something that I host myself, which syncs between my various machines, and which I can use from the command line, because that’s where I spend most of my time.

So, here it is:

whosthat is written in Perl (because I like Perl), runs from the command line, and stores its files in simple text files (YAML) that I can sync between different machines via rsync or OwnCloud or Dropbox or whatever.

The two main functions are:

whosthat Rich

Returns details about records where the name or email address matches “Rich”

whoworkson openstack

Returns all records where the project or “team” matches “openstack”.

Behind the scenes, there are people records, project records, and team records.

People consist of a name, email address, notes, and what project or team they work on.

A project is, initially, an open source project, since that’s what I care about in my job, but there’s no reason it has to be. It’s any project that they work on.

And a team was, initially, the team or department within my company that someone is on, or the AWS Service they work on. But more generally, it could also be what company they work on, for tracking of people outside if my company.

Data is stored in YAML files. There’s also a addwho and editwho command for doing those things. But these just open the YAML file in your $EDITOR. It’s intentionally very simple. Could get more features over time, but this does what I need it to do.

There are a few things in this that are AWS specific. In particular, it assumes, by default, that email addresses  are and it links to our internal system for additional user info. I’ll try to make these configurable eventually, but right now that’s hard-coded.

If something like this is of interest to you, please do try it out. It’s Apache licensed and free. If you speak Perl, your patches are welcome. If you don’t, your ideas are welcome, but no guarantees that I’ll get anything done, since it’s very much a scratch-my-own-itch project.


Lost passport; Found passport; Headed home.

Short version: Lost my passport; Found it again; Heading home.

This morning I checked out of my hotel in Paya Lebar (Singapore) and went to the airport. I went around 10am, not because my flight was imminent, but because Changi airport is the world’s best airport and I wanted to see more of it.

When I got to the airport, the checkin desks weren’t open yet, so I sat by an outlet and started some writing that I have been putting off. About an hour later, my manager says, on our team chat, that he lost his passport at TSA on the way to Amsterdam, and had to go back and get it.

So … I check my pocket for my passport … and it’s not there.

I went to the info desk to ask about lost and found, and it’s unstaffed. The security guy, who doesn’t understand a lot of English, says, yeah, someone will be there soon.

I went through all of my bags three times, emptying them on the floor, and started to panic. Thinking back, I KNOW that I had it when I left the hotel, and that I put it in my back pocket, rather than in the pocket of my bag where it goes. Ergo, I must have left it in the taxi.

After waiting on hold for more than an hour with the taxi company and opening a lost item report on their website, I start trying to figure out what happens if I don’t find it. That leads to an hour on hold, and then being passed around to various people at the US Embassy. And of course it’s Sunday, so nobody has any actual answers.

And then several hours talking with my company travel folks, and getting passed around to one person after another after another and back to the beginning and FINALLY getting a straight answer that I can get my flight moved to tomorrow, so that I can go to the embassy.

More time talking to the embassy tells me that an emergency passport takes 1-2 days, best case. So back with the travel agency to find a hotel. And back with the taxi company checking on the lost item report.

Anyways, after about 6 hours, I went downstairs looking for some food, and … there’s another info desk, and they have my passport. Apparently I dropped it as I came in the door when I arrived, and it’s been there all day.

So rather than seeing Changi Airport, I spent 6 or 7 hours on the phone, being as stressed almost to the point of tears.

So I’m in the Blossom Lounge now, and heading home soon.

Becoming an ASF Committer

I’ve been mentoring some folks at work who want to become committers in various ASF communities, and wrote the following as part of trying to document that advice.

Note that I’ll likely update this article periodically to reflect edits on my internal version of this doc. Your feedback would be very helpful in that process, as I try to help my colleagues be better upstream citizens.


Nothing in this post should be construed as a guarantee. You can do everything listed here, for years, and still not become a committer. This is because the decision is made by individuals on the project PMC, who do things for their own reasons.

On the contrary, this document discusses how things should work, and sometimes do work, in some Apache Software Foundation (ASF) projects, but might not on the one you’re interested in.

Beneath each of these recommendations is the assumption that you are acting in good faith, for the benefit of the project. Simply attempting to check these boxes to game the system will reflect badly on you, and probably on your employer, too.

Becoming a Committer

It’s important to remember that becoming a committer is not a reward, or a recognition, so much as that it is the project expressing self-interest. That is, people are added as a committer to a project because it benefits the project, not because it’s some kind of pat on the back for the individual in question. As such, every behavior suggested here is about advancing the interests of the project. It is critical that you think, first and foremost, about being a project owner, and working towards the benefit of the project and its users.

These, therefore, are the behaviors that you should exhibit if you want to become a committer, and then a PMC member, on an ASF project. (These are not unique to ASF projects, of course, but process will differ greatly from one project to another, and are largely similar among ASF projects.)

Read the mailing list

ASF projects communicate on the mailing list. If you want to be involved in the community, you must set aside time every week (preferably every day) to keep current on the community discussion.

When first participating in an ASF project, you can (and should) look back several months (or as far as you have time for) to see what has been discussed recently. You can do this at

A growing number of projects also have a presence on Slack, Discord, or somewhere else. Find where that is, and become a regular. A shrinking number of projects have a presence on Libera IRC – mostly the much older projects. This is where you’ll connect with the older members of the projects and learn more of the ancient project lore.

Contribute code (and other things)

If you want to become a committer, you should make significant contributions to the project. The most obvious thing to contribute to a software project is code. Code contributions should be diverse in terms of size and significance. That is, you should work on small issues and large. You should collaborate with others on features and fixes, and you should propose significant changes yourself. You should dig up old tickets, and work towards resolving them.

In particular, you should work on code that is of benefit to all users, rather than focusing solely on features that benefit only yourself, or your employer. As a project owner, you should care about the entire health and sustainability of the project.

Code contributions are not the only type of contribution that counts towards becoming a committer, it’s just the most common. Design, documentation, marketing, event management, and many other ways of contributing to the success of a project are also often considered in making someone a committer. While the term “committer” implies committing code, it can also be interpreted as someone who is committed to the project.

End user support

Answering end user questions has many benefits. It’s the best way to establish expertise in aspects of the software that effect actual users, and, thus, the best way to stay in touch with user concerns. It’s also the way to establish and maintain visibility in the project community, because your name is always visible on the mailing list.

Caution: Do not just jump in and answer every question with visibility as a primary goal. Ensure that your answers are actually useful, and contribute something to the conversation. Simply posting to every conversation, particularly when someone else has already offered a good answer, can be perceived as attempting to game the metrics.


Improving the documentation is one of the most effective things that one can do to improve the user experience. If you notice many people asking similar questions, this is usually an indication that the documentation is weak on that point. Fix it. When the question is asked again, point to the improved documentation, and ask for feedback as to how it could be further improved.

Take criticism of the documentation as a challenge, rather than a personal criticism.

Review PRs and tickets

Dig into unmerged PRs and outstanding tickets. Figure out how to navigate the process to get an old ticket resolved, or a PR merged.

This is an investment in the project in two ways.

The obvious improvement is getting an issue fixed or a PR merges, thus enhancing the project. The less obvious way is that ancient tickets, and unmerged PRs, communicate that the project is not actively maintained, and that user issues are being ignored. This undermines project trust. Thus, addressing these things builds community trust, and increases your personal value to the project.

Be visible

Participate meaningfully in discussions on the developer mailing list. Drive discussions through to action. Advocate for changes that help yourself and your employer, but also for those that improve the project as a whole.

Get to know the important characters on the project, and what their priorities are. Help them achieve those priorities in whatever way you can. Figure out who you can best collaborate with to advance your own personal interests in the project, but also the overall health of the project and community.

Start conversations around topics you’re passionate about, and volunteer to be the one to address them.

Do not, however, just talk to be seen. Nobody is fooled by that.

Vote on releases (non-binding)

Vote on release candidates and releases (non-binding).

Note that a vote should always mean that you’ve actually tested, so testing releases is implied here, too. Indicate what platform(s) you’ve tested on, and what was the nature of the tests that you performed. Testing releases on a variety of platforms and configurations is a very valuable piece of information for projects with limited testing infrastructure.

While these votes don’t “count” towards making a release official, it’s both hugely beneficial for the project, and increases your visibility.

Give talks

Propose talks to conferences about the project, and about how your employer’s customers are using it.

Proposing “Introduction to Apache Woobly” talks has many benefits. It is a great way to get the word out about the project. It’s good for establishing yourself as an expert in the field. It educates users (and potential customers) about operating the software. And it will help you identify what’s actually important about the software, how people use it, and what kinds of questions real users are asking about the software.

ApacheCon is the obvious place to give these talks, but also look for conferences about the general technology space around the project you’re contributing to.

Once you’re a committer …

If and when you achieve your goal of becoming a committer, don’t consider your journey done.

Becoming a PMC member is a continuation of the same path. Continue to do all of the above things, focusing more on the health of the project as a whole, rather than just your personal interests, or those of your employer or manager.

Also, take an active interest in other contributors – both those on your team, and those with other employers. Mentor them in following the same path that you followed. Encourage them. Celebrate them, and mention them to other contributors. This is an investment in the future of the project, so that, some day, when you move on to something else, the project will live on.

Interest across multiple projects, and at the Foundation-wide level, is the start of the path to becoming a Foundation Member, if that is something that interests you.


Finally, a reminder – there’s no way to guarantee promotion to committer or the PMC. However, if you make your goal the improvement of the project, rather than just about personal promotion, and approach these recommendations as a path to project ownership, in good faith, these are your best path towards that goal.


Find your project’s committer and PMC membership lists at

Read mailing list archives at

Find your contribution count to date on Github, for example: (You can drag a date range to narrow it down to recent contributions.)

View past board reports from your project at This is a good way to judge the rate at which a given project adds committers and PMC members. It’s also a way to compare how long other individuals took to attain committer status.