N. Alex Rupp's Blog

May 2004 Archives

TechEd 2004, Day 04

One of the major themes at TechEd this year was how to increase productivity. The marketing slogan was "Do More With Less". Early on, I mentioned how Microsoft's Visual Studio tools give them an edge on the Java community. This isn't because Java can't have tools that are just as good as Visual Studio, but it's because the collected principles that lead to the development of those tools aren't a conscious and explicit focus of our community (at least not from what I have seen).

The principles aren't rocket science either, and once you see them you'll know that most if not all of us are aware of them all at some level, but this is not the same as the explicit, direct focus I see coming from the Microsoft development community. I liken it to our focus on eXtreme Programming or Agile Development principles, of which the Microsoft development community is just becoming aware.

These principles, perhaps better thought of as best practices, revolve around constantly and intentionally raising the level of abstraction in building software solutions, using more patterns and more frameworks for increasingly specific problem domains, grouping software into product lines and using component assemblies and code generation. It isn't any one of these principles that we need to pay more attention to—we must practice them all at once, the way we practice agile development or extreme programming.

The singular end goal of these principles is to identify and develop Domain Specific Languages, high level abstract languages that help us illustrate and discover patterns in our software, in our business processes and in our development practices. Domain Specific Languages can help us write frameworks for dramatically improving our productivity when developing solutions for specific, narrowly scoped aspects of software development.

Domain Specific Languages contrast with UML in that they are highly tuned to a specific aspect of business or development, and they can more easily be used to configure underlying frameworks or generate code for specific families of software components. What I'm talking about here are tools and frameworks for writing software solutions—not just for writing software code. They needn't necessarily be graphic-based languages. For instance, Groovlets are a perfect example of a domain-specific language for abstracting and speeding up the development of Java Servlets.

But Domain Specific Languages should help reveal patterns in the creation of software components, and those patterns should be able to be summed up into even higher level Domain Specific Languages—perhaps a graphic or symbol based language, or perhaps not. The important part is that we continue to explicitly push for more abstraction in our tools, in how we represent the code, business concepts and development processes.

In the session I attended on Domain Specific Languages, quite a bit of time was spent contrasting them with the UML. DSLs can be customized for any problem domain, they can be developed by cooperative organizations or built by single companies and made popular through use before becoming officially standardized. DSLs, because they are more finely tuned to specific problem domains can more easily be used to generate software code, whereas trying to accomplish MDA with raw UML repeats the mistakes of CASE tools. This is not to say that the UML is worthless, though. It is great for quickly expressing basic development concepts and for documenting different areas of development.

No tools are perfect for everything, and DSLs not only acknowledge but actually embrace that fact. DSLs provide ways to express, model and develop very specific problem domains, because at the end of the day, improving business productivity is what computers are for. Can you imagine if a company tried to build a single tool that could be used for working on every aspect of an automobile engine? Or for building a house? There are millions of highly specialized tools for performing every type of job which can be done, and they are all very carefully tuned for their own specific problem domain. Software development tools are no different.

I thought the presentation on this topic was great, and I'll hopefully be able to more explicitly apply these principles as I work on development tools in the future.

TechEd 2004, Day 03

Open standards allow multiple vendors to offer their own implementation of valuable technologies. The Sun and JCP open standards are particularly good at helping small vendors participate in the technology market. Competition makes software cheaper, forcing the vendors to improve the quality of their products and services. Open standards also lower the risk for the end users by at least providing for some common ground between technological platforms.

Microsoft and Sun seem to have much different overall attitudes about the role that Open Standards have to play in the technology industry. Like any tool, Open Standards are good for certain jobs and not so good for other jobs.

At first blush, Sun is a stronger advocate of open, community driven standards. They sponsor the Java Community Process, which allows major and minor players in the software industry to determine the future of the Java language and platform.

Microsoft, on the other hand, seems at first blush to be more monopolistic in their intentions. I've written this myself about them several times in the past. They envision themselves as the ground upon which all of us should build our software. They also see themselves as the thought-leaders of the industry.

