Read at Joe’s

If you’re a golfer like me, or familiar at all with the sport, you’ve probably heard of Natalie Gulbis. She’s the leggy, blond golf pro who not only looks good, but has the game to have won on the LPGA tour, which is no mean feat. Most professional golfers struggle for years and never come close to winning a tournament. She also was a standout in the Solheim Cup in 2005, helping the US to a win in the team matches with Europe.

This week, I discovered that she’s now on Twitter as @Natalie_Gulbis. She is, as far as I know, the first top-tier professional golfer of any tour to be on Twitter. Yay, Natalie!! That she would be the first is totally in keeping with her accessible, outgoing and friendly personality.

At this writing (Dec 29. 2008), she only follows 4 people and is followed by only 234. But I give her and her agent major props for realizing Twitter is a good place to be. Like anyone new to Twitter, it may take a little time to discover how it works. I’m hoping that unlike many celebrities, she will really get in and talk with people.

Of course, someone like Natalie Gulbis needs to be careful with the public. I can imagine she has more than her share of unwanted attention. But at least on Twitter, you don’t have to hear from anyone you don’t want to. And there is so much to be gained from engaging with people and making new acquaintances and friends, not to mention drawing non-golfers into the sport.

If I may make a suggestion, it will be the same as to anyone new to Twitter. Listen first, follow first. If you hear something interesting chime in. Make an observation, a joke, ask a question or state your opinion. Most importantly, be a person, not an inaccessible celebrity. Twitter is a conversational medium, a means for introducing and connecting people, not just another broadcast channel. Let that sunny personality of yours show through. You’ll find we’re a friendly lot and you’re more than welcome to join the conversation.

Tags: golf, Natalie Gulbis, twitter

If there are any WordPress plugin coders reading this, I need your help.

I’m writing a WordPress plugin to add Open Microblogging Support to a blog. In order to do this, I’d like the plugin to add a special OpenMicroblogging Page to the blog. This special Page is supported by a custom Page Template. Page Templates are normally added to the theme directory. And therein lies my lack of understanding. How do I get a plug-in to add a page template? Copy the php file in the installer code? Seems a little dodgy, but maybe?….

Tags: development, distributed microblogging, open microblogging, page template, plugin, themes, wordpress

@Pamelump (Pamela Leigh Seiple) just tagged me with this photo meme. I have to go to the 6th photo on my 6th Flickr page and write a blog post about it.

Ok, so the aforementioned photo (6,6) is this one:

This photo is from a set I made about a year ago, on a very cold day in Worcester, Massachusetts. I had lunch with two diner fanatics, Scott Monty and CC Chapman at an old haunt of mine from my college days, The Boulevard Diner. You can read the story on the set page, and there’s a video to go with it, too.

But probably my most lasting memory from that day is not that photo, but this one:

I blogged about it here: Accidently Memorable.

After spending quite a few hours on yesterdays post, OAuth and OMB post-sharing, it occurred to me with the first cup of coffee this morning that I had missed one important user interface twist in the use of OAuth that actually makes it quite necessary.

It depends on how the UI for subscribing works. If, as with a feed reader, the subscriber enters the URL of the person they wish to follow, authorization is unnecessary. The user has made their intention known to their own account, and can simply request the posting server to send updates.

However, if the the subscriber subscribes by visting the site of the poster, and the poster allows unrestricted access, then there must be a mechanism for the subscriber to tell his own site that he wishes to subscribe to the poster’s updates. This is where OAuth comes in, and it is indeed a well-matched use-case for OAuth’s functionality.

Apologies to Evan at Identi.ca.

Tags: authentication, authorization, development, microblogging, OAuth, OpenMicroblogging

This post has been superseded. I missed an important web UI issue which lead me to an incorrect conclusion.

Square peg, round hole

The OpenMicroBlogging Specification (OMB) contains a section on the use of OAuth to authorize a remote service to post to a user’s local service. After spending some time studying the OAuth and OMB specs, it seems to me that this is not the use-case that OAuth was designed to solve. A square peg in a round hole, you might say.

