So I'm not a courier - SO WHAT!?!?

Portland is a bike town. It wins awards for bike friendliness and what not.

There are also lots of couriers. Lots of them are rather insane and ride on their tricked out fixed gear bikes. These things are sexy bikes - flat out. You have to be either stupid or have insanely strong legs to be able to ride one of these things.

Anyways, as I consistently note, I am wershed up. These dudes aren't. They are cool - Portland gromit cool. If I was cool again, I'd be one of these dudes.

They also have tricked out back packs - you know the kind - all messengered out.

So as you know, I walk to work - it rocks. I recently bought a tricked out messenger bag. It's orange, ginormous and pure bold. And it is water PROOF not water resistent (when you live in Portland, you care about these things).

If you aren't pure bold enough for a messenger bag they have all sorts of other not messing around bags that may be to your liking.

This will conclude the 2007 Portland Snow blog series. I will return to tech blather next time.

Snow results in Chili. Chili results in Hot Sauce. Hot Sauce Results in . . .

Alright so I'm a B-player on hot sauce tolerance, but I still like it.

You need to try this particular hot sauce and you don't have to be some sort of hot sauce meat head to like it.

Marie Sharp - Belize. The one I have is the "Habanero Pepper Sauce - HOT". It is a mix of carrots and habanero and it is delightful.

I oddly had chili with lunch that was average to poor. My beautiful wife then happened to make chili for dinner that was good to delicious. I added some of this sauce to it and it became delightful.

I got a tip on this sauce from the best butcher in Portland a few years ago and am on my third bottle.

Walking to work in the snow in Portland

It snowed a whopping 4-5 inches in Portland yesterday from 5-8 AM.

In a city that does not have many snow plows, this is a problem.

Luckily for me, I walk to work so it was no problem.

Our office shut down at 12:30 PM - this was nice I was able to get things done. The problem with snow days in corporate America is that none of the deadlines move.

I grew up in Michigan - it took over a foot of snow to make anyone even think of shutting school down etc.

I was blathering about this to my co-workers when Ed pointed out that I now get cold when it is less than 50 degrees. In true Portland form, I wear a ski hat if it is less than 50 degrees. And sometimes when it is over 60 degrees. I guess 6 years in Portland has an affect on you. I wish I could say "You can take the boy out of the Midwest, but not the Midwest out of the boy". Or something like that. But at least on this front, it appears that I am being assimilated. Oh well.

SOAP over JMS

Hey, looks like SOAP really does work over any protocol. Well over JMS anyway (not really a protocol). Saw this here and here. I'm sure all of these vendors (I know Sonic does) provide their own proprietary SOAP to JMS mapping. I suppose there is some value in them mapping it the same way.

The chances of me using this? Zero.

With SonicMQ, however, I have happily used their RESTish HTTP Adapter that just maps destination names into the URL & looks for HTTP Headers for any messaging specifics. Want to check for a message? Check the response queue via a different HTTP GET. Certainly not perfect, but can be useful when working with a technology that does not have a richer client available.

I took a quick scan of this document & remembered a Tim Bray post from last year.

I guess I won’t offer any further commentary on the contents of this document. I can’t help but feel for the H/I/I/M staff who are going to have to do the work, and am reminded of Fritz Lang’s immortal Metropolis, where Maria says: “Nobody cared about the slaves who died laboring to raise the Tower of Babel.”