In many ways, both of the last two paragraphs are uninformed. From my perspective here this week, both Microsoft and Sun have more in common than might be evident at first glance.

For instance, Sun created its own standards body that allows it to excercise veto power over JSRs in the Java Community Process. This is intelligent, because while the community should be able to (and encouraged to!) inform and influence the future of the Java platform, it should not be able to force that future if Sun thinks it is bad for the technology, the industry or both. This strategy lets the community push for new technologies and come to compromises and agreements with each other, but also lets Sun cast the deciding vote and do what it can to protect the community from itself (let's face it—sometimes we need it). We benefit from community participation and leadership as well as from Sun's unifying vision.

On the other hand, Microsoft has turned their C# and Common Language Runtime specification over to the ECMA and ISO standards organizations in order to show the world that it didn't need to excercise absolute control over the technology. Of course, they hold on tight to their implementations. I was surprised at first that Microsoft would relinquish their specs to a third party standards organization, but I think they knew what would happen if they didn't. They've come under too much fire in the past decade, and I think they've realized the benefit of sharing. Now they can commit themselves to shipping the absolute best implementation of these specifications. But what is the process for moving the technology forward? How do future versions of the spec get ratified and become standards themselves? How can companies and individuals participate in future of the technology? I can't answer these questions tonight. By working through ISO, can Microsoft provide the same unified vision that Sun can with the JCP? Or do we need to worry about dozens of *mostly compatible* CLRs popping up in the next 20 years?

Open standards can serve customers and vendors, but they require compromise from both ends. The alternative, proprietary and closed albeit ubiquitous technology, might lead to a rapid evolution of features, but it also comes with the risks associated with vendor lock-in and a significant limitation on the number of vendors who can participate in the market. Macromedia's Shockwave is a perfect example of this stagnation. Everyone has seen what it can do, but not many seriously consider developing smart UIs on it. I can't say for certain why that is, but my guess is that it's because there are so few tools available for working with it, and not many developers can afford them. In this case, Macromedia might have become too successful for its own (and our own) good.

I was speaking with an IBM rep yesterday afternoon, and I mentioned the tradeoff between open standards and vendor lock-in. He pointed out that in the end, everyone customizes and tweaks out their implementations of a standard technology, and that customers always get locked in to some degree or another. But he insisted it's a moot point, because all the major vendors offer migration tools to overcome the differences, and that lock-in override is just another feature they can sell. The best of these custom extensions can end up driving the future of the spec.

I'd have to say (and I think that the .NET and Java communities would agree with me on this one) that the best model for driving technology forward requires a degree of open standardization and community participation coupled with an executive force at the top to provide vision and leadership.

Fortunately, both the Java and the .NET communities seem to be on this track. Hopefully this trend will help developers from each side play better together in the coming years, and crank out some fine software while we're at it ; )

Now, if only more of the Microsoft leadership could take the two hours to read the Open Source Definition, the Free Software Definition, grok the difference, and start acting like it. Microsoft spent a decade educating news reporters about technology—did they think they were done? They need to realize the role that real Open Source organizations have to play in uniting small vendor communities, driving innovation and enabling small businesses and vendors to get a foothold in our industry. Sun definitely gets the picture, but there are still too many in the Microsoft camp who mistakenly equate Open Source with rabid, viral anti-capitalism, and they're missing out on a very important community resource in the process. Communities of every size are improved when their members work together and form businesses. Likewise, businesses are strengthened when they form communities and voluntarily share knowledge. Open Standards and Open Source licenses contribute to this.

I don't fault Microsoft's leadership for not taking more time to explore and communicate the distinction between Open Source and Free Software. And I'm not just talking BSD versus GPL here—it goes much deeper than that. Most mainstream Journalists certainly don't get it, yet they're the ones writing all the sensational articles about Open Source (who would ever trust a journalist about technology or law anyway?) Most Open Source developers don't even understand the difference. But that's alright—there are many people who do get it, there are books and literature coming out on the topic, and those who have figured it out will be happy to explain the difference to anyone who asks.

Those of us committed to real Open Source development know that we're doing so in order to open up more technological markets to more people, that innovation and hard work in software development should be rewarded, but also that there's much more to business than the bottom line.

Not to imply that Microsoft is completely oblivious to these things—there are some in Microsoft's ranks who know exactly what I'm talking about. Hats off to them, and may they all rise quickly through the ranks. ; )