This is not to say that authorization is not needed for allowing post-sharing, only that OAuth was designed to address a different situation. The simplest way I can characterize the difference is that OAuth applies to a “one human, two services” problem and microblogging post-sharing is a “two humans, two services” problem.

OAuth’s intended use-case

So, what problem does OAuth fit? OAuth is intended to solve the problem of a person who has content or resources on Service A and wants to allow his/her account on Service B to access those A resources - without giving Service B his/her login credentials for Service A. Note well that it is the same person having accounts on both A and B. This is the “one-human, two services” aspect.

So, for example, let’s say you have an account on Twitter and want to use one of the many alternate Twitter clients out there, e.g., Twalala. You have an account with Twalala and would like to be able to access your account on Twitter without having to fork over your Twitter password. Using OAuth, you would be able to, in essense, tell Twitter to allow your account on Twalala.com to perform various read or post functions with your Twitter data. By the way, Twitter has been promising for months to implement OAuth for exactly this purpose. Again, note that there is only one person with accounts on both systems.

OMB post-sharing use-case

Now, let’s look at the case of two people on two different OMB-compliant sites who want to share their posts, either unilaterally or bilaterally. Let’s say I have an account “joecascio” on site subscriber.com, and my friend has an account “johnsmith” on poster.com and I would like to follow John’s updates. Note that it should not be necessary for either me to have an account on poster.com nor John to have an account on subscriber.com in order for me to “see” his updates. Indeed, this is the whole point of federated microblogging; that we can share posts without having to have accounts on many different services. So simply from this fact alone, OMB post-sharing is clearly not the “one person, two accounts” use-case. If post-sharing worked by requiring John to have an account on subscriber.com (the second of the “two services”) and then authorizing subscriber.com to let his Poster.com account post there, then yes, that would be the OAuth use-case. But it isn’t!!

So, what is an appropriate protocol or process for enabling and controlling post-sharing? I don’t have the complete answer, and I’m hoping that this post will cause some of the many smart people out there to suggest some. But I can state at least some of the problem characteristics, requirements or constraints.

Post-sharing is subscribing, not cross-posting

When I register my interest in someone else’s microblog posts, when I “follow” them, it means I want to subscribe to their post stream, just like I would subscribe to their traditional blog. If it were a traditional blog, I would do this by polling their RSS feed which is a simple GET by the subscriber. It does not involve the poster initiating a transaction to “send” me anything. But since microblogging implies a much lower latency, which would be inefficient to perform by polling, OMB introduces an optimization. The service on which the post was originally made proactively sends the new post to all subscribers. Great! We can now be notified that a new update is available within a few second without having to poll every few seconds.

BUT this is point of my observation. I would argue that this proactive send is merely an artifice of the optimization and does not change the fundamental relationship of poster and subscriber. From that basic user point of view, the fact that the poster initiates the data transfer is immaterial. The subscriber is still simply seeing something they expressed interest in reading.

This is where I believe OMB goes astray. It lets an optimization detail obscure the higher level concept. Following someone’s posts means I want to see those posts in my view, but it does not require that either party perceive it as cross-posting to my site. I could equally accomplish the same viewing of that post by fetching it on demand, albeit not as efficiently.

Subscribing is implicit authorization

Keeping firmly in mind the fundamental concept of poster and subscriber, what if any authorization needs to happen when I request to follow ‘johnsmith’? I would say that the very fact I am requesting to see John’s posts is an implicit authorization that he can send them to me. Whether he wants to let me see them is a different story and the subject of another post. Let’s assume he will let me see his posts and we want to use the OMB optimization of his service (poster.com) proactively sending them to me.

When I request to subscribe, I need to send a URL of where to send the notifications and a means to verify that the sender is who I granted the privilege to.  This could be accomplished to different degrees of security. A fairly loose method would be for the subscriber to send a callback URL in the request that encodes a UID for the poster’s account. If the request transaction is secure, we can be reasonably certain that only the the “real” poster will be sending POSTs to that URL. Of course, this does not prevent the poster from sharing the UID, but the subscriber can always simply invalidate the URL and stop receiving the notifications.

