Meatloaf
1 small onion or 1/2 large onion
2 cloves garlic
3-4 pieces wheat bread
1 lb. ground beef
1/2 tsp. sea salt
1 egg
Preheat oven to 350 degrees. Chop the onion and fry in a little oil until transparent.
While the onion is cooking, break the egg into a bowl. Then pulverize the bread in the food processor and add to the bowl with the egg. Pulverize the cooked onion and the garlic, and add to the bowl. Mix in the remaining ingredients, form into a loaf, and bake.
(This is a very simplified and scaled down recipe, based on the one in Julia Child's The Way to Cook.)
Tue, 18 Jul 2006I am the media again
Evan spotted it—this is my first week as the new site editor of LinuxWorld.com. That's dmarti@nww.com if you're looking to reach me at work.
Adam Gaffin has a tricked-out Drupal set up over there, so watch this space for what I'm up to at work.
Mon, 17 Jul 2006MLP: negotiating, waste, book swapping
Val Henson explains how to negotiate your salary and benefits (for women, but applicable to others as well).
People of California, stop leaving your old tube monitors on the street with a FREE sign. You're not fooling anybody. Get rid of electronic waste legally, coming to San Jose July 21-23.
Just joined PaperBackSwap.com and had three Laurell K. Hamilton books claimed on day one. Books out: 3. Books in: 0 (but one on the way). Time to clean out the paperback collection.
Evan (I mean, Evan) is trying MicroID.
QoTD: Koby Bahar
"The protective shelters in Haifa are equipped with wireless connections and all Intel employees have laptops, so that hasn't affected work."
-- Koby Bahar, spokesperson, Intel Israel
Fri, 14 Jul 2006Linking projects and markets
Stefan Kooths, Markus Langenfurth, and Nadine Kalwey wrote, (PDF) "Without a price signal, it remains unclear whether development time spent in Project A would create greater utility if spent in Project B. The traditional economic view of software, in which it is a nonrival good among users, therefore only applies to existing software, that is, from an (economically less interesting) ex post perspective. However, whenever the issue is about using scarce resources for the production of new software, competition among potential future users definitely exists if they are faced with the choice of having to do without the new Software A so that the alternative Software B can be programmed, or vice versa (ex ante rivalry). Markets can easily solve this conflict through the price mechanism, while other coordination processes fail in this aspect as they are unable to valuate and consequently compare A and B due to the lack of pricing."
Signal is a good thing. Direct participation by users in peer production is one way to get it, a software deficiency market might turn out to be another, and Seth Schoen pointed me to The private provision of public goods via dominant assurance contracts by Alexander Tabarrok. See also Assurance contract on Wikipedia.
Open source business metrics that sound bad but are
really good
Metric 1: How many person-years of development have you abandoned and replaced with Free code from outside the company?
Why it sounds bad: all that expensive work wasted. Code monkeys don't work for bananas, dude.
Why it's really good: Two reasons. First, Sunk cost fallacy. Second, if people are open-minded enough to kill their own projects in favor of outside software, they're open-minded enough to avoid unnecessary duplication to start with.
Metric 2: In how many languages are you developing new code?
Why it sounds bad: Where are we going to find Haskell programmers?
Why it's really good: Only great, powerful libraries can make people bring in alternate languages. New languages popping up in projects is a sign of healthy exploration, lack of wheel re-invention through the use of those libraries, and productivity.
Metric 3: How many email addresses of technical contributors appear on the web?
Why it sounds bad: The recruiters and spammers are going to eat us alive! And how can we make sure all those people are on-message?
Why it's really good: The biggest transformation in software is the erasure of the line between "the business side" and "the technical side". Everyone needs to know what's going on in the market. And "on-message" is obsolete -- the market already knows the truth about your company from your jobs page, products, and discussion sites about your products anyway.
Metric 4: How many of your employees have left to work for a company that develops or intermediates an IT product that you use?
Why it sounds bad: We want to retain our staff! After all the work we put in training these people? And who are those bastard vendors think they are, anyway?
Why it's really good: If your company does something worthwhile, those people are still working to make the IT products you use do what you want. They're just making the changes further upstream. By the way, congratulations for choosing a vendor that listens to customers in an effective way.
(This is based on a series of conversations with Kim Polese and Doc Searls in preparation for "Why Spiralling Complexity is Good For You", a talk that Kim gave at a 451 Group conference last month.)
Thu, 13 Jul 2006WordPress meets Coral
This looks nifty: Coralize for WordPress If you run your podcasts on WordPress, you can make Coral host the audio.
Is Housing Wealth an ATM for homeowners?
New meaning for Google bomb.
Evan points out the organizational system Do-ocracy. Sounds like how a lot of decisions get made in Commons-Based Peer Production. Rick Moen covers how to mix do-ocracy and democracy, and how not to.
Dave Rosenberg puts an end to the sportcoat with jeans look.
Valerie Henson covers Crash-only software on LWN. "Crash-only design helps you produce more robust, reliable software, it doesn't exempt you from writing robust, reliable software in the first place."
Wed, 12 Jul 2006QoTD: Tim Lee
"Having open source projects in the mix ensures there will always be some competition for the market-leading firm no matter what happens in the marketplace."
-- Tim Lee
(Are open source projects stronger and more capable in a market where the proprietary choices are less diverse? Does all hope need to vanish for proprietary competitor number two—Netscape, WordPerfect—to get a critical mass of Regular Users to take the plunge?)
Getting stuff working
Doc is trying to get EVDO working. Interesting to watch the troubleshooting process that Generation M goes through.
How to get stuff working
1. Read blogs and mailing list posts written by people who are trying nifty products. Search Google and Technorati for product names. Look at devices that people are carrying around at freedom-loving events, and ask how well they work. ("That's a cool camera, does it work with gPhoto?" is a good way to meet random people, too.)
2. Wait for someone to post an "I got (product) working" article that describes something you like, and is reasonably clear and spell-checked.
3. Do what that person did. When you go in to buy the product, reveal as little information about your intended use as possible to the product vendor.
4. If the product doesn't work right away, ask questions on the blog or list.
5. If you do have to call for hardware replacement, don't contradict any instructions that the support person gives you. "Send replacement" is at the end of a maze that includes a bunch of hoops for you to jump through.
By the way, "re-branding" AT&T Wireless as Cingular cost the phone company $4 billion (Advertising Age, registration required). Now they're switching the name back. Will they spend another $4 billion? Advertising consultant Judy Neer said, "To the real techies, they get it and they understand it. But to the average consumer, it's very confusing." She forgot the hate. Where's the hate? That $4 billion came from somewhere. Oooo, Jonathan Coulton ringtones!
(Personally I really wish they had kept "Cingular" so I wouldn't have to type & all the time, but I guess phone company name changes are the biggest dead-cat bounce for the TV industry since DTC pharmaceutical advertising. Maybe I'll just call the company T, since stock symbols are harder to change than brand names.)
Tue, 11 Jul 2006Hardware support models
(Updated: added link to Robert O'Callahan. Original posting date 28 July.)
The old Linux hardware support model, which basically amounted to releasing new hardware and waiting for the Linux developers to figure it out after it's been on the market for a while, is broken.
But so is the old proprietary OS hardware support model of putting software on a CD in a box, knowing that the OS will be updated while that box is being shipped to the store, and the OS running on the customer's system is unlikely to be the same as the one that you tested with.
Keith Shaw hits that one head-on. New security policies restrict some bundled software that must have worked fine when the hardware vendor tested it with a previous OS release.
What all hardware customers, regardless of OS, need is a driver process that recognizes three fundamental facts of life. First, people invent new hardware. Second, people discover security bugs and fix them. Third, if you don't test two pieces of software in combination, they're going to break when the user tries to run them.
I have a lot of hope for the Novell Partner Linux Driver Process. Also, Greg K-H (who works for Novell) comments on Microsoft's WinHEC and compares driver development models.
(Worst of all is the bastard spawn of the two hardware support models that people are now fighting in Linux 3D support. Jamey Sharp and Greg are making me happy about the future of this area, though. Between Intel's push into higher-performance 3D hardware and the r300 project's ATI support efforts, we should have a decent 3D scene soon.)
If you're interested in these issues, and in trying to come up with a driver development plan that works for your company and for the users, check out OSDL's Linux Open Drivers page. Upcoming event: Open Drivers Summit, which should cover some of the same things we talked about at FreedomHEC 2006, along with product management and legal considerations.
Mon, 10 Jul 2006Streaming, trade show, toolbars.
Andy Wingo explains how to stream a conference with Flumotion.
Peter Norvig: Teach Yourself Programming in Ten Years. (And better learn some martial arts...)
Ubuntu's California Team is looking for Ubunteras and Ubunteros to work the booth. Borrow trade show rule 1 from Debian: DON'T SHOW THEM YOUR ASS CRACK!
Jono Bacon takes a new approach to showing tool buttons. Break the rule of "always show lots of tools onscreen as it makes the app look more professional." What does it mean for the next generation of desktop apps? Fewer toolbars, I hope. (Superbrowser!)
Dude...
Dude, you're getting a fire! (via Paul McNamara.) Will the TSA start making you mail your Dell home?
I think that was a ThinkPad I saw in some recent International Space Station photos. Hope so.
Sun, 09 Jul 2006GNOME meets Web 2.0
Jono Bacon covers how to combine the best of desktop and net tools in Remixing how we use the Open Source desktop.
Sat, 08 Jul 2006I thought my lap was getting too warm...
To force the processor to minimum speed:
sudo killall -USR1 cpudynd. Source: cpudyn
FAQ.
QoTD: Eric Schmidt
"Manually searching the Web is not a sustainable model, long term."
-- Eric Schmidt, 1997
(via Doc Searls)
Fri, 07 Jul 2006MLP: employment, parking, spam, publishing
Good things to keep in mind: RESIGNATION/LAYOFF CHECKLIST from Rands.
You ought to be ashamed (but you aren't): discussion of the correlation between corruption and diplomatic parking violations. (I wonder how this correlates to GPL violations and other copyright infringement.)
Two good spam-fighting links from Justin Mason: Hotmail has Many, Many Spamtraps. (via Justin Mason) What if you don't have millions of abandoned accounts? I suppose you could check your logs for spammers doing dictionary attacks, and just use those addresses. Anyway, if everyone created 10 spamtrap addresses per real user, the cost of sending spam would go up ten-fold. (In other news, don't send any mail to timandmelissa@zgp.org.) Also, "arguably, the optimal time to do final filtering might be just before the user is about to read their mail." -- Joe St Sauver (PDF) (via Justin Mason)
The parasitism on scientific publishing that Robert Maxwell started is finally turning around. (via Ethan Zuckerman.)
Ruby entry in the quest toward the goal of AJAX without writing the JavaScript yourself: rb2js (via RedHanded)
McFarlane Prize
Nominate your favorite Australian web site for the McFarlane Prize for "excellence in web design by Australian web developers." Nigel McFarlane did a lot to make web sites work better. My favorite article was this Greasemonkey tutorial.
Wed, 05 Jul 2006One person's prediction market...
Jason Ruspini writes, "Real-money markets whose primary purpose is to reveal information and that provide no significant risk-sharing, capitalization or entertainment value must be subsidized...."
A prediction market is a tool for buying information. Robin Hanson: "The whole idea of prediction markets is that someone who wants to know the answer to a question might be willing to pay to create a market to entice traders to help answer their question."
That's the prediction market from the point of view of the people who want the information. What is the prediction market from the point of view of the people who have the information? If you're a sales rep playing the sales forecasting market, from your point of view the prediction market is an incentive market. Besides your commission, you also earn by helping the market get the forecast right. The money to pay you for that information has to come from somewhere.
So my idea of a software deficiency market isn't really a prediction market at all. It's just a market for, on one side, hedging the risk of having to run software that doesn't do what you want, and, on the other side, a market for selling your ability to make software do what people want. The information is a by-product.
(After reading Chris. F. Masse .COM for a while, I now have a bunch more RSS subscriptions on the subject of prediction markets, so I should be making fewer mistakes like that in the future.)
Technology journalism needs more prediction markets.
Open Source is not a Market Category
Venture capitalists are going for open source software. Good point from Robin Vasan, managing director at the Mayfield Fund: "We don't see this as a space, we're not calling this a category."
Accounting software is a category. Vertical applications have one category per target industry: "restaurant management software" or "radio station software". Open source is a set of norms, on top of which you can build a variety of development methodologies and business models. It's more general than a pure development methodology such as "Extreme Programming" or a pure business model such as "Per-Seat Licensing", but it's not a market category in itself. So it would be a difficult thing to do a magazine or trade show about.
Code monkey like relevance
JP lists some reasons why enterprise immune systems tend to try and reject the implementation of social software".
Here's a missing one: "Not My Department. Social software is nifty, but it's for the Technical Side of the company. We're on the Business Side, so we're going to use anti-social software. So just give me the bullet points."
Why does the half-networked company happen? The blame lies half with the software, half with the company. First, social software for companies has two problems. Problem number 1: Offline. The big cheese is on some conveyance that either doesn't have a net connection, or makes it impracticably slow to use social software on the laptop. Better to work locally and queue up the results as outgoing email.
Problem number 2: interface complexity. The biggest thing that social software can give you is a common repository for the status and owner of tasks that the company is doing. RT is a nice system, but much of the other social software that gets thrown at companies is too complicated to be productive for non-programmers.
Companies trying social software also have two problems. Problem number 1: Setting an example. If you're the big cheese and you want your organization to use social software, you have to use the social software. Mark Shuttleworth, for example, kicked off the Launchpad BTS with Bug 1, assigned to himself. If you answer some other form of communication before you check the social software, people in your organization who want to reach you will start using that instead. And then people who want to reach them will use it, and the social software system breaks down, sometimes within days.
Problem number 2: Ignoring workarounds. Most office workers won't complain about social software, especially if the Official Way to Complain is through clunky social software. They'll try it, and if it doesn't work, they'll just do what they set out to do using anti-social software. Actions speak louder than trouble tickets. If someone is sending out a company phone list as a spreadsheet instead of updating the directory, or big email attachments with 20 recipients start to circulate, think of it as a bug report, only done as a performance piece. What's wrong with the social software? Orkut and LinkedIn show us that social software can be easier to use than anti-social software, so it's not just a question of "people are used to office suites." Business and social software both have some hard problems to solve in order to connect with each other. JP seems to think it's worth it, and I agree.
Meanwhile, Sacha writes, "I don't want to deal with market studies and hypothetical users. I want names and faces and stories. I guess that's why software development or system administration don't really appeal to me as careers."
Sacha, saying that you don't want to be a programmer in the 21st century because you don't want Marketing between you and the user is like saying you didn't want to be a programmer in the 20th century because you didn't like waiting for the operator who carries your stack of punch cards to the computer. The way software development gets organized is always changing. It's getting lighter weight all the time.
The process of making software got three steps more productive, Fred Brooks writes, when programmers went from assembler to higher-level languages, when they went from punch cards to terminals on time-sharing systems, and when they first got pluggable pipes and filters in the Unix and Interlisp environments. After that, programming doesn't get a "silver bullet" of productivity. The underlying problems are truly complex.
But there's a good chance that we're in the middle of getting a whole speedloader-full of silver bullets if we consider the company as a whole, not just the development team. Companies are figuring out ways to use social software to break down the organizational equivalent of the Bicameral Mind. Instead of paying for Marketing to shuttle between developers and users, let the information move through peer production, connection on a basis of shared code and norms, and customer-developer turnover. Good example: Mike Olson gets the most value from open source in the form of direct user "validation of the product's value," Brian Aker reports. Wait a minute—a hacker doing journalism about business in his spare time? Exactly. And all of that is powered by social software.
Want to subscribe to the future? Read Christopher Blizzard, Brian Aker, Greg K-H, Matt Cutts and others. At the best companies, real developers don't have time for "hypothetical users" because they're already getting information directly from real ones. (I'm always looking for more examples of this phenomenon, so hit me with the RSS links, people.) Throwing Marketing in between modern developers and the users would be like starting a restaurant and hiring deep-sea Vestimentiferan worms, which live, isolated from the rest of the biosphere and never eating but deriving their energy from symbiotic sulfide-metabolizing bacteria, to write the menu. By all means avoid companies that isolate you from real users and bury you in Big Dumb Word Processor Documents, but recognize that they're going to get rarer and rarer. The software profitability crunch and the turn towards social software mean that wasteful marketing/code monkey divisions are getting squeezed out.
--
Don Marti
<dmarti@zgp.org>