TechEd 2004, Day 02

I don't know exactly what I was expecting from Steve Ballmer's keynote address this morning. I've never seen the man speak before, or heard his voice. In fact, I haven't even seen a photograph of him that wasn't a decade old. What I did not expect was for Mr. Ballmer to have somehow transformed into a spitting image of my former Governor, Jesse Ventura. They look alike. They speak alike. It threw me for a loop.

Mr. Ballmer has a very strong presence on stage, but it wasn't his presence that really drew my attention during his keynote. It was the contents of his message and, more importantly, the way in which he delivered it that most impressed me.

What I'm about to do might be a bit unfair, and I apologize in advance if I upset anyone, but the only other major keynote speaker from the IT industry that I've ever seen was Scott McNealy, who gave the final address at JavaOne last summer. The more time I spend here and the more I explore the differences between the Java and .NET communities, the more I wish I were going to San Francisco in June, so that I could make back-to-back comparisons while it's all still fresh in my mind. Last year Sun and Microsoft were still embroiled in a major lawsuit, and so of course Mr. Ballmer's speech this morning was more positive and constructive than Mr. McNealy's was last June.

But even so, Ballmer did not lash out against other technologies, or against Sun. He certainly didn't make the mocking of his company rival a central part of his keynote, as McNealy did last June. He kept an extremely positive focus, and stuck to community and technology-based topics throughout the entirety of his address. It was very relieving.

I'll get into the technical and business related contents of his speech in a moment, but first I want to make some important cultural and rhetorical critiques. Mr. Ballmer is a visionary, and he probably doesn't walk in the quite the same world as you or I do.

This became more obvious to me throughout the day. After spending some time in the trenches discussing ideas and technological considerations with different developers and vendors, I've come to the conclusion that there is still a great deal of bitterness toward Java developers among the .NET rank and file. What surprised me most was how the topic of Java, even among and between perfect strangers, always returned not to the technological flaws of our platform, but to the "jerk" attitudes of our developers.

I'll be the first to admit, my flaws are boundless. I've written and said some things in the past, particularly about Marc Fleury and about the Redmond giant, that were deliberately inflammatory and sensational to no constructive end. I know it's a bad habit to get into as a writer, and especially as a critic whose job is to interpret and not to cast judgement. This editorial style certainly doesn't make me a better person, so I've been trying to grow out of that practice. It certainly helps to have people I admire, like Richard Monson-Haefel, acting in an extremely courteous manner toward someone he's slighted. For that, Richard, I'm very grateful.

It's easy to demonize your opponent when they only exist on your computer screen, but it's another matter altogether when they're standing right in front of you. And the whole "tribe mentality" plays into it as well, as it does in software projects, as it did last June when Scott McNealy made his keynote and burned Microsoft. It isn't difficult to see how the rank and file Java developers might amplify this half-playful distain into raw contempt for the .NET crowd. But the "US versus THEM" Napoleon-complex mentality is a luxury we can no longer afford as a developer community. As an American citizen, I can definitely say that political events of the last year have given me pause to reconsider how I conduct myself in public, and especially how I regard and treat my competitors in the public arena. I don't hate these people—I have a tremendous amount of respect for them, even if I disagree with them on technical details.

Which brings me to the next part of my blog for the day. For the last year I've been flirting with the dream of bringing affordable J2EE technology to small and medium sized businesses, and of someday making it possible for small companies to buy affordable, enterprise quality software. That, more than anything, is the reason that I use, study and develop Open Source software. Sometimes I get frustrated by the high cost of deploying enterprise-strength web applications. I'm probably just trying to crack an egg with an axe, but it's the principle of the damn thing that I just can't shake. I'm a small player but I like to think big, and I admire other people with the same penchant. I'd like to be able to deliver big, even to small clients who share my unfortunate addiction to thinking big. What really bugs me is when people I know make tongue-in-cheek comments about how companies who can't afford to pay hundreds of thousands of dollars for J2EE's stability and features don't deserve it. I refuse to accept that only Fortune 500 companies deserve rock-solid code. This totally ignores the market potential and the importance of small and medium sized businesses, and doesn't do much for the reputation of the Java guy.