In fact, this is pretty much how the RSS cloud API works and this could be a more proper model for OMB post-sharing.

What do you think?

I would be very interested to hear what others have to say about this post. One thing it does not cover is the complementary function of a subscriber GETting, rather than being sent an update. It also does not cover the perfectly matched use of OAuth to allow a user to grant access to other of his/her services just as described in the Twitter/Twalala example under “OAuth’s intended use-case”.

Tags: authentication, authorization, development, microblogging, OAuth, OpenMicroblogging

I just got through watching this video of Jason Fried that was recorded earlier this week in Boston. It’s the long-form, illustrated-with-slides version of the extemporaneous talk he did for RI Nexus this past Wednesday in Providence. I highly recommend this to anyone involved in software development.

Listening to his list of specific dos and don’ts in more detail just now made me realize that there’s one overarching philosophical tenet that guides all the details and that is the following.

Run your business and build your product for yourself, not for investors or shareholders or analysts or “big” customers. Run your business to sustain your own life-style and your own integrity. Build things you believe in, not what some purchasing manager put in an RFP.

Investors want you to grow without bounds. That makes you put in crap you don’t want. Salesmen want you to put in a useless feature so they can get a big sale. Big customers want you to put in things only they want. While some of these forces may have some benefits, in the long run, they only push you to do things that dilute or muddy up the product with noise. Truly great products are simple, coherent, easy to understand and perform quickly and reliably.

For me, this means satisfying the artist, artisan and craftsman in myself, not somebody who makes money off of what I do. That is where great works come from; not from a balance sheet, an enhancements list, a specification or god knows, Microsoft Project.

Tags: development, philosophy

Many thanks go out to Jack Templin and RINexus for bringing Jason Fried, founder of 37Signals to Providence last night. Jason spoke on many aspects of his success and what got him there, and answered a lot of questions, even mine!

What really impressed me about Jason’s story was that he became a success doing things the way I’ve always thought they should be done. And more to the point, exactly the opposite of the way traditional management tells you it should and must be done. Some examples from his talk.

1. Don’t get venture money. Bootstrap your idea in your spare time keeping your day job. You don’t want anyone telling you what to do who doesn’t share your passion for what you’re doing.
2. Don’t have a board of directors. What do they know about what you’re trying to do?
3. Don’t write specs, write code. You can’t tell whether something is good or bad from a spec, only from working code. Do it quick. If it’s no good, throw it away and move on. People in organizations are dreadfully afraid of making a mistake. Don’t worry about it, just do it.
4. Don’t keep an enhancement or bug list. Trust your gut to do what’s most important. When you keep hearing the same thing from people you know and trust, go ahead and do something about it.
5. Try to do everything in two week increments. That is, don’t let people get bored doing the project. They do their best work when they’re excited about the outcome.
6. Don’t plan too much. My question to Jason was about whether or not his small 12 person operation would scale up. He said, “I don’t know and I don’t care. We’ll worry about that when the time comes.”
7. Don’t hire any marketing people. Your customers are your best marketing dept.
8. Trust your employees. 37 signals gives each of their employees an unlimited charge card, to spend on whatever they want, however much they want. The company bought one employee flying lessons. Not because it would be a usable skill, but because it would make him a more happy and well-rounded employee. In their experience employees do not abuse the charge privilege, but use it sparingly, knowing that it comes of the bottom line.
9. Don’t spend money on an office. Keep employees in their own homes. That’s where they’re most productive. In an office it’s too easy to be interrupted and too easy to call a meeting. Meetings are productivity killers.
10. Charge money for your product from Day One. This is a complement to the Don’t take money from VCs rule. Nothing succeeds like revenue. If you have something worth paying for, people will pay for it. If it can’t sustain itself, find something else to do.