Not sure if they already are (don't see any of their names listed), but it would be nice if these vendors got involved in AMQP. That seems to have some promise.

Why AMQP? Though many networking protocol needs have been addressed, a large gap exists in common guaranteed-delivery messaging middleware. AMQP fills that gap...

What is AMQP? AMQP enables complete interoperability for messaging middleware, both the networking protocol and the semantics of broker services are defined in AMQP.

AMQP Model The AMQP model explicitly defines the server's semantics because interoperability demands the same semantics for any server implementation.

Wire-level Format To enable technology-neutral interoperability, AMQP defines an efficient wire-level format with modern features.

Distributed Caching != JavaSpaces

I have been talking about distributing caching and JavaSpaces lately.

While you can use JavaSpaces as a caching technology because a JavaSpace keeps stateful objects (Entries) in memory and can be persistent (i.e., survive a failure), it isn't necessarily the best alternative.

Conversely, while you could use a distributed cache as a service orchestration engine because it has an eventing model in it & you could hack master/worker on top of it, it probably isn't the best choice.

The combination of a good distributed cache and a good JavaSpaces implementation, however, may be a good combination.

There certainly is overlap & you have to be fairly deliberate in figuring out which tool you want to use for certain things, but it seems achievable.

A distributed cache is likely the best place to store reference data, hard to query data (e.g., from a mainframe), user session data, etc. where a JavaSpace is probably the best place to store transient conversational service state.

It is the combination of these technologies that allows you to avoid the dreaded work in process database.

More importantly, both technologies use Java POJOs rather then XML so you can avoid a lot of mapping complexity (certainly not all) within the core of a large application.

Anyway, I still have a lot to learn, but am beginning to settle on this distinction.

Mobile Code vs. Mobile Data

As I am trying to learn more about Jini and specifically mobile code, I came across this blog post at discipline and punish.

For almost a decade now we've been steadily marching towards mobile data. For many, distributed computing is summed up by the motto: it's just data. But it's interesting to note that, with the (re)(re)emergence of Grid Computing, mobile code is poised to make a comeback. While mobile data allows for a lot of dynamicity in the consumer-side, it's mobile code that lets you deal with major dynamicity on the service-side. When you have dozens (or hundreds, or thousands) of nodes constantly coming and going then highly mobile services really start to pay off. The JINI guys are certainly on to something and question of which approach scales better is far from settled. I suspect in the future we'll rely heavily on both distributed computing styles.

Sounds about right.

Also Dan Creswell is helping to educate me - thanks Dan!

JavaSpaces sans Jini

Apologies to my new Jini friends. I am a neophyte.

I work with and have spoken with a number of people who say things like, "I LOVE the concept of JavaSpaces - I just don't want to bring all of Jini with it".

What they are really saying is they love JavaSpaces - TupleSpaces really, they just can't stomach the mobile code bit. These are not stupid people. Honestly, this includes me a lot of the time.

Most of these people lived through J2EE and wouldn't bet their job on auto-deployment of a .war file or .ear file work - why should we think something more complex (downloading the code) will not result in panic? I remember talking to BEA about their auto-deployment - some engineer said they had something like a 120 page spec on this functionality alone (and it still didn't work).

I could just send Dan Creswell an email, but I've heard this comment so often that I figured I would put it out here for all to see. I'm sure this topic has been discussed before - thing is it still is being discussed.

Dan, others, are we neophyte's just wimps for fearing mobile code?

How hard would it be to de-Jini JavaSpaces?

Is this completely out of the question, stupid, etc.?

For JavaSpaces to see a lot of mainstream usage 1 of 2 things needs to happen IMHO:

1. Educate the neophytes on the power of mobile code. Help them not fear it. Help them to convince their infrastructure and security groups that it is viable
2. Create a JavaSpaces sans Jini (really sans mobile code) version

Update 07-JAN-06 PM - I'm hoping that at the very least some education can occur via this post for me and other Jini neophytes. So I started this wiki page at jini.org.

Simplicity & Integrating with Less Code

I have been on a distributed caching & JavaSpaces kick lately due to the reasons listened here.

I was talking to my co-worker Erik yesterday and we concurred that one of our biggest goals is to come up with an architecture that is as simple as possible and requires the least amount of code.

Coming from my experience with SOA of various flavors and EDA, I have been on many projects that wrote way too much code. The more code the more defects. This is what is so appealing to me about JavaSpaces and potentially distributed caching (e.g., memcached, Tangosol Coherence) (or some of both). In the core of an application it is possible to use these layers as your service orchestration tier as well as your transient data store. This is very appealing as you skip a significant amount of OR and OX mapping which saves heaps of time and defects.

The JavaSpaces API itself is extremely seductive. Lifted from here:

• write: Places one copy of an entry into a space. If called multiple times with the same entry, then multiple copies of the entry are written into the space.
• read: Takes an entry that is used as a template and returns a copy of an object in the space that matches the template. If no matching objects are in the space, then read may wait a user-specified amount of time until a matching entry arrives in the space.
• take: Works like read, except that the matching entry is removed from the space and returned as the result of the take.
• notify: Takes a template and an object and asks the space to notify the object whenever entries that match the template are added to the space. This notification mechanism, which is built on Jini's distributed event model, is useful when you want to interact with a space using a reactive style of programming.
• snapshot: Provides a method of minimizing the serialization that occurs whenever entries or templates are used; you can use snapshot to optimize certain entry usage patterns in your applications. We will cover this method in detail in a later article.

