MSFT and Adobe

Well, jeeze, this is going to get interesting, isn't it?

I'm looking forward to hearing more details on "Microsoft is expected to show a new friendliness to the open-source community by unveiling plans to release the source code to a part of its Silverlight technology at MIX 07 next week, according to sources familiar with the company's plans."

Will this be shared source or open source - like with non-MSFT committers and what not?

Update: So I read through a bunch of stuff and I still don't quite "get it". Multi-platform means Winders and OS X? Em, I thought MSFT sold Linux now? No Linux? But Flex runs on Winders, Linux, Solaris, and OS X? Also, didn't find any details on the OSS details - anyone see any?

Just Noting a Political Prediction

Momentary topic change from my enlightening tech commentary/blather. No need to get all bent out of shape on me. I'm neither a Demican nor Republicrat. I don't like either.

Saw this article today on Fred Thompson. I'd just like to note that I told my wife 8 years ago that I thought Fred Thompson would be U.S. President some day and she remembers. So before he declares he is running, I reiterate my prediction - if only so that I can say, "yeah I called that 10 years ago" if he wins. I don't like any of the candidates so far and find it appalling that the election is already in full swing. Not sure if I'll like Fred Thompson or vote for him, but sounds like he'll be a force to be reckoned with. I mean come on - how is Hillery going to compete with: "He plays President Ulysses S Grant in the film, Bury My Heart at Wounded Knee, which opens next month."

I think it is safe to say that it will be good to have a change. But I say that after every election and then nothing changes - just different people blathering.

Quote that I agree with from the article:

"The president Americans want is, in fact, the guy they see on Law and Order: wise, thoughtful, deliberative, confident without the cockiness of George W Bush, urbane yet country. Fred Thompson communicates all those virtues."

I don't care what your politics are - I just think this is the truth.

And I don't care what anybody says, I liked Reagan.

Adobe OSS Flex

Adobe taking Flex OSS the other day made my day.

Here is a good video interview with Adobe product management.

The future is coming!!

It should be very interesting to see the impacts of this.

We started working with Flex a few months ago after trying every viable Ajax RIA framework. We were very reluctant to do this at first as Flex was propietary. There were just too many "pros" to using Flex over any Ajax framework, however. We estimated the cost of development and maintenance of Flex vs. Ajax to be massive. So we went with it anyway.

But now that it is OSS, dang!

Update Changed "We estimated the cost of development and maintenance of Flex & Ajax to be massive." should read: "We estimated the cost of development and maintenance of Flex vs. Ajax to be massive."

Browser with a run-time

Update Mark Pilgrim readers let me defend myself :)!!!

I'm with Patrick on this one.

Mark's tried and true "just leverage the web" argument doesn't seem to apply. Mark is one of my favorite bloggers and I typically agree with him.

Then again, the Adobe person's "“One word; branding”" doesn't really make any sense to me.

Flex and Apollo are compelling because they are essentially a browser with a real run-time in them. Ajax is neat and a great way to incrementally add booya to your in-production-today-built-on-Struts web app (or whatever your equiv is). But Ajax isn't a run-time and most of us don't really want to write our app N times for N different browsers/versions.

But happilly, "in the future", we have greener pastures to look forward to. We can like "do stuff" and not like "bleed to death" doing it.

And guess what? It will run on Winders, Linux, and OS X. And you will write it one time. And test it one time.

Like what Java was supposed to do but wasn't on the desktop and you only get 10 years before people say, "times up, what's next?".

Lean book

I'm wrapping up Implementing Lean Software Development.

I highly recommend it.

The Poppendiecks rock.

It is pretty hard to argue with much of anything they say.

Here is a good video of Mary presenting to Google if you don't have time to read it - it will give you a taste of Lean SW Dev.

Funny Comment

Noticed a funny comment on this post:

Leus said...

To Johnny Prewitt:

John, every time you repeat the phrase "stable and engineering driven environment," God kills a kitten.

Please don't do it again.

10:05 AM

CSI Portland

Nice to see Stuart Cohen's new venture announced. Here is the Collaborative Software Initiative website.

For once, I knew about this and even the name! for 2 months and kept my promise and kept my mouth shut. Of course I have been so busy the past two weeks that I went completely dark and am just seeing it now.

Good luck Stuart! I'd love to see this take off. Can't help but think I played a role in inspiring it :)

Update 22-APR-2007 I wrote this when I was totally fried from a busy week and travel. Now that I read it with a rested mind, I'm even more excited.

Here are some excerpts from the press release:

Former Open Source Development Labs (OSDL) CEO Stuart Cohen today launched a new company that will solve shared enterprise IT problems by bringing together companies to develop software at half the cost of outsourcing. The company, Collaborative Software Initiative (CSI), is pioneering a market-changing process that applies open source methodologies to business communities facing similar IT challenges.

CSI is initially working with industry leaders HP, IBM and Novell to help vertical industries identify and scope projects where collaboration among industry peers can meet requirements quicker and with less expense.

