For the last couple of weeks, I’ve been posting podcasts to the Sourceforge blog. (You can subscribe to our podcast HERE or in the iTunes store.)

Almost everything that I do in the process relies on Open Source software developed at Sourceforge, so I wanted to take a moment to thank those projects.

Recording and editing: Audacity

I record with a Blue Snowball with a shock mount, which is a USB mic that I can plug directly into my laptop. If you’re looking for a mic to get started with, I recommend this one. It’s easy to use, and gives excellent sound quality.

Usually I record the calls using Skype and Call Recorder. This is the one piece of non-free software that I use in the process. It’s free, in the sense that I didn’t pay for it, but it is closed-source. While there are alternatives, it’s not always reasonable to expect the person that I’m calling to install and configure new software just so that they can talk with me for ten minutes. Pragmatism has its place.

The editing is all done in Audacity. I’ve long been a big fan of Audacity. I have other recording programs, including some commercial ones, but haven’t yet found anything that beats Audacity for either functionality or ease of use. Some of the commercial apps do more, but so far it hasn’t been anything that I needed to do. Also, their documentation is simply wonderful, including detailed explanations of even simple features. Additionally, there are numerous community-created howto videos showing how to do various tasks.

Until recently, I was using GarageBand for one particular part of the podcast creation process involving merging several different tracks seamlessly, and found a video showing me how to do this in Audacity.

So, I use Audacity to clip out the smalltalk, the um’s and ah’s, and try to edit the conversation down to the essentials, so that you’re not forced to listen to a lot of extras. I know that I have trouble finding the time to listen to the few podcasts I follow, and if it’s much more than 10 minutes, I tend to move on. I try to respect your time in the same way.

Audacity exports in MP3 and Ogg Vorbis formats, which many commercial tools don’t do.

Editing ID3 tags: kid3

When necessary, I use Kid3 to update the ID3 tags on the MP3 and Ogg files. This is a final sanity check to make sure that the files we push out all have consistent tagging, so that they’ll show up in the same place in your various audio programs. Kid3 is one of those delightful pieces of software that just works. No unnecessary extras. It’s small and fast and efficient, and gets the job done.

Uploading: Filezilla

Yes, I could just use command-line scp, and often I do. But Filezilla integrates well into my workflow, so I use it sometimes to copy these resulting audio files up to the staging area so that the folks I’ve been interviewing can review the recording before I push it out to the blog. Filezilla is another piece of software that just works. It is intuitive and doesn’t require a great deal of setup or explanation in order to get it to do what you need.

That’s all

Sure, it’s not a big toolchain for this task. And I continue to look for ways that I can replace non-free components of it with Open Source software. I have, for example, come across a few references to projects that were presumably Open Source implementations of the Skype protocol. Unfortunately, they all seem to be abandoned projects, which was sad. However, as I said above, pragmatism has its place, and one has to get the job done.

I’ve always loved advent calendars. They help kids deal with the seemingly endless stretch to Christmas. And I love seeing what’s behind the next door every morning.

This year, I made one. In part, it was an excuse to buy power tools, but also I had a lot of fun making it.

I used a jig saw to cut out the pieces, starting each piece by drilling a hole just large enough to insert my smallest jig saw blade, and also drilling a larger hole directly in the middle, exactly the same size as the dowel rod. You can see that in some of the pictures. After cutting out the piece, I sanded off the end of the dowel rod, cut a piece between one and two inches long, and inserted it into the center hole with some wood glue. Each piece was numbered (1 to 25) as I took them out.

When I was done cutting out all the pieces, I laid the board over the backboard, and traced out each hole on the backboard in pencil, and put the piece number on there too. Then I stained the front board and painted each piece and wrote the number on it in silver marker once it dried.

I then painted something in each space on the backboard, and erased the pencil marks, and wrote the number on there, too. I used a spray shellac to seal all of this so that it will last for a few years.

