Digging In

Andy Weissman of USV posted about the unbundling of all things web--apps become APIs, and ... " that education is being unbundled into its component parts: content, teachers, credentials, community, physical campus, mentors, hiring and network." I weighed in...  Hasn't Google become more like AOL in some senses? Plus, hangouts, docs, email, etc.   It seems inevitable for the niche gorilla to continue to add new products and more niches, becoming an aggregator like the one they might have initially displaced.   Interesting that Twitter has not taken that approach. Facebook has. LinkedIn has, though perhaps more naturally and narrower than Google. Stack has (hi joel), in very natural and sensible ways. And Andy asked... that's interesting - is the tendency of the unbundler to always try to re-bundle? ...so I thought about it some more...  The tendency is toward revenue growth, which leads to adding products or features that drive revenue toward t

I've picked up coding again after quite a few weeks off. I've been noodling on a version of Jawaya, completely stripped down, and just simplifying everything. But from the time I rebuilt it using Node.js (which was what, December?), I haven't popped it onto a public server. Until today. And today was when I remembered the 20 things or so you need to know to get an app up and running--versions, dependencies, different syntax for 5 different environments and services...but the thing is, I actually did remember most of it. What's interesting is that the dependencies have changed in several (or more) of the modules, and even node itself in all likelihood. So after getting git up and running on my linux instance over on Rackspace (don't forget to add a new RSA token from the instance to GitHub or you'll get errors), and pushing to GitHub and pulling, I fired it up $ node app.js Fail. But well! It failed perfectly. Node's got line-level error message

I've been fascinated by discussions of networks of networks for quite a long time, likely since 2003 whenI started paying attention to them. Fred's post today sparked a memory of one discussion in 2004. Here are some links I just came across as I went back to read some of the threads. http://www.bubblegeneration.com/2005/09/web-2.cfm http://avc.blogs.com/a_vc/2005/09/reeds_law.html http://www.avc.com/a_vc/2005/10/rethinking_reed.html http://web.archive.org/web/20040803090232/http://avc.blogs.com/a_vc/2004/07/measuring_media.html http://web.archive.org/web/20040806011746/http://www.pacificavc.com/blog/2004/07/08.html#a651 http://web.archive.org/web/20040806122844/http://www.corante.com/many/archives/2004/07/12/cost_per_influence.php http://web.archive.org/web/20040803003823/http://www.buzzmachine.com/archives/2004_07_10.html#007472 There are links in all of these posts to other related posts--definitely check them out and the comments. Reading all of these wil

I really like oHours.org. Nate started the company a while back, and seems to be focused on his other startup, but to me this is the basis for a truly great experts network that gives them the ability to monetize their excess capacity. In other words, to be able to charge people for consulting hours. I asked him a year ago when he was going to add in payments, and he pretty much said he wasn't thinking about it. The payment system still isn't in there, but it's easy enough to send someone to paypal (ugh) or some other interface to charge for the hours. But there should be an option to require prepayment, so your time as an expert isn't wasted. Today I have slots available starting at 1:30. They are pretty brief at 20 minutes, and free. You'll notice the little oHours widget at the top of the right column, just about another cool widget for searching the site and its comments. I'll blog about Gawk.it after I play with it a bit more.

Back in Ye Olden Days, software had to be copied onto these things called floppy disks, and later, onto CDs. That was before the internet solved all the world's problems, but even then CDs persisted for a long, long time. You had to make copies of the software, and if you were fancy, you'd put it in a printed box (maybe even with your own  printing). Then you'd ship it to the customer. That's right, you'd hand it over to Captain Postal and he'd throw it into the belly of Ye Old Ship, hoist the mainsails, and he sailed upon the lowland seas. Aye. We used to say back in the Olden Days, " it's not software unless it ships ". Now, I haven't shipped software that I've been working on since December. Why? Well, because I keep toying with it. And because I don't think it's good enough to copy onto a stack of floppies three stories high. Or even a CD. It's just not ready. And frankly, it's a labor of love, and I'

Someone at AVC turned us on to a blog... and this post is really worth reading.

I've been thinking a lot over the past few months about the Lancaster tech scene and the potential for a real ecosystem as we evolve Startup Lancaster and some of our founders land investment, build businesses, and/or exit. Brad Feld has really influenced my thinking about this over the years, partly through his work with Tech Stars. So I sent Brad a link to an old post on tech ecosystems and how to create one in our region. Here's an excerpt from that post: A self-sustaining, regenerative ecosystem has these indicators: new startups formed by former employees of earlier startups new startups staffed by former employees of other startups new startups funded by investors and/or employees of earlier startups with part of the proceeds from earlier successes through at least two cycles He posted about it on Startup Revolution --thanks Brad! So what's that SR? It's part of his effort to shed light on startup communities and startup life, topics he covers in h

I am alternately highly disciplined and highly undisciplined. Sometimes either state can continue for weeks. Today I'm cranking on a bunch of stuff. But I'm also participating in commenting on blog posts and twitter. Part of that's work, but part isn't. The disciplined approach would be to avoid the not quite work stuff. But damn it's good stuff--hard to pass up :) Back to it--reading this post reminds me that the post itself has taken me off task. Dig in :)