Today, I saw more evidence of that truth than I was prepared for. Microsoft's development tools are easy to use, easy to learn, and affordable. That is why .NET is so appealing to small and medium sized companies. According to Ballmer, over 50% of IT developers in the country use .NET. These people don't write code--they have forms and wizards for developing just about anything you can think of. When they do write code, they have development tools that actually force them to write unit and performance tests. And from what I can tell, they have tools for writing those as well.

The tools they've got coming out this year will probe their software for security vulnerabilities, and color highlight the areas of their code which they have not adequately tested, forcing them to correct the error before they check the code into the repository. Tools, to amplify their productivity. Tools, to tell you while you're developing if you'll have fatal errors at runtime, thereby easing the testing and QA process. Tools for performance testing components in ASP.NET web applications, to push multiple simultaneous threads through your software, to bootstrap an ASP runtime environment and use it behind the scenes to simulate a live runtime environment. JUnit won't even add a Multithreaded Test Runner to their core API. Tools to design web UIs, built directly into their ASP.NET IDE. More tools than you can shake a stick at.

In the United States, only the pharmaceutical company Pfizer spends more money on R&D than Microsoft does. They've embraced Agile development techniques in Redmond and before long the rank and file will catch on as wel—they will have no other choice. The tools are there to make Test Driven Development ubiquitous throughout the .NET industry. In the realm of tools and ease of use, Microsoft and the ecosystem of small vendors surrounding them have got us outgunned and outclassed.

All of this was running through my mind before Mr. Ballmer even finished his keynote.

BUT—we in the Java community don't claim to be the most approachable or user-friendly development platform in the world. Usability has never been the greatest strength of the Java platform, and I know we're making strides to overcome our deficiency in that area. As I attended various sessions on .NET technologies, especially one about developing web applications with ASP.NET, it became fairly clear to me that we still have a tremendous and important role to play in the future of enterprise computing, of persistent transactional object frameworks, of distributed component frameworks, of ultra robust application servers. We've got a good handful of J2EE app servers on the market already, and more are one the way from JBoss, Jonas and Geronimo. The licensing costs will fall by necessity, freeing up more spending for support and better feature offerings.

Microsoft does not seem to have an answer to EJB, or at least the developers I've spoken with don't spend much time considering distributed component architectures. They're still coaching developers to hand-write their SQL code—the very thing that drove me from ASP technologies back in 2000. "Sometimes it's better for performance to customize the SQL", a gentleman explained to me this afternoon. Agreed, but where is the option to have a persistence engine do the heavy lifting for me? I can always subclass a BMP object to do custom transaction stuff. When the customer decides to change to a different database on a different operating system (yes, it actually does happen) and they've got to rewire their library of data access objects, it will certainly help that the SQL queries are encapsulated into objects and not scattered throughout the application, but it won't save them if they've got 6,000 unique data objects in their system. I'm not saying this to be cruel, or to spit on ASP.NET technologies. It's just my perception. ASP.NET might not be the best tool for that job. Or maybe it is. If so, is it worth the risk of lock-in? If it's not worth the risk of lock-in, does that mean that Microsoft and its employees are all terrible and evil? Of course not. It probably just means we need a two-tiered market, and that things are the way they are for a very good reason.

It always seems to return to two crucial factors: the tradeoff between flexibility and performance, and the tradeoff between vendor lock-in and the inefficiency of committee-governed standards bodies. Is that what this whole long fight has really been about?