I’m sure there were more, but those are the ones that stuck with me. As a survivor of 35+ years in the software development business, I can personally attest to the practicality of these guidelines. I have seen the opposite fail miserably for my whole career, but every once in a while, I managed to become part of something that didn’t obey the rules, and those were the memorable successes.

Don’t let the management, marketing and financial suits tell you any different. Do what you know is right. If it doesn’t work, learn from the experience and don’t make the same mistake again. But please, don’t think you can ever get it right without trial and error. It’s so obvious it’s painful, but there are still legions of project and product and people managers who wouldn’t have jobs if not for torturing you with requirements statements, schedules and bug reports.

And one thing that he swears will never be added to BaseCamp, their project management tool: Gantt Charts. Hurray!!

Tags: development, entrepreneurship, Jason Fried, RINexus

This morning, I read an excellent blog post entitled “A Failure of Ideas, not Execution”, by Hank Williams, which was copied on the nextNY blog. It’s about the failure of most Web 2.0 companies to be acquired because they don’t have any strategy for making money from their ideas. One particular aspect of these failures is a bugaboo of mine, so I thought I’d follow up. Williams writes the following.

The idea that the raft of social media companies with no revenue model was going to somehow “figure revenue out later” after building up large audiences of free users has, I think been debunked.

I couldn’t agree more. Just having users is no measure of potential profitability, especially if you have nothing but advertising as a way to generate revenue. A database of users is not worth very much, in my opinion, even as a data asset. But investors continue to use this as a metric for valuation. Indeed, it seems to have become one of the accepted conventions of startup business. Buy why? I think it’s because, in the absence of real revenue, there aren’t any other ways to measure a web 2.0, social media startup. And, in addition, you have to have made those users go through a tedious registration process. It’s as though investors won’t count a user unless you made them go through some pain to register.

This is nonsensical. It’s like setting up a bricks and mortar retail store where you give things away instead of charging for them, but only letting people in the door if they sign your guest book. Well, what does that prove? That they value what you’re giving away? That you somehow “own” them now?