With the addition of JavaSpaces05, there is collection based (i.e., bulk) read, take, and write.

The integration patterns possible with this API are very powerful. Master/Worker, distributed, highly scalable data structures, etc.

It appears that with certain distributed caching vendors, you can achieve some semblence of these patterns, although I am not convinced of that yet, and the associative nature of JavaSpaces (i.e., you use templates containing objects with what you are looking for in a space to find it) is just amazingly seductive.

Love it or hate it, JavaSpaces comes with Jini. To a newbie like myself, Jini takes some getting used to. The whole mobile code bit tends to make people who have lived through J2EE classloader hell nervous. But there are those who say it works fine in Jini. It is a different paradigm and this makes people very nervous.

Maybe what is needed is a mix of J2EE (specifically servlet, JMS, JMX MBeans), distributed caching, and JavaSpaces. Maybe you can use JavaSpaces for both caching and service orchestration. Maybe you should use all of Jini. Maybe there is something else.

From previous lessons learned around persistence in EDA, I am 100% convinced that we need some sort of flexible transient data store (no work in progress database - I beg you!). I see that today as being some form of a persistent distributed cache that requires very little if any mapping code. I also have seen the power of asynchronous integration and SEDA and am not about to give up on it. JavaSpaces and Master/Worker appear to give me that. What other ways are there? Maybe things that I would have considered anathema a year ago like sending objects through JMS for the eventing layer isn't really that awful? I do know that I do not want XML at the core of a brand new system again - again way too many defects with mapping etc. Too slow, too lame. Sure, at the periphery to integrate with services that require it, but never again in the core of the system.

Lots of thinking results in lots of blather . . .

Bottom line, I want this to be as simple as it can be and I want to write as little code as possible. Oh and it should scale like the dickens, be simple to specialize, maintain, etc.

2007 Predictions

I promised last week to post some predictions for 2007.

Here goes . . .