Finally, I used wood glue to put the front and back boards together, clamping them for several hours.

See the finished results on flickr.

(This is long. Summary: OmniTI is the best technology company around, and they do a lot of things right.)

Today is my last day at OmniTI, after just over two years. Yesterday I had my exit interview, and I want to record some of my thoughts from that before they get away. Andi asked me a few questions, and I talked a lot.

OmniTI has been a great place to work. I have (almost) no complaints. It’s a fantastic company, with fantastic coworkers.

Several things stand out.

First – OmniTI has a way of telling the customer the truth without being discourteous. The customer is always right, except when they’re not. Many technology people have a way of telling the customer they’re wrong in an arrogant or condescending way. I’ve never seen that at OmniTI.

Sometimes customers come with a problem they want solved. Other times they come with a solution they want implemented. In this latter case, you have the choice of blindly doing what they ask, or helping them evaluate the options, and possibly steering them towards better solutions. Doing this without an “I know everything better than you” attitude is a skill that takes practice, and doesn’t generally come naturally to those of us who are computer guys. I’ve watched Theo and Clinton do this over the last two years, and have been continually impressed with their professionalism.

Second, I’ve been impressed with the intentional, dedicated way which people at OmniTI strive to better themselves – to learn, improve, and expand their skill set. I have been particularly impressed with my manager, Clinton, and his effort to become a better manager. Managing geeks isn’t easy. We are an unmanageable bunch. We are always right, and don’t like to be told otherwise.

I was put on Clinton’s team when he was a new manager, and watched him work really hard at becoming a better manager. He asked us how he was doing, and he took our comments seriously, and acted on them. He admitted when he’d realized he’d done something wrong, and he celebrated when we did things right, while still being very forthright with us when we did things wrong. He knows when to ask our opinion about decisions, and when to stop the discussion and make the decision.

And he demands excellence — which I’ll talk about more in my third point in a moment.

On the whole, Clinton has turned into one of the better managers I’ve ever had.

My third point is about demanding excellence. I have worked a lot of code monkey jobs. You get vague requirements, and you slam out some code that does what you interpret them to mean, and you move on, hoping nobody ever looks at the code.

Not at OmniTI.

At OmniTI, software is a craft. It’s really the first time that I’ve taken the term Software Engineering seriously, or, rather, seen it done really seriously. I’ve had glimpses of it before, mostly with people like Schwern, and others in the Perl community in the late 90s and early 00’s. But at OmniTI, I had excellence demanded of me as never before. It has caused me to look at software development in a new way, and look back a little sheepishly at some of my earlier efforts.

Fourth, OmniTI has a philosophy of “everyone knows everything.” It’s not sufficient to be a Perl coder. You must also know JavaScript and CSS and HTML and a little Python, PHP, C, and Java, because that gives you a whole-picture view that informs your Perl code. That’s not to say that we don’t have experts. We do. We have some of the most amazing UI experts I’ve ever worked with. But they can read Perl code and debug PHP and can homebrew as well.

I have learned more Javascript, CSS, and Python in the last two years than in the previous 15.

And it’s more than just crosstraining so that the project can keep on if someone leaves. OmniTI really cares about the professional development of its employees. I’ve only worked one other place (Hi, Paul!) where I felt that the professional development of employees was this important.

One final thing – Openness. Several times, Andi asked “How could OmniTI do X better”, and each time, I had to answer, well, I had some suggestions to that end, and I talked with someone about them, and things got better. Every time.

I had some complaints with Clinton when I started working for him, as my Beloved will affirm. I talked with him. Things got better. This is not to say that I was right and he was wrong. Rather, we had several good conversations in which we understood one another better. This happened in manager/employee issues as well as technical issues. None of them were big deals, but I can see that other managers might have made them big deals by refusing to be open about things, or insisting that they were right in all things.