Enterprise scale technology is not always necessary. But when it is necessary, when a distributed component architecture is necessary, when you need a Component Transaction Monitor and common server-side component model, does .NET measure up? And if so, is it worth the risk of getting locked in? This is what I still don't know. Critics of Microsoft's MTS technology always return to the issue of vendor lock-in, of the open-ness of EJB as a server-side component model, of the ability of different vendors to implement the technology and compete with each other for performance, features, pricing, etc. If the Sun and Java community weren't as dedicated to sharing the wealth of ideas, of supporting non-profit organizations who want to compete in their CTM market, projects like Geronimo couldn't even exist.

I think that, out of respect for my boundless ignorance, I'll defer any further exposition on this topic until after I've spoken with some more .NET evangelists, specifically the ones who would know about .NET's distributed component architecture capabilities. Also, out of respect for the customers and managers who ultimately must make this decision, I'll just keep looking for the common ground, the higher patterns and the difficult questions, and leave the decision to the people who ought to be making it. Finally, out of respect to the engineers and developers on both sides of the fence, I'm going to try really hard for the remainder of the week to represent the "Java guy" as a fellow developer and not as an outspoken, embittered ideologue.

I will write about this rockin' hotel room, when I get a chance. Hope everyone's having fun out there ;)

TechEd 2004, Day 01

I must admit, it was a little odd being a Java guy walking into a room full of .NET User Group Leaders from all around the country. The abundance of caffeine and general rowdiness of the 75 member crowd helped ease tensions somewhat, and while I got my bearings I took careful note of the group, its dynamic and the subject matter they were covering. What I found was equal parts encouraging and intimidating.

The TechEd conference doesn't start until tomorrow, but there were several pre-session groups meeting today. I had the good fortune of being invited to the User Group Leaders Summit, where I met my hosts, traded good-natured jabs with .NET devotees and talked shop with a bunch of hardcore development community volunteer leader-types.

The User Group Summit was headed up by the International .NET Association (INETA). From what I can tell, INETA User Groups are analogous to the Java User Groups. They're an independent organization, and their founder goes to great lengths to maintain a comfortable operating distance from Microsoft's PR machine, while simultaneously being careful not to alienate them. It strikes me that the INETA groups highly value their independence and don't want to come across as a Microsoft vendorfest to their members. They focus on C# development topics and although they thankfully accept Microsoft's sponsorship, they do maintain a good degree of independence. That's a difficult balance to strike.

What really fascinated me about the UG Leaders Summit was that the .NET Group Leaders from around the country knew each other, had their own community structure, and genuinely seemed to enjoy being around each other. These guys were rowdy. They were having a good time. And it wasn't just because we each got a 30 oz bottle of Tequila at the end of the meeting. People were really positive and nice. This was a slight cultural change for me, because all too often I find the Open Source Java community to be extremely high strung and competitive--sometimes to the point of being vicious. I like to think of the dynamic of our community as an extreme form of tough love. I haven't worked a lot with the Java User Group communities from around the country, and I have an inkling that things are a bit different in those circles than they are in the Jakarta / JBoss / TSS / Bile Blog OS Javasphere that used to form my only umbilical link to our community. (For the record, I don't think this "tough love" culture extends into the Java.net community--the folks from Sun's "shining city on the hill" are pretty amiable).

It was just a different vibe--not necessarily better, just different. I can see more of that in the future of the Javasphere. We live in a pressure cooker, but as the language and platform mature and we continue to carve out our niche, gain credibility in the industry and grow as developers, I think we'll see less of the infighting and more of the cooperation typified by last year's OpenEJB / Geronimo alliance and by the general good will surrounding Java.net.

One surprising thing I learned at today's Summit is that in the last 3 years, INETA and Microsoft have built up a 200,000 to 250,000 member developer community, and they're continuing to push forward, doing everything they can to make sure that .NET technologies take off at the local community level. They're hyperactively heading up programs to develop high school and college students, and they recognize the long term importance of bringing fresh blood into the industry. They are investing time, software and significant amounts of money into their evangelism efforts.