1. Even the day coders will run screaming from WS-*. The battle is won; we night coders killed it because we didn't want to be controlled by vendor-pires and it is fundamentally flawed technology. Sadly, even though I believe that it is dead, it will take 2 more years before the industry echo chamber comes to terms with it. Software vendors who are heavily invested in WS-* will spend 2007 doing two things: one last gasp at making WS-* happen and quietly writing their Plan B MRDs.
2. REST usage will increase in lieu of WS-*, but it won't unseat messaging and other middleware.
3. People will settle down a tad about Ajax. It's great and all, but I've been seeing more and more botched impls. Like just about everything, its just a tool not a dogma.
4. XML will finally be considered one tool in the tool chest just like every other technology. Development teams will only use XML where it actually adds value and not force it into places where it does not belong.
5. The virtualization march will continue.
6. Distributed Cache and JavaSpace usage will accelerate as more people grok the power of this architecture style.
7. Apache River will breathe new life into Jini/JavaSpaces. Both will see lots of new interest and implementations. 2007 will be a "rebuilding year" (as they say in sports) - 2008 will be the big year for a Jini/JavaSpaces come back. Someone from Sun will formally apologize to all the people maimed by J2EE in 2009 and acknowledge that they should have marketed Jini as a service technology from the beginning (ok just kidding that isn't going to happen).
8. The Open Source patent war will begin in earnest.
9. Community Source Software will slowly start to take off in industry verticals as more executives grok the possibilities and come to terms with the fact that they are already sharing industry vertical software with their competitors; they just don't have access or any control of the source code. Look for a success or two in 2007 which will set the stage for a pandemic by 2009.
10. Even more smart people will start blogs or at least start reading blogs which result in even more transparency and open collaboration between software vendors, customers, and consultants and ultimately better software, more innovation, and less waste.

Alright, that is all I have . . . mostly just a bunch of blather, sorry. I am very excited about 2007. Should be an exciting year to say the least.

SBA & EDA Lessons Learned

I am still getting my head around SBA (Space Based Architecture)/distributed caching patterns.

I have a ways to go, but the more I read about it (blogs, docs, specs, etc.), talk about it with my insanely smart co-workers, and do stuff with it (hands on) the more I like it.

Like most humans, my mind works quickest when I can associate concepts. As I have mentioned before, I see a lot of parallels between SBA and EDA - specifically Message-Centric EDA. Last Spring, I did a series on lessons learned from an implementation of what I consider Message-Centric EDA. I'm going to pick out a few notable differences that I have noticed so far that makes SBA extremely appealing to me.

1. Content Based Routing
   Content Based Routing, Itinerary Based Routing, any service orchestration you can think of other than frightening things like BPM/BPEL are all achievable with SBA. And its done by using the state of your objects, not Topics, XML and all the complexity and angst that comes with it.
2. Choose Topics over Queues
   SBA wins hands down. Instead of mapping your system into using Hierarchical Topic Names including event types and states you put objects into the space and the state of the objects drives the service orchestration (take, notify, etc.). It's insanely simple. This eliminates 2 mappings: system state to Hierarchical Topic Names and Object to XML (and back). In a large system, this results in heaps and heaps of complexity eliminated.
3. Persistence
   No XML shredding in SBA, the space fits the transient data solution I mentioned. It can be configured to be persistent/reliable & in some implementations mirrored, clustered, etc. Getting relational databases out of the transient state business is great for simplicity / flexibility / maintainability / scalability. Again, one less mapping to deal with - only persist to long term storage at well defined states (again based on your objects, not a serialized XML version of them).

SBA basically turns messaging patterns upside down. The patterns are similar, just simpler in SBA. At first look, the SBA versions seem better. Perhaps the grass is greener, perhaps not.

The right answer is probably all of the above / both SBA and EDA. The really hard part is figuring out where to use which in building loosely coupled cohesive systems.

Update 29-DEC-2006 I was inspired thinking about this further on the walk to work this morning . . . I mention complexity and mapping above. Things like object to XML (and back) (OX), system state to hierarchical Topic names (and back), object to relational db (OR), Object to XML (Castor, JAXB, etc.), XML to relational db (XML shredding). Why do you care about all this? I'll tell you why you do. Not having this cruft in your system results in:

1. Hundreds of conversations and meetings that you will not have sorting this mapping out
2. Many design decisions / design details you won't care about
3. Thousands of unit tests you won't write
4. Hundreds of defects that you won't file, ponder, fix, and unit test

Update 07-FEB-2007 Appeasing the "then" vs. "than" police.

Update 22-JUL-2007 As this page is linked to from a Wikipedia page on Space Based Architecture, and gets a fair amount of referrals, I think that I have a responsibility to temper my original comments with what I believe today. I continue to have high hopes for Tuple Spaces, JavaSpaces, and SBA. In my opinion, however, there are not enough viable alternatives today. This is very important to me. I am watching with great interest what will happen with Apache River prior to making any further investment in this technology.

Apache River

Apache River is a new Apache podling (incubated project).

This should be fun to watch.

2007 is going to be fun I think.

"River" is a good enough name - I like it, but then again, I love rivers

Powerbook Rot

Jon Udell complains about Powerbook Rot.

Sadly, I have experienced the same thing with mine.

I drive mine pretty hard because, well, it's a laptop. And my 20 month old daughter pokes at it - maybe that is my problem.

My biggest beef is the power cord. I am on my second one ($100 or so) and it is cracked with electrical tape all over it (fire threat) and barely works. I have to keep one hand on it half the time. Lame. They brag about the magnetics, but I think it isn't durable enough. Next beef is the battery - they go to crap pretty quickly. I think this is just laptop batteries in general though.

Anyway, in general I love OS X. It is the only thing to have your family on. I just think there is some room for improvement around durability. How sweet would a ruggedized Powerbook be? Maybe they have those somewhere.

Annyway . . .

First Turducken

I had my first Turducken Christmas Eve.

It was delicious.

Here is a picture of it.

Yes this is ridiculous, but don't knock it until you try it.

We didn't do the hard work of assembling it. We just bought it at my wife's childhood butcher (and now my sisters) and baked it. The truly experienced apparently deep-fry them.

2007 Predictions Starting

Here come the 2007 predictions. Who doesn't like these? Perhaps we need another round of blog tag on that ;)

Patrick Logan has one that I'd like to see come true. I'd at least like to see a good hard look at it. I've lived web services, ESB, EDA, and they all have their issues. I'm sure Jini/JavaSpaces has its as well, but perhaps the best of all of them is the right fit (ok REST not web services).

As the industry comes to term with the failure of WS-* we can either start over and reinvent things again or perhaps take a look back at some of the technology that should have been front and center to begin with.

I will post my prediction next week.

VMWare for OS X

The virtualization march continues . . .

VMWare has an OS X beta.

Saw this on Matt Raible's blog.

Jini Red Pill

My point is, that all this JBI/BPM/Web Services/'Lets Ra-ra-ra about RoR' is what you get and what you accept when you take the Blue Pill, so the thing is why don't you have a go with something different, could be anything (for those that have never tried Jini but have even a slight interest in SOA, have a look it doesn't bite). Follow your enthusiasm, you'll never know where it might take you. Take a chance - take the Red Pill