The last post wasn't particularly brilliant or crisp. I've been thinking a lot about platforms, silos, and web-based atomic units--individual, unique objects that can be accessed by their own URLs. These aren't new concepts, but the topic is on my mind. There's a limit to the usefulness of atomic units after a certain size; while you could break down this page and change it to an aggregated page of individual letters, it would not be particularly interesting or useful. A blog post is more than just a collection of letters; the words give it meaning, and not so much the individual words, but phrases and sentences. So perhaps whatever's quotable is worth turning into it's own unit with a unique URL, indexable, shareable, portable. An image is an obvious object; shareable, reference-able with its own url. Collections of images are as well. Collections of images and phrases pass muster. What these objects give us is remixable content--ah, now I remember

First we connected terminals to mainframes in a hub and spoke model. Then we connected the spokes. But the connectivity was highly limited--sending files, accessing an application, maybe accessing a central database in the old client-server model. Then came the web and we went back to the hub and spoke model, but on a different scale and with different user interfaces. Then came peer to peer software, where you could connect directly to me without a server in between. SILOS But in each of these, there were technologies, data, applications, and data in silos: each limited to activity within its own container, with perhaps limited connectivity. Then we came to the current but unfinished phase of converting from closed silos to interconnected ones on a per application basis, largely through APIs, and now evolving to interconnectedness through sets of open APIs that open the door to discrete functionality within the apps. Much more data is available and accessible. Acce

Founders, don't do this . Employees, don't let founders to that to you. And there's recourse--few judges would allow this sort of thing to stand.  Check out the first comment: "My husband was an OnLive employee as well. One of those employees who puts in a full day in the office then comes home and puts in another 3-4 hours from home. We are currently pregnant with our second child and I have numerous serious health issues complicating pregnancy even further. My husband has been staying up until 1:00am night after night lately working for OnLive, only to come to work this morning to find out we have no job effective immediately, our stock is now worth nothing, there will be no severance, and if we don't find a solution for health insurance before the benefits lapse on the 1st of the month then my pregnancy will become a preexisting condition and we will be on the hook for all of the out of pocket costs ourselves. We went through job loss when the economy firs

Someone commented over at Fred's that I sound bitter a lot. I'm not at all. I'm a pretty happy guy these days, and really love building businesses. But the most interesting stories--or rather then ones I remember easily--are the nasty ones with some sort of injustice (perceived or real). For me it's the "optimism of dissent"; the negative implies the desire for a better way, but the framing doesn't point to that vision. I forget to celebrate the wins sometimes. When I ended my music career (but not the music), I started a tech career. That was 1994. The first year as building PCs; I'd spend 18 hours a day working on things, learning as much as I could, fixing stuff, breaking stuff and then fixing it, serving customers, and gaming a bit. Wins all around. Not muh money, but a lot to celebrate. When I ended the PC business it became a services business. Learned about larger companies, seeing solutions for problems, learning the value of the relati

One of the great things about gardening is that it's outdoors and away from technology, except what you bring with you. Typically I have my phone with me, though sometimes I leave it in the car, usually unintentionally. I'll take pictures, look up stuff about watering plants or bug species, and maybe text or respond to an email. But that's about it. But my tomatoes are splitting from inconsistent watering and that really nasty dry spell.  And there are plotholders who don't know the rules. Some who haven't paid their annual fees yet. And supporters who appreciate occasional updates. As usual I start thinking about possible solutions to these minor problems. Water--let's drill a well and build and irrigation system, simply because we can if we raise the cash. But let's automate it, and make it controllable over the web if we want to intervene. And, as usual, I'm not the first to think of these things. Garduino is an Arduino project--a combi

You have a sense. So you make some calls. Read some articles. Talk through it with friends. Design some features. Build it out. And then stop. Someone else dissed it. Doesn't get it. Wouldn't use it. And you listen. Why? You were compelled to invest in your desire to solve a problem, or improve something, or make something happen. You did the research, talked to others who share the problem, and designed something to scratch the itch. And then some guy--perhaps credible, perhaps not--says he doesn't get it and it blows you out of the water. You're laying there, dazed, dripping wet on the mud at the edge of the river--hell, let's call it the river of startup goodness --and sit steaming in your own misery because...because...what was it? Someone didn't dig what you're doing? It's easy to criticize. Just ask me for some criticism--I'll happily give you some; hell I'll criticize you for asking in the first place. Easy. It's hard

I have a few weeks before I need to start working for pay again, so I'm picking up the Jawaya project again. A lot has changed since I started rebuilding it in Node.js over the winter.  I put it down completely when I signed on to help Tereza at HonestlyNow. HN is built on  Symfony, which is a PHP MVC framework. When I got there it was a website; when I left it was a platform of APIs that any developer could build around without the Symfony dependency.  I like taking that approach--core set of APIs that support a variety of clients: mobile, widgets, plugins, bookmarklets, and the site itself. Separating the presentation layer from the core business logic makes code maintenance a lot easier, too.  So with the search project, I'm returning to that API-based approach and separating the front end from the back end entirely, simply returning data or system messages.  Node has advanced a bit. I'm thinking about hammering out something like Twitter, but for develope