Open Source Unleashed

Open source overview 8/27/2008

Here are some interesting tidbits of open source news/updates from the past week or so:

• Red Hat Digital Keys Violated by Intruder - Security. Vulnerabilities in operating systems are nothing new. But let's be real for a second, when it occurs at an open source vendor like Red Hat the underlying assumption is that open = vulnerable. Still, this incident does bring into question the issue of certification as it relates to distribution of open source. I mean, if I download Fedora from Mirror #5 located in Country X, how sure am I that Red Hat, the assumed originator of the binary/source code in question, vouches for the contents of that package at that particular time?

• Does the market really want open options for cloud computing? I tend towards the perspective that open standards/open source sounds like it has more overlap with cloud computing than it actually does, at the current moment. I'm not particularly sure at this stage in the life of cloud computing that there is enough differentiation between a proprietary and open source cloud to drive preference for either. In essence, I think the market is still sorting out exactly what the cloud is about.

• Can Dell capture emerging markets with simplified PCs? I've got to wonder what cultural barriers might play a bigger role in determining if Dell can capture emerging markets. After all, price is only one determinant of success in capturing emerging Asian, African and Latin American nations. The article mentions computing needs, which I think is an apt term on account of the inherent diversity across the different nations in those regions. If the millions of "consumers" who compose these places are simply lumped into the emerging nations category from a strategy perspective, I feel like the results will suffer.

• Where will JavaFX lead?  The question shouldn't be does Sun have a shot in the mobile arena but how will it fit into the picture. How a mobile app space, one that has yet to mature to the point where bona-fide structural characteristics are evident, does not have room for another player is beyond me. That being said, it's also not clear exactly what JavaFX will bring to the table as an Rich Internet Application (RIA) enabler. Granted, the alignment between Java and JavaFX is a great for Java developers who have been left out of the RIA picture while Adobe, Microsoft and AJAX have provided their developers with capable tool sets. However, the JavaFX development kit simply needs to get out there and assert itself as an option before it's place is clear.

• What is Spacewalk?  A summary of what the open source (GPLv2) Linux systems management solution allows you to do might go as follows:
  
  • Perform inventory on systems (hardware and software information)
  • Install and update software
  • Collect and distribute custom software packages into manageable groups
  • Provision (kickstart) systems
  • Manage and deploy configuration files
  • Monitor systems
  • Provision and start/stop/configure virtual guests
  • Distribute content across multiple geographical sites.

Technorati Tags: open source software

Tactical open source for now...strategic open source later?

A corollary to the explosion of open source within the enterprise is it's evolution as an objective. In that light, open source has evolved from remote unknown/curiosity into somewhat of a key IT objective. Still, as I see it, open source continues as a tactical concern instead of a strategic one. By that I mean, it remains a means to achieving strategic IT initiatives such as building service-oriented-architectures (SOA), bringing enterprise collaboration into play or introducing web 2.0. A reality which isn't necessarily bad/good...only indicative of an actual state of affairs.

Listed below are just some of the strategic IT initiatives that open source, as a tactical measure, fuels:

• Enterprise collaboration. Tools such as Open-Xchange and Zimbra, instant messaging platforms like Openfire and Jabber, WordPress for blogging, and TWiki and MediaWiki can help drive the mandate for increased collaboration.

• Web 2.0. Dynamic languages (PHP, Python, and Ruby) along with various open source Ajax frameworks and tools from players such as Adobe and Laszlo Systems all contribute to

• Service-oriented architecture. Open source ESBs: Mule, OpenESB, and JBoss ESB help beat a path to SOA but are also supplemented by other enabling technologies including Axis, ServiceMix and Synapse.

Moving forward, I can visualize open source emerging as a strategic interest similar to, while also remaining a tactical driver for, the aforementioned. This as firms realize the inevitability of embracing open models of interaction and the enterprise software model matures to better accommodate open styles of software development. When this occurs we'll witness more participation by organizations in open source communities, more innovative forms of internal self-support as well as bridges to and from platforms like Microsoft's .NET or SAP's ABAP. The latter as both giants also come to a better understanding of where open source fits into their respective futures.