Essentially, what INETA and Microsoft are trying to do is outgrok the ASF on community building. And from what I just saw, they're way ahead of the curve. In their words, "we're trying to get it. You can help us REALLY get it." And by "get it" I think they mean to figure out how to have a successful user community in every city and on every major college campus in the world. I'm speculating, but it's hard not to smell ambition this raw.

The secret to their success as an organization, in their words, is that they focus on "the community and individual developers", something which I think the ASF has been rightly and repeatedly criticised on in recent days. As far as these guys are concerned, "the developers ARE the customers." They put a lot of work into developer-building, mentoring, developer guidance, etc.

Are we sunk? Hardly. We've still got a LOT to contribute to the enterprise cookpot. As far as build environments, unit testing tools and the wide spectrum of ASF licensed Open Source enterprise products go, we're still in the game. We've got tools like AOP, Groovy and Maven--industry altering software products that have thus far escaped the .NET community's attention. I see Open Source enterprise projects like the ones sponsored by the ASF and the Codehaus as the most crucial strategic assets we have if we ever want to bring the Java enterprise to the masses.

But it's an uphill battle. Java suffers from a reputation of being too complicated and too expensive, but that reputation is in my opinion exaggerated. For instance, it's possible that the EJB 3.0 spec committees are spending unnecessary time refactoring the EJB APIs. They're doing this in order to make EJBs easier to develop using agile and test-driven techniques. But the root of the problem might actually lie in the architecture of the major EJB containers. Maybe the "heaviness" of EJB containers prevents efficient container-driven testing. I know there are products available right now that address the need for dirt-simple in-container EJB unit testing, and it strikes me that the EJB spec committee could leverage this technology and devote more effort to things like security and authentication. Microsoft's not going to wait around while we get our act together.

In the end, the aggressive competition between different Open Source Java project teams might turn out to be one of our greatest strengths, if we can manage to keep the competition good-natured, and not forget who it is we're really working for. I pity the .NET outsider who tries to break in and compete head-on with the Groovy team, or the AspectJ folks. We'll see what happens.

Tomorrow I'll write more about my UNBELIEVABLE hotel room, and see if I can get any pictures up. :)

What about a Shockwave Community Process?

This is pure speculation on my part, but what if Macromedia were to assemble a community-driven process based on the JCP that they could use to extend the Shockwave platform and give companies and individuals around the world a chance to have a voice in the matter?

It strikes me that Macromedia could do the same thing with Shockwave that Sun has done with Java. If they did, I have a feeling that Shockwave would achieve the true universal ubiquity they've been pursuing for so many years. I'm not certain, but it seems that the only thing preventing companies around the world from wholeheartedly embracing the SWF platform as the standard platform, and not just the de facto platform, for developing Rich UIs is a perception about Macromedia holding monopoly control over the platform, a shortage of vendors offering competitively priced tools for working with Flash technologies and the attending lock-in fears and paranoia that naturally follow from that train of thought.

So I'm floating this idea out, just to see what people have to say about it. Suppose the Shockwave platform had more vendors developing tools for it, and suppose tool vendors could be involved in steering the future of the platform (of course Macromedia would still have veto rights for any specification requests, as Sun does with Java), do you think the community wants and could support this sort of arrangement?

When it comes to Rich UIs, nothing even comes close to having the market penetration and feature capabilities of Shockwave media. Building an equivalent open platform from scratch would require a massive movement, and probably a decade to achieve the momentum, mindshare and market penetration that Shockwave currently has--it strikes me as a tremendous waste of time to pursue this goal, when the answer lies right in front of us. The largest challenge would be to bring the major players to the table and get them talking. Is it possible?

It's been done before. And I think it could be done again.

Conference Season

Why on earth would I choose TechEd over JavaOne?

Well, I didn't exactly choose TechEd. It chose me. Or, rather, Microsoft did. They've invited me to come to the TechEd conference as their guest and as a community-minded Java evangelist sort of guy. Who could resist generosity like that? I think the Microsoft folks are hoping I'll find something on their side of the fence worth writing home about. And to be honest, I'm sort of hoping the same.

