Really, I usually preempt people by calling myself a snob, because I think it’s silly to be anything else.  Why own something you don’t care about?  You’ve got to wear a given amount of clothing, use a computer a given amount of time, own a given amount of dishes and furniture and stuff — why not surround yourself with things you actually like and prefer, rather than just settling for whatever crap wanders along?

Of course, this isn’t entirely feasible — I have plenty of bookshelves I don’t really care for, but my spending priorities don’t currently including spending a bunch of money on replacements, for example.  But certainly, all things being equal, care about what you buy and use.  Be a snob.

I was considering blogging this anyway, because it gives me a reason for writing a bit of a gadget blog — not specifically gadget, but review-oriented.  Obviously I’m not going to switch to all reviews all the time, but my research is thorough enough and (according to friends) my reviews are humourous enough that I figure it’s worth writing some of these things down.  Given I was already thinking of this, I was happy to see (via BoingBoing) that Bruce Sterling agrees:

It's not  bad to own fine things that you like.  What you need are things that
you GENUINELY like.  Things that you cherish, that enhance your existence in the
world.  The rest is dross.

Do not "economize."  Please.  That is not the point.  The economy is clearly
insane.  Even its champions are terrified by it now.  It's melting the North
Pole.  So "economization" is not your friend.  Cheapness can be value-less.
Voluntary simplicity is, furthermore, boring.  Less can become too much work.

The items that you use incessantly, the items you employ every day, the normal,
boring goods that don't seem luxurious or romantic: these are the critical ones.
 They are truly central.  The everyday object is the monarch of all objects.
It's in your time most, it's in your space most. It is "where it is at," and it
is "what is going on."

I completely agree.

So, you may see a few more reviews here than you might expect from a sysadmin blog, but hopefully you’ll find them useful and entertaining; and if not, you can always just call me a sock snob at the next conference.

One thing some people apparently don’t realize is that Puppet couldn’t have been created without Reductive Labs — there’s no way I would have had the time or motivation to create Puppet without a company devoted to funding its development.  All of the money that Reductive Labs makes goes back into funding Puppet, mostly in the form of development, marketing, and community management (although less of the latter, recently).  Almost all of the money I spend on marketing is in the form of conference speaking, so don’t think I’m spending big coin on TV spots or anything, but these conferences have been *huge* sources of community growth.

Strangely, I’ve heard complaints that I’m focusing too much on the company and not enough on the project, and as a result the product is suffering.  I find this strange because the project doesn’t pay my bills, feed my children, or buy my beer, the company does, and without those things, the project itself couldn’t exist.  If, instead, I had taken some corporate sysadmin job, I’d have been spending maybe 5-10 hours a week on Puppet, instead of between 10 and 60 hours a week like I’ve been doing for the last three and a half years.  This, I think, is the thing that people tend to forget about open source — yes, you can make money doing open source, but in doing so you almost always put yourself in conflict between making money and writing code.

The key is that Reductive Labs doesn’t make money when I write Puppet code, it makes money by helping people with existing code; yet, my business model is based on plowing that money into writing code, on the assumption that the code will make the product better, increasing the market, and hopefully allowing both project and company to grow.

This gets especially complicated when my own goals show up.  I’ve always seen Puppet as the first step toward building a significantly enhanced toolchain for system administration, and it was always my goal to use Puppet as a launchpad to having Reductive Labs fund other great projects.  (This phrasing is important — I need to make money to do development full time, so Reductive Labs (currently) needs to make money to fund that development.)  This is why I’ve always resisted billing us as “the Puppet company” — I don’t want to be pigeonholed in the event we have other successes, which I hope we will.

These longer-term goals are also why I’ve avoided joining other companies and just doing part-time development on Puppet for them.  Leaving aside that none of them would have considered hiring me until I’d already had significant success with Puppet (which puts us in a strange Catch-22, where they’d only offer to hire me once I’d shown I didn’t need their help), no one has ever expressed an interest in hiring me to build a product group, which is what I’m trying to do here.

Going back to finding that balance, one of the things I’ve foolishly allowed myself to do in the last year is get too caught up in fixing bugs, rather than adding functionality or doing interesting refactoring.  It’s amazing how disheartening and depressing it is to spend all of your days fixing bugs in code you wrote, all the while struggling to make enough money to pay people to help you fix those bugs.  Having more people at the company has helped bring focus to my efforts and those of the company as a whole, and having many more people involved in the project has helped bring focus to the needs of the project.

I think that’s about all I have to say on the subject right now — a presentation of the problem, a statement of the status quo, and a wandering finish.  Now that I’ve introduced the topic, though, I hope to be able to post more lucidly and usefully about it in the future.