« February 2007 | Main | April 2007 »
March 29, 2007
Google's Solar Power Installation
Anthony Ravitz is talking about how Google installed 1.6MW of solar panels at their headquarters. He starts by talking about all of Google's green initiatives.
The solar project, with financial incentives from PG&E, has a payback of 7.5 years. Solar works best at the same times that peak power is needed.
Google's is the largest commercial installation of solar in the US. It uses 9212 Sharp 208 photovoltaic modules. The modules we put on standing metal seam roofs. On sloped roofs, they're mounted flat on the southface, but on the north face, they're kicked up. On flat roofs, they're kicked up to face south. Shading part of the panel dramatically drops power production, not just proportional to the portion shaded. Google built carports to increase the roof capacity so they could put more panels in.
The modules are strung together in a series of fourteen modules and then fed to an inverter. They have outdoor rated cable, so conduit is not required. The inverters look like they're mounted on the roofs outdoors. The installation is relatively straightforward.
11:23 AM | Comments (4) | Recommend This | Print This
Bruce Perens on Software Patents
Last week Scott and I talked to Bruce Perens for the Technometria podcast. Bruce happened to be in Utah (although we did the interview over the phone) because of Brainshare. He wasn't in town to attend, but to protest the recent agreement between Novell and Microsoft.
We had a good discussion of software patents, why he thinks the Novell-Microsoft agreement is bad for open source, and the change to the GPL to combat the deal. You can read a summary and listen to our discussion on IT Conversations.
10:45 AM | Comments () | Recommend This | Print This
Generation C: Matt Webb
I didn't capture this whole talk, but here's what appealed to me most. Matt describes what he calls "Gen C" using a collection of C words: Communities, connected socially and electronically, creative, controlling, complex. He says that as a "paid up member of Gen C, I want to help design my products."
I think that's a key point that product manufacturers are missing. Many people have a desire to tinker with things and will if you give them the opportunity. Just as important: the product shouldn't require that you tinker with it to make it work.
Things like Flickr are a good example of this idea on the Web. For most people, it just works, but if you really want, there's an API that you can use to enhance and customize it. Some people do and the product is better because of their work.
Companies that find a way to bring those hacker-users into the product development process will ultimately be more successful because they enlist a vast army of people who they don't have to pay in solving their customers needs and improving their products.
10:30 AM | Comments (1) | Recommend This | Print This
March 28, 2007
Why to Not Not Start a Startup
With all the ETech stuff I've been immersed in, it's easy to forget there's other stuff happening. This Paul Graham essay dispelling myths about startups is one you don't want to miss. It goes well with Marc Hedlund's tutorial from Monday.
10:30 PM | Comments () | Recommend This | Print This
Hacking Organizations: Chad Dickerson
Chad Dickerson, who I've known since he was the CTO at InfoWorld, and runs the Yahoo! Developer Network, is giving a talk about how to hack an organization. When Chad put together the Yahoo! Hack day, he had to hack everything from the way brand managers thought about brand to talking the groundskeepers into letting people camp on the lawn and turning off the sprinkler system.
1:00 PM | Comments () | Recommend This | Print This
The Core of Fun: Raph Koster
Raph Koster introduces himself as an alien from another planet: a game designer. He's the author of The Theory of Fun. He starts by introducing structure in music and art with some cool audience participation.
There are different dimensions to fun:
- Hard
- Easy
- Visceral
- Social
Hard fun is about solving problems. The problems tend to be mathematical Therefore the grammar of hard games ignore presentation.
He applies the theory of fun to Amazon.com and concludes that it's not structural, not fun. There a lots of sequential steps and don't provide any "fun" or feedback.
The magic ingredients:
- Territory - where you meet the challenge matters. Doing the same thing in different places should make a difference. The topology should affect the available options.
- Preparation - when you buy it, what pages and interactions you saw should matter. Everything you did before should matter. The last interaction you had should matter (think of your opponents last move). Never start an interaction with no context. You must prepare for the encounter.
- How - should involve skill on your part (eBay is more fun than Amazon). The core verb should be repeatable. Tricks and tips should matter. You should feel like you're growing more competent. Competition is an important element and people need to be able to see it.
- What - buying different things should feel different. The same verb must be applicable in many different challenges. A given verb is a hammer. You should present them with lots of nails.
- With - what tools you use should matter. Give users an array of tools to solve the problem. The system should give the user different rewards of different feedback based on how the challenge was met.
- For? - you need feedback. A game that has only one possible outcome is boring. A lot of services drive you toward a given outcome and then they stop. Usually, the best feedback is a grater challenge. Sometimes it's a pleasant surprise. Either way it has to be highly visible.
- Few? - don't always get what you want. Low risk activity for high reward is bad for fun. You need to drive users to challenges at the edge of their ability.
- Phooey - fun comes from learning. Failure is important to learning. Making a wrong choice has to be a set back. Fun won't exist if there's no consequence.
All of this can be quantified. You can give people ratings for how hard it is to accomplish a particular task. What is the challenge rating for buying a particular book at Amazon?
12:38 PM | Comments () | Recommend This | Print This
Is This an Apple Conference?
This is a big hotel. There are several other conferences going on at the same time as ETech. I was in the gift shop during the break. A guy with a badge from one of the other conferences saw me standing in line, MacBook in hand, and asked me "Is that an Apple conference or something? Everyone there is using an Apple!"
12:14 PM | Comments () | Recommend This | Print This
Learning from Muggles
Danah Boyd is talking about learning from muggles. If we consider the technologists to be the wizards, that makes the normal user a muggle. There's a real danger in designing for ourselves.
Danah describes four stages people go through in their lives:
- Identity formation and role-seeking - young people are trying to make sense of the societal roles around them. We are defined, in large part, by the people around us. Friendship and interaction become important.
- Integration and coupling - This period is trying to find meaningful labor and determine how they can contribute. A lot of twenty-somethings are engaged in jobs, not careers.
- Societal contribution - This stage is about family and pursuing the ideals and dreams we have about how life should be.
- Reflection and storytelling - As we get older, we try to make sense of what our life was about.
Danah shows how these needs play out in social sites that cater to these different groups (with the exception of the last stage). MySpace is tailored to the needs of identity formation and role-seeking, whereas LinkedIn doesn't appeal to them at all.
Danah talks about the positive and negative aspects of what happens online--both for society and individuals.
- Persistence - what we do online is around for forever
- Searchability - where we are online is finable
- Replicability - what we do can be put up all over
- Invisible audience - We don't know who we're talking to
She brings up the story of the Star Wars kid who made an innocent video and found his life turned upside down.
There are extensive implications for our privacy. There are new rules and we don't know the consequences. Andy Warhol talked about being famous for 15 minutes, but we're really famous for 15 people.
Technology is shifting the rules. Do we just keep making technology and playing the ostrich or do we pay attention to what's happening? Do we have a responsibility for what happens with our spells, enchantments, and incantations? Rather than thinking about just the business side of what we do, we need to consider the societal aspects as well.
11:11 AM | Comments () | Recommend This | Print This
The Coming Age of Magic: Ubiquitous Computing User Experiences
 Mike Kuniavsky (click to enlarge) |
