A bit of a throughback (first posted on my blog here), but here’s a 3 minute parody video from 2007 about the impending tech bubble. Fun, but not very accurate.
My friend and former colleague Corey Snipes has been working to get a Bootstrapper’s meetup off the ground in Denver. This is a small group (limited to 12, I believe) of people who are building products (typically software) and self funding. I believe most of the members are in the solopreneur mode (I know Corey is).
I imagine this kind of support group would be fantastic–certainly I had a similar group when I was a consultant in the past, and bouncing ideas off of others in similar situations made the struggle much easier.
I’ve not made this meetup yet because, a) I’m not sure I’m bootstrapping (and you know what, if you aren’t sure you’re bootstrapping, you aren’t bootstrapping!), b) I live in Boulder and Boulderites have a hard time leaving the Boulder Bubble, and c) Wednesdays in general are tough days for me to do anything outside of the house.
If you are a bootstrapper in the Denver area, take a look.
I maintain a link blog about Colorado food and local food in general. I use Tumblr, but I’m only incidentally interested in Tumblr traffic. Tumblr hooks up to Facebook and Twitter, and pushes links there. (I realize that I am missing interaction on Twitter and Facebook by using these networks as broadcast only, but I don’t have time to fully engage, so I thought a limited presence was better than nothing.)
Having maintained this link blog for over two years, I have learned a few things.
- It is easy to start a project like this, but hard to finish. There’s always more to do. I think I’ll stop when it stops being interesting.
- Deciding to do this is a great way to gain a broad understanding of a field while providing some value (via curating). As you find more and more sources of links, videos, articles and audio content, you’ll gain a sense of what is happening. Even if you don’t painstakingly read every article, you’ll still get a sense.
- Speaking of sources, Google alerts is your friend. I get emailed alerts on a variety of searches, and about 25% of the results are worth posting. Facebook and twitter are additional great sources of links.
- An RSS reader can help you if you are really diving in.
- Giving someone notice that you’ve referenced their article via an ‘@’ mention will get you their attention.
- Queuing up posts on Tumblr is a life saver. This lets you stack up posts and portion them out one per day. I typically have between 15 and 30 posts in my queue. This makes timely posts more difficult, but frees me up to forget about the link blog for weeks at a time.
- A link blog like this is a great use of your in between time, especially if you have a smartphone. In five minutes I can scan and post two or three links, where five minutes is barely enough time to think of a regular blog post. The Tumblr app is very good.
- A linkblog is a great resource for other content generation. I have a newsletter about local food as well, and a key section of that is interesting links. Those are almost entirely drawn from the Tumblr.
The linkblog approach is very similar to Twitter, but differs in a few crucial ways:
- the permanence of the link repository (Twitter only stores your last 3200 tweets)
- less interaction, unless you login to each social network
- the ability to post richer media
- you own the content (and can host it on your domain)
- ability to queue up content (without paying)
These attributes make a linkblog a fine complement to Twitter.
There are some problems with this model, however.
- Limited interaction with followers, either on Tumblr, Facebook or Twitter.
- I’ve found that engaging on Twitter and Facebook directly is far more effective if you want content to be viewed or links to be clicked.
- A linkblog like this is not truly building my tribe
So, if you have limited time, want to gain insight into a particular area of interest, and are OK with the drawbacks, create a linkblog.
26 minutes about the benefits of quitting.
I’m working on a project with a number of developers (about 9 checking in code) that is moving rather fast and we’re using git and github. It’s actually really interesting to me, because most of my experience has been with smaller teams (and centralized VCS) where having everything on HEAD is perfectly fine. I was even able to branch using CVS because the chance of merge conflicts with no one else doing development was small.
I remember having lunch with a friend who worked at Rally and we talked about git. He said that they were heavy users, and “once you use it, dude, you’ll never go back”. At the time I thought–how great can git be? I’d been using it for a small project I was coding by myself, and it seemed nice enough, but not revolutionary.
But, now that I’m using it in a fast moving team with a large number of developers touching lots of parts of the system, the branching and merging capabilities of git are starting to shine. The project lead, who has used git before, recommended the Driessen git flow (from 2010), which is more complex than the github flow.
We’ve been using this for a few weeks and I’ve found it be clear, fairly easy to understand and still flexible enough to let development move forward at a breakneck pace. The supporting branches, along with
master (always what is in production) and
develop (always works, what is coming down the pike in terms of features), seem to be a nice compromise between the strictures of traditional, centralized VCS and the free-for-all that is possible with git.
I was browsing Hacker News the other day, and ran across this article, lamenting how difficult it was to support a company with an open source project and that insomuch as one could, consulting generated far more revenue than selling SaaS services like hosting. For the record, I’ve never touched LocomotiveCMS. From a brief glance, it looks nice.
While I feel for them, I think that they have alternatives:
- Sell premium support. Right now, it appears the only way to get premium support is to host with them, and it seems that many clients are more interested in self hosted solutions. Makes sense–if you are a rails developer (the target market for this CMS) you already have a hosting solution. But if premium support was offered separately, they could hire someone (possibly part time) less skilled than Didier, the primary developer, and have them take care of tier 1 support. And still offer a warm fuzzy feeling for harder problems, which would escalate to Didier. Companies like to pay for that kind of service, even if they don’t always use it. This strategy would also decrease the amount of revenue needed to hire someone to help Didier (customer server folks are less expensive than developers).
- Sell an ebook (or a couple). These are far easier to create and sell than a SaaS product. (I use leanpub!) It could be an ‘authoritative guide to LocomotiveCMS’ or just focus on one part. Since Didier knows which questions he often answers for people who have paid him money, he’s probably got a very good idea of where the pain points are.
- Someone suggested this in the comments, but a marketplace for plugins to LocomotiveCMS seems like a natural way to go. Again, i don’t know that community, and marketplaces for CMSes can be hard to kick start, but this is worth evaluating.
- I’m sure there are others. Here’s an exhaustive list of business models, courtesy of the AVC community, so if I were them, I’d review and see what was a fit.
In my comment on the HN post, I talk about how products often face a “round peg in an elliptical hole” problem. I meant that products often solve 80% of the problem for 80% of the users. They also require users to change their processes (more crystallization). Typically there’s just enough offset that people feel cognitive drag. (Of course, the same thing usually happens with custom solutions, you just don’t know that until you are done. Doh!)
Especially in crowded markets, like CMSes, it is far far easier to sell enough hours to make a living customizing a solution than it is to sell enough products to make a living. Brennan Dunn covers this ground well. Every consulting company I’ve ever seen or been a part of, and every consultant I’ve ever known (except the ones who were contracting for one client and really were employees with more flexibility), dreams of transitioning from non scalable consulting by the hour to scalable product sales. One friend even had a name for it–the “von MacIntyre machine”, which would make money while he slept.
But it’s hard.
27 minutes on profit models from Derek Sivers.
This is a picture of my bike lock.
There are many bike locks, but this one is mine.
I always put my bike lock on as seen. My helmet with the lock running through the styrofoam (because, on the off chance someone wants to steal a bike helmet, they’d have to destroy mine to get it). The lock running through both the front wheel and the frame, so that the wheel can’t be stolen–nothing sadder than a locked bike with a missing front wheel–quick release works well. The actual lock (where I put my key) sheltered from the elements, both because the helmet protects it and because it is facing down.
After commuting on my bicycle hundreds of times and leaving it overnight a handful of times, I’ve determined this is the optimal lock procedure. Not that I’m not open to new ideas–a few years ago I took my helmet with me, but then I saw someone lock their helmet like this and thought “what a wonderful idea!”. But once I arrived at what seemed an optimal solution, I just put it on autopilot. This frees up my mind to pursue other things. It also means I have not analyzed the way I lock my bike in a deep way until I started to write this blog post, and once this is done, I won’t think about it for the foreseeable future. The bike lock setup is settled. I’m always looking for other aspects of my life to settle, while still being open to possible improvements (if you lock your bike differently, let me know!).
There’s a similar tension in software development. On the one hand, I want to be open to new ideas, frameworks, concepts and solutions. On the other hand, it can be easy to go after the newest ‘shiny thing’ every time, spin my wheels, and not accomplish what I need to accomplish. One way to the latter issue is to make some decisions in my work life. This can range from the trivial–I have used the same aliases file for over a decade–to foundational–I only work on the unix stack.
Sometimes settling constraints are imposed by the project–it’s a RoR app that needs to be upgraded, or there are already extensive java libraries that this application will use (and that can mean that you won’t get the gig or the job). Time also can be a limiting factor–deadlines have a wonderful way of focusing you to work on the problem at hand, rather than running off to explore that new library. It’s also important to realize that you can settle the trivial–what shell you work in, what OS you use, how you lock your bike–which lets you focus on the important–the app you are writing, the restaurant you biked to.
(Of course, what is trivial for some projects may be foundational for others.)
When you are working on a side project, sometimes settling on a technology can be hard–it is more exciting to explore that new XYZ rather than grind away at a bug or a new feature in an app that I’ve already written. But, in the end, extending and shipping an existing app almost always is more rewarding.
We software developers live on a knife edge–on one side is irrelevance, though it may be profitable (COBOL), on the other side is flitting from new technology to new technology (whether it is Erlang, Haskell, NodeJS or something new) but never mastering them.
One of the companies I’ve met with wanted a bit more context around work I’ve done, so I wrote up some of the ‘greatest hits’ of tech work I’ve done in the past couple of years. It was so much fun, I thought I’d post it here so I’ll remember it in a few years. This is just some of the tech highlights, and doesn’t include other things I’ve learned (managing folks, softer development skills, etc).
- Colorado CSAs.info is a directory of Colorado CSAs. This site received 28k visits in 2013, and 26k visits so far in 2014. You can view the source. The source has some quick and dirty aspects, since this is a side project.
- Home valuation processing software output. This was a fairly simple algorithm (linear regression among geographic datasets) but involved some interesting processing because of the number of records involved (1M+) and data sources. The graph shown here was generated by code I wrote. The content is human generated, however. I worked directly with the CEO on requirements for this v1 project.
- I wrote an ebook about an aspect of mobile app development last year:
- I built large chunks of COhomefinder (which has not been touched in 2 years, because the business has decided to move forward with an outsourced home search solution). The last code I touched was replacing google maps with mapquest. I also built a widget for featured home listings that could be dropped into other websites. You can see both on the search results page.
- I wrote a hybrid mobile app that displays news and info about neighborhoods in the front range. This never really got much traction, unfortunately.
It’s fun to look back.
This 13 minute OSCON keynote from Tim O’Reilly talks about developer autonomy, healthcare.gov and open source.