I like all references to the (now) eternal Red Pill. I loves the Red Pills. They keep me spry and handome.

I also like all things and people that are wise enough to diss JBI/BPM/Web Services in one sentence. Now that is a skill.

Mind you I have heaps to learn about Jini and JavaSpaces. Just saying I like this sentence.

All I know is WS-* is dead, REST doesn't cut it for (a lot of) the stuff I do, and I know enough already about the problems with ESBs and Messaging. I want some new problems to deal with. Or at least I want to fix a couple problems. No idea where it will go at this point.

I will say that I am going to be really pissed at Sun if Jini does turn out to be great. I mean I lived through 5 years (5 years!!!) of J2EE - all of it - even CMP!! If Jini is heaps better and Sun put me through that misery just because they totally botched the marketing campaign around Jini then I'm going to be a little upset.

Blog Tagged

Patrick Logan blog tagged me.

You are supposed to share 5 little known things about yourself.

Update 15-DEC-2006 Patrick Logan wondered why I didn't take the time to explain my nickname, "fuzzy" and "panic" (i.e., Panic From Fuzzy). So I'll work it into my five things. Just a warning - it isn't very exciting.

Here are my 5:

1. Probably the best thing that ever happened to me was being "held back" (i.e., failed) the first grade. I was just a late bloomer. But who knows what would have happened if I continued on when I wasn't quite ready. I give my parents *a lot* of credit for letting me fail at lots of things when I was young. They also encouraged me to pick myself back up. Based on my experience, I think the best thing parents can do is let their children fail. It teaches them resilience. If they don't fail when they are young they will not know how to deal with things that are hard when they are in the real world. If they aren't failing once in a while, you aren't doing your job as a parent.
2. In high school I played hockey, tennis, and soccer (for 1 year). I liked hockey best. I quit soccer to play hockey more (I had some catching up to do). I was an average player. Getting up for 5:30 AM ice time was very good for teaching me work ethic. I received the nickname "Fuzzy" on my high school hockey team. No particular reason - you know how nicknames sometimes just stick. My Dad calls me Fuzzy and me friends from college and high school do as well. I basically stopped it once I entered "the real world", but it has seen a resurgence since I named my blog this (go figure).
3. I attended The University of Dayton. It is a Catholic school. The brothers there are Marionist and their philosophy is to "Promote quality education of the whole person". This worked well for me. I studied a lot, but also "socialized" a lot. I really enjoyed my years at UD. Today I am not that into organized religion. But I am still a spiritual person. I need to figure out what to do about this in the next year or two as my child grows. I want her to be spiritual too. I might go religion shopping or I might just go to a Catholic church.
4. I got a C in my first computer science class. Programming was very hard for me at first. You may laugh, but the concept of loops *blew my mind*. I remember sitting in my professor's office telling him how hard I was working (I was) and having him say that computer programming isn't for everyone and maybe I should hang it up. My resilience kicked in here and I eventually got it. I am very glad I stuck with it because I really love what I do for a living. The term "panic" came from UD. My friends and I were very into lingo (using clever word plays etc.). For whatever reason, the word "panic" was used often. I still think that it is a very versatile word and that it is applicable to heaps of "real world" situations.
5. I love the outdoors. I hike and fly fish as much as I can (less since I had a child 1.5 years ago). My favorite activity is definitely fly fishing. I stop thinking about work related stuff for hours on end when I go fly fishing

Here are my 5 tags: Sarge Dodge, Mike Dierken, Matt Asay, markg, Kris Tuttle

Hiring

So we have some killer jobs opening in Portland, Oregon and Indianapolis, Indiana if you are interested.

The job description is a wee bit enterprisey, but that is just how our CTO talks. He's a great dude and isn't enterprisey to a fault. Very empowered place to work. Come join the fun. Let me know if you are interested (mherrick66 AT yahoo DOT com).