However, before this takes place there must be more awareness of the open source that is being used on both sides of the equation. For all of the Java based shops out there, I'd be willing to guess that the majority employ at least some open source. And I'd also venture to guess that very few know just how much. Since being aware of its presence will assist in effectively leveraging a larger scope of open source software, it's critical for this to change. The same goes for those companies dealing with suppliers...how many retain disclosure from suppliers regarding the amount of open source that is being used in commercial products? Very few, most likely. This variety of information might not seem relevant but is actually useful within the context of determining the value received in exchange for commercial licenses.

Yet the question of exactly how this transition from tactical to strategic will take place, remains. From my perspective, the increased presence of open source as a tactical mandate of sorts will drive the need for stronger open source governance. Which will further implicate closer alignment of overarching IT strategies with the open source domain. Currently, this link is missing and open source fails to remain relevant from a planning or strategic perspective. All despite the fact that there is definite value to be realized through open source on both fronts. The key will be for organizations to grasp that open source can, in fact, serve as a business accelerator.

Technorati Tags: enterprise strategy |  open source software | governance

On Red Hat moving forward

In order to make good on a seven-year goal to capture 50% of middleware deployments for portals, service-oriented architecture (SOA) and application servers and services, Red Hat has been advocating its "Enterprise Acceleration" initiative designed to help enterprise customers shift the center of their middleware universe to architecture based on JBoss Enterprise Middleware (JEM). Half of all enterprise middleware workloads by 2015 is a formidable goal, to say the least. However, Red Hat has pointed to a growing level of dissatisfaction with inflexible/monolithic proprietary middleware as support for this target. The stated strategy focuses on: expanding the JBoss Enterprise Middleware portfolio, stimulating the partner ecosystem, sponsoring new projects in the open source community and introducing new measures to ensure performance and interoperability.

To be realistic, one major caveat in publicizing this brand of far-reaching goal (time-wise) is the fact that, by 2012 very few will remember, let alone hold Red Hat to it. On one hand the quarterly focused, bottom line Wall-Street types could care less what Red Hat says it's going to achieve 94 months from now...short-term profitability, stock price and market share count for more (plus, this safe harbor provides a good deal of legal shelter). On the other hand, any and all viable players in the middleware market will be setting their sights high for 2015...it's a competitive necessity.

Regardless, a closer look gives reason to consider that the enthusiasm exhibited by Red Hat senior leadership and associated week's ambitious goals regarding JEM, might be more than PR wire fluff. Recent activity surrounding JBoss technology indicates that it is, indeed, at the core of a rapidly maturing middleware business for the company. There is also a noticeable fit with the expressed strategic focus associated with the Enterprise Acceleration initiative, serving as early evidence that company direction is indeed aligned with stated objectives in the near-term.

Over the past 6 days, announcements of partnerships with companies like iWay Software, Hyperic and SeeWhy have hit the wire. Obviously the timing was far from coincidental, but it sufficiently backed the commitment to expanding a partner ecosystem that will need to grow by a factor of two or three in the process of meeting the aforementioned Red Hat objectives. Both the iWay and Hyperic partnerships addressed an area that will be critical for the JBoss Enterprise SOA platform moving forward: the budding overlap of enterprise Java and the Web 2.0 generation.

The indelible effect that rich internet applications have had on web-driven application development is practically undeniable. That being said, SOA will encapsulate these realities as it evolves, meaning any and all platforms which claim to tackle this space must do the same. The iWay partnership, in addition to enabling integration with more than 400 databases and applications, strengthens the capability with regards to building rich, Web 2.0-esque apps. The jointly developed management platform project, dubbed RHQ, went live last Thursday led by Red Hat and Hyperic. RHQ will serve as the foundation for JBoss Operations Network v2.0, due in late Spring 2008 and is directed at ensuring that features like inventory, data collection, configuration management control and strong alerting and provisioning is available towards meeting the needs of an increasing array of web-driven enterprises.