I’ve never had any patience with finding out things in an annual review. If you have a complaint about me, I want to hear about it when it happens, not months later. People at OmniTI consistently told me as soon as a problem came to light so that it could be addressed before it became a big deal. There should never be a surprise in an annual review.

So, there’s the gist of my exit interview. I expect I said other wise and insightful things. You could ask Andi to fill you in.

So, with all of these glowing things to say about OmniTI, why am I leaving? Well, I’ve been working in Open Source since about 1998. It’s my passion. My day job has always been something that I did to pay for the parts of my life that matter, but Open Source has always been relegated to the spare change of my time, when I’m tired and have other things to think about as well. If I don’t close those last 29 open documentation bugs on the Apache http server, nobody will think less of me. But it’s my passion.

Several weeks ago, Steve Jobs died. I’ve never been the Apple fanboy, nor have I been a resident of the Reality Distortion Field. But on the day Steve died, I watched his Stanford commencement address, and one thing struck me. Find your passion. If you haven’t found it yet, keep looking. Don’t settle for a job that you’re not passionate about.

When the position at Sourceforge opened up, it was immediately obvious to me that this was an opportunity that I couldn’t let slip by, even if it meant taking a huge risk. So here we are.

(If you haven’t watched that commencement address, you really should. It’s short, and it’s worth your time.)

Two years ago I had the opportunity to become a part of OmniTI, where I have learned more than I imagined possible. I learned about how serious software engineering is done. I learned about scalability, and redundancy. I learned how to deploy web apps in environments where there’s no tolerance for failure, as well as how to deal gracefully with that failure when it happens.

I’ve had the chance to work with some great people, and on some amazingly cool and interesting projects.

Now, I have the opportunity to learn something new.

At the beginning of November, I will be joining the team at SourceForge, where I will be the (tentatively titled) Community Growth Hacker. I’ll be working with tens of thousands of Open Source communities, spanning many technologies, licenses, and nations, and helping them be successful.

I wrote yesterday about the many definitions of success. I expect that conversation to continue for years to come.

In my office, I have the center panel of this Dilbert comic strip. I’ve long since forgotten the remainder of the strip. That, in combination with listening to a speech by Steve Jobs late last week, gave me the little extra nudge I needed to take this risk. It’s a big change in what I’m doing 9-to-5, but it’s in line with where my passions have been for the last 15 years.

I have a lot to learn, and I welcome this exciting opportunity to learn from thousands of talented people, and hope to share with them some of my experience from the last decade in Open Source. I think I might have a few things to teach, but I know I have much still to learn.

I have, over the last 15 years, been involved, to one degree or another, with several successful Open Source projects you’ve heard of – Perl, PHP, Apache HTTP Server. I’ve also been involved in several projects you haven’t heard of, but not all of them because they weren’t successful. Habari, Reefknot, and IAMB are three of these.

Of course, I’ve also been involved in several Open Source projects that you’ll never hear of, because they were a big flop.

There’s just so many ways to define “success”, when it comes to an Open Source software project. I suppose there is in any category. Success might mean that it achieves its goals. Or it might mean that it has a large community of users, or of developers. It might mean that it active in terms of commits, features, or bug reports. In some cases, it might mean that it is financially profitable to some or all of the people involved, either directly (support, sales, customization) or because the participants end up getting jobs as a result of their participation.

The Reefknot project, abandoned many years ago, was successful, in the sense that it did some interesting work, and then knew when to quit. It spawned another project – The Perl DateTime project, which is one of the most important places where date, time, and calendaring modules are developed in the Perl world.

Habari is a successful project in that it runs this website, which does everything I want it to. And also because it introduced me to various people I consider friends. And because it was a great lab for learning about how new Open Source communities work. And, of course, because it is still an active development community who are doing interesting things in the blogging space.

I mention all of this because I’ve been pondering what it means to help an Open Source community to be successful. What it means will necessarily vary depending on the goals of the community in question, and the personalities involved.