Government and industry standards are driving much of today's software development, prompting IT managers to outsource fundamental projects that require too much time and money. CSI offers a better way, based on more than 10 years of proven methodologies in open source development. This approach, called Collaborative Software, is software developed or acquired by a variety of like-minded companies at a fraction of internal development or outsourcing costs. For applications that don't enable competitive advantage or are associated with non-value added activities such as compliance, Collaborative Software allows business managers to maintain individual control and direction over a project while accelerating compliance, reducing costs and consolidating project timelines.

"Free and open source software principles are carrying the software market forward and putting older, largely proprietary, ways of doing business to the test," said Eben Moglen, chair of the Software Freedom Law Center and pioneer in the FOSS movement. "By adapting these principles to collaborative computing among industries, the CSI is formalizing an important step in the FOSS evolution."

Looks like my 2007 predictions are trending well :)

Specifically, point #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.

Visualize a Ginormous Standard Free Simple World

Saw this on Bill de hOra.

Visualize legacy WS-*. And ginormous industry encompassing standardization efforts for that matter. Could this be it? Could it be the last gasp of this madness? CORBA, J2EE, WS-*, and onto a path of more simple sanity? One can dream.

I continue to be shocked that even today, 6-7 years into WS-* that people still think it is the next thing. I am befuddled by this.

I have been a consultant, software vendor, and IT dude (customer). I haven't been an analyst. I agree with Bill here:

What has happened with WS-* promotion, and what is happening with SOA is bad for the industry, bad for shareholder value. Customers will come to reject the vendor/analyst/consultant triumvirate if it comes to appear to be nothing more than a racket. In effect, that would be a rejection of the entire market. This helps no-one, least of all customers, dependent as they are on software and related services.

Update Patrick Logan and James Robertson say it better than I do. Especially - James. He captures what I loathe the most about the echo chamber and how it defines what is mainstream. It makes very well paid smart people stop thinking - stop innovating - stop looking for a better way. Instead they pick the safe route - whatever the echo chamber is saying - even though it has the highest chances of failure. I hope I never become this - if you aren't risking something you will never get anywhere. And you will be a part of what I think is the typical customer's biggest problem - the lack of the will to innovate and succeed.

Push vs. Pull Systems

Interesting post by Dan Creswell who links to John Hagel.

Update Also see this earlier post by Dan.

I liked this table in the paper.

Talks about Lean based pull systems in manufacturing applied to systems. H.o.t.

Push Programs	Pull Platforms
Demand can be anticipated	Demand is highly uncertain
Top down design	Emergent design
Centralized control	Decentralized initiative
Procedural	Modular
Tightly coupled	Loosely coupled
Resource centric	People centric
Participation restricted Few participants	Participation open Many diverse participants
Efficiency focus	Innovation focus
Limited number of major re-engineering efforts	Rapid incremental innovation
Zero sum rewards Extrinsic rewards dominate	Positive sum rewards Intrinsic rewards dominate

Our Crazy Fugger

Patrick is our resident Crazy Fugger.

I understand him a little more each episode.

I agree with Edward Povazan: A whole parallel computing universe that I, having been on a C/C++/Java path, would not have been exposed to.

I don't know Smalltalk, but have had several enlightening conversations on it with Patrick. If history had played out a little different, we might all be building with Smalltalk.

For me, exploring JavaSpaces has been a bit like what I hear Edward saying - there are whole other worlds out there in software. Some good bits / some bad bits to be sure, but some of the things that didn't catch on in the mainstream certainly should have. There were reasons to be sure - some of them self-inflicted, but the calculus of what technologies make it and which ones fail is far from meritocratic.

Update: Fixing capitalization of Smalltalk from SmallTalk after being vigorously scolded by Patrick :)

Rubber Match

This week is the rubber match between the Space Men and the Flex Men at work.

We've covered a lot of ground in this phase of the project. A lot of it was fighting learning curves and getting infrastructure stood up. We spent a lot of time using Lean set based decision making on what technology we wanted to use. This was good in that we are more confident in our decision, but bad in that it cost time. The good news is we wouldn't have picked the technology we ended up with if we had used a traditional "place your bets early" approach. So it worked. Yay.

It is inevitable yet annoying that the first rev. of any piece of software has to pay the first rev. tax of standing up infrastructure, figuring out methodology, forming/storming/norming/hopefully-performing, and learning rapidly in general.

The team makes its choices (as Sarge would say) and lives with the repercussions. We made a lot of good choices luckily, but we certainly made some bad ones. The bitch of it is you never really know which choices were good and which choices were bad unless they were very right or very wrong. You are always left wondering what if we did this - what if we did that?

And so it goes - here comes the rubber match between the Space Men and the Flex Men. I am using this phrase incorrectly, but I felt like using it anyhoo, so so what!?. It really is the integration week. When we take a lot of reasonably well tested Jini/JavaSpaces code (unit, integration, and FIT) and try to integrate it with Flex code.

For better or worse, we split our small team into two - one focusing on the backend JavaSpaces side and one focusing on the Flex UI side. This was mostly due to fighting learning curves, but was also due to working styles and geography. We wanted to try a lot of things and splitting the team at the time seemed to be a way to cover the most ground with technology and methodology. We'll never know if this was a good decision. But we made our choices.

A team where everyone is skilled in all areas of the system is obviously best. But you can't just wave a wand and make this happen. You have to get there iteration by iteration choice by choice.

Wish us luck this week - the rubber match is going to hurt! :)