Red Hat will benefit tremendously if JEM can mature into one of the key players in the middleware/SOA market, especially in light of the fact that Red Hat Enterprise Linux (RHEL) continues to make headway of its own. As it stands now, Red Hat hasn't been able to effectively cross-sell JEM to as many RHEL customers as was expected by outsiders when JBoss was acquired, despite the fact that those same customers are in the midst of building reference architectures to deliver the applications and services their businesses need. If the gap between JEM and RHEL can be closed without slowing down the latter, the open source enterprise computing stack envisioned by some will be all that much closer to reality. 

The above is particularly interesting since Red Hat's progress as it relates to the above will have a significant impact on how its success story will [continue to??] play out. While the investment community is well already aware that the company has recently experienced a decline in share value, the stock is trading around $18.06 and in highly volatile times, like those today, more than a few will be undervalued. Knowing this, investors will be searching for "bottom feeder" investment opportunities characterized by consistent performance from companies that tend to fly under the radar. If Red Hat can make good by bringing forth the fruits of executing its Enterprise Acceleration strategy the company will develop into an investment opportunity during bearish times. This would arm the company with the ammunition and momentum necessary to seize a leadership position in the tech industry.

Technorati Tags: Red Hat |  open source software | middleware |  JBoss | SOA | Enterprise Acceleration

Kepping an eye on the OSGi

SOA World Magazine is running a well-written, informative article authored by Dave Chappell and Khandero Kand, on the Open Services Gateway Initiative (OSGi) that I highly recommend reading especially if you're a Java developer. While the piece is technical in nature it provides critical insight into some of the changes to application development that are gripping the future of middleware. What's particularly compelling about OSGi is the fact that it readily enables a programming model based on some of the core tenets of Service Oriented Architectures (SOA): dynamic flexibility, agility and modularity. Far too often the aforementioned are thrown about carelessly as buzzwords, loosely interpreted to sell a branded product or service. However, in the case of OSGi they are upheld down to the nuts and bolts of enterprise systems, i.e. the construction of software.

As the article points out, the current generation of Java containers is not well suited to support a fully modular SOA pattern. As a result, the prospect of designing and implementing enterprise systems without introducing issues with cross-dependencies, dynamic loading and lifecycle management is certainly complicated. The emergence of an OSGi container is dead set on changing that reality by enabling universal middleware, an ambitious term to say the least, but one that aligns with the expansion of use of the OSGi specification beyond embedded devices. More than just a catchy phrase, the prospect of universal middleware is made real by an intersection between open standards and open source. And if it can build momentum within the context of an increasingly SOA driven world, look for open source middleware to benefit tremendously as a result.

In essence, OSGi is a step towards agile systems of application modules grouped by business functionality available through interface contracts between services. OSGi provides the component-oriented, container framework that is capable of hosting dynamic services that do not have to be registered programmatically while providing the means to track and react to changes in the lifecyle of a service. In anticipation of the realities rooted in dynamic lifecycle problem, the OSGi/Spring combination has emerged as a solution with Spring providing dependency injection and aspect-oriented programming (AOP). Formerly known as Spring OSGi but renamed Spring Dynamic Modules for OSGi, the pattern of extensibility and freeing developer hands/heads to tackle more complex issues that has characterized the growth of Spring since its early days, has taken root in similar ways. Enterprise developers seeking to further simplify application development have taken to this combination, contributing to the significant industry momentum behind OSGi over alternatives like JSR 277.

In a broad sense, OSGi is at the forefront of a movement towards platform agnostic services that are inherently modular in nature. The result? Container independent services that sit above underlying implementations of OSGi. This is another of level of abstraction meant to enable the service based architectures of tomorrow but also an opportunity for the current wave of open source enterprise technologies, i.e. J2EE application servers and ESB frameworks to establish more traction. If OSGi can standardize one approach to SOA from a Java perspective, the doorway for heterogeneous SOA arsenals over single vendor suites will open even more.