Basically you need to be a digital assassin, a leader, play exceptionally well in the sandbox with all kinds and have communication skills. You know commodity type skill set ;)

You know, like nunchuck skills, bowhunting skills, computer hacking skills..

Update 18-DEC-2006 To apply online go here. It is req# 27179BR. For the Portland job, you need to have some mainframe experience (e.g., VSE, iSeries-AS400, zSeries-MVS). You also have to have IT portfolio management experience. This job has a range of levels that you can be hired in as depending on your experience.

Technologist/Architect Job Description

Serves in multiple leading architectural roles across multiple projects and domains. Role is for the highest level professional ranking within IT. Must be capable of handling an aggressive and challenging workload at the highest levels of quality and throughput.

Responsible for developing business systems plans, roadmaps, and strategies that drive the delivery of software solutions which provide competitive advantage in the three to five year time frame. Works with solution delivery teams to provide direction, guidance, and hands-on mentoring. Reviews and develops architectural models and solution artifacts at both conceptual and detailed levels. Analyses highly complex enterprise wide system, technical, process and product issues to develop strategic direction and transformation plans -- participates in and is responsible for effective execution.

In-depth knowledge of business operations, objectives and strategies; in-depth understanding of global business and technology trends and the financial services industry. Experienced in applying best practices of architecture governance, methodology, and agile methods at both project and enterprise levels. Leads projects of strategic impact. Drives end-to-end life cycle improvements in IT processes.

Must have superior verbal and written communication skills, and have demonstrated application at all levels of business, systems, and executive interaction. Role requires extensive development of materials ranging from proposals, strategies, standards, architecture assessments, research papers, and presentation materials for diverse audiences.

Generally, the following minimum requirements apply: 15 years of related experience; Bachelors or Masters Degree in Computer Science or similar; current mastery of multiple architecture specializations (i.e. information, data, application, solution, integration, or enterprise architecture); current experience and mastery of IT concepts, strategies, software engineering, and modeling techniques.

Candidates will be required to demonstrate proficiency via sample written exercises, modeling scenarios in one or more disciplines, and potentially analytical and/or software engineering tests.

Range of technical skills required include: Information Management (governance, strategy, meta data processes); Data Management (logical data modeling, enterprise warehousing, business intelligence, object-relational modeling); Enterprise Architecture (business and technical reference models, solution architecture, legacy systems modernization, business process modeling); Software Engineering (full lifecycle development, including management, compliance, UML modeling); Network and Infrastructure Architecture; Enterprise Application Integration (mainframe architecture, J2EE middleware, ERP implementation); Enterprise Program and Portfolio Management.

Jini/JavaSpaces & Distributed Caching

We are taking a gander at some space / cache technology and looking at ideal ways to do service orchestration with it in the architecture.

I am fortunate enough to work with Patrick Logan and he has some good questions. He worked for Gemstone a while ago so he knows their are opportunities to hurt oneself if one chooses unwisely.

I like JMS enough, but it has its issues. If there is a better, simpler way to do service orchestration I'm all ears.

Master/Worker with spaces might work. What else?

I like location transparency. It’s neat.

Update 27-DEC-2006 Just tickling your RSS reader - some good comments on this post. Please chime in if you have an opinion. I am becoming fascinated with this topic. There are a lot of parallels between SBA/distributed caching and EDA service orchestration models. I'm spending some time getting my hands dirty trying to get my head around it better.

OSDL Layoff

OSDL had a layoff the other day.

I have gotten to know a number of these fine people. They have been very good to me. I wish them luck. There are some good people left - Mike Temple and Tom Hanrahan certainly know stuff.

I also wish Stuart Cohen luck in his new venture. I certainly share his enthusiasm for it . . . its just a tough nut to crack (speaking from experience).

Not nearly as complicated as sharing code amongst your peers via some predatory vendor (and only having access to the binaries - not the source), but large companies have a hard time groking this. And there are forces that don't want this to happen.

We just need some more success stories . . .

Linux has won - some people just don't get that yet, but it won. Open Source still needs defenders and custodians like OSDL. Patents are obviously the next battle. Diane M. Peters knows a lot about that.

So I don't know if this is bad news or just a blip. My gut says its a blip. Times are changing . . . Linux won - old structures require change.

OSS is crawling up the stack . . . if Stewart has his way, the last big $$ maker will fall next. And then everyone will have to compete on business value rather then intellectual property lock in.

Wouldn't that be nice?