Mike Kuniavsky, the founder of Adaptive Path, has a company called Thing M, a device design studio that "Lives at the intersections of ubiquitous computing, ambient intelligence, industrial design and materials science." He's giving a talk on The Coming Age of Magic.
The idea is that Moore's Law has pushed the price of computing so low that it is nearly disposable. Computing can be everywhere. People have talked about ubiquitous computing for a long time, but the era of cheap, low-power computing, and wireless communication has arrived.
We no longer need to serve as the knowledge intermediaries for computers, they can be embedded in objects to make the dynamic. What does this do to people's experiences?
People's reaction to ubiquitous computing devices is to consider them more like animals than they do to rocks and other inanimate objects. People know their Roomba isn't an animal, but they treat them that way.
He brings up the MagicCap OS developed by General Magic in the mid 90's and points out that a metaphor can be extended too far. While it's easy to mock something in retrospect, the point remains that taking the desktop metaphor beyond the desktop doesn't work.
To that point, sticking a largely unmodified PC into another device doesn't work. It creates an information management problem on top of the other problems that the device is designed to solve. You can't optimize your house. You can't produce leisure.
The answer is magic. Not in the traditional sense that people understand magic, but specifically in the sense of enchanted objects. This isn't pretending that technology is magic or lying about how technology works. It's an abstraction for describing how enchanted objects work.
What sets enchanted objects apart from their static counterparts is their ability to interact. They should be
- Everyday objects
- Familiar - look and act like you'd expect them to
- Physical - there is a physical use mode
- Screenless - no assumption that there's a text output
- Not human - no expectation that they behave like us
- Not superhuman - ultimately we're in control of the object
There are some devices now that have these properties. He references the Ambient Orb, the Nokia Medallion, the wand-like Nintendo Wii, and so on.
Ubiquitous computing is a by-product of market forces. Metaphor is emergent. Magic as a metaphor for ubiquitous computing is an emerging metaphor. Metaphor is powerful and we need to be conscious of its power or we end up over using it. Good magic should explain, not conceal deceive, or cripple.
10:27 AM | Comments (2) | Recommend This | Print This
March 27, 2007
IT Conversations Meetup
I just got back from the IT Conversations meetup here at ETech. I really enjoyed meeting people, talking about what they like and don't like, and hearing how they use IT Conversations. There were about a dozen people there. Doug Kaye was able to come and I think people enjoyed quizzing him about the beginnings of IT Conversations and giving him feedback on some of the technical aspects of how things work. Thanks to everyone who came!
If you weren't able to be in San Diego for this meetup, we plan on having more in other parts of the country as time and opportunities allow. Watch for more news here or sign up for the IT Conversations group at Eventful and get notified when new events are posted.
11:16 PM | Comments () | Recommend This | Print This
What's IT Conversations?
Yesterday Steve Gillmor gave me the perfect answer for when people ask me what IT Conversations is. It goes like this:
You: What's IT Conversations?
Me: Are you familiar with NPR?
You: Yes...
Me: It's nothing like NPR.
Does that help?
Bonus link: Doc Searls offers up Irrational Public Radio. From their homepage:
Where other news sources leave off, Irrational Public Radio starts, and proceeds almost mercilessly. For the discerning listener, IPR is a stalwart of integrity, a bastion of integrity, and just a huge heaping platter of integrity. We commend you for your taste and your fetching personal scent.
7:31 PM | Comments (1) | Recommend This | Print This
Medieval Tech Support
Kelly Flanagan sent me a link to this video about medieval tech support teaching someone how to use a book. Just read the captions unless you speak Norwegian.
7:27 PM | Comments () | Recommend This | Print This
Advanced Analytics in the Anonymized Data Space: Jeff Jonas
Jeff Jonas gave a great keynote this morning. (Here's a paper from IEEE Security and Privacy that explains some of this.) This afternoon he's adding context. Literally. Contexts allow seemingly unrelated records to become related. The idea is that two records get created in two different data stores, because of some common event, but the common event is unobservable to the organization and the perceptions around that event are not connected.
When the organization queries these data sources to make a decision, the fact that these records are related might not be known. He calls this enterprise amnesia. The answer is a database that creates persistent context that relates these records. The query is done against the persistent context. The context is like the card catalog in a library, serving as an index to records.
Query might be any number of things. If you do not process every new piece of data (perceptions) first like a query, then you will not know if it matters...until someone asks. Jeff treats query as data. When a query is made against the context, and gets no response, it's stored as a database. Later if data shows up that matches the query, you get a match. Treating queries like data makes it so you don't have to ask every question every day.
- Queries find data
- Data finds queries
- Data finds data
- Queries find queries
The latter one gets users with like interests together with one another.
In the grand scheme of things, the context allows you to reconstruct the non-observable. More perceptions lead to reduced ambiguity. The time when you're ingesting data is the best time to make discoveries. Jeff calls this perpetual analytics.
Jeff's analytics engine takes queries and data in through the same pipe. No joins, to triggers, no stored procedures. When you discover something new, you fix all the related records. He tells the story of a con man who had six different identities with no overlap. One day the con man introduced a PO Box to the system that allowed all six identities to be tie together.
Context is "persistent" in the sense that it's not created on the fly with the query on federated data sources. Sequence neutrality is crucial since perceptions may come in different order.
The technology Jeff developed (called NORA) is for sharing context within an organization. What if you want to share data with others. For example, the government doesn't want to share it's data with the cruise line, and the cruise line doesn't want to share customer information with the government. Can you encrypt to the data and analyze it in the encrypted form? Jeff calls this ANNA.
The anonymizer doesn't just hash the data, it first processes it to create rooted forms. For example, Bob, Bobbie, and Rob are all rooted to Robert. This allows the encrypted form to be analyzed and queried for matches. Then the context points back to specific records and you can then have a narrow conversation about specific records rather than grabbing entire data sets.
4:45 PM | Comments () | Recommend This | Print This
ETech 2007 Photos
I've posted some pictures from the Emerging Technology (ETech) conference on my gallery site.
3:41 PM | Comments () | Recommend This | Print This
Hierarchical Temporal Memories
Jeff Hawkins of Numenta (and also founder of Palm and Handspring) talked about brains and computers. He discussed hierarchical temporal memory in detail. There's a platform you can download and play with. I was busy listening and didn't get good notes.
1:21 PM | Comments () | Recommend This | Print This
Creating Alternate Realities: Jane McGonigal
 Jane McGonigal (click to enlarge) |
Jane McGonigal is a "happiness hacker." Or at least that's how I'd summarize what she said. She does this by designing alternate reality games. Alternate realities do away with limitation in an effort to explore possible alternatives to current situations. (Slide to be here by Friday.)
Jane gives a "forecast from the future" of things she thinks will be important for technology and tech companies. Here are the things she mentions
- Quality of life is the primary metric for evaluating everyday technology
- Positive psychology is a principle influence for design
- The public expects tech companies to have a clear vision of a life worth living.
- To succeed, a brand or product must increase real happiness, the new capital.
She recommend some books:
- Stumbling on Happiness
- Science of happiness
- Authentic Happiness
She discusses realms of happiness:
- Pleasure - satisfying experiences
- Engagement - immersive responsive systems
- Meaning - a power role or actor
Various traditional games (which she discusses) play in different ways in these realms. But games are a weak signal of desire. It's all accidental at present. Can a game make improved quality of life a real priority.
She describes some games she's created: reshelving 1984 from fiction to non-fiction in all fifty states, assassinating people with acts of kindness, and tombstone poker.
These games are all supergames. They are large scale in geography and number of people. They're superimposed on reality. They are superheroic--players always play themselves. They are supercomputing, engaging the collective thought of thousands of people. These are all important for putting the game in all three realms of happiness that Jane mentioned before.
12:34 PM | Comments (2) | Recommend This | Print This
AWS and Your Data Center: ETech 2007
Werner Vogels, Amazon's CTO, is talking about their Web services--specifically the outsourced data center products (S3, EC2, and SQS) that I've written about before and that were the subject of an IT Conversations interview I did with Doug Kaye and Jeff Barr.
Werner begins by making a case that (a) scaling is critical to Web businesses and (b) scaling, economically, is really hard. I was just twittering with Phil Burns last night about servers. He just took delivery of four for TagJungle. He's got a lot of work ahead of him setting them up. When TagJungle grows again, Phil has to do it all over again. Werner's making a case that small businesses shouldn't have that headache.
EC2 relies an Amazon Machine Images, virtualized machine images that you can create yourself (based on Xen) or simply download as a virtual appliance (see my earlier discussion of virtual appliances).
Someone (missed the name) from RightScale demoed using AWS for transcoding music on TuneCore. He shows how servers can be deployed and scaled based on demand.
Doug Kaye was invited up next to talk about the GigaVox system (GigaVox Audio Lite) that is the subject of my discussion with him and Jeff Barr. Doug is in the top 1% of AWS users in terms of the complexity and sophistication of his application. Doug says that the best part is that "no one's wearing pagers."
There's a very small upfront investment and the bill grows as you grow. There are no sudden capital spikes.
Werner recommends From Push to Pull- Emerging Models for Mobilizing Resources, a paper by John Hagel and John Seely Brown. I'll have to read it. Here's the abstract:
Not really an abstract: In the past decade, we have seen early signs of a new model for mobilizing resources. Rather than "push", this new approach focuses on "pull" -- creating platforms that help people to mobilize appropriate resources when the need arises. In lean manufacturing, early elements of a pull model began to emerge from Toyota in the early 1950's. As we will discuss below, however, lean manufacturing represents a hybrid between push and pull models -- it still contains significant elements of push models.
11:20 AM | Comments (4) | Recommend This | Print This
Kathy Sierra
Update: Read about Kathy Sierra, Chris Locke, and Due Process.
Kathy Sierra, who's blog I've come to enjoy very much, canceled her tutorial yesterday and session this morning because of death threats (warning--this link goes to graphic material) she's received on her blog and on other blogs. This saddens me deeply and makes me angry. I'm sad and angry that someone--anyone--has to endure this kind of fear in their life. What's more, I'm sad that these actions have silenced someone who has so much to offer to the world. It's unacceptable. It's hateful. It's simply wrong.
10:26 AM | Comments (12) | Recommend This | Print This
March 26, 2007
Secrets of Mental Math: Arthur Benjamin
The closing keynote for Monday night, usually something fun and light, did not disappoint. The speaker was Arthur Benjamin, author of the book Secrets of Mental Math. He's a "mathemagician" doing mental math at lightening speed. He did magic squares, 4 digit number multiplication, day of the week calculations, and other things. It was very fun and entertaining.
10:17 PM | Comments (1) | Recommend This | Print This
IT Conversations Meetup Tuesday
Don't forget that we're having an IT Conversations Meetup tomorrow night at 7:30pm. The session in the Gregory A room of the Manchester Grand Hyatt. Doug Kaye's in town and will be joining us. Come and give us feedback, ask questions, and talk about anything at all. I hope you can make it.
9:44 PM | Comments () | Recommend This | Print This
O'Reilly Radar: ETech 2007
Technology, hackers, Gibson, alpha-something-or-other, future, etc., etc., etc. You've heard the O'Reilly schtick before. Tim knows you've heard it before, so he skipped it and give as a new quote from Dale Doherty:
"You guys aren't pulling your weight around here. You're not having enough fun!"
Make Magazine is fun. People are doing what they do for the sheer joy of it. Snowboarding wasn't started as a business, rather for fun. Linus Torvald didn't start Linux for a business--he started it for fun.
Finally, the Gibson quote. Tim talks about his future son-in-law putting a design for a new kite surfing kite online on Monday and testing it on Friday--and it was built in China.
The power supply for the one-laptop-per-child project is a pull-string charger. Colin Bullhaup of Potenco says "We used to get mockups. Now we get new working prototypes on a weekly basis." Hardware design is starting to iterate like we do with software.
Chumby is open source hardware: a Web 2.0 clock radio "you can hack with a seam ripper." The business model is widget subscription. Get the hardware cost as low as possible.
Threadless.com is a custom order t-shirt shop with a twist. Users submit and vote on designs. Only when a design gets enough votes do they get manufactured. They've had 75,000 t0shirt designs submitted and made 800 of them that have all sold out. T-shirts today, motorcycles tomorrow.
In the future, we'll specify products in small lots, buy them just as they're made and recycle them immediately. (Refer to Bruce Sterling's talk from last year).
Since last year's focus on attention, a number of sites have become more promiscuous with data. Twitter is the latest. There's an etech Twitter. Facebook has a mini-feed.
I missed a whole big thing about prediction marketing and it's relation to the stock market. We may learn things from the stock market.
Tim brings up Peter Rips' Web 2.0 - Over and Out post. Tim says that Web 2.0 is really about systems that harness network effects to get better the more people use them. Web 2.0 is about the build-out of the Web. Where is the Web 2.0 address book? Not hear yet.
Amazon and Google don't so much get better result because of their superior algorithms as they do because they have better and more data.
9:20 PM | Comments () | Recommend This | Print This
Applied Web Heresies: ETech 2007
I really wanted to go to Putting the Fun in Functional: Applying Game Mechanics to Social Software by Amy Jo Kim, but my inner geek won out and I went to Applied Web Heresies with Avi Bryant (slides). I hope someone else took good notes.
The basis for the talk is Seaside, a web framework for Smalltalk that Avi wrote several years ago. The problem with Seaside is you're not going to use it! There are a lot of interesting ideas in Seaside that people should know, so this tutorial is way of spreading the ideas outside of Smalltalk.
Avi suggests using Seaside as a recipe. He tells the story of Primo Levy and onions in the varnish. There are a lot of "best practices" of Web development that were good decisions at the time but which are no longer needed.
Here's the basic requirement list:
- OOP
- Servlet-style app server
- Blocks and closures
"First thing we do, let's kill all the templates." Templates were a good idea that have become useless and harmful. They're constraining or they're a bad programming language. The is a belief that templates are useful for model/view separation. But HTML is now a semantic layer and CSS is the real view layer (see Zen Garden). This is an interesting point of view and one I have a hard time arguing with.
So, you need a rich library for generating HTML (see AWT for inspiration). Each widget has a render method that gets a canvas passed to it.
The first thing we did was write a small framework to get things going. Different groups were working in different languages. I used Ruby (even though I don't really know Ruby). Here's mine:
require 'webrick'
require 'stringio'
server = WEBrick::HTTPServer.new(:Port => 2000)
server.mount_proc("/heresy"){|req, res| Application.new.handle(req, res)}
server.mount_proc("/favicon.ico"){|req,res| res.status = 404}
class Application
def handle(req, res)
canvas = Canvas.new(res)
render_on(canvas)
end
def render_on(html)
html.heading("Hello World")
end
end
class Canvas
def initialize(res)
@res = res
res['Content-Type'] = 'text/html'
end
def heading(str, level=1)
@res.body = "<h1>"+ str + "</h1>"
end
end
trap("INT"){ server.shutdown }
server.start
We're omitting tag objects here and just spitting out HTML, but a real API should do that.
The next heresy that Avi proposes is that sessions are two valuable to persist. In general, you can never marshall and unmarshall the stuff in memory reliably. All the good stuff's in memcached anyway. Keep the session in the memory of the application server
What about load balancing? Use sticky sessions. YAGNI Application servers going down is unusual. Users losing session data is a minor annoyance. Live with it.
NeXT's WebObjects is the inspiration for much of what Avi's done.
Next we move from our HelloWorld application to something that has stateful sessions. We're going to build a registry of sessions and push the canvas down a level so that the sessions hold the canvas. My Ruby coding skills were not up to keeping up, so I cheated and grabbed Avi's code (which includes a much more usable Canvas object):
require 'webrick'
require 'stringio'
server = WEBrick::HTTPServer.new(:Port => 2000)
server.mount_proc("/heresy"){|req, res| Application.new.handle(req, res)}
server.mount_proc("/favicon.ico"){|req,res| res.status = 404}
class Registry
def initialize
@items = []
end
def register(item)
@items << item
(@items.size - 1).to_s
end
def find(key)
@items[key.to_i]
end
end
class Application
@@sessions = Registry.new
def handle(req, res)
session_cookie = req.cookies.detect{|c| c.name == "heresy"}
if(session_cookie)
session = @@sessions.find(session_cookie.value)
end
unless session
session = Session.new
res.cookies << WEBrick::Cookie.new("heresy", @@sessions.register(session))
end
session.handle(req, res)
end
end
class Canvas
def initialize
@io = StringIO.new
end
def tag(name, attrs={}, &proc)
@io << "<"
@io << name
attrs.each{|k,v| @io << " #{k}='#{v}'"}
@io << ">"
proc.call
@io << "</#{name}>"
end
def text(str)
@io << str
end
def heading(txt, level=1)
tag("h#{level}"){text(txt)}
end
def string
@io.string
end
end
class Session
def initialize
@count = 0
end
def handle(req, res)
@count += 1
html = Canvas.new
render_on(html)
res.body = html.string
res["Content-Type"] = "text/html"
end
def render_on(html)
html.heading("Hello World: #{@count}")
end
end
trap("INT"){ server.shutdown }
server.start
What's left to do on session? Lots, including:
- Unguessable session keys
- Session keys as query params
- Session locks
- Expiration from registry
The next piece of heresy: meaningful URLs don't carry enough meaning. People put a lot of energy trying to create names that describe the particular point in an application. Not every page in an application is a meaningful part of an API. URLs, particularly query parameters are classic place where people repeat themselves. Don't repeat yourself. Lots of meaningless names create namespace collisions.
Avi proposes using a registry to store IDs against page names. The inspiration for this is TCL/TK: Register closures/blocks as callback objects. Here's the code that implements this refinement (I did it almost all by myself--I had to peak to see how WeBrick handled requests):
require 'webrick'
require 'stringio'
server = WEBrick::HTTPServer.new(:Port => 2000)
server.mount_proc("/heresy"){|req, res| Application.new.handle(req, res)}
server.mount_proc("/favicon.ico"){|req,res| res.status = 404}
class Registry
def initialize
@items = []
end
def register(item)
@items << item
(@items.size - 1).to_s
end
def find(key)
@items[key.to_i]
end
end
class Application
@@sessions = Registry.new
def handle(req, res)
session_cookie = req.cookies.detect{|c| c.name == "heresy"}
if(session_cookie)
session = @@sessions.find(session_cookie.value)
end
unless session
session = Session.new
res.cookies << WEBrick::Cookie.new("heresy", @@sessions.register(session))
end
session.handle(req, res)
end
end
class Canvas
def initialize(cbs)
@io = StringIO.new
@callbacks = cbs
end
def tag(name, attrs={}, &proc)
@io << "<"
@io << name
attrs.each{|k,v| @io << " #{k}='#{v}'"}
@io << ">"
proc.call
@io << "</#{name}>"
end
def text(str)
@io << str
end
def link(name, &proc)
id = @callbacks.register(proc)
tag("a",{ :href=>"?#{id}"}){text(name)}
end
def space
@io << " "
end
def heading(txt, level=1)
tag("h#{level}"){text(txt)}
end
def string
@io.string
end
end
class Counter
def initialize
@count = 0
end
def render_on(html)
html.heading("Hello World: #{@count}")
html.tag("p"){html.text("this is fun!!!")}
html.link("--"){@count -= 1}
html.space
html.link("++"){@count += 1}
end
end
class Session
def initialize
@callbacks = Registry.new
@root = Counter.new
end
def handle(req, res)
req.query.each do |k,v|
if callback = @callbacks.find(k)
callback.call(v)
end
end
html = Canvas.new(@callbacks)
@root.render_on(html)
res.body = html.string
res["Content-Type"] = "text/html"
end
end
trap("INT"){ server.shutdown }
server.start
As we finished this segment, I said "I get what we're doing, but why are we doing it?" In other words, why go to all this trouble to create a registry of callback methods and URLs that point to it uniquely? The answer is in the next little exercise. Here's the code I produced:
require 'webrick'
require 'stringio'
server = WEBrick::HTTPServer.new(:Port => 2000)
server.mount_proc("/heresy"){|req, res| Application.new.handle(req, res)}
server.mount_proc("/favicon.ico"){|req,res| res.status = 404}
class Registry
def initialize
@items = []
end
def register(item)
@items << item
(@items.size - 1).to_s
end
def find(key)
@items[key.to_i]
end
end
class Application
@@sessions = Registry.new
def handle(req, res)
session_cookie = req.cookies.detect{|c| c.name == "heresy"}
if(session_cookie)
session = @@sessions.find(session_cookie.value)
end
unless session
session = Session.new
res.cookies << WEBrick::Cookie.new("heresy", @@sessions.register(session))
end
session.handle(req, res)
end
end
class Canvas
def initialize(cbs)
@io = StringIO.new
@callbacks = cbs
end
def tag(name, attrs={}, &proc)
@io << "<"
@io << name
attrs.each{|k,v| @io << " #{k}='#{v}'"}
@io << ">"
proc.call
@io << "</#{name}>"
end
def text(str)
@io << str
end
def link(name, &proc)
id = @callbacks.register(proc)
tag("a",{ :href=>"?#{id}"}){text(name)}
end
def space
@io << " "
end
def heading(txt, level=1)
tag("h#{level}"){text(txt)}
end
def string
@io.string
end
end
class MultiCounter
def initialize
@counters = [Counter.new, Counter.new, Counter.new]
end
def render_on(html)
@counters.each{|ea| ea.render_on(html)}
end
end
class Counter
def initialize
@count = 0
end
def render_on(html)
html.heading("Hello World: #{@count}")
html.tag("p"){html.text("this is fun!!!")}
html.link("--"){@count -= 1}
html.space
html.link("++"){@count += 1}
end
end
class Session
def initialize
@callbacks = Registry.new
@root = MultiCounter.new
end
def handle(req, res)
req.query.each do |k,v|
if callback = @callbacks.find(k)
callback.call(v)
end
end
html = Canvas.new(@callbacks)
@root.render_on(html)
res.body = html.string
res["Content-Type"] = "text/html"
end
end
trap("INT"){ server.shutdown }
server.start
The only changes here are the addition of a MultiCounter class that creates a three item array of counter objects and a render_on object that calls render_on on each member of the array. Then, instead of putting a Counter object at the root, I put a MultiCount object. And you get three of the Counter widgets on the same page. This shows how easy it is to use the objects as Web widgets. Avi says you can't do this with named URLs.
Avi remarks that pages are a lousy unit of reuse and partials ain't much better. "But every piece of my application is a beautiful and unique snowflake." Again, with the CSS.
What aren't we doing?
- Splitting callback registries up by page view
- Tracking the back-button
- Redirecting after side-effects
- Forms!
Overall this is a very interesting set of thoughts about Web development. Clearly he's espousing a lot of new ideas, which generated a lot of "How do you ...?" questions. Very good stuff. This tutorial made me think, which is the best kind.
2:56 PM | Comments (9) | Recommend This | Print This
Coder to Co-Founder: Etech Tutorial
I'm sitting in Marc Hedlund's tutorial, Coder to Co-Founder: Entrepreneuring for Geeks. Looking him up on the Web, I found, what else, a post he'd done about twitter about how Twitter is wall for the Web (and some other things).
Something from Nothing: Marc makes the point that being employee number one for a company is easier than being the founder because being employee number one implies something's already there--a name, an idea, money, and so on. You should work on the idea that won't leave you alone.
It's Good to Be King: It's fantastic to have an idea, get people to work on it, and see if it works. It's enormously satisfying to do that. Everyday there is a new problem, something you haven't done before, something new to learn. As founder, you get to do everything and that's fun.
One of the most important skills is to be able to listen to others tell you what's wrong with your idea, solicit feedback, and learn. If you're more excited than you're afraid then it's time to start. It's rational to be afraid, but you get over that with your excitement for an idea.
Better ideas: Your ideas will get better as you understand business better. Engineers like to think all ideas are about engineering, but there are more things you need to know. He suggests following a sales guy around. Sit in on a sales call and listen to customers. I think that's excellent advice--but don't limit it to sales. I remember being tutored in business finance by a very patient and smart guy, Chris Heim, when I was a new CTO. That was very helpful to me.
Losing sucks: Having start-ups on your resume is tough because people see it and think you'll leave the next time you have an idea. Closing down a business is hard, but you learn a lot. Have some cash in the bank--you won't want to go right out and get a job once you close your company down. Having money in the bank is flexibility.
Good reasons: One good reason to start a company is you get to create a company you'd like to work at. Boy is that true! There is nothing better than being about to make decisions that make a company a good place to be.
Bad reasons: Don't start a business to be rich or famous. There are better, easier ways. Don't start your business because you want total control. This doesn't work. The very ideas of a "company" is that you get other people to help you and you have to delegate authority to them.
The idea: The idea will change over time. What matter is identifying the demand. Talking to people will help identify the demand and help you refine the idea. Early on, find out what matters to people, rather than designing the Web site.
Build what you know: Mark recently started wesabe, an online money management tool. He knew about the idea because he knew plenty of people, including himself, who needed help managing money--and knew what didn't work.
Give people what they need: Note that this is different than what they say they need. Don't listen as much to needs as to problems. Mark interviewed about 1500 people about managing money as he got going on Wesabe.
Keeping secrets from the market: If you keep your secrets from the market, it will keep it's secrets from you. Be inclined to be open about your idea. This doesn't inoculate you from people stealing your ideas, but the benefits outweigh the downside. You certainly need to have secrets, but don't keep secrets in areas you need feedback from people.
Prudence becomes procrastination: You can be too careful.
Momentum builds on itself: Building UI prototypes, demos, and so on will help people connect to your idea and become enthusiastic about it. Put your idea on paper, build a pitch deck, write a one-page summary, code a prototype, etc.
Partners: it's enormously helpful to have a partner. Co-founders and others can give you a big push. When you're all on your own either you do something or nothing happens. When there's more than one, you can feed off each other. You have a commitment to someone else.
Timing: In down times, money is scarce. In good times, employees are scarce. Any time is a good time to start a great company. It's more important to have a great idea than to have great timing. Take advantage of whatever the landscape is when you start.
Competition: Entrepreneurs are unduly scared off by competition. All that matters is if you are better than the others.
What to worry about: Is there a need? Are you building for yourself?
Don't worry: about not having help, advice, etc. Don't worry about raising money.
Explain yourself: tell your idea to the taxi driver and other people you run into. Perfect your elevator pitch and you'll perfect your idea. He tells the story of the founder of del.icio.us who found out from talking to people that most people don't call bookmarks "bookmarks" but "favorites" because of IE's influence.
Critique a friend: Get someone who knows your idea try to pitch someone else. You'll learn a lot about your idea.
People: talk to people--not just your friends. You don't have to be comprehensive. Get out of your normal group of people. Don't get so much advice that you talk yourself out of your idea.
Co-founders: Being the co-founder in a business is a way to ruin a friendship. You'd think just the opposite. I have seen this several times--it's easy to get into disagreements you can't work out and become bitter.
Three is fine, two divine: This is the same rule as for airplane partnerships. :-) One co-founder is ideal, two is OK, more than that is unworkable.
Employees: The first few hires set the tone for the whole company. Boy is that true. Don't give people full time job offers until you're sure. Hire them as contractors and then give them a full time offer if it works out. This is some very good advice.
Joiners: Lots of people will know about you and not be willing to make the leap early on. Find a way to keep them interested. It's not a bad thing that as you get more successful, people want to get involved.
Veterans: Startup veterans are a great source of help since they love the culture.
People you like: Hire people you like. Work with people you like. Find smart, talented people and hang out with them.
Share a passion: Find people who believe. If you've got to convince them, they don't have the vision of what you're doing. Find people who are as passionate as you are.
Funding: Two paths: bootstrapping or investments. Bootstrapping is when you don't give up equity and build the company on your own. This is usually a pre-requisite for getting investments, especially for first timers without a track record. How do you do it?
- Moonlighting - recommended if you're single
- Consulting - How many slots do you need to support yourself? Fill them all and then as you get customers for your product, fill slots with your own product work. Tough because clients have to take priority.
- Loans and grants - Banks are risk averse, but some companies do start this way. Find a grant that you can do and work on it and your idea.
- Customers
- Yourself and family
Bootstrapping has the advantage of letting the company grow at it's own rate. Bootstrapping is the way to go if you aren't after the model that investing requires: liquidity event in 4-5 years. Bootstrapping is hard. You're worried about money all the time. Funded competitors may be able to move more quickly. Still, do it unless you absolutely can't.
Investments: Types: angel ($25-500K), venture capital ($100k-5m), funding round (selling private shares).
Angels are the least onerous. They can often be big supporters. On the other hand, they're getting more sophisticated and requiring more terms up front.
VC's want control and that can be tough. You could be fired from your own company.
For a funding round, you have to agree on an evaluation, pre-money and post-money, and a share price. Marc points to this article from feld.com for more information on how the math works.
There is a very simple trick to getting VC money: don't need the money. If you don't need them, it drives them crazy and they will call you and ask for meetings. If you're needy, it implies that you're desperate.
Metrics: 10 face-to-face pitches yields 1 term sheet. One term sheet yields on round of financing. From pitch to term sheet on average is two months. Signing the term sheet to "going to contract" (and getting money) is one month. The total time is 4- 12 months.
What you need: 10-15 slide Powerpoint presentation (pitch deck), executive summary (2-3 pages), and an introduction to a VC.
The best pitches are plainspoken and entertaining. Never let on that you're keeping a secret.
Marc shifts into strategy:
Identifying demand: Marc's company competes with Quicken (and lots of other online apps), so what problem exists that Quicken doesn't meet? Marc noticed that Quicken wasn't a high priority product from their public filings. This led him to believe that there might be unmet demand.
Room to grow: What has changed that allows your start up to take a position that didn't exist before? For Marc, what changed was OFX, a standard for getting data from banks, started to get a real uptake in adoption by banks.
Market shift: Another place for start ups is a place where the market has changed. Virtual workers and the Internet are two examples that Marc relates.
Solve a problem: Some successful companies can simple mitigate a problem, but most need to solve it.
Fly along the bottom: be the cheapest solution in your segment. Being the middle solution puts you in a position where you're getting feature pressure from the top and price pressure from below. Not a comfortable position. Be on the top or the bottom, but not in between. For Web start-ups, the bottom's a great place to be.
Paying equity: The good thing about paying with equity is that you don't have to raise money. The bad part is that people who work for equity have to get money from somewhere, so they get distracted. Equity is the most expensive thing you will ever pay with, but it might be all you have.
Launch an idea: The moment something's working, get it out and let people bang on it. This is a great way to get feedback. Marc didn't do this with Wesabe, because he wanted to get certain features (community oriented) working to differentiate Wesabe from other "Quicken on the Web" products. You can only make a first impression once.
Publicity: Don't buy Google Ad words, fly people around, etc. Get a good PR person--they can get people writing about you and that's a huge payoff.
Support pipeline: Marc answers 80% of the customer support emails that come into Wesabe. For a startup, customers who write to support are the ones who care about you and will give you good feedback. Customers who write for support are the ones who are already committed. Pay attention to them.
Viral: How do your current customers lead to new customers? How can your product sell itself?
Kibo: get a name that isn't already a popular word on Google. You'll be able to easily find what people are saying about you and respond, reinforce ideas, etc. He mentions that if you mention Wesabe on your blog, Marc or his partner will see it (Hi Marc!)
Transparency: Wesabe's CEO's cell phone number is on the homepage. Talk about what works, what doesn't, what you're doing and so on. People like authentic stories. When you're honest about things that go wrong as well as when they go right, people will respond.
Case studies: Marc is finishing up with some case studies of two businesses he's worked on. The first was an idea for helping people get better customer service with tools, collective bargaining, etc. He works through the good and bad points of the idea. He ultimately decided not to pursue this idea because of the negatives.
The second case study is his current gig: Wesabe. Money is the #1 stress in most people lives and the idea fits well with the Web. The biggest resistance to the idea is that people are private about their financial information. Banks are complicated and it's easy to turn into a company doesn't really solve the problems. Ultimately, Marc decided to pursue this idea.
Learning more Here are some resources that Marc recommends:
- The Art of the Start Marc says that he doesn't agree with everything Guy says in the book and it's very VC centric. Still good information.
- Founders at Work - Good balanced view of founding stories.
- Getting Real - There's dogma here, so be careful. The discussions this starts are more useful, perhaps, than the actual content.
- The Ten-Day MBA - You don't need an MBA to start a business, but you need some information. This is very true. I went to a three week executive course at Univ. of Michigan in 2001 and it was very useful.
- The Product Marketing Handbook for Software - more for desktop software than the Web, but useful anyway.
- What the Numbers Say - understand the math you need for business (and other things)
9:43 AM | Comments (5) | Recommend This | Print This
InfoWorld Ends Print Publication
As was rumored last week, InfoWorld announced today that it would end the print side of its business. Its sad for those involved and apparently, many didn't know until it came out in rumors.
On one hand I'm surprised, as you always are, an on another I'm not. Let me note that I'm a contributing editor at InfoWorld, which means that I write for them, but I have no inside knowledge Heaven knows I wasn't consulted on this. Even so, it doesn't take a rocket scientist to see a business where more and more of the revenue comes from the online side shut down the expensive business of manipulating and shipping atoms around.
Nevertheless, this will change the InfoWorld audience and limit some opportunities to reach out to different groups. When I was Utah's CIO, InfoWorld just showed up and was on my desk. Occasionally I'd pick it up and read it. It quickly became one I sought out to read because of the focus of the articles on issues I cared about and the quality of the writing. That kind of interaction is different in the online world. You have to convert search-engine drive-bys into readers.
Steve Fox, InfoWorld's Editor-in-Chief has said that very few layoffs will occur since most people will simply work on the online version or the events side of the business (a big focus lately). I suspect those let go will be people who's expertise is in Quark and other "print-only" skills.
While I'm sad about the demise of a print publication I'd come to love. I am interested to see how this experiment works out. C|net, has shown that online only can be a good model. I've worked closely with many of these folks over the last 4 years and come to respect them very much. They're smart and committed. I'm sure they'll do well in the new venture. I wish all my InfoWorld friends good luck!
Bonus links: See Tim O'Reilly's post about the problems at the San Francisco Chronicle and Dave Winer's followup. Newspapers are going to have a much tougher time with this kind of transition than companies like InfoWorld who have been moving more and more of their revenue stream online for years.
9:02 AM | Comments (1) | Recommend This | Print This
March 23, 2007
Novell Demos InfoCard Selector for OS X and Linux
I just put a story up at Between the Lines about the InfoCard selector that Novell demo'd today at Brainshare. Very cool stuff.
3:36 PM | Comments () | Recommend This | Print This
Utah Stories
Richard Markosian is the creator of a Web site called UtahStories.com. I love the idea and I love the execution. The site hosts a collection of short video documentaries about current events, people, and history in Utah.
There's a menu item called "Tell Your Story" that is "temporarily unavailable" so I'm not sure what the model is for user submitted stories. I'd love to see a way for podcasts and video to co-exist on the site.
3:13 PM | Comments (1) | Recommend This | Print This
Authorization Models and Delegation
I promised yesterday that I'd talk a little more about our discussion on delegation. I've since had a profitable discussion with Devlin and Bryant as well.
The problem with delegation is that it requires something that has eluded organizations since computer security first became an issue: how do you build good authorization models? Most applications are built without much prior thought to the authorization model and then it gets slapped on afterwards. For organizations, it's even worse. The business has fuzzy ideas about authorizations and they change them all the time. "Oh, we're spending too much money on catering; from now on VP's have to sign off on all catering requests, in triplicate."
To see why an authorization model is needed for delegation, consider this scenario. I work at BYU and BYU has, in the name of efficiency, stopped giving out paper paystubs. It's all online. Also supposed my wife handles the family budget and needs access to the paystub. I always forget to print them out (and besides having everyone print them on expensive laser printers instead of distributing the paper in the first place is lame). I want to authorize my wife to have access to the paystub. I can't. There's no way to delegate my authority to see my paystub.
Consequently, I break BYU policy and give my wife my NetID and password so she can impersonate me and see the paystub (at least in this scenario). Of course, because she's impersonating me, she has all my rights and can also change student grades, update the 401K, and send a nasty note from me to the University president. Now, she wouldn't do any of those things, but BYU doesn't care that she wouldn't, they care that she might. And so, there's strict policy against sharing NetIDs and passwords, like there is in most organizations.
BYU has set up a situation where their practice (electronic paystubs without a delegation system) sets up situations where people routinely ignore their policy (don't share NetIDs). Of course, BYU isn't alone in this folly. Every organization on the planet has these problems and the increased mechanization of formerly people-based processes is only going to exacerbate them.
Solving this problem for this one instance of delegation isn't all that hard: add a way for me to select any other NetID to also see my paystub. Since almost anyone can get a NetID of their own at BYU (universities are at an advantage here), my wife could get her own NetID and I could select her to see my paystub and the problem is solved.
Solving the problem more globally is much more difficult, nigh unto impossible. After all, I want to delegate all kinds of things: my son to use my bookstore discount, my TA to keep grades, my colleague to update my course calendar when he substitutes for me, my assistant to update my appointment calendar, etc. The list is endless.
You could imagine a bunch of smart people sitting down and coming up with lists of roles, lists of resources, lists of actions on resources, lists of permitted delegations, and then building a big edge-colored, acyclic graph that represents all of this that the various systems on campus could query to get "the answer." Of maybe you couldn't imagine that. I can't. I especially can't imagine them meeting day after day to update the graph as things change as they inevitably do in a community of 50,000 individuals.
This is the same problem that the Semantic Web faces: endless debates about ontologies. Dave Weinberger, working on his Everything is Miscellaneous book, would probably agree that such a task is hopeless. We're likely to end up right back where we are now: building one off delegation solutions
Devlin, Bryant, and I were wondering if there are ways to use folksonomies to solve this problem. Is there an analog for authorization that would work in many cases and allow common usage to define the cowpaths? You'd still need to identify resources and actions that need explicit authorization to meet legal and risk requirements, but is that most things or a small subset? I'm not sure.
10:53 AM | Comments (4) | Recommend This | Print This
March 22, 2007
IEEE's Glenn Zorpette Hits Trifecta at ABM Awards
One of the regular hosts on IEEE Spectrum Radio on IT Conversations is Glenn Zorpette. He just won three awards from the American Broadcast Media for this article on Re-engineering Iraq. He also produced some audio from the piece which we featured on IT Conversations.
I enjoyed both the article and the show on IT Conversations. It's been one of the most popular shows in that series. If you missed it, go back and listen. I think you'll enjoy it enough to want to go read the article.
7:32 PM | Comments () | Recommend This | Print This
CTO Breakfast Links for March 2007
Mentioned at this morning's CTO Breakfast:
- I brought up Twitter. Until last week I'd never heard of it, now it seems I hear about it several times a day. I signed up to play with it. My first reaction is that the Web site is sloooooooooooow. Kathy Sierra wonders if Twitter is too good. The basic question is whether the level of interruption justifies the potential good. I think I'm siding with Kathy on this one.
- Barry Bryson brought is TomTom, a Bluetooth enabled GPS device that ties to the Treo (and other things) and gives you portable navigation support. Looks pretty cool. We all gawked at it and did the geek toy thing.
- Phil Burns mentioned Jott, a simple service that transcribes message you leave on it with your phone to text and emails them to you. I signed up and left a few messages--they came though perfectly. If I could just convince my Mac that they're not Spam now...
- Phil also brought up the Utah Blogger's Conference that will happen June 28 and 29th. Robert Scoble will be there. I'll be talking about podcasting. It should be fun.
- Joey Dempster told me about Open Source Web Design a source for good, free templates and css. I plan to spend some time checking it out.
We had a pretty long discussion about delegation. I'll write about that in another post.
7:08 PM | Comments () | Recommend This | Print This
March 21, 2007
Blistering Blister Packs
Dave Weinberger has a humorous look at the dangers or blister packs, which he refers to as "physical DRM." He includes a list of things that are easier to open, including "an unripe, fused pistachio shell." Wired had a piece on Tales from Packaging Hell a while back which is not nearly as entertaining.
10:31 AM | Comments (1) | Recommend This | Print This
John Backus Dies
John Backus, the inventor of FORTRAN, BNF, and winner of the 1977 Turing Award (read his lecture) has passed away at 82. I tell my CS330 students about Backus and the development of FORTRAN every semester when we discuss BNF (he's the "B" in BNF). As I said when Ralph Griswold died a few months ago, Computer Science has always been a discipline where the founders were still around. That's changing.
10:13 AM | Comments (1) | Recommend This | Print This
March 20, 2007
On Impersonation and Delegation
 An Elvis Impersonator (click to enlarge) |
A couple of my students, Devlin Daley and Bryant Cutler, are doing some work on delegation in OpenID. Kim Cameron has been posting about delegation and that led to some interesting discussions in the lab.
First we distinguished between impersonation and delegation. The former is an authentication issue, the second is an authorization issue. Kim's point, and I think fairly made, is that you don't ever want some one other than the entity to whom the identity belongs to authenticate as that identity.
Rather, you want the entity (be it a service or human) to authenticate as itself and then use authorizations that have been delegated to it. As Kim says, this is the best way to reduce exposure and liability.
Now, back to OpenID. OpenID is nothing but authentication, so any OpenID "delegation" will necessarily be an impersonation. There's no way around it. You can't delegate authority because there's no universal authority model in OpenID. If Flickr accepts OpenID, they'll build their own authority model on top of it.
This, of course, assumes that you're doing delegation at the IdP. The relying party could build it's own delegation service inside of the Web app and it would work just fine. This will be spotty and as different as there are ways of authentication at systems now. Maybe that's the way it has to be.
So, what of OpenID impersonation? Is it "bad" in the general sense that Kim talks about? Yes. But in a relativistic sense, I think it has some advantages that might be worth the dangers. Assume a few things with me: OpenID becomes wildly popular and it's used at lots of Web sites.
You want to give your administrative assistant the ability to make changes to your calendar. The calendar site you use has no delegation mechanism. In the absence of an OpenID delegation (impersonation) scheme, you've got one choice: give your assistant the password to your OpenID (and every site you've used it at) or do your own scheduling.
An OpenID delegation (impersonation) scheme can at least provide you with a method that allows (a) the rights to be restricted to a given URL, (b) the rights to be revoked at will, and (c) an audit trail to be kept at the IdP of when those rights were used.
The biggest hurdle, in my mind, is that there is an ethical problem in allowing anyone, even with good motives, to pose as you. The relying party has the right to know who's acting for who. In many cases they might not care, but in some cases, the replying party is being put at risk through impersonation.
Say for example that you're purchased an account with T-Mobile for Wi-Fi hotspots or a single user account on a Web site. With impersonation, you can spread the use of that license to multiple parties without the replying party ever being the wiser. Sure, people do that with accounts right now, but building it into a system and making it easier to do, with less risk to the user, is problematic.
Should the research be done? Should a paper be published with the ideas? Yes. That's just information and is likely to be useful to others in solving similar problems--perhaps in a way that allows true delegation. But actually building them into an IdP is something that should be carefully thought through. If nothing else, being an IdP that allows delegation might hurt your IdP reputation.