The theory, as it was explained to me once, is that you can expect to be able to convert some small percentage of free users into paying users. But if that’s the case, why make it difficult for them to sample your wares? Why not get as many in the door as possible? Why not make it as easy as possible? There is a way to do this, yet still give them an identity on your site. It’s called OpenID, an open, single-sign on technology for authenticating users and creating unique records for them on your site. Basically, it lets you use the same user identification (a URL like http://joecascio.net) and password for every site that accepts it. It’s very similar in concept to a general credit card like Visa or MasterCard. Instead of having a separate credit account with each merchant, you have one account with the credit card company and use that same account ID (the credit card number) everywhere you shop.

Someday, I hope Web 2.0 companies and more importantly, their investors, realize that it’s more important to get people in the door and shopping than getting them to sign your guest book. This goes hand-in-hand with Hank’s point that you have to give them something worth paying for.

I’ve been tweeting this weekend about making chili. I love chili and over a lot of years, I’ve refined my recipe to the point where it’s easy to make and tastes great. When I started out making chili, I experimented with different recipes and ingredients. I threw everything but the kitchen sink into it, usually to no good end. After a while, I realized that chili recipes are sort of like Japanese gardens. They’re not complete if there is something you can still take out.

My recipe tends to be more old school, and includes no tomatoes, only meat, onions, chili peppers, jalapenos, a bit of sweet pepper and spices. Here it is:

Joe’s Exothermic Chili

Serves approx. 8

Ingredients

• 2 lbs. stew beef
• 1 lb. hot Italian sausage. I use Perri’s.
• 1 small can diced green chilis
• 1 small can sliced jalapenos
• 1 sweet pepper
• 1 1/2 tbsp brown sugar
• 4 - 6 tbsp chili powder
• 2 tbsp cumin
• Olive oil
• 1 can red kidney beans
• (optional) 2 cloves garlic
• (optional) 1 - 2 tbsp Masa harina (southwest corn flour, NOT corn meal)

Directions:

1. Grind or dice stew beef into small pieces. I use a Cuisinart for this.
2. Remove casings from sausages
3. Mince onions, sweet pepper
4. If you use garlic, mince the cloves
5. Cover bottom of a large sauce pot with a generous amount of olive and heat.
6. When oil is hot, fry garlic until brown, then remove.
7. Add minced onions, sweet pepper and diced green chilis
8. If jalapenos are in vinegar, wash them off with cold water before adding add to pot
9. Cook vegetables until onions are soft
10. Break sausage meat into small pieces and add to pot. Break up as much as possible using cooking spoon.
11. Add minced/diced beef
12. Cover and cook on low heat for at least 45 minutes, stirring often, until fat and juices are generated, making a stew-like mixture. This much meat should generate enough liquid to almost cover the meat and other ingredients
13. Add chili powder and cumin. Broth should turn a dark reddish-brown color.
14. Cover and let simmer, stirring occasionally for at least another hour.
15. Add masa harina slowly to achieve desired thickness.
16. Test for taste, add brown sugar slowly to taste, add more chili or cumin if necessary, or tabasco to desired heat level.
17. Add beans, let simmer until bubbling again.
18. Serve with shredded jack cheese and/or sour cream garnish.

Like any stew-type dish, it really benefits from spending a night in the refrigerator so the flavors blend nicely.

A while back, I posted a video blog entry of my chili-making process. Here it is:

Enjoy!!

Just now, someone I follow on Twitter posted a link to what looks like an interesting article in the Boston Globe’s online site boston.com. So, I click on the link and instead of seeing the story, like I used to, I now get this:

Sigh…. I thought we’d gotten past this foolishness of forcing readers to sign up on your site just to read your content. Now I have to create yet another login ID and password that I have to remember.

If you go to the registration page you find this form:

As you can see, they want lots of personal information about you, including your job and household income. All I can say to you, Globe, is that it’s none of your damned business how much I make or where I work, how old I am or what town I live in. If you want to offer me something additional for putting in this information, then I might consider it. I don’t have to tell you this stuff to read the paper version, do I?

Why do I have to register for Boston.com?
We’re now asking the readers of Boston.com to register for two reasons. We’d like to:

1. Improve your experience on the site by offering content and features tailored to your interests.
2. Target the marketing messages you receive to make them more relevant and deliver a better value for our advertisers

Many newspaper Web sites require registration. Our hope is that our quick and easy registration process will minimize any inconvenience. The best part is that you only need to register once for full access for life.

This just doesn’t wash for me. For 1., using a regular old cookie, they can track what I look at without having me register. Once they do that, they can accomplish #2. If they really want to know where I live and how much I make, they can politely ask and let me say no. They should never force me to do it, though. That’s just making it hard for me to consume their content, and making my experience unpleasant.

I would consider paying for access to the Globe, just like I pay to get a paper copy as long as they didn’t get greedy about it. Maybe charge $1 year or $.10 per visit. That would provide them a revenue stream to offset the marketing information they get from making you register.

Now, let me offer a very reasonable alternative. The open protocol, open source, single sign-on technology for the web is OpenID. In the same way that a general credit card (e.g., MasterCard, Visa, AMEX) lets you avoid having to have a special credit card and account with every store, so OpenID lets you have one (or a small number) of Internet identifiers that can be used wherever OpenID is accepted. the Boston Globe should offer OpenID as an alternative means of authentication and registration. OpenID providers like MyOpenID.com and labs.verisign.com, as well as Yahoo, Flickr, WordPress.com and AOL all provide for demographic information if the user approves it. If the Globe offered OpenID as an alternative to creating yet another login/password (YALP?) and agreed to accept the level of demographic information I authorize through my OpenID provider, I would object far less to registering for the site.

What would really be cool is if I could associate a charge account with my OpenID, and simply by logging in and approving either once or every time I visit, pay the Globe for accessing their content.

And, by the way, Boston Globe, your parent company The New York Times, just attended the OpenID Content Provider Advisory Committee meeting in New York City. You’ve got no excuse! Get with the program!