From “Lessons from the Anti-Mentor” (via my folks):
Although I’m not a fan of Digg, I nevertheless appreciate the following quote (originally in Business 2.0 magazine and more recently referenced in ComputerWorld) from Jay Adelson, Digg’s CEO: “A lot of companies are afraid to touch their original technology, to reconsider the premise on which they started the business. But when you stop doing that, that’s when you get lapped.”
Aside: This post is brought to you by the shiny new beta two version of Windows Live Writer. Recommended.
From: Craig Randall
Sent: 5/30/2007 7:45:19 PM
Newsgroups: jetbrains.omniamea.eap, jetbrains.omea.reader, jetbrains.omea.pro, jetbrains.omea.dev
Subject: When will the source finally become open for Omea?Omea Team-
Many months ago Jetbrains announced that Omea was going open source. However, to date the source is still entirely closed. There has been very little explanation about the lack of follow-through (timely or otherwise) concerning progress (or challenges) in achieving the publicly announced goal of making Omea an open source project.
When you read through a significant number of posts since the Omea announcement, it’s obvious that the Omea community is loyal. But all loyalty has its limits, and I fear that Jetbrains is pushing this community to the point of writing off the announcement as vaporous. That is really unfortunate and completely unnecessary. From my correspondence separately with you, I know that there is still passion around Omea (i.e. the core dev’s at Jetbrains).
So, what say you? Can you give your long-suffering community a definitive answer about when you will finally make Omea fully open source?
-Craig
It’s also been almost six months since version 2.2 was released. So regardless of the critical environment around open sourcing your product, you need to convince your community that, regardless of open/closed, Omea is alive and well, receiving its due care and feeding one way or another.
You made Omea free (as in free beer); now, please liberate Omea.
Sincerely, your languishing advocate…
Update 3/14/2008: JetBrains has finally released Omea under GPL v2, and the community can participate in its ongoing development (!!). More in a separate post…
I recently came across the following quote from Abraham Lincoln: “Character is like a tree and reputation like its shadow. The shadow is what we think of it; the tree is the real thing.“
Considering how the passing of the sun, for example, causes a tree’s shadow to change shape (and finally disappear), the President’s statement gives me pause. How much time do I devote to “shadow observation” rather than observing the tree itself? How much time do I attend to my “personal tree” instead of worrying about shadows currently cast by it (i.e. others’ perceptions)?
At the Microsoft MVP 2007 Global Summit held last month, I had the opportunity to hear Jack Greenfield talk about software factories. During Jack’s presentation Sam Gentile essentially remarked that while he understands and uses software factories, he doesn’t understand the point/value of software product lines (e.g. BDUF vs. agile…).
As Jack provided a thoughtful response, I too was thinking about how I’d reply. The following analogy came to mind–from an episode of The History Channel’s “Modern Marvels” show on the subject of assembly lines. (You can view a small portion of the show online here.)
Henry Ford was quite successful in cementing the role of the assembly line in automobile manufacturing. A well-known remark of his is, “You can have whatever color you want as long as it’s black.” And the way Ford tooled and drove its assembly line exemplified this focus. After Ford’s workforce rebelled against the ever-increasing speed of the line and was wooed back by essentially by money, Ford’s customer base increased its demand for customization–even just a change in external paint color. Enter GM.
GM was able to grab a fair bit of market share from Ford by understanding how to copy Ford’s success while also addressing consumer demand for increased choice.
Later, after choice was commoditized (i.e. presumed by the consumer), quality came to the foreground. Enter Toyota.
Toyota dramatically changed the role of the line worker to a fully empowered, responsible agent of quality and process improvement. Instead of increasing production by dialing up the speed of the line, Toyota practiced “kaizen.” Its management reduced available resources by 10% and expected/supported the line to adapt. Quality wasn’t a job–recall Ford’s more recent “quality is job one” campaign–it was a mindset…a workplace lifestyle, if you will.
Now South Korea and its Hyundai corporation are getting into the fray with an emphasis on enhancing quality through robotics and repeatable fine tolerances in manufacturing as a result. A May 2007 Motor Trend article about Hyundai’s recently revealed Concept Genesis emphasized the potential of a car that can compete with a Lexus while featuring a price of a Toyota. Sounds like more disruption to me.
Back to software factories and software product lines…
At its very beginning, Ford represented (just) a software factory. GM represents an initial software product line–harvesting assets from Ford. Toyota represents a later software product line–harvesting assets from GM and from Ford.
Perhaps Ford could have kept GM at bay or out of its market by taking more of a “software product line” mentality from the get-go–similarly, American auto makers and the likes of Toyota and Honda (Japanese auto makers).
Later, another MVP remarked that his essential concern is protection from what is going to change (or from “variability” to reference Jack’s translation of this concern). I believe that a software product line practice can raise visibility here and also to the inverse concern: Where are my fundamental assumptions? What are my invariants and what happens when change happens there?
In the case of automobile makers like Ford, GM and Toyota, history offers powerful examples of why architects should pursue software product lines and understand how they underlie software factories.