I'm not signing any NDAs while I'm there, and still refuse to install MS Office on my computer. But I am going to hang up my blinders for a week, and devote some serious attention to .NET technologies. If Scott McNealy can extend the olive branch, then I can too.

So, in short, expect some coverage from San Diego. Probably nothing earth-shaking, but you never know. I'll try to keep the topics pertinent to Java vs .NET, architectural styles, interesting patterns, Open Source potenials, integration points, common ground and the like. A few Java.NET fusion topics might give those of you who are going to JavaOne some helpful context.

Open Source Flex alternatives require broad industry support

"When a scientist says something is possible, they're probably underestimating how long it will take. But if they say it's impossible, they're probably wrong" --Nobel Prize Winner Richard Smalley.

In this case they're definitely wrong. Four years ago, while working for marchFIRST, I helped build a Flash-XML-Java driven site for building and configuring skinnable rich media blog sites. We built this for Proctor & Gamble's Tremor.com project.

I've not used Flex, specifically because I would like to bring similar products to the Open Source market. The licensing restrictions for the beta versions were a bit draconian, and I'm careful to avoid potential future legal enganglements when intellectual property law and Open Source software is concerned.

At this time, there is no alternative product to Flex or Lazlo that offers a competitive feature set. Such a configurable suite could be assembled with Flash MX and the library of Open Source J2EE and XML technologies available from the Apache Software Foundation & The Codehaus. The problem with running an Open Source project to build a Flash-XML-based UI framework is that very few Open Source developers can afford the Flash MX development suite, and at the moment, I count myself among them. If a framework of this kind is ever to make it to the Open Source marketplace, broad industry support will be required. However much I'd like to personally fund a project to develop this technology, I cannot at this time, and have no desire to go it alone.

Tomcat, Geronimo, Apache, none of these Open Source technologies would exist for us to use if companies like Sun, IBM, HP, Apple, BEA and the ASF weren't willing to cooperatively drive the standards, share ideas and contribute time and energy to providing the necessary development infrastructure. This strategy has proven to be extremely successful and practical.

The reason we don't have Open Source products for developing Shockwave media is not because the shockwave format is top secret. It's not. OpenSWF.org is a good place to start if you're looking for Open Source SWF editors.

But in terms of features, Macromedia has outperformed the competition and achieved a virtual monopoly status in the marketplace with their tool sets. To their credit they did this by delivering better products to the market before their competitors could. But the perception is that now they dictate the standards, can bring their reference implementations to market long before anyone else and in recent years, as one of my readers recently put it, "they've grown haughty".

The world has been content to rest on their laurels while this happened. Now it seems that Macromedia can charge any sum they want for their products, because they're the only game in town. The prices of the MX 2004 product line illustrate this. Back in 1998, a small business could easily afford a handful of licenses for Flash 3. With Macromedia chasing the high end of the market, what are the little guys going to do?

Communities are improved by the presence of strong business, and businesses are improved when they join together into communities. That's what Open Source is all about--it's what separates us from the Free Software crowd. Unfortunately, the talking heads in the technical press usually don't recognize the distinction, and Open Source gets all the bad press that Free Software rightly deserves. If you check out Gluecode's website, you'll see their motto is "Open for business." I've never seen a better phrase to sum up the relationship between Open Source and the marketplace. (Gluecode, by the way, is my pick for "Company most likely to destroy the JBoss Group")

Macromedia's shown us what's possible with the technology, and they've done a fine job addressing the desires of the market. But there's also a gigantic and growing market for affordable alternatives. If we want affordable alternatives to Flex, then we need to generate them. Any successful effort to bring shockwave products to the Open Source market would greatly benefit from Macromedia's leadership and support.

Macromedia is no bogeyman. They've recently broken their MX 2004 suite into two editions, but they still each cost over a thousand dollars. Their older products aren't getting much cheaper, either.

I am going to be at the Microsoft TechEd conference next week in San Diego. Anyone who wants to meet with me there and discuss the possibility of developing Java and XML driven Shockwave technologies for the Open Source market should send me an email. Any help Macromedia can offer will be welcomed with open arms.

This work is licensed under a Creative Commons License.