Once players like Oracle/BEA and IBM step to the forefront with OSGi containers, the prospect of creating services supported by a standardized, dynamic deployment framework across the nexus of closed and open source offerings will receive a drastic boost. At this point, developers will be afforded the option of writing with the framework instead of against a product-specific approach to enabling SOA...a tantalizingly real opportunity to take a step forward in the Java enterprise application development arena.

Technorati Tags: SOA |  open source software | OSGi |  Spring | middleware | enterprise systems

Springing forward with Tomcat

Perhaps it was the preceding post Sun-MySQL buzz or the tidal wave of speculation surrounding a potential Microsoft-Yahoo merger that served to overshadow last week's SpringSource-Covalent announcement. However, regardless of its "press index," the merger marks not just the joining of forces by two notable players in the open source landscape but also the synthesis of two technologies (Spring and Tomcat) that have played a sizable role in the evolution of enterprise application development over the past three years. While the Spring portfolio has garnered the lion share of consideration as the new face of enterprise Java development, Tomcat has quietly become a staple in the same arena. And as it stands, finding a Java developer who hasn't heard of Tomcat is like, well, finding one who can't tell you what Spring is. A fact that few claimed to dispute, only that Tomcat has historically played the role of a well-kept secret instead of an up-and-comer.

Still, as the Covalent business model bares witness to, Tomcat has also found a home in more than a handful of data centers. Nonetheless, Tomcat is consistently classed for it isn't as opposed to what it is. Thrown into the same category as a JBoss or even a Geronimo (WAS Community Edition), Tomcat is mostly overlooked as a smaller, not feature-poor open source application server, when in reality it was never developed to be an fully-fledged app server. Yet for those, who continue to associate enterprise application infrastructure solely with the traditional application server, Tomcat isn't ready to approach the holy grail of "enterprise-readiness." In light of the presumption that scalability and uptime is gained through hoofing the app server route, it's interesting how easily accepted that reality that Apache httpd powers countless scalable LAMP apps while Tomcat's ability to do the same for Java apps is barely granted a passing murmur. In actuality, Tomcat continues to be used behind a fair share of non-trivial web application. Maybe not to the extent that its ASF brother has, but certainly proportional within the boundaries of the Java web development.

Still companies with products positioned around the Java web container have taken note of how a significant chunk of their service and support business involves Tomcat-driven applications and infrastructures. Enterprise penetration was certainly high enough to warrant the acquisition of the leading support and service provider for Tomcat to be snapped up, not by a threatened giant, but an emerging open source player, like SpringSource. Perhaps this move will pave the way for a more complete top-to-bottom lightweight stack for Java development similar in composition to LAMP...who knows?

So as SpringSource and Covalent  work towards merging operations under one roof, it will be interesting to note the growth curve for Tomcat as a commercially viable commodity...especially with regards to Spring powered applications. I fully expect an ascertainable jump in decisions to standardize on Spring-Tomcat now that services and support subscriptions are available from a single source. Which might not constitute a direct threat to an Oracle or an IBM per se, but is certainly the source of cohesive commercial momentum for open source in the enterprise.

Technorati Tags: Tomcat |  open source software | SpringSource |  SpringSource | Covalent | enterprise Java

Open source ecosystems and collaboration as the currency of innovation

Thus far I've been able to resist an annually occurring itch to post a set of predictions for the newly minted year. Unfortunately this means I won't delve into how 2008 is going to somehow lead to the dissolution of the proprietary software development model (I don't see the former ever fully occurring) or why a given open source category/product/company is set to become the next world-beater (if I knew that I probably wouldn't be posting on this blog). However, there is, in fact, a noticeable trend which speaks to the how the maturation of the open source model is only one component of the grander evolution taking place within the entire software industry.

After attempting to portray how open source ecosystems can double as platforms, I think its logical to assert that they also serve as organic collaboration networks. Where the more open, flatter structural composition of these ecosystems creates a hotbed for the brand of collaboration that is required to scale in an increasingly "globalized" world. Interestingly, at the core of the seemingly generic term, collaboration, is the seeds for disruptive innovation. Webster's supplies the following as a definition - something (as a device) created for the first time through the use of the imagination. Yet despite the fact that in today's Information-driven world innovation is no longer entirely pursuant to the physical domain, the term continues to be erroneously coined, misused and cliched more than is worth mentioning.

Nonetheless, open source has proven capable of naturally cultivating the germination of disruptive innovation. Perhaps because full-blooded innovation in this current age is synonymous with openness. Simply put, to innovate is to embrace openness and vice-versa, seeing how innovation mandates a high degree of collaboration across the board. And since the relationship between innovation, collaboration and openness is a topic that warrants a dedicated post, at the least, or a book to be safe, it suffices to suggest that if you're not engaged in dismantling barriers to participation you're probably not innovating very effectively.

Yet even as open source has continues to emerge as a reliable method of integrating the principles of openness into the software development model (and the business of software at a macro level) openness doesn't always (more times than not it doesn't) entail open source. So even if the open source development model, in particular, has yet to satisfy the clamoring for radical creativity exhibited by some this doesn't exactly disprove openness as an innovation accelerator, in general. Still, a cogent analysis of how open source has powered disruptive innovation should consider its affect on:

• Software cost-value models. In addition to enabling more cost-effective software to be created, the primary wave of commercial open source continues to shape the consensus expectation for the cost-value ratio's of the majority of software categories.
• Acquisition mechanisms for enterprise quality software. There are countless examples of how open source has contributed to the divestment of monetary barriers from the process of acquiring software used in production environments.
• Investments in the software development process. Direct investment in open source software communities responsible for projects that are strategically aligned with organizational objectives has become a valid option. In addition to the traditional routes of in-house development, outsourcing, third-party customized development and purchasing COTS.

Most classify the above as "disruption" plain and simple, when in fact, it is also a form of rapid innovation...one that just so happens to shift the very foundation of the current status quo. The downstream effect will give birth to a new class of roles geared to leveraging resulting opportunities. In this light, forward-thinking organizations will take advantage of the option to establish themselves as active participants in the open source productive process as opposed to limited inactive consumers of its output (software assets). More of these companies will consider connecting directly to open source ecosystems, engaging and building value collaboratively with the different members therein. In parallel to this trend, leading open source ecosystems will evolve into bona-fide sources of software innovation made possible by a sense of mutually-beneficially collaboration.

Accordingly, I see the following roles assuming new meaning during the aforementioned transformation of the open source model as a productive process. The shift

• Facilitator - The driving force behind the existence of an open source ecosystem. Could be a commercial company or a not-for-profit organization.
• Adapter/Accelerator - Third parties that serve as a form of technology transformers. They account for the bulk of the customizations and indirect uses of open source software. This category is set to swell as open source becomes the engine for new categories of software and software uses. Examples: system integrators, value added resellers, etc.
• Active Contributor - Organizations embarking upon a continuous cycle of IP contribution to an open source ecosystem.

Deutsche Post's decision to enter a collaborative partnership, involving the Swordfish SOA framework, with the Eclipse Foundation is a prime example of such. In this case, Eclipse is the main Facilitator, Sopera an Adapter/Accelerator and Deutsche Post the Active Contributor...not to insinuate that these roles won't be shared in part by all three parties, either. What stands out most is that this isn't a startup looking to attach to the Eclipse gravy train, rather it is the world's largest German logistics company contributing proven, mature technology that has been running for six years. The code initially contained a framework, a messaging plug-in, a service discovery plug-in and a management plug-in...no small potatoes, at all. Meaning Deutsche Post saw, not only, the opportunity to collaborate with Eclipse in enabling the implementation of OSGi-based service providers and consumers, but also the value of doing so as fully open task under Eclipse governance.

Staying on the Eclipse track, we find Boeing contributing code to OSEE. Where the objective is to create an industry-specific framework with a team of Boeing engineers leading the way. Yet the pattern in clear: business needs being met under an open source umbrella using a Connect-Engage-Build approach. When contrasted with mainstream views that interacting with an open source community is the result of goodwill or the mandate to "give as you take," there is a stark difference. These efforts don't mark the good-hearted nature of Boeing nor Deutsche Post, rather they are working examples of a new twist to the notion of traditional IT investments, led by companies which understand that there's more to gain from accepting an actively productive role in open source ecosystems.

Eventually I fully expect a monetization model to sprout around these activities where all participants begin to embrace and integrate these relationships and roles more closely into their business models. Interestingly enough the barriers are hardly technological, i.e. there is a substantial number of technologies at the center of open source ecosystems, but momentum-based, i.e. how much acceptance is necessary to overcome latent inertia.

Technorati Tags: Boeing |  open source software | open source ecosystems |  Deutsche Post | Eclipse Swordfish | OSEE | IT investments

Book review: "Java EE 5 Development using GlassFish Application Server"

Back in October, Packt Publishing (a UK based publishing company specializing in focused IT books) extended the offer of reviewing titles from their open source selection. I accepted and decided on the following two titles:

• "JasperReports for Java Developers" by David R. Heffelfinger
• "Java EE 5 Development using GlassFish Application Server" by David R. Heffelfinger

Today I'm sharing my review of the latter, with additional information, about this and other titles, available on Packt's website.

To be clear, I made every attempt to read the book, having had a background in enterprise software development, from a developer's perspective. Especially considering the fact that the book is aimed at Java developers wishing to become proficient with Java EE 5, who are have some experience with Java. The theme centered on using GlassFish version 2 to develop and deploy applications. Its author, David Heffelfinger, earned a Masters degree in Software Engineering from Southern Methodist University and is currently editor in chief of Ensode.net, a web site about Java, Linux and other technology topics.

Overall I thought "Java EE 5 Development using GlassFish Application Server" was a well constructed publication that can serve as a solid introductory foundation as well as a decent reference for GlassFish powered development. I did think that it could have done a better job of integrating an overarching vision of how GlassFish fits into the concept of a Java EE 5 solution at a higher level. Especially seeing how the book cover contained the text, "From Technologies to Solutions." Nevertheless it contains enough information and examples to provide the type of comprehensive breakdown of the GlassFish architecture that an uninitiated developer needs.

The first chapter spans an overview of, getting, installing and verifying a current version of GlassFish. I thought this could have included a clear delineation of the GlassFish architecture in picture format, to better provide a clear account of its composition. Still, I was able to follow the installation prompts and install GlassFish successfully, quite a testimony considering my experience with other tech books that endeavored to provide installation instructions. The second (Servlet Development and Deployment) and third (JavaServer Pages) chapters were useful even if they probably could have been combined into a unified chapter, if only because GlassFish boasts a number of impressive features that arguably deserve mention/added coverage throughout a book of this nature.

The next two chapters covered Database connectivity and the JSP Standard Tag Library (JSTL). The latter of which I found particularly useful considering how lacking up-to-date, developer-oriented usage-based JSTL documentation is. Interesting enough, Chapter 4 contained a section called Final Notes which contained mention of accepted design patterns related to Data Access Objects (DAOs). I thought that segment should have been longer and duplicated across every chapter in the book. My reasoning is that since application server architectures are implementations of a Java EE specification there is heavy overlap between design patterns and other accepted best practices. It would have been useful to have a couple of paragraphs shed light on that reality.

Chapter 6 (JavaServer Faces) and chapter 7 (Java Messaging Service) were, in my opinion, two of the better written chapters throughout the entire book. The section in chapter 6 about integrating JSF and JPA was a timely cross reference that provided applicable practical insight into pulling the view and model components of an MVC web application together. Chapter 8 (Security) was well-placed but could have used more information about the security behavior of a Java EE container towards providing a clearer picture for developers of what happens in a simple web application. Reading through this chapter was also the point where I realized that it would have been tremendously useful to see a compilation of to the JSR's that are implemented by GlassFish as a reference.

The last three chapters: 9 (Enterprise Java Beans), 10 (Web Services), and 11 (Beyond Java EE) did not disappoint even if Chapter 11 probably could have used additional information about topics, i.e. GlassFish JBI,  beyond the scope of core Java EE. Also, it might not have hurt to make mention of SOA accordant, GlassFish-friendly components like OpenESB in either the last chapter or an Appendix.

If you're considering using GlassFish as the basis of your Java EE 5 development this title is absolutely perfect for scaling that initial learning curve and getting up to speed on GlassFish version 2. For administrators or developers who don't want to reduce the time it takes to get comfortable and productive in the book will be a really big help. It's straight forward and allows readers to really jumpstart their efforts right away.

Next week I plan to post my review of JasperReports for Java Developers.

Technorati Tags: Java EE 5 |  open source software | GlassFish

A pot for Sun's open source potpourri?

After offering informational updates about its progress in the open source realm Sun has signaled that it has made good, thus far, on previously stated intentions to release 100% of their products as open source. Undoubtedly, all three of the open source software projects mentioned in the summit briefing have reached a respectable level of critical mass and are viably relevant from an industry-wide perspective, even if they stand juxtapose to more popular open source alternatives. And perhaps it sounds like I'm pulling punches by reiterating how early it is to capably comment on whether Sun's open source strategy "worked or didn't. Nonetheless, I will go on record as stating that Sun should consider better associating its open source offerings with a larger sense of a cogent portfolio.

Currently OpenJDK, OpenSolaris and GlassFish come off as standalone entities with a similar page look and a Sun emblem and copyright statement at the bottom. To be sure, Sun has made impressive steps in the area of consolidating community look-and-feel, standardizing the set of development tools provided and streamlining a single point of entry. Yet I'm unable to spot where they converge as members of the Sun open source ecosystem. And maybe that's the intention. But in the case of an established vendor like Sun it doesn't hurt to advance a brand-related, quality guarantee even when the community/source code is open.

To be fair, Sun hasn't had the luxury of starting and building a singular project to the point where other, even totally unrelated projects are found worthy by association (an open source mustard seed of sorts, a la the Apache web server). Also, until recently, Sun hasn't been associated with an open source pedigree despite having been active here and there dating back to 1999. Still in order to leverage any kind of cross relevance within its growing stable of open source efforts, Sun must establish distinguishing aspects of an open source approach which reflects the company's overarching strategic perspective.

To use the Apache parallel again, software produced under the ASF umbrella comes coupled to an association with an established level of quality that is rigorously maintained. Users are guaranteed that each software asset produced is done so under the auspices of the ASF's oversight and guidance. Sun would benefit greatly from working towards a similar end, where regardless of the specific variety of software in question, i.e. an IDE (Netbeans) or an operating system (OpenSolaris) there is an indelible affiliation with the overarching Sun-branded, open source software development "philosophy." It's useful to visit the Netbeans homepage and see links to GlassFish and OpenJDK yet that connection could stand to take root beneath the HTML surface

Admittedly, large scale projects like OpenJDK and OpenSolaris are more different than they are alike, which makes it harder to adhere to a predetermined outlook on building a thriving communities. However, each project should bear not just a Sun stamp of approval in name and look but also a distinct Sun-taste. This wouldn't interfere with the development of unique project-specific identities while concomitantly promoting a distinct sense of federation, one which will prove helpful in unifying emergent revenue opportunities under the scope of Sun's business model. Even if it's a complex prospect to say the least.

Technorati Tags: Sun Microsystems |  open source software | GlassFish |  OpenJDK | OpenSolaris