Slashdot Mirror

You asked, he answered!

For Slashdot's 20th anniversary -- and the 23rd anniversary of the first release of Red Hat Linux -- here's a special treat.

Red Hat CEO Jim Whitehurst has responded to questions submitted by Slashdot readers. Read on for his answers...


What...
by Master5000

...is your day like?

JW: I can tell you this, no two days are the same. Broadly speaking, I strive to prioritize time with customers, partners, and Red Hat associates above other meetings.

When I'm in town, my day starts at 5:30 am with a run. I'll scan email and the news during breakfast and take my kids to school. My first calls usually start at 8 am as I'm driving to the office. Today for instance, I'll meet with a few members of our Corporate Leadership team. I'll then sit down with our chief technologist to hear what's happening in the Office of the CTO.

I usually grab lunch around 11:30 am. I tend to bring my lunch, but will occasionally head to our cafeteria for a sandwich or salad. In the afternoon, I'll get briefed on my schedule for some upcoming events, which will include meetings with partners, customer panels, press, and analysts. I usually spend a few hours a day responding to emails and coordinating activity through email. I try to get home by 6 pm to eat dinner with my family and spend time with my kids. I'll usually jump back on email once everyone is asleep before knocking out around 10 pm.


The plans for CentOS?
By Anonymous Coward

Now that CentOS has received a more official status in the Red Hat world, what are the plans for the project?

JW: The ecosystem around Red Hat Enterprise Linux is sprawling and complex, and that's one of our strengths. You have midnight hobbyists working together with multinational corporations. You have people working on GPU hardware, and you have people working on Ruby apps. Some want the latest-and-greatest, and some want to keep everything exactly the same for years and years. So lots of different kinds of people are doing lots of different kinds of work, and all of them are contributing to this massive project called "Red Hat Enterprise Linux". It's not surprising that we can't accommodate all of that innovation in a single project.

That's one of the reasons we split Fedora and Red Hat Enterprise Linux: we freed up Fedora to be innovative and move quickly, which freed Red Hat Enterprise Linux to be more careful, more conservative, and handle the very important and difficult work of stability and security for code that upstream communities have long since moved past. Fifteen years later, we're still very happy with how that's worked out, and Fedora remains a thriving engine for new ideas that make their way down into Red Hat Enterprise Linux and many other projects.

CentOS solves a very different problem for us. First, there are some people that we can't serve with Red Hat Enterprise Linux today, but we still want to participate in the Red Hat ecosystem. Folks using Xen, for example, may not be able to run today's Red Hat Enterprise Linux, but they can absolutely work with the CentOS project and still participate in the broader ecosystem. Second, there are people and partners who are building software that needs a more stable, Red Hat Enterprise Linux-like lifecycle but want to experiment at the kernel level, stuff which would be impossible for us to support in Red Hat Enterprise Linux. OpenVSwitch and DPDK are a perfect example of this, and the CentOS SIG process has served them really well. They can do all the things they need to do in development and with their partner communities, and their innovations still pass from the upstream communities into Fedora, and ultimately into Red Hat Enterprise Linux, Red Hat Virtualization, and OpenStack.

Meanwhile, changes in hardware and software are changing how we think about a traditional operating system distribution. Things are more automated, hardware is moving faster and less predictably, and containers force us to differentiate between bringing up hardware and creating a stable platform for applications. To address all of these changes, Red Hat is going to need every element of our ecosystem -- Fedora, CentOS, and Red Hat Enterprise Linux -- to respond.


Systemd, WTF???
by rknop

As I understand it, one of the stated goals was to speed up boot times. It's had exactly the opposite effect on my Ubuntu system -- that is, when the boot doesn't die altogether when I try to mount NFS shares. (Also, thanks to systemd, I can't even *reboot* or shut down the machine when there's a hung NFS process. I am forced to hard-reset it.)

For years, warning flags have been raised about systemd. It more or less seems that we're bringing all the disadvantages of the Windows architecture to Linux, without any of the advantages of running Windows.

So, again: systemd, wtf???

JW: We had a lot of systemd questions, so I am replying to them all collectively.

==========================================================================================================
My question is related: is Red Hat, as an organization, at all concerned about the damage that systemd has done to Linux's usability, its reputation, and its community? Is Red Hat concerned with how systemd has driven so many Linux users to FreeBSD?

................................................................................................

And a follow up, why not spend some of RedHat's money on a sane init system?

I'm sure you can put a few dollars and bright minds on a system that works reliably. The last thing I want my embedded system to do is get hung up on an init failure.

................................................................................................

This begs the question, so I'll just ask it: Have any customers ever moved away from Red Hat because of systemd?
==========================================================================================================

JW: First, allow me to address why Red Hat adopted and invested in systemd as it helps to address many of the other questions. Traditional init systems, like System V init, served the UNIX and Linux communities well for decades, but that is a long time and it is not surprising that they have their limitations. The problems an init system needs to solve today are different from the ones that traditional init systems were solving in the 70's, 80's and even the 90's.

Red Hat considered many available options and even used Canonical's Upstart for Red Hat Enterprise Linux 6. Ultimately we chose systemd because it is the best architecture that provides the extensibility, simplicity, scalability, and well-defined interfaces to address the problems we see today and foresee in the future. Of all the passionate debates and disagreements, the fact remains that systemd is the cornerstone of nearly all Linux distributions on its own merits.

Any change like systemd is going to disruptive. We understand that many were not happy with this change and we appreciate the passion of the community. The continued growth and adoption of Red Hat Enterprise Linux, as well as other systemd based distributions, tell us that most users have embraced systemd and there was not a large exodus to FreeBSD or alternatives. We partner with the largest embedded vendors in the world, particularly in the telecom and automotive industries where stability and reliability is the number one concern. They easily adapted to systemd.

We see new users (both new to Linux and prior SysV init users) who truly take the time to learn systemd embrace the simplicity of the interface and its capabilities. We also hear that it is no more difficult to learn than the complexities of init and rc scripts to a new user. It's simply different.

The Debian community provides a thorough, independent evaluation of the systemd initsystem debate. Additionally, the systemd developers provide a list of the biggest myths around systemd.

There are some real advantages, too. Because systemd tracks processes at the service level, daemons can be properly killed, rather than trusting them to do the right thing. This also makes it easy to use cgroups to configure SLAs for CPU, memory, etc. Likewise, security with SELinux and sandboxing become much simpler. The dependency resolution between services is a significant improvement over the sequential ordering of the init rc script mechanism.

Looking forward to all of the exciting innovation taking place around large cloud scalability, OpenStack, Kubernetes, and Containers, we see continued integration and innovation with systemd that would either not be possible or very difficult with init based systems.

So we'll continue to invest in systemd, as it meets our customer's expectations around capabilities, stability, maturity, and community momentum. There's not a realistic alternative today that comes close in terms of adoption and functionality. That said, we're always watching how projects and communities evolve and in that way, systemd is no different from any other component that we ship.

Lastly, I wouldn't dare to debug anyone's setup here, but mounting NFS at boot time is notoriously problematic if you do not have highly available NFS servers. This is a problem that existed before systemd and I think it's much safer to use autofs to mount those volumes on demand or other mount options such as nofail or nobootwait. It is best to not blame systemd for issues that also affect init or are misconfigurations. Ironically, systemd provides more troubleshooting and debug options than init, so that might be helpful to you.


==========================================================================================================
Why isn't Linux on the desktop more widespread?
by snooo53

I'm curious your thoughts on why Linux hasn't grabbed more laptop/desktop marketshare from Windows and MacOS over the years? It seems that with the privacy concerns around Windows 10 and Apple's lack of focus on MacOS there may be a huge opportunity in the near future. What things need to happen in the consumer marketplace and within the OSS community for it to really take off? Can 2017 be the year of the Linux desktop?

................................................................................................

Why not have a consumer desktop?
by Danathar

Given Ubuntu's success at providing a stable, developed and popular desktop environment for non-technical consumer users, why doesn't Red Hat provide the same thing? Why is that right for Ubuntu but not Red Hat?

................................................................................................

Strategy
by olau

Red Hat is big and getting bigger. Where are you heading at the moment? Would Red Hat ever try to move into the the more consumer-focused places where Ubuntu has ventured, or is that just not profitable enough?

................................................................................................

Why does GNOME have such an unusable UI?
by Anonymous Coward

GNOME is a Red Hat project due to the amount of people and funding they get from Red Hat. Then, why does GNOME have such an unusable UI, particularly to the mayor audience of your products? The UI makes basic tasks such as switching between windows a chore unless you install shell extensions, which break frequently and cause unstability.

................................................................................................

Proprietary driver support
by ARos

Many proprietary hardware vendors continue not to take the Linux desktop and workstation markets seriously. Recall, e.g., Linus's rant against NVIDIA. As a leader in the Linux and FOSS communities, what will you do to persuade major vendors to write and maintain functional drivers for Red Hat Enterprise Linux and Fedora? ==========================================================================================================

JW: We also had a lot of great questions on the Linux desktop - let me try to answer collectively:

A functioning, useful desktop is obviously critical to the success of the Linux community. A nice GUI makes Linux more accessible and approachable, and that's why we continue to make investments in projects like GNOME, Wayland, and nouveau. Everyone benefits from improvements in this area, so let's call that the baseline. The primary driver for that work is in Fedora, and I was really glad to see such great reviews of F25. If you haven't tried Fedora in a while, now's a good time to jump in. Personally, I love it.

Of course, one of the perils of the desktop is that "desktop success" is so specific to each individual, since everyone has their own opinion about what a desktop should or must do. That means that even when we think about our "baseline" investment in the Linux desktop, someone's going to be disappointed. What's worse, it's very difficult to make money on a "baseline," since it's something that people just expect to have in the first place. Nevertheless, we spend a lot of time and money on getting these projects right because it is so important to the broader community and the success of our own products.

There's another category of desktop, let's call it the "enterprise desktop". This category requires features that just don't come naturally through a community, and they need some additional investment. The "enterprise desktop" customers who pay for a Linux desktop want that same functioning, useful "baseline" desktop, of course. They also want things like enterprise management features, security tools, compliance tools, identity management, and even simple things, like the windowing system should scale correctly when it's run in a VM on Windows.

You've probably already read my comments on the future of the desktop, and you know that I think the "enterprise desktop" market is changing dramatically. You can see this in how Microsoft has changed their own strategy. Among other things, tablets and phones are far more important than they were just five years ago. We don't think about the software on tablets and phones as part of our core business, so we've left that space alone. But their influence is still there, so the "enterprise desktop" features people are willing to pay for has changed, and that's has an influence on how we invest our resources.

There's a third category, which is the "technical workstation". These are power-hungry people with domain-specific applications, like 3D visualizations, animation, fluid dynamics simulations, stuff like that. They naturally gravitate to Linux because that's where the tools and research that makes them successful starts. We've had great success in that space, and we continue to make investments here.


How do you monetize Open Source?
by mykepredko

What would you recommend to somebody who feels they have a great application idea and are probably ready to go for angel/first round funding but feels that the application should be Open Source?

Do you put in customization/support as the way to fund the endeavor long term or is there another approach for the OSS conscious entrepreneur?

JW: Open sourcing an idea is great because you will be able to innovate faster with the community than you would by going it alone. There are many, many open source startups doing exciting things, and many with VC backing. So, there is clearly a path for the OSS conscious entrepreneur. Red Hat chose a subscription model for our business; others have gone the customization/open core route. We believe in an upstream first development model, so open core/customization does not work for us. But, there are certainly many successful open source companies that use this model, and the true answer here is that there are likely a lot of variables depending on what your app is focused on.

Most importantly, recognize the value of the open source development model is around user participation. So building a business model around open source starts with a clear, deliberate strategy on how to get others with different perspectives and expertise involved in writing the code. If you don't have others actively involved in writing the code, then it's hard to get the leverage you need for an open source model to work.

Building a new community is hard. We've started a few at Red Hat, but most of the time we look for existing ones that already have a robust community. Where a robust community exists, open source always wins. From a business model perspective, recognize that you can't sell the value of the functionality, because the functionality is free. So think hard about how you add value around that functionality. For Red Hat products it's typically a combination of commitment to a defined life-cycle with the bits, downstream certifications/eco-system, ability to drive upstream roadmaps to meet our customers need, and support.


Open source?
by martiniturbide

What is the current commitment of Red Hat with open source for 2017? Redhat may be the most profitable software company that endorses open source for their products. What is the recommendation for other companies to be profitable and at the same time remain being good open source citizens?

JW: Red Hat's commitment to open source has never wavered. We are committed to having a 100% open source product portfolio, with an upstream first development model. This means that we do our work to get features integrated into open source projects before we integrate them into Red Hat products. Dave Neary from Red Hat's Open Source and Standards team wrote a good blog post about this approach. And we have followed through on this commitment even with the technologies we acquire â" something I think is pretty unique to Red Hat. In the last few months, we've open-sourced Ansible Tower and Codenvy.

My recommendation to other companies: contribute. In the last few years, we've seen a lot of new voices championing open source. That's great to see, even when it's your competitors. Faster innovation and more choice is always a good thing. But, open source is a commitment, not a buzz phrase. Companies that want to be good open source citizens need to walk the walk. Another must-read on Red Hat's commitment here is this blog post from Paul Cormier.


Building a strong company
by resplin

Red Hat has distinguished itself through its commitment to open source and its ability to remain profitable.

Mike Olson famously said "you can't build a successful stand-alone company purely on open source." He argues that you cannot scale an open source model that does not rely on selling proprietary components because it is too easy for competitors to undercut a vendor's services offerings when they don't have to pay for R&D.

How do you feel about that assessment? Is Red Hat's success impossible to replicate by other open source companies?

JW: First off, let me say that Mike is a great guy. I've known him for many years, since I first joined Red Hat. And I want to applaud him for his work in driving Cloudera to where it is today. I'm thrilled to see their success. But in regards to open source business models, we've agreed to disagree.

I'd argue that Red Hat is a successful company by many metrics, built purely on open source. My contention is that too few open source companies follow the Red Hat model. I don't want to overly bash open core models. Some will be successful, but competitively, I'd argue that there's no faster way to innovate at scale than through open source communities. We've said before that half open is still half closed. I think it's too easy for early adopters to find workarounds to open core offerings, which can hurt a business when it moves past the early adopter phase.

I refer to this a bit earlier in the Q&A, but the important thing to remember in an open source business model is that YOU CAN'T SELL FUNCTIONALITY because it is available for free. If you just think about functionality, then Mike is probably right - you need to add proprietary code that you can sell. But implementing a piece of software in an enterprise context is about so much more than the functionality.

Red Hat is successful because we obsess about finding ways to add value around the code for each of our products. We think of ourselves as helping make open source innovation easily consumable for enterprise customers. Just one example: For all of our products, we focus on life-cycle. Open source is a great development model, but it's "release early, release often" style makes implementing it in production difficult. One important value we play in Linux is that we backport bug fixes and security updates in supported kernels for over a decade, all while never breaking ABI compatibility. That has huge value for enterprises running long-lived applications. We go through this type of process against all of the projects we chose to productize to determine how we add value beyond the source code.

I would agree that this type of business model won't work across every technology category. At Red Hat, we look very deeply at the categories we've expanded into to ask ourselves whether our model can be effective and make an impact in a given space.

What advice do you have for building a sustainable business, especially one that is driven by open source values?

JW: Start off by reading a couple of answers above. To summarize:

1. Start (or find) an open source project that truly benefits from broad participation and work to build (or become involved) in that project. Projects where participation benefits the quality and innovation of the code are inherently advantaged over proprietary code. So you can check the first box - a technology that is superior to competitors.

2. Identify how you can uniquely add value to that technology that transcends the code. This is what I talk about above. The code is free. It's better because of yours and others' contributions. But those are freely given and free to use and therefore are very hard to monetize. Focus on how customers might implement the technology. For Red Hat, we like layers in the stack that are run-times, where enterprises will likely want long-lived support. We also like layers where hardware touches software, because there is huge value in standardization and certifications, which are not attached to the code, but to the products that we rigorously test and build joint support mechanisms for with the hardware vendors. If you identify this, you are well on your way - you have a project that is superior to competitors' and you have a vehicle to uniquely add value to that project in your product.

3. Surround yourself with like-minded, passionate people. Culture always trumps strategy. That's a short paraphrase of a famous quote. Companies too often fail because of internal strife, ethical failings, or simply losing their way. I know that startups have to begin with a product and business model, but durable success happens via people working together to make it a reality. And that's all about culture and leadership.


Recruiting open source talent
by resplin

As Red Hat has scaled, it has to remain staffed with all types of non-technical business professionals. How do you help these professionals learn to "sell free software"? Has it been difficult to train these professionals on the open source business model?

JW: I think that anyone can pretty easily put themselves in our customers' shoes and understand the benefits of open source. For one, no one wants to feel locked into a proprietary solution or data format. We all want choice and flexibility, and open source is a great way to enable that.

For another, everybody wants access to rapidly innovating technology that helps solve their business problems, and our model gives them the ability to consume the latest and greatest technology, but in a way that's stable and secure for the enterprise.

And finally, everybody's experienced the frustration of having something in their car break and not having access to fix it. It seems like many companies deliberately make it difficult for their customers to tinker with or improve their products. Open source is the exact opposite -- we welcome people to take a look under the hood, see how things work or why they're broken, and roll up their sleeves to contribute if they want to make it better. All in all, it's a pretty simple and compelling value proposition that even someone brand new to our company can understand.


Coding Chops
by CrashNBrn

So who wins in a "code off" ?

Jim Whitehurst, Mark Shuttleworth, Tim Cook, Larry Page, or Satya Nadella.

JW: That's a tough one, but I think I could at least compete! I wasn't new to Linux when I joined Red Hat. I'm actually working towards my Red Hat Certified System Administrator (RHCSA) now. It's not an easy certification to get - if I'm successful, I think I'll have hopefully proven my chops. I can compile a Linux kernel and kernel modules and can build pretty decent apps. Though OpenShift makes building apps so easy, I'm not sure that's a huge distinction. (Note: Shameless plug!)

But the actual answer to your question is Linus Torvalds. He really should be on that list!


A long term view on IoT security?
by mlts

Are there any plans or products to help with IoT security?

RedHat is one of the few companies that can step in and do something in regards to device security, even when device makers have little to no interest in this topic, as to them, security has no ROI, or as one IoT company exec told me, "the only person that has ever made money from a padlock is the lock maker."

Being able to lure IoT vendors to use secure tools wouldn't just benefit them, but it would benefit the Internet in a whole. Even something like manifest lists that interact with FirewallD to ensure a device is only able to communicate with authorized devices and cannot take input/output from rogue sources would improve the IoT ecosystem tremendously.

JW: We are already helping with IoT security indirectly. Open source and Linux powers nearly every IoT device that exists. This is an example of open source winning, you can't escape its reach any longer. That said Red Hat has always been a substantial contributor to open source projects and security is always a part of this collaboration. We were doing security before security was cool.

Rather than putting a focus on individual IoT devices, our focus is on the open source ecosystem as a whole. This is an instance where a rising tide lifts all boats. The goal is not help a single device or vendor, but to work on features that will affect the entire industry. By focusing on improving security in the Kernel, the compiler, glibc, the libraries used, even in the graphical user interfaces, we are helping build the future of IoT device security. IoT is changing the rules and perception around security. There is a lot of opportunity to get IoT security right, which means we have to focus on getting open source security right. We all win or we all lose when it comes to IoT security.


OpenStack vs AWS
by resplin

How can we improve the future of OpenStack? The dominance of Amazon has challenged the relevance of well funded players like Microsoft, Google, and IBM. How can OpenStack compete? The network effects around a dominant cloud platform threaten to relegate OpenStack to be a long term niche player, like Linux on the desktop. How can we avoid this fate?

JW: Most important is that the hybrid cloud is real, and it's increasingly part of the dialog we have with users and customers. Cloud isn't either-or. You can have a mutli-cloud deployment where you are using OpenStack for some workloads and AWS for others. We consistently hear from our customers and users that they are in public clouds like AWS *and* their on-premise cloud deployments. The public cloud providers are all great partners of ours, and I view OpenStack as a complementary technology to them.


As corporate IT loads shift to public clouds...
by Anonymous Coward

...does this marginalize the role of operating system vendors? I would imagine that most AWS customers would lean on Amazon for technical support rather than Red Hat.

JW: On the contrary, the emergence of public cloud has made the operating system even more relevant. There are several reasons why:

The first is around application mobility. The vast majority of customers I speak with plan to use more than one public cloud. So portability becomes a major requirement. And since OS is where the application ultimately touches computing resources, having an OS that can consistently run across all major platforms becomes even more important. As with any single platform provider, optimizations for provider unique hardware, architectures, or services may address specific situations in the OS and we have all seen how that played out in the single-source, vertically integrated Unix stacks - hence Linux. So we remain dogged in our drive in working with all our cloud, hardware, and software partners to ensure that RHEL (and all our products) enable as many platforms as possible to reinforce customer choice and application mobility.

Second, much of the value we provide in Linux is around life-cycle. We commit to a decade+ long life-cycle of patching and support of RHEL. That allows enterprises to confidently run long-lived applications on RHEL. That requires a massive engineering investment in skills, tools and processes. I guess others (like public clouds) could ultimately chose to do that, but it's a very different business than they are in today, and I'm not sure why they would chose to do that versus the many other areas of opportunity that more closely match their current capabilities.

Finally, new application models like containers and microservices are bringing the operating system to the forefront. Each and every container has its user-space dependencies in Linux in it, and therefore requires management of those components in the container regardless of where that container runs. As the leading Linux vendor and as a leader in many of the projects around containers, Red Hat is uniquely positioned to help customers as they build and deploy containers on public clouds or on premise.


Product vs Engineering
by Nite_Hawk

Hi Jim,

Thank you for answering our questions! How do you view top-down product driven development vs bottom-up engineering driven development? Are there situations where one excels vs the other?

JW: To be honest, I'm not sure I'm the right person to answer that question. I've had the great fortune of having a very strong engineering leadership team at Red Hat, so I have allowed them to drive how we engage with communities and build our products.

In a broad sense, Red Hat does a bit of both. Our business model is built from the project out to the product, because we so strongly believe in the power of user driven innovation. So I guess you could say that we are more bottom-up engineering developed. But a big part of our value is taking customer needs and driving those into upstream projects so that they end up in our products. So we really are a hybrid.


Puppet versus Ansible?
by waveclaw

Where do you see the configuration management market going in the next year or two?

JW: First things first, it's interesting to note that Ansible started as an orchestration platform that also happens to be able to do configuration management as well.

Orchestration is the hot topic right now for automation versus last year's configuration management tools. Ansible is more orchestration than configuration management. Puppet and Chef require tools like mCollective to pick up the orchestration piece. Red Hat now runs Tower. And Tower now ships as part of the Red Hat Ceph storage product. Red Hat's Satellite product is based on the Foreman which includes Salt, Puppet, Chef and Ansible support.

But where is this market heading? Are we likely to see consolidation? Integrations? Or even a flood of config management system tied products from vendors?

JW: Orchestration isn't a natural capability of many of the other tools on the market, but if you think about it, the ability to orchestrate configurations is really pretty critical. As it turns out, the order in which you provision IT applications and environments is really, really important. And Ansible handles this by design.

That being said, we have a number of customers that use other configuration management platforms like Puppet and Chef, and they use Ansible to deploy and manage agents, and then to orchestrate application deployments by deploying configurations as defined by these other tools. So really, it's easily a "yes, and" story, not an "either or".

Then we have Ansible Tower -- which actually, Red Hat was a paying Ansible Tower customer before we acquired them. Tower helps orgs operationalize automation across all their teams and IT environments in ways other tools cannot easily do otherwise. It's also key to plumbing automation into devops workflows.

There is some possible consolidation, but there's still a lot of market adoption to be had. We come across customers every day that have previously not used any configuration management solution at scale. This is a problem for those companies that want to scale, and running workloads in the cloud or with containers is nearly impossible without a mature automation and configuration management posture. So while there's some consolidation possible, there's still a lot of growth out there. As for config management being tied to vendors, I suspect that you'll continue to see other organizations mirror our approach to hybrid here. For an IT org that is trying to juggle deployments both on-premesis as well as in the cloud, they need tools that will work just as well in either location. This is a particular strength of things like Ansible.


Are there plans to tighten Ansible Integration
by waveclaw

We use and love Ansible, but it still seems to be a separate product. Are there plans to integrate it more? Having it as an integrated deployment option for JBOSS Operations network (JON) would be good.

JW: When we acquired Ansible, we knew we had to be careful not to immediately crush them with all of our scaling requirements. At this point, roughly 18 months post-acquisition, we can say that the Ansible team is heavily engaged with nearly every Red Hat product team. So whether you're talking about Red Hat Enterprise Linux, OpenStack, OpenShift Container Platform, Ceph Storage, CloudForms, Insights, or many of our other offerings, Ansible is either already integral to those offerings, or is being planned for a near release. It's an important piece across our portfolio.

Specifically to JBoss and our middleware offerings, several of our consulting teams came together to create a Ansible Roles to ease the deployment and management of various JBoss offerings. And I think that illustrates perfectly what Ansible means to us -- even our services teams are engaging in the Ansible community and getting involved. Which is both a testament to what Ansible can enable customers to do, but also to the love that so many different teams across Red Hat have for Ansible.


If meritocracy over democracy...
by turkeydance

if meritocracy over democracy is his choice, who decides what is "merit"?

JW: Great question. One thing that's important to me is that we continually question how well we apply the principle of meritocracy in practice. In general, we try to define our business goals and the problems we're trying to solve in clear and objective terms, so that it's obvious to everyone what the best and most feasible ideas are. You can get a feel for what kinds of information and detail we share internally by checking out the Open Decision Framework, which is a collection of our best practices for making open and inclusive decisions. We think of meritocracy as a leadership behavior, and you can see how we define it here. (PS: You can also find it on GitHub under a Creative Commons license.)

In practice at Red Hat, people with a long history of contribution and good ideas build their reputations as people to be listened to. It's not a perfect process, but because it is a "multi-round game" with reputations built over many interactions, it's a pretty good way for informal leaders to emerge.


Enterprise Desktop Market / Emerging / Demand
by GioMac

I am running more than 250 Linux desktops at the company and can get even more, but there is no centralized management solutions for that, and that's an issue with customization and security too. KDE desktop is very good at some point with it's ability to have strict configuration files and immutable options, that does about 25% of what we can get with Microsoft and Group Policy Object, and we see that a little effort is required to make things work.

Can we expect that Red Hat will enter that market in the nearest (3-4 Y) future?

JW: I appreciate the feedback and idea for a new market for us. Let me take that feedback back to our desktop team. I really can't talk about future product plans in this venue, but I'll make sure they know that you see an opportunity here.


RHCA Exams
by kamilyunis

My question is about Red Hat Certified Architect exams. It is very good and we are very happy about Red Hat's new subscription-based trainings. It is great. But when it comes to RHCA, it is limited for locations.

RHCA level exams are very expensive, and travel and accomodations make it more expensive. I am 2xRHCE, because of these exams is available in my location. Azerbaijan Baku, MIddle EAST, Caucasus does not have center to take exam. Please take this into consideration. Vmware, Cisco, Microsoft, AWS, OpenStack make their exams available in everywhere online, so it is easy for everyone to take it. Why open source company limits people passions to location.

I believe that me and people like me can become multi level RHCA if they get chance to take exam in their own location. And this will help recognition and value of RedHat in regions also. Please make this available as Cisco for us. At least make it possible on Kiosk In Georgia or Azerbaijan so we can take exams also. I am from Azerbaijan, Baku. With Loves to best open source company in the world.

JW: We recognize the need to reach people who are interested in certification throughout the world. We are constantly expanding our global testing options, and increasing the number of ways we offer testing for our certifications, including adding secure, preconfigured kiosks and laptops with our Red Hat Training Partners.


==========================================================================================================
Red Hat Enterprise Linux is too static to keep pace with kernel devel.
by nbritton

I have found that Red Hat Enterprise Linux is too stagnate / static to keep pace with the rate at which the kernel is now developed. The 3.10 kernel is four years old at this point and the fact that Red Hat Enterprise Linux 7 will be in production support until 2024 is disheartening because the enterprise industry will be a decade behind the latest kernel developments and updates from associated projects. Compared to other vendors' Linux offerings, when I use Red Hat Enterprise Linux I get the same feelings I got when I was force to use AIX, HP-UX, and Solaris. I hated administrating those products because they were stuck with defaults like ksh from a decade ago.

My question is, would Red Hat ever consider releasing a Linux distribution with a shorter development cycle and with more aggressive tracking of upstream projects? I see a place for a distribution that is somewhere in between Red Hat Enterprise Linux and Fedora. Perhaps you could morph or fork CentOS into the upstream development for Red Hat Enterprise Linux? For example: Upstream --> Fedora (Bleeding Edge) --> CentOS (Next Release of Red Hat Enterprise Linux) --> Red Hat Enterprise Linux. This would give system engineers and architects a greater range of products to choose from and it could help stabilize Red Hat Enterprise Linux even more then it already is.

In short, the Linux kernel is the largest and the fastest moving software project in the world, so what changes are you going to make to keep up with it?

.....................................................................................................................................................................................................................................

The Price of Reliability
by hcs_$reboot

Worked on SunOS, Solaris, MacOS, Red Hat, CentOS, and, more recently, Ubuntu. CIOs choose Red Hat mainly for support and reliability. Reliability is the word that comes to most engineers mind when the RH and CentOS OSes are mentioned (certainly for good reasons). Reliability mainly relies on using older kernels and features, that have been patched over and over ; sure, that works, reliability wise. But on a number of rather recent projects, comparing Ubuntu server and RH/CentOS, it appears setting services up (eg Samba) was way easier on the newer Ubuntues than on the latest RH/Centos (not mentioning the many issues migrating from 6 to 7) . Also, using newer kernels, Ubuntu performs well, taking advantage of the newest internals, memory management and sharing, IPC etc ... and no specific reliability issue (IMHO, reliability wise, Ubuntu and the like are as solid as RH nowadays).

Question: in 2017, does reliability still mean using long-tested, but older kernels and features?
==========================================================================================================

JW: There's a common misperception that Red Hat Enterprise Linux pulls a Fedora kernel and stays on it for 10+ years while the world moves onto newer kernel versions with better features and newer hardware. It's true that we standardize on a specific kernel version for the life of a major release, but that's not the whole story.

Our stability is actually in our kernel ABI (kABI), which is a promise of stability that a kernel developer can rely on for the life of a Red Hat Enterprise Linux release. When we release a major version of Red Hat Enterprise Linux we actually backport many key features from newer kernels, bugfixes, etc. and we do it in a surgical way that not only delivers new features and hardware on an older kernel, but also preserves the kABI. For example, Red Hat Enterprise Linux 6 was based on the 2.6.32, but when we released Red Hat Enterprise Linux 6 it also had an additional 2600 patches (features, hardware, bugfixes, CVEs) and this continues for the development life of the release. The stats on Red Hat Enterprise Linux 7 are similar. This provides a customer expected balance between stability and innovation. We also have a driver update program (DUP) that makes it easy to add kernel drivers prior to the public availability of the next minor release.

So don't take the kernel version at face value -- we spend a lot of time backporting newer kernel features into every major release! If you want the latest and greatest and don't care about kABI, ABI and long-term stability, Fedora is ready for you.

Enterprise customers continue to expect stability, security, scalability and reliability, but also want higher levels of automation and ease of use, multiple deployment methods (bare metal, virtualization, containers and cloud) and the new features as they appear upstream and with hardware and userspace tools that can help to exploit them. If we sense critical new features going upstream that will break kABI and can't be backported, we will plan accordingly.

IBM has open sourced a "high performance, scalable virtual machine" with "a great pedigree... [it's] at the core of many IBM enterprise software products." Slashdot reader dxb1230 writes: IBM has open sourced their JDK/JVM implementation named J9 as OpenJ9. The community now has an alternative implementation of Java which has been well tested on enterprise workloads and hardware. This unlike, OpenJDK, has all the bells and whistles like jit.

An anonymous reader writes: Some media outlets called Ceylon an attempted "Java killer" when Gavin King first unveiled his secret two-year development project in 2011. In 2013 Red Hat finally released version 1.0 of the modern, modular statically-typed programming language for the Java and JavaScript virtual machines. After another four years, "Ceylon has a small but very active and enthusiastic community of developers and users, and indeed is the fruit of the hard work of a large number of contributors over the years," says a project proposal page at Eclipse.org seeking "to further grow our community... a key strategy to achieve that would be to move Ceylon from Red Hat to a vendor-neutral foundation."

That project has now been approved, and the "Eclipse Ceylon" project has been created. It includes the Ceylon distribution and its SDK, plus the Java2Ceylon converter and the Ceylon Herd project's server (and related services) for Ceylon module sharing. There's also three IDEs (and their code-formatting and functionality-sharing modules).
Back in 2011 InfoWorld predicted that instead of becoming a Java killer, "it is more likely Ceylon will join a growing list of new languages resting atop the JVM, while the Java language and platform will continue on as staples of enterprise computing."

An anonymous reader writes: Some media outlets called Ceylon an attempted "Java killer" when Gavin King first unveiled his secret two-year development project in 2011. In 2013 Red Hat finally released version 1.0 of the modern, modular statically-typed programming language for the Java and JavaScript virtual machines. After another four years, "Ceylon has a small but very active and enthusiastic community of developers and users, and indeed is the fruit of the hard work of a large number of contributors over the years," says a project proposal page at Eclipse.org seeking "to further grow our community... a key strategy to achieve that would be to move Ceylon from Red Hat to a vendor-neutral foundation."

That project has now been approved, and the "Eclipse Ceylon" project has been created. It includes the Ceylon distribution and its SDK, plus the Java2Ceylon converter and the Ceylon Herd project's server (and related services) for Ceylon module sharing. There's also three IDEs (and their code-formatting and functionality-sharing modules).
Back in 2011 InfoWorld predicted that instead of becoming a Java killer, "it is more likely Ceylon will join a growing list of new languages resting atop the JVM, while the Java language and platform will continue on as staples of enterprise computing."

Binestar writes: I've been doing IT consulting for years, but I'm not a programmer beyond bash scripting, perl scripts to make administration easier, and batch files to make Windows easier. I recently found an online course for modding Minecraft that my 9-year-old daughter is really enjoying (she built a custom sword that shoots lightning). Does anyone have any recommendations on online courses that would be age appropriate and worth the investment? It's been easy to get her interested in the Minecraft modding course because, as any parent with young children knows, Minecraft is kinda popular...

The course she's taking now is teaching her Eclipse and Gimp, and I'm sure there are other tools installed that they haven't had her open yet. What other vendors have stuff worth introducing her to? I've also started looking at things like the Kano and Learn to Mod, but as a non-programmer, I'm not really sure which are most useful for introduction and which are accomplishing what they claim vs. being a waste of money/time.

Anyone have experience or suggestions to help sort this out?

msmoriarty writes with news that the Eclipse foundation is ten years old this week. Although Eclipse was released in 2001, development was controlled by IBM until the creation of the independent Eclipse Foundation in 2004. "According to Eclipse Foundation Director Mike Milinkovich, that's a major reason Eclipse was able to thrive: 'IBM....did an exemplary job of setting Eclipse free ... We became the first open source organization to show that real competitors could collaborate successfully within the community.' He also talks about misconceptions about Eclipse, its current open source success, and what he sees for the future."

msmoriarty writes with news that the Eclipse foundation is ten years old this week. Although Eclipse was released in 2001, development was controlled by IBM until the creation of the independent Eclipse Foundation in 2004. "According to Eclipse Foundation Director Mike Milinkovich, that's a major reason Eclipse was able to thrive: 'IBM....did an exemplary job of setting Eclipse free ... We became the first open source organization to show that real competitors could collaborate successfully within the community.' He also talks about misconceptions about Eclipse, its current open source success, and what he sees for the future."

sl4shd0rk writes "Hackers can now build applications directly on their Android devices with the beta release of AIDE. The Android IDE is at beta version 7, and already allows editing and compiling of apps as well as integration with LogCat. AIDE is even compatible with projects started on Eclipse so you can move a project over and work on it. Finally, a reason to get yourself that Transformer keyboard dock?" sl4shd0rk also provided a screencast which is attached. InfoQ has a short interview with the developers. Mildly interesting is that it does the compilation on device instead of shipping the work off to some network service or other. The app is, like a lot of Android stuff, only free cost with no corresponding source code at the moment.

New submitter dd1968 writes "Today IBM announced the release of a new set of Open Source development tools based on their EGL programming language. The announcement describes the tools as being built from the ground up on an 'open, extensible compiler and generator framework.' The one-language approach places an abstraction layer between the developer and target languages, frameworks, and runtime platforms."

An anonymous reader writes "Eclipse has launched a website for a new JVM language, called Xtend. It's built with Eclipse's Xtext and compiles directly to Java code, similar to what CoffeeScript does to Javascript. It's not just an announcement but it's already there and useable, including a very feature-rich Eclipse integration."

msmoriarty writes "10 years ago this month, IBM open sourced an internal project focused on creating a common component framework for developers: Eclipse. In an interview with ADTmag.com, Eclipse Foundation director Mike Milinkovich remarks on what was, back then, a revolutionary move: 'You've got to give IBM a lot of credit...Ten years ago, the notion that open source might be the best way for software vendors to collaborate was really a novel idea... Eclipse demonstrated the advantages of collaboration in open source, even amongst fierce competitors.' The Eclipse Foundation is celebrating the anniversary with a kickoff party at its EclipseCon Europe 2011 conference, and if you're an Eclipse community member, the Foundation is also inviting you to add yourself to the Eclipse 10th Birthday Timeline."

msmoriarty writes "10 years ago this month, IBM open sourced an internal project focused on creating a common component framework for developers: Eclipse. In an interview with ADTmag.com, Eclipse Foundation director Mike Milinkovich remarks on what was, back then, a revolutionary move: 'You've got to give IBM a lot of credit...Ten years ago, the notion that open source might be the best way for software vendors to collaborate was really a novel idea... Eclipse demonstrated the advantages of collaboration in open source, even amongst fierce competitors.' The Eclipse Foundation is celebrating the anniversary with a kickoff party at its EclipseCon Europe 2011 conference, and if you're an Eclipse community member, the Foundation is also inviting you to add yourself to the Eclipse 10th Birthday Timeline."

h00manist writes "Google is donating Windowbuilder Pro and Codepro Profiler to the Eclipse project. 'Google acquired the software when it bought Instantiations, relaunching the Java graphical user interface building tool Windowbuilder Pro shortly after. Now the outfit has decided to donate both Windowbuilder Pro and the code analysis tool Codepro to the open source Eclipse project. Although Google has announced its intention to donate the software, it needs go through a rigorous filtering process to ensure that no intellectual property rights will be breached. Once those formalities are dealt with, it is likely that both Windowbuilder Pro and Codepro will tip up in the Indigo release of Eclipse sometime in June 2011.'"

crabel writes "In Java 1.6.0_21, the company field was changed from 'Sun Microsystems, Inc' to 'Oracle.' Apparently not the best idea, because some applications depend on that field to identify the virtual machine. All Eclipse versions since 3.3 (released 2007) until and including the recent Helios release (2010) have been reported to crash with an OutOfMemoryError due to this change. This is particularly funny since the update is deployed through automatic update and suddenly applications cease to work."

andylim writes "At EclipseCon 2010 attendees were challenged to create a robotic control system to drive a NASA-provided robot across a prototypical Mars landscape. To win the EclipseCon e4-rover Mars challenge, developers could either prove their e4 programming skills by creating the best e4-Rover client, or use an e4 client to operate the Rover through a series of tasks to collect points. Software architects Peter Friese and Heiko Behrens built an iPhone client for the EclipseCon challenge which controls the robot around NASA's Mars landscape using the iPhone's accelerometer."

spongman writes "Microsoft's Senior Vice President, Developer Division, S. Somasegar has announced that Microsoft has acquired Teamprise from Sourcegear, LLC, and will be shipping it as part of the upcoming Visual Studio 2010 release. Teamprise is an Eclipse plugin (and related tools) for connecting to Team Foundation Server, Microsoft's source-control/project-management system. What's most interesting about this is not only that Microsoft has realized that heterogeneous development platforms are important to their developer customers, but the fact that Microsoft themselves will now be developing and shipping products based on those heterogeneous platforms, including 5 versions of Unix."

Last week you asked Jazz technical lead Erich Gamma questions about Jazz or anything else in his realm of expertise. Here are his answers, along with many external links and places to continue the conversation if you are interested. Why Jazz? -- by autophile (640621)

Could you explain, minus the marketing speak that seems to pervade the IBM site, what is Jazz, what makes it a community-oriented developer's site, why is it different from, say, sourceforge.net, and if Jazz is so community-oriented and yet apparently tied in to Rational, where are the community versions (not trials, not demos, not limited to the point of uselessness functionality) of Rational products?

Jazz is not a product but it is the name of a project that has the goal of building a new set of team products and to better integrate existing products.

The Jazz project was kicked-off in 2005. At that time we observed that the tooling situation for an individual developer using an IDE like Eclipse was pretty good. However, when it came to working as a team, our own experience and feedback from our customers indicated there are still many pain points. Our own experience comes from working for many years on Eclipse. We developed in a globally distributed team, spread across many time zones, and using many agile practices. The goal of the Jazz project was to take a fresh look at how teams work together and to build a new generation of products from the ground up that makes development more collaborative, but also more fun. We put the team at the center of all our designs. Initially we focused on development related pain points like support for iterative planning, painless build submissions, collaborating and fixing broken builds, simplifying parallel development, easy progress tracking, and finally improving transparency. Collaboration becomes more effective with increased transparency. One of the goals here is to make it easy for everybody to know what is going on in the project without having to ask. Since then we expanded the scope to cover the role of testers and business analysts. The set of new products that were built from the ground up include:

• Rational Team Concert (RTC): Provides a new customizable work item/defect tracking system, a continuous build system, a new source control system, and customizable agile planning that supports project management practices like the ones from Scrum, and dashboards and reports. Version 2.0 has actually shipped just a week ago.
• Rational Quality Manager (RQM): Provides test management, test planning, and includes a test lab management component.
• Rational Requirements Composer (RRC): Provides requirements definition for business analysts, client stakeholders and software developers using a variety of capture techniques.

These products share a common infrastructure using the building blocks we refer to as the Jazz Foundation. The Foundation provides a common set of services that can be leveraged by a Jazz tool. To enable integration with existing tools, the Jazz Foundation supports the Open Services for Lifecycle Collaboration initiative; an independent project to define a set of REST based protocols for sharing information across disparate tools. Actually, we are not only contributing to the specification, we have actually used the OSLC specifications for integrating the above tools.

Finally, we have grown a community around the Jazz project on www.jazz.net. Transparency and feedback are very important to us, not only for the tools we provide, but also for how we develop the products ourselves. To get that direct feedback, we do our development on jazz.net out in the open. On jazz.net you can interact with the development team, learn about our development plans, see our RTC powered dashboards, submit defects and enhancements, or download intermediate milestone builds.

If you want to read about how all these capabilities come together, there is a new eBook available for download. The eBook describes, using scenarios, how business analysts, development teams, and testers collaborate using the above mentioned products.

If you are interested in how we develop our products using Rational Team Concert in a globally distributed team, I did a web cast that sheds light on our development practices.

Rather than reading feature comparisons, I suggest that you jump in and give Rational Team Concert 2.0 a try. We made it very easy to kick the Team Concert tires. In less than 30 minutes you will have a running server, a client, and a sample project for a small team working on a fictitious JUnit release. There is also a community edition called Express-C (free for up to 3 users). Based on community feedback, we have made more features available in the Express-C edition. You can find the descriptions of the editions on the Jazz site. For those of you that do prefer to compare features, there is also a feature overview of RTC . If you have questions, feel free to post them to the user forum on jazz.net. Our development team is always there to answer questions.



Rational? -- by an anonymous reader

I work in a small shop that makes some use of Websphere Application Server and the Rational development tools. I basically find the entire structure of the IBM software offerings relating to the above technologies incomprehensible. Products are constantly being renamed, discontinued, bundled, unbundled and rebranded. Names are long, generic, and practically interchangeable, and so are the feature lists. How do you plan to run a community support site based around this hodge-podge? I would assume the volatile nature of IBM's software marketing makes your task something approaching impossible. How do you expect to build a strong developer community based around products that are in a constant flux? I don't see any way around ending up with a large number of granular, isolated communities that spring up around specific products and thrive for a year or two. In short, how do you plan to unify a developer community without IBM first unifying the software development platform that this community is to be built around?

Obviously the Rational portfolio has grown through acquisitions (Build Forge, Watchfire and Telelogic being the most recent), and the process of bringing these acquired products into a logical product family while minimizing disruption for existing users is an ongoing effort. One goal of the Jazz project is to improve the integration of existing products by providing the Jazz integration architecture and by contributing to the OSLC initiative as mentioned above.

The Jazz community site is the live development infrastructure for the Jazz project and the new Jazz products. We launched www.jazz.net in 2006 together with the availability of the first Rational Team Concert beta version. As you can see from the URL it is "ibm" neutral and focuses on Jazz products. Since then the community has rapidly grown and there are now over 17000 participants in Jazz forums. Customers really appreciate the direct communication channel with the development team. Given the positive feedback we have recently on-boarded two additional Jazz products on jazz.net: Rational Requirements Composer and Rational Quality Manager. This was combined with a reorganization of the site itself to optimize for the new projects, improve user experience, and create a high quality technical library of materials created by the development teams themselves to help educate and get teams set up and running and become productive very quickly. Additional Jazz products will on-board on jazz.net as they emerge. Some of the Jazz products will also be in flux, the point is that we make them available early, are transparent about their development and invite users to provide feedback.



RTC vs CQ and CC -- by SunSunich (1588709)

First of all let me congratulate you on the successful launch of version 2.0 of RTC and 1.0 JF. It is really great work, thank you and all the Jazz Team. The functionality of Rational Team Concert greatly overlaps with the ClearQuest and ClearCase. Why is it necessary to create a new product? Why not just release it as new versions of old? For customers, it could be easier to adapt. What is the future of CQ|CC, how you see it? Thank you.

With the Jazz project we are trying to do something new and do it in the open - but clearly we understand that we can't just leave the existing customers behind. As mentioned in the question about the Jazz project above, we have experienced several pain points with the existing tools. A common point of friction was the lack of integration which resulted in a lack of transparency. One lesson from Eclipse was that to achieve integration you need some common foundation or integration platform. Retrofitting a new integration platform wasn't a viable approach and in addition there were additional pressures to better support agile practices. While the Jazz project did start from the ground-up, we reused many ideas from CC and CQ. For example, the stream model from CC or the customization support from CQ. Once we went down this path it was obvious that we needed an integration solution for CC and CQ.

In RTC 1.0 we provided "synchronizer" connectors which can synchronize data between the Jazz and the CC or CQ repositories. With this functionality, an agile team can start to use RTC while periodically synchronizing their code with the "mothership" CC repository. For RTC 2.0 we have expanded the integration options with the support "bridge" connectors. A bridge doesn't synchronize the data but rather links artifacts across repositories. The CC Bridge allows linking a ClearCase UCM activity with an RTC work item. This allows CC users to continue using CC, but also benefit from the additional capabilities RTC offers such as agile planning support, work items, reports, dashboards, notifications etc. The CQ Bridge provides linking CQ Records and RTC work items. Finally, both RTC and CQ implement the Open Services for Life Cycle Collaboration specification for change management systems. This enables a third tool like the Rational Quality Manager to work with either RTC or CQ when it comes to filing defects for failed tests, for example.

To conclude, there is still a significant investment in enhancing ClearCase and ClearQuest and this will continue. RTC 2.0 provides good options for users who want to use RTC, CQ and CC together. All these options have been enriched further in 2.0 to enable gradual adoption.



Could Jazz Benefit from a Distributed Model? -- by A.K.A_Magnet (860822)

Do you think Jazz could gain from a distributed model, like git does for source control management, where the repositories can be forked and kept synchronized upstream/downstream (a bit like a "progressive fork" where fixes can be shared but the project can be forked for various reasons)? I heard there is a git connector in incubation but it seems to me more than just code artifacts should be distributed. After enjoying the many benefits of distributed SCMs, it's hard to go back, and I think at least issue management could gain from the same model.

Using the terminology from above the Git integration will be a bridge connector. It will be available as an incubator on jazz.net soon and it leverages the OSLC change management specification supported by RTC to create the linkage to RTC work items. Flowing changes across repositories is appealing and this feature is in our backlog. Some explorations to support a distributed Jazz SCM were already undertaken. Details on the current status and open issues are available on the developer wiki on jazz.net.

Cleaning Up Collaboration -- by eldavojohn (898314)

Jazz seems to rely heavily on developer community and their collaboration--and the influence for Jazz is said to be the World Wide Web. "The Jazz portfolio consists of a common platform and a set of tools that enable all of the members of the extended development team to collaborate more easily." The biggest problem I have with collaboration tools is the metadata. No one does it right. Someone writes a blog or uploads a document but doesn't tag it. Enterprise search is broken. Management hands us wikis yet no one has the time or patience to maintain them. The protective blanket of "it's agile, baby" shields us from any beat downs. And with every new tool I realize that it's not the tool that improves collaboration, it's the team. Look at Slashdot's tagging system. Does it help me that one hundred stories are tagged with "no"? Collaboration seems to spontaneously work but is often out of your control when it does and doesn't. How does Jazz fix these problems? How does Jazz improve collaboration when it seems to me that tools are such a small part of collaboration? Will a small development team be able to use such a large set of tools?

I agree that no tool can fix collaboration problems and the team plays the main part in the game. In the Jazz project, we are focusing on collaboration in the context of software artifacts like builds, change sets, test plans, defects, or baselines. Software artifacts are semantic rich, structured, and there are typically rules, permissions or approvals involved when it comes to changing artifacts. Jazz products can improve the collaboration around software artifacts by making these rules explicit. Our goal was that the tool not only acts as the police but also as a guide that helps team members conform to the rules. Let's use Rational Team Concert as an example. When a change set requires a review before it is shared with the team, the tool will not just flag you when the review is missing, it also offers to initiate the review process for you. This involves suspending the changes from the current work space, attaching them to a work item, and notifying the reviewer that there is a pending review.

Behind all this is a process component in the Jazz Foundation that allows you to configure these rules in a flexible way. The flexibility is required since otherwise tools can get easily in the way. A team operates differently during an early exploration of a product and one week before it ships. The rules can be specific to a particular role, or a particular team, and the development phase of the project. Here is an analog example to tagging a blog: checking in a change set and wanting to track the reason for the change. To guide users, you can define a precondition for the check-in operation that will ensure that the change set is linked to a work item tracking the reason for the change. When a user attempts to check-in a change set without an associated work item, the user is shown a list of work items that they own to choose from. If none of them apply, the user can easily create a new work item on the fly to complete the check-in. As a side effect the change set and the work item are now linked together. As you work with Rational Team Concert it establishes many such links between artifacts for you in the context of your work. For example, the work items that are fixed and included in a build are linked to the build result artifact. These links increase the transparency and allow everybody in the team to understand why something was changed, which will helps collaboration.

In addition to making team roles and rules more explicit, the tools improve collaboration by helping team members stay on top of changes that affect the whole team. The team's current sprint or iteration plan and the current progress are easily accessible for everybody to see. Team members are notified about events in their team and they can track event feeds using RSS readers and aggregators. Similarly, broken builds are linked to a work item where the discussion about the broken build takes place and this work item is then easily visible and accessible from the team's dashboard. These are just a few examples that illustrate how a tool can facilitate the collaboration in the context of software artifacts.

Now regarding the question on small development teams, RTC is designed to scale up from single teams working in a single release to multiple (even distributed) teams working on multiple releases and you can easily use RTC for small teams. In fact, the Express-C edition is free for teams up to three. Even a small team needs to do the backlog and sprint planning, needs continuous builds, needs to track progress, manages defects and wants to make the current state of the project visible on dashboards.

The Directions of the Eclipse Foundation -- by eldavojohn (898314)

Eclipse has been going on since the early 2000s and six days ago enjoyed the release of Galileo (v3.5). If you've had time to look at recent release, what are your opinions on what Eclipse has become? Has it made any wrong turns? How do you respond to criticisms of "bloat" or "too resource intensive"? Do you see it becoming more than what it is or transforming?

The Galileo release is quite an achievement. Over 30 projects with over 380 committers from over 40 organizations have contributed to this joint release. Obviously you do not want to consume Galileo all at once but rather pick one of the available packages that suit your needs. Now that my team's focus is on Jazz and Rational Team Concert, we have become consumers of many Eclipse projects. Having a release train with aligned project releases is a big help for us and is the right direction.

As consumers we also appreciate the API stability that Eclipse platform provides. Regarding bloat, the API stability is not free. It means that once something has surfaced as an API, you cannot remove or change it anymore. For example, if you look under the covers in the Eclipse source code, you find three different preference store mechanisms. This is the price you pay for API stability. Actually, Eclipse now includes some nice tools to track API changes and more.

The "too resource intensive" criticism depends on which packages/plug-ins you are using. Eclipse is an extensible system and is therefore vulnerable to contributions that can be too resource hungry. To keep a software system interesting to users, you need a constant flow of new features. The challenge is to preserve the performance and resource characteristics as new features are added. The Eclipse SDK team does measurements to track this. There is a set of performance JUnit tests that are run for each build. Once a test runs slower than the baseline from the previous release, the test turns red. The results are published for each build. Here is an example report from Eclipse 3.5. Based on our own use of Eclipse for developing RTC, I do not experience that Eclipse has become slower over time or more resource intensive.

Looking back, I don't necessarily see wrong turns, but rather some turns we probably could have taken but didn't. For example, the Eclipse platform is language agnostic and the Java Development tools built on top of the platform. There is a language toolkit layer (LTK) in between the platform that provides some generic infrastructure for implementing refactorings. However, this layer is thinner than implementers of new languages on Eclipse would like. They therefore have to resort to copy code from JDT. This is obviously not ideal. Even though we were aware of this issue, we didn't have the cycles to pursue a more generic language layer. Having said that, I must say that the Eclipse C Development tool is cool in Galileo and there is good support for many other languages. There also is the Dynamic Languages Toolkit incubator project at Eclipse.org.,



Will SWT and Swing ever merge in Eclipse? -- Fuzuli (135489)

I have to build quite complex tools using GEF and GMF, and there are many cases where I'd like to have the power of Java2D, and reuse some of the great frameworks out there built on Swing. More and more people are using AWT/SWT bridge, since SWT does not provide an underlying drawing framework as rich as Java2D. Eclipse has great things like EMF, and the platform is number one choice for tooling, but when it comes to things like Bezier curves etc, Swing is much easier to use. So are we going to see more developer friendly versions of Eclipse where Swing is more available to us?

SWT has continually improved its advanced graphics API for drawing Bezier curves, alpha blending, gradients etc. You can see it in action in the GraphicsExample (http://www.eclipse.org/swt/examples.php.) and there are several example snippets. If the current support is not sufficient, then you should file enhancement requests against the SWT component at eclipse.org.

As you mention SWT provides the support to enable the SWT/Swing integration and enables embedding an AWT hierarchy in a SWT widget hierarchy. The SWT team has currently no plans go beyond this. However, there is also the Albireo project at Eclipse.org. This is a technology project in incubation with the goal of simplifying the task of combining user interface components from the Swing and SWT toolkits.

A follow-up question -- by an anonymous reader

will SWT and the whole Eclipse workbench ever run in a Web browser? We have built a product based on SWT/Eclipse but our customers complain they cannot run it from a browser and instead have to download 200MB+ worth of plugins before they even start evaluating our product.

The eclipse e4 project has been investigating this very question. At EclipseCon 2009, the team provided an update and showed some interesting demos. You can find more details about the e4 project and a presentation covering the eclipse/desktop exploration online.

The short answer is that there is no free lunch for existing applications which generally must be re-factored to take into account that the application is now split between client and server. For your application to run in a web browser, the libraries it uses must also run in a web browser. In particular, one needs web equivalents of the workbench facilities that Eclipse RCP apps are based on. The approach currently being investigated is to provide "e4 workbench services". The e4 project is increasing support for running JavaScript on the desktop. As a consequence when the application is written against these workbench services, the same JS code can run unchanged in both the desktop and the web. In combination, this provides a path to achieving a good user experience in both the desktop and the web with some reuse.

A different approach being investigated in parallel is the eclipse Rich Ajax Project, which is also part of the Galileo release. RAP runs your SWT widgets remotely in a web browser, which have some other trade-offs as the approach used by e4.



On strong typing, and design patterns and testing -- by bADlOGIN (133391)

A number of weak typing language zealots like to point out that Design patterns is simply a way to make strongly typed languages "suck less". This can be a compelling argument in terms of simplicity and syntax in examples when you take a look at books like "Design Patterns in Ruby" compared with "Design Patterns: Elements of Reusable Object-Oriented Software". There's also an argument that strong typing is a form of tight coupling and antithetical to half of the Object Oriented axiom, "loose coupling, strong cohesion". Given the momentum in popularity that unit testing across multiple languages and development methodologies has (rightfully!) enjoyed, is it time to encourage language designers and programmers to move away from strong typing usage and substitute better testing practices?

The Design Patterns book is now over fifteen years old and it predates the Internet, Java, and XML, which is pretty amazing to me. However, it doesn't predate Smalltalk. Smalltalk is an influential and powerful dynamic object-oriented language. When working on the pattern catalog, we looked for known uses of our patterns in the Smalltalk libraries. If you study some of the pattern examples you can see how they can be implemented in Smalltalk. What is definitely true is that dynamic languages provide some interesting pattern implementation variations. I do not go as far as to say that static typing is in strong contrast to object-oriented principles. You can define loosely coupled systems in statically typed languages using interfaces and abstract classes. In addition, the more recent Dependency Injection pattern allows you to configure the dependencies of an object externally.



On the Current State of Academia? -- by eldavojohn (898314

I know a lot of people that are very vocal about what is right and wrong with education today. Especially college institutions: "No one teaches C, everyone teaches four years of Java, no one understands the theory, a CS grad doesn't even know what a model-view-controller pattern is." The list goes on. Since you have your doctorate and have probably spent a lot of time in research and academia, what's wrong with most computer science or engineering programs in general today? What would you like to see more or less of? Are there any subject directions recently taken (EJB, garbage collectors, interpreted languages) you'd like to comment on? You seem to be non-opposed to Java which, I'll admit, is rare to me for someone with a doctorate. I would like to hear your views since so often all I hear about Java is that it is slow and only good for people that want cheap software developed quick by beginner developers.

I cannot complain about the students that come out of nearby universities and that interview for positions on our team. Many of these students used Eiffel as their first language but they are all familiar with different languages using different paradigms. While they are not experts in EJBs, JFS, Dojo, Ruby on Rails or whatever, they have a solid CS background with lectures on patterns and are eager to learn. They come up to speed quickly with new technologies. This is required when joining a team like ours working on Rational Team Concert. For example getting started on the Rational Team Concert project requires a new team member to learn a mix of things such as Java, JavaScript, Dojo, CSS, C# (when working on the Visual Studio Client), Eclipse Plug-ins, REST and finally our agile development practices. One possible area of improvement is more familiarity with larger software systems and their architectures. Open Source project like Eclipse can serve as great study material. On the positive side I also observe that more students are starting to contribute to open source projects and can point to submitted patches in their CVs.

Last week you asked Jazz technical lead Erich Gamma questions about Jazz or anything else in his realm of expertise. Here are his answers, along with many external links and places to continue the conversation if you are interested. Why Jazz? -- by autophile (640621)

Could you explain, minus the marketing speak that seems to pervade the IBM site, what is Jazz, what makes it a community-oriented developer's site, why is it different from, say, sourceforge.net, and if Jazz is so community-oriented and yet apparently tied in to Rational, where are the community versions (not trials, not demos, not limited to the point of uselessness functionality) of Rational products?

Jazz is not a product but it is the name of a project that has the goal of building a new set of team products and to better integrate existing products.

The Jazz project was kicked-off in 2005. At that time we observed that the tooling situation for an individual developer using an IDE like Eclipse was pretty good. However, when it came to working as a team, our own experience and feedback from our customers indicated there are still many pain points. Our own experience comes from working for many years on Eclipse. We developed in a globally distributed team, spread across many time zones, and using many agile practices. The goal of the Jazz project was to take a fresh look at how teams work together and to build a new generation of products from the ground up that makes development more collaborative, but also more fun. We put the team at the center of all our designs. Initially we focused on development related pain points like support for iterative planning, painless build submissions, collaborating and fixing broken builds, simplifying parallel development, easy progress tracking, and finally improving transparency. Collaboration becomes more effective with increased transparency. One of the goals here is to make it easy for everybody to know what is going on in the project without having to ask. Since then we expanded the scope to cover the role of testers and business analysts. The set of new products that were built from the ground up include:

• Rational Team Concert (RTC): Provides a new customizable work item/defect tracking system, a continuous build system, a new source control system, and customizable agile planning that supports project management practices like the ones from Scrum, and dashboards and reports. Version 2.0 has actually shipped just a week ago.
• Rational Quality Manager (RQM): Provides test management, test planning, and includes a test lab management component.
• Rational Requirements Composer (RRC): Provides requirements definition for business analysts, client stakeholders and software developers using a variety of capture techniques.

These products share a common infrastructure using the building blocks we refer to as the Jazz Foundation. The Foundation provides a common set of services that can be leveraged by a Jazz tool. To enable integration with existing tools, the Jazz Foundation supports the Open Services for Lifecycle Collaboration initiative; an independent project to define a set of REST based protocols for sharing information across disparate tools. Actually, we are not only contributing to the specification, we have actually used the OSLC specifications for integrating the above tools.

Finally, we have grown a community around the Jazz project on www.jazz.net. Transparency and feedback are very important to us, not only for the tools we provide, but also for how we develop the products ourselves. To get that direct feedback, we do our development on jazz.net out in the open. On jazz.net you can interact with the development team, learn about our development plans, see our RTC powered dashboards, submit defects and enhancements, or download intermediate milestone builds.

If you want to read about how all these capabilities come together, there is a new eBook available for download. The eBook describes, using scenarios, how business analysts, development teams, and testers collaborate using the above mentioned products.

If you are interested in how we develop our products using Rational Team Concert in a globally distributed team, I did a web cast that sheds light on our development practices.

Rather than reading feature comparisons, I suggest that you jump in and give Rational Team Concert 2.0 a try. We made it very easy to kick the Team Concert tires. In less than 30 minutes you will have a running server, a client, and a sample project for a small team working on a fictitious JUnit release. There is also a community edition called Express-C (free for up to 3 users). Based on community feedback, we have made more features available in the Express-C edition. You can find the descriptions of the editions on the Jazz site. For those of you that do prefer to compare features, there is also a feature overview of RTC . If you have questions, feel free to post them to the user forum on jazz.net. Our development team is always there to answer questions.



Rational? -- by an anonymous reader

I work in a small shop that makes some use of Websphere Application Server and the Rational development tools. I basically find the entire structure of the IBM software offerings relating to the above technologies incomprehensible. Products are constantly being renamed, discontinued, bundled, unbundled and rebranded. Names are long, generic, and practically interchangeable, and so are the feature lists. How do you plan to run a community support site based around this hodge-podge? I would assume the volatile nature of IBM's software marketing makes your task something approaching impossible. How do you expect to build a strong developer community based around products that are in a constant flux? I don't see any way around ending up with a large number of granular, isolated communities that spring up around specific products and thrive for a year or two. In short, how do you plan to unify a developer community without IBM first unifying the software development platform that this community is to be built around?

Obviously the Rational portfolio has grown through acquisitions (Build Forge, Watchfire and Telelogic being the most recent), and the process of bringing these acquired products into a logical product family while minimizing disruption for existing users is an ongoing effort. One goal of the Jazz project is to improve the integration of existing products by providing the Jazz integration architecture and by contributing to the OSLC initiative as mentioned above.

The Jazz community site is the live development infrastructure for the Jazz project and the new Jazz products. We launched www.jazz.net in 2006 together with the availability of the first Rational Team Concert beta version. As you can see from the URL it is "ibm" neutral and focuses on Jazz products. Since then the community has rapidly grown and there are now over 17000 participants in Jazz forums. Customers really appreciate the direct communication channel with the development team. Given the positive feedback we have recently on-boarded two additional Jazz products on jazz.net: Rational Requirements Composer and Rational Quality Manager. This was combined with a reorganization of the site itself to optimize for the new projects, improve user experience, and create a high quality technical library of materials created by the development teams themselves to help educate and get teams set up and running and become productive very quickly. Additional Jazz products will on-board on jazz.net as they emerge. Some of the Jazz products will also be in flux, the point is that we make them available early, are transparent about their development and invite users to provide feedback.



RTC vs CQ and CC -- by SunSunich (1588709)

First of all let me congratulate you on the successful launch of version 2.0 of RTC and 1.0 JF. It is really great work, thank you and all the Jazz Team. The functionality of Rational Team Concert greatly overlaps with the ClearQuest and ClearCase. Why is it necessary to create a new product? Why not just release it as new versions of old? For customers, it could be easier to adapt. What is the future of CQ|CC, how you see it? Thank you.

With the Jazz project we are trying to do something new and do it in the open - but clearly we understand that we can't just leave the existing customers behind. As mentioned in the question about the Jazz project above, we have experienced several pain points with the existing tools. A common point of friction was the lack of integration which resulted in a lack of transparency. One lesson from Eclipse was that to achieve integration you need some common foundation or integration platform. Retrofitting a new integration platform wasn't a viable approach and in addition there were additional pressures to better support agile practices. While the Jazz project did start from the ground-up, we reused many ideas from CC and CQ. For example, the stream model from CC or the customization support from CQ. Once we went down this path it was obvious that we needed an integration solution for CC and CQ.

In RTC 1.0 we provided "synchronizer" connectors which can synchronize data between the Jazz and the CC or CQ repositories. With this functionality, an agile team can start to use RTC while periodically synchronizing their code with the "mothership" CC repository. For RTC 2.0 we have expanded the integration options with the support "bridge" connectors. A bridge doesn't synchronize the data but rather links artifacts across repositories. The CC Bridge allows linking a ClearCase UCM activity with an RTC work item. This allows CC users to continue using CC, but also benefit from the additional capabilities RTC offers such as agile planning support, work items, reports, dashboards, notifications etc. The CQ Bridge provides linking CQ Records and RTC work items. Finally, both RTC and CQ implement the Open Services for Life Cycle Collaboration specification for change management systems. This enables a third tool like the Rational Quality Manager to work with either RTC or CQ when it comes to filing defects for failed tests, for example.

To conclude, there is still a significant investment in enhancing ClearCase and ClearQuest and this will continue. RTC 2.0 provides good options for users who want to use RTC, CQ and CC together. All these options have been enriched further in 2.0 to enable gradual adoption.



Could Jazz Benefit from a Distributed Model? -- by A.K.A_Magnet (860822)

Do you think Jazz could gain from a distributed model, like git does for source control management, where the repositories can be forked and kept synchronized upstream/downstream (a bit like a "progressive fork" where fixes can be shared but the project can be forked for various reasons)? I heard there is a git connector in incubation but it seems to me more than just code artifacts should be distributed. After enjoying the many benefits of distributed SCMs, it's hard to go back, and I think at least issue management could gain from the same model.

Using the terminology from above the Git integration will be a bridge connector. It will be available as an incubator on jazz.net soon and it leverages the OSLC change management specification supported by RTC to create the linkage to RTC work items. Flowing changes across repositories is appealing and this feature is in our backlog. Some explorations to support a distributed Jazz SCM were already undertaken. Details on the current status and open issues are available on the developer wiki on jazz.net.

Cleaning Up Collaboration -- by eldavojohn (898314)

Jazz seems to rely heavily on developer community and their collaboration--and the influence for Jazz is said to be the World Wide Web. "The Jazz portfolio consists of a common platform and a set of tools that enable all of the members of the extended development team to collaborate more easily." The biggest problem I have with collaboration tools is the metadata. No one does it right. Someone writes a blog or uploads a document but doesn't tag it. Enterprise search is broken. Management hands us wikis yet no one has the time or patience to maintain them. The protective blanket of "it's agile, baby" shields us from any beat downs. And with every new tool I realize that it's not the tool that improves collaboration, it's the team. Look at Slashdot's tagging system. Does it help me that one hundred stories are tagged with "no"? Collaboration seems to spontaneously work but is often out of your control when it does and doesn't. How does Jazz fix these problems? How does Jazz improve collaboration when it seems to me that tools are such a small part of collaboration? Will a small development team be able to use such a large set of tools?

I agree that no tool can fix collaboration problems and the team plays the main part in the game. In the Jazz project, we are focusing on collaboration in the context of software artifacts like builds, change sets, test plans, defects, or baselines. Software artifacts are semantic rich, structured, and there are typically rules, permissions or approvals involved when it comes to changing artifacts. Jazz products can improve the collaboration around software artifacts by making these rules explicit. Our goal was that the tool not only acts as the police but also as a guide that helps team members conform to the rules. Let's use Rational Team Concert as an example. When a change set requires a review before it is shared with the team, the tool will not just flag you when the review is missing, it also offers to initiate the review process for you. This involves suspending the changes from the current work space, attaching them to a work item, and notifying the reviewer that there is a pending review.

Behind all this is a process component in the Jazz Foundation that allows you to configure these rules in a flexible way. The flexibility is required since otherwise tools can get easily in the way. A team operates differently during an early exploration of a product and one week before it ships. The rules can be specific to a particular role, or a particular team, and the development phase of the project. Here is an analog example to tagging a blog: checking in a change set and wanting to track the reason for the change. To guide users, you can define a precondition for the check-in operation that will ensure that the change set is linked to a work item tracking the reason for the change. When a user attempts to check-in a change set without an associated work item, the user is shown a list of work items that they own to choose from. If none of them apply, the user can easily create a new work item on the fly to complete the check-in. As a side effect the change set and the work item are now linked together. As you work with Rational Team Concert it establishes many such links between artifacts for you in the context of your work. For example, the work items that are fixed and included in a build are linked to the build result artifact. These links increase the transparency and allow everybody in the team to understand why something was changed, which will helps collaboration.

In addition to making team roles and rules more explicit, the tools improve collaboration by helping team members stay on top of changes that affect the whole team. The team's current sprint or iteration plan and the current progress are easily accessible for everybody to see. Team members are notified about events in their team and they can track event feeds using RSS readers and aggregators. Similarly, broken builds are linked to a work item where the discussion about the broken build takes place and this work item is then easily visible and accessible from the team's dashboard. These are just a few examples that illustrate how a tool can facilitate the collaboration in the context of software artifacts.

Now regarding the question on small development teams, RTC is designed to scale up from single teams working in a single release to multiple (even distributed) teams working on multiple releases and you can easily use RTC for small teams. In fact, the Express-C edition is free for teams up to three. Even a small team needs to do the backlog and sprint planning, needs continuous builds, needs to track progress, manages defects and wants to make the current state of the project visible on dashboards.

The Directions of the Eclipse Foundation -- by eldavojohn (898314)

Eclipse has been going on since the early 2000s and six days ago enjoyed the release of Galileo (v3.5). If you've had time to look at recent release, what are your opinions on what Eclipse has become? Has it made any wrong turns? How do you respond to criticisms of "bloat" or "too resource intensive"? Do you see it becoming more than what it is or transforming?

The Galileo release is quite an achievement. Over 30 projects with over 380 committers from over 40 organizations have contributed to this joint release. Obviously you do not want to consume Galileo all at once but rather pick one of the available packages that suit your needs. Now that my team's focus is on Jazz and Rational Team Concert, we have become consumers of many Eclipse projects. Having a release train with aligned project releases is a big help for us and is the right direction.

As consumers we also appreciate the API stability that Eclipse platform provides. Regarding bloat, the API stability is not free. It means that once something has surfaced as an API, you cannot remove or change it anymore. For example, if you look under the covers in the Eclipse source code, you find three different preference store mechanisms. This is the price you pay for API stability. Actually, Eclipse now includes some nice tools to track API changes and more.

The "too resource intensive" criticism depends on which packages/plug-ins you are using. Eclipse is an extensible system and is therefore vulnerable to contributions that can be too resource hungry. To keep a software system interesting to users, you need a constant flow of new features. The challenge is to preserve the performance and resource characteristics as new features are added. The Eclipse SDK team does measurements to track this. There is a set of performance JUnit tests that are run for each build. Once a test runs slower than the baseline from the previous release, the test turns red. The results are published for each build. Here is an example report from Eclipse 3.5. Based on our own use of Eclipse for developing RTC, I do not experience that Eclipse has become slower over time or more resource intensive.

Looking back, I don't necessarily see wrong turns, but rather some turns we probably could have taken but didn't. For example, the Eclipse platform is language agnostic and the Java Development tools built on top of the platform. There is a language toolkit layer (LTK) in between the platform that provides some generic infrastructure for implementing refactorings. However, this layer is thinner than implementers of new languages on Eclipse would like. They therefore have to resort to copy code from JDT. This is obviously not ideal. Even though we were aware of this issue, we didn't have the cycles to pursue a more generic language layer. Having said that, I must say that the Eclipse C Development tool is cool in Galileo and there is good support for many other languages. There also is the Dynamic Languages Toolkit incubator project at Eclipse.org.,



Will SWT and Swing ever merge in Eclipse? -- Fuzuli (135489)

I have to build quite complex tools using GEF and GMF, and there are many cases where I'd like to have the power of Java2D, and reuse some of the great frameworks out there built on Swing. More and more people are using AWT/SWT bridge, since SWT does not provide an underlying drawing framework as rich as Java2D. Eclipse has great things like EMF, and the platform is number one choice for tooling, but when it comes to things like Bezier curves etc, Swing is much easier to use. So are we going to see more developer friendly versions of Eclipse where Swing is more available to us?

SWT has continually improved its advanced graphics API for drawing Bezier curves, alpha blending, gradients etc. You can see it in action in the GraphicsExample (http://www.eclipse.org/swt/examples.php.) and there are several example snippets. If the current support is not sufficient, then you should file enhancement requests against the SWT component at eclipse.org.

As you mention SWT provides the support to enable the SWT/Swing integration and enables embedding an AWT hierarchy in a SWT widget hierarchy. The SWT team has currently no plans go beyond this. However, there is also the Albireo project at Eclipse.org. This is a technology project in incubation with the goal of simplifying the task of combining user interface components from the Swing and SWT toolkits.

A follow-up question -- by an anonymous reader

will SWT and the whole Eclipse workbench ever run in a Web browser? We have built a product based on SWT/Eclipse but our customers complain they cannot run it from a browser and instead have to download 200MB+ worth of plugins before they even start evaluating our product.

The eclipse e4 project has been investigating this very question. At EclipseCon 2009, the team provided an update and showed some interesting demos. You can find more details about the e4 project and a presentation covering the eclipse/desktop exploration online.

The short answer is that there is no free lunch for existing applications which generally must be re-factored to take into account that the application is now split between client and server. For your application to run in a web browser, the libraries it uses must also run in a web browser. In particular, one needs web equivalents of the workbench facilities that Eclipse RCP apps are based on. The approach currently being investigated is to provide "e4 workbench services". The e4 project is increasing support for running JavaScript on the desktop. As a consequence when the application is written against these workbench services, the same JS code can run unchanged in both the desktop and the web. In combination, this provides a path to achieving a good user experience in both the desktop and the web with some reuse.

A different approach being investigated in parallel is the eclipse Rich Ajax Project, which is also part of the Galileo release. RAP runs your SWT widgets remotely in a web browser, which have some other trade-offs as the approach used by e4.



On strong typing, and design patterns and testing -- by bADlOGIN (133391)

A number of weak typing language zealots like to point out that Design patterns is simply a way to make strongly typed languages "suck less". This can be a compelling argument in terms of simplicity and syntax in examples when you take a look at books like "Design Patterns in Ruby" compared with "Design Patterns: Elements of Reusable Object-Oriented Software". There's also an argument that strong typing is a form of tight coupling and antithetical to half of the Object Oriented axiom, "loose coupling, strong cohesion". Given the momentum in popularity that unit testing across multiple languages and development methodologies has (rightfully!) enjoyed, is it time to encourage language designers and programmers to move away from strong typing usage and substitute better testing practices?

The Design Patterns book is now over fifteen years old and it predates the Internet, Java, and XML, which is pretty amazing to me. However, it doesn't predate Smalltalk. Smalltalk is an influential and powerful dynamic object-oriented language. When working on the pattern catalog, we looked for known uses of our patterns in the Smalltalk libraries. If you study some of the pattern examples you can see how they can be implemented in Smalltalk. What is definitely true is that dynamic languages provide some interesting pattern implementation variations. I do not go as far as to say that static typing is in strong contrast to object-oriented principles. You can define loosely coupled systems in statically typed languages using interfaces and abstract classes. In addition, the more recent Dependency Injection pattern allows you to configure the dependencies of an object externally.



On the Current State of Academia? -- by eldavojohn (898314

I know a lot of people that are very vocal about what is right and wrong with education today. Especially college institutions: "No one teaches C, everyone teaches four years of Java, no one understands the theory, a CS grad doesn't even know what a model-view-controller pattern is." The list goes on. Since you have your doctorate and have probably spent a lot of time in research and academia, what's wrong with most computer science or engineering programs in general today? What would you like to see more or less of? Are there any subject directions recently taken (EJB, garbage collectors, interpreted languages) you'd like to comment on? You seem to be non-opposed to Java which, I'll admit, is rare to me for someone with a doctorate. I would like to hear your views since so often all I hear about Java is that it is slow and only good for people that want cheap software developed quick by beginner developers.

I cannot complain about the students that come out of nearby universities and that interview for positions on our team. Many of these students used Eiffel as their first language but they are all familiar with different languages using different paradigms. While they are not experts in EJBs, JFS, Dojo, Ruby on Rails or whatever, they have a solid CS background with lectures on patterns and are eager to learn. They come up to speed quickly with new technologies. This is required when joining a team like ours working on Rational Team Concert. For example getting started on the Rational Team Concert project requires a new team member to learn a mix of things such as Java, JavaScript, Dojo, CSS, C# (when working on the Visual Studio Client), Eclipse Plug-ins, REST and finally our agile development practices. One possible area of improvement is more familiarity with larger software systems and their architectures. Open Source project like Eclipse can serve as great study material. On the positive side I also observe that more students are starting to contribute to open source projects and can point to submitted patches in their CVs.

Last week you asked Jazz technical lead Erich Gamma questions about Jazz or anything else in his realm of expertise. Here are his answers, along with many external links and places to continue the conversation if you are interested. Why Jazz? -- by autophile (640621)

Could you explain, minus the marketing speak that seems to pervade the IBM site, what is Jazz, what makes it a community-oriented developer's site, why is it different from, say, sourceforge.net, and if Jazz is so community-oriented and yet apparently tied in to Rational, where are the community versions (not trials, not demos, not limited to the point of uselessness functionality) of Rational products?

Jazz is not a product but it is the name of a project that has the goal of building a new set of team products and to better integrate existing products.

The Jazz project was kicked-off in 2005. At that time we observed that the tooling situation for an individual developer using an IDE like Eclipse was pretty good. However, when it came to working as a team, our own experience and feedback from our customers indicated there are still many pain points. Our own experience comes from working for many years on Eclipse. We developed in a globally distributed team, spread across many time zones, and using many agile practices. The goal of the Jazz project was to take a fresh look at how teams work together and to build a new generation of products from the ground up that makes development more collaborative, but also more fun. We put the team at the center of all our designs. Initially we focused on development related pain points like support for iterative planning, painless build submissions, collaborating and fixing broken builds, simplifying parallel development, easy progress tracking, and finally improving transparency. Collaboration becomes more effective with increased transparency. One of the goals here is to make it easy for everybody to know what is going on in the project without having to ask. Since then we expanded the scope to cover the role of testers and business analysts. The set of new products that were built from the ground up include:

• Rational Team Concert (RTC): Provides a new customizable work item/defect tracking system, a continuous build system, a new source control system, and customizable agile planning that supports project management practices like the ones from Scrum, and dashboards and reports. Version 2.0 has actually shipped just a week ago.
• Rational Quality Manager (RQM): Provides test management, test planning, and includes a test lab management component.
• Rational Requirements Composer (RRC): Provides requirements definition for business analysts, client stakeholders and software developers using a variety of capture techniques.

These products share a common infrastructure using the building blocks we refer to as the Jazz Foundation. The Foundation provides a common set of services that can be leveraged by a Jazz tool. To enable integration with existing tools, the Jazz Foundation supports the Open Services for Lifecycle Collaboration initiative; an independent project to define a set of REST based protocols for sharing information across disparate tools. Actually, we are not only contributing to the specification, we have actually used the OSLC specifications for integrating the above tools.

Finally, we have grown a community around the Jazz project on www.jazz.net. Transparency and feedback are very important to us, not only for the tools we provide, but also for how we develop the products ourselves. To get that direct feedback, we do our development on jazz.net out in the open. On jazz.net you can interact with the development team, learn about our development plans, see our RTC powered dashboards, submit defects and enhancements, or download intermediate milestone builds.

If you want to read about how all these capabilities come together, there is a new eBook available for download. The eBook describes, using scenarios, how business analysts, development teams, and testers collaborate using the above mentioned products.

If you are interested in how we develop our products using Rational Team Concert in a globally distributed team, I did a web cast that sheds light on our development practices.

Rather than reading feature comparisons, I suggest that you jump in and give Rational Team Concert 2.0 a try. We made it very easy to kick the Team Concert tires. In less than 30 minutes you will have a running server, a client, and a sample project for a small team working on a fictitious JUnit release. There is also a community edition called Express-C (free for up to 3 users). Based on community feedback, we have made more features available in the Express-C edition. You can find the descriptions of the editions on the Jazz site. For those of you that do prefer to compare features, there is also a feature overview of RTC . If you have questions, feel free to post them to the user forum on jazz.net. Our development team is always there to answer questions.



Rational? -- by an anonymous reader

I work in a small shop that makes some use of Websphere Application Server and the Rational development tools. I basically find the entire structure of the IBM software offerings relating to the above technologies incomprehensible. Products are constantly being renamed, discontinued, bundled, unbundled and rebranded. Names are long, generic, and practically interchangeable, and so are the feature lists. How do you plan to run a community support site based around this hodge-podge? I would assume the volatile nature of IBM's software marketing makes your task something approaching impossible. How do you expect to build a strong developer community based around products that are in a constant flux? I don't see any way around ending up with a large number of granular, isolated communities that spring up around specific products and thrive for a year or two. In short, how do you plan to unify a developer community without IBM first unifying the software development platform that this community is to be built around?

Obviously the Rational portfolio has grown through acquisitions (Build Forge, Watchfire and Telelogic being the most recent), and the process of bringing these acquired products into a logical product family while minimizing disruption for existing users is an ongoing effort. One goal of the Jazz project is to improve the integration of existing products by providing the Jazz integration architecture and by contributing to the OSLC initiative as mentioned above.

The Jazz community site is the live development infrastructure for the Jazz project and the new Jazz products. We launched www.jazz.net in 2006 together with the availability of the first Rational Team Concert beta version. As you can see from the URL it is "ibm" neutral and focuses on Jazz products. Since then the community has rapidly grown and there are now over 17000 participants in Jazz forums. Customers really appreciate the direct communication channel with the development team. Given the positive feedback we have recently on-boarded two additional Jazz products on jazz.net: Rational Requirements Composer and Rational Quality Manager. This was combined with a reorganization of the site itself to optimize for the new projects, improve user experience, and create a high quality technical library of materials created by the development teams themselves to help educate and get teams set up and running and become productive very quickly. Additional Jazz products will on-board on jazz.net as they emerge. Some of the Jazz products will also be in flux, the point is that we make them available early, are transparent about their development and invite users to provide feedback.



RTC vs CQ and CC -- by SunSunich (1588709)

First of all let me congratulate you on the successful launch of version 2.0 of RTC and 1.0 JF. It is really great work, thank you and all the Jazz Team. The functionality of Rational Team Concert greatly overlaps with the ClearQuest and ClearCase. Why is it necessary to create a new product? Why not just release it as new versions of old? For customers, it could be easier to adapt. What is the future of CQ|CC, how you see it? Thank you.

With the Jazz project we are trying to do something new and do it in the open - but clearly we understand that we can't just leave the existing customers behind. As mentioned in the question about the Jazz project above, we have experienced several pain points with the existing tools. A common point of friction was the lack of integration which resulted in a lack of transparency. One lesson from Eclipse was that to achieve integration you need some common foundation or integration platform. Retrofitting a new integration platform wasn't a viable approach and in addition there were additional pressures to better support agile practices. While the Jazz project did start from the ground-up, we reused many ideas from CC and CQ. For example, the stream model from CC or the customization support from CQ. Once we went down this path it was obvious that we needed an integration solution for CC and CQ.

In RTC 1.0 we provided "synchronizer" connectors which can synchronize data between the Jazz and the CC or CQ repositories. With this functionality, an agile team can start to use RTC while periodically synchronizing their code with the "mothership" CC repository. For RTC 2.0 we have expanded the integration options with the support "bridge" connectors. A bridge doesn't synchronize the data but rather links artifacts across repositories. The CC Bridge allows linking a ClearCase UCM activity with an RTC work item. This allows CC users to continue using CC, but also benefit from the additional capabilities RTC offers such as agile planning support, work items, reports, dashboards, notifications etc. The CQ Bridge provides linking CQ Records and RTC work items. Finally, both RTC and CQ implement the Open Services for Life Cycle Collaboration specification for change management systems. This enables a third tool like the Rational Quality Manager to work with either RTC or CQ when it comes to filing defects for failed tests, for example.

To conclude, there is still a significant investment in enhancing ClearCase and ClearQuest and this will continue. RTC 2.0 provides good options for users who want to use RTC, CQ and CC together. All these options have been enriched further in 2.0 to enable gradual adoption.



Could Jazz Benefit from a Distributed Model? -- by A.K.A_Magnet (860822)

Do you think Jazz could gain from a distributed model, like git does for source control management, where the repositories can be forked and kept synchronized upstream/downstream (a bit like a "progressive fork" where fixes can be shared but the project can be forked for various reasons)? I heard there is a git connector in incubation but it seems to me more than just code artifacts should be distributed. After enjoying the many benefits of distributed SCMs, it's hard to go back, and I think at least issue management could gain from the same model.

Using the terminology from above the Git integration will be a bridge connector. It will be available as an incubator on jazz.net soon and it leverages the OSLC change management specification supported by RTC to create the linkage to RTC work items. Flowing changes across repositories is appealing and this feature is in our backlog. Some explorations to support a distributed Jazz SCM were already undertaken. Details on the current status and open issues are available on the developer wiki on jazz.net.

Cleaning Up Collaboration -- by eldavojohn (898314)

Jazz seems to rely heavily on developer community and their collaboration--and the influence for Jazz is said to be the World Wide Web. "The Jazz portfolio consists of a common platform and a set of tools that enable all of the members of the extended development team to collaborate more easily." The biggest problem I have with collaboration tools is the metadata. No one does it right. Someone writes a blog or uploads a document but doesn't tag it. Enterprise search is broken. Management hands us wikis yet no one has the time or patience to maintain them. The protective blanket of "it's agile, baby" shields us from any beat downs. And with every new tool I realize that it's not the tool that improves collaboration, it's the team. Look at Slashdot's tagging system. Does it help me that one hundred stories are tagged with "no"? Collaboration seems to spontaneously work but is often out of your control when it does and doesn't. How does Jazz fix these problems? How does Jazz improve collaboration when it seems to me that tools are such a small part of collaboration? Will a small development team be able to use such a large set of tools?

I agree that no tool can fix collaboration problems and the team plays the main part in the game. In the Jazz project, we are focusing on collaboration in the context of software artifacts like builds, change sets, test plans, defects, or baselines. Software artifacts are semantic rich, structured, and there are typically rules, permissions or approvals involved when it comes to changing artifacts. Jazz products can improve the collaboration around software artifacts by making these rules explicit. Our goal was that the tool not only acts as the police but also as a guide that helps team members conform to the rules. Let's use Rational Team Concert as an example. When a change set requires a review before it is shared with the team, the tool will not just flag you when the review is missing, it also offers to initiate the review process for you. This involves suspending the changes from the current work space, attaching them to a work item, and notifying the reviewer that there is a pending review.

Behind all this is a process component in the Jazz Foundation that allows you to configure these rules in a flexible way. The flexibility is required since otherwise tools can get easily in the way. A team operates differently during an early exploration of a product and one week before it ships. The rules can be specific to a particular role, or a particular team, and the development phase of the project. Here is an analog example to tagging a blog: checking in a change set and wanting to track the reason for the change. To guide users, you can define a precondition for the check-in operation that will ensure that the change set is linked to a work item tracking the reason for the change. When a user attempts to check-in a change set without an associated work item, the user is shown a list of work items that they own to choose from. If none of them apply, the user can easily create a new work item on the fly to complete the check-in. As a side effect the change set and the work item are now linked together. As you work with Rational Team Concert it establishes many such links between artifacts for you in the context of your work. For example, the work items that are fixed and included in a build are linked to the build result artifact. These links increase the transparency and allow everybody in the team to understand why something was changed, which will helps collaboration.

In addition to making team roles and rules more explicit, the tools improve collaboration by helping team members stay on top of changes that affect the whole team. The team's current sprint or iteration plan and the current progress are easily accessible for everybody to see. Team members are notified about events in their team and they can track event feeds using RSS readers and aggregators. Similarly, broken builds are linked to a work item where the discussion about the broken build takes place and this work item is then easily visible and accessible from the team's dashboard. These are just a few examples that illustrate how a tool can facilitate the collaboration in the context of software artifacts.

Now regarding the question on small development teams, RTC is designed to scale up from single teams working in a single release to multiple (even distributed) teams working on multiple releases and you can easily use RTC for small teams. In fact, the Express-C edition is free for teams up to three. Even a small team needs to do the backlog and sprint planning, needs continuous builds, needs to track progress, manages defects and wants to make the current state of the project visible on dashboards.

The Directions of the Eclipse Foundation -- by eldavojohn (898314)

Eclipse has been going on since the early 2000s and six days ago enjoyed the release of Galileo (v3.5). If you've had time to look at recent release, what are your opinions on what Eclipse has become? Has it made any wrong turns? How do you respond to criticisms of "bloat" or "too resource intensive"? Do you see it becoming more than what it is or transforming?

The Galileo release is quite an achievement. Over 30 projects with over 380 committers from over 40 organizations have contributed to this joint release. Obviously you do not want to consume Galileo all at once but rather pick one of the available packages that suit your needs. Now that my team's focus is on Jazz and Rational Team Concert, we have become consumers of many Eclipse projects. Having a release train with aligned project releases is a big help for us and is the right direction.

As consumers we also appreciate the API stability that Eclipse platform provides. Regarding bloat, the API stability is not free. It means that once something has surfaced as an API, you cannot remove or change it anymore. For example, if you look under the covers in the Eclipse source code, you find three different preference store mechanisms. This is the price you pay for API stability. Actually, Eclipse now includes some nice tools to track API changes and more.

The "too resource intensive" criticism depends on which packages/plug-ins you are using. Eclipse is an extensible system and is therefore vulnerable to contributions that can be too resource hungry. To keep a software system interesting to users, you need a constant flow of new features. The challenge is to preserve the performance and resource characteristics as new features are added. The Eclipse SDK team does measurements to track this. There is a set of performance JUnit tests that are run for each build. Once a test runs slower than the baseline from the previous release, the test turns red. The results are published for each build. Here is an example report from Eclipse 3.5. Based on our own use of Eclipse for developing RTC, I do not experience that Eclipse has become slower over time or more resource intensive.

Looking back, I don't necessarily see wrong turns, but rather some turns we probably could have taken but didn't. For example, the Eclipse platform is language agnostic and the Java Development tools built on top of the platform. There is a language toolkit layer (LTK) in between the platform that provides some generic infrastructure for implementing refactorings. However, this layer is thinner than implementers of new languages on Eclipse would like. They therefore have to resort to copy code from JDT. This is obviously not ideal. Even though we were aware of this issue, we didn't have the cycles to pursue a more generic language layer. Having said that, I must say that the Eclipse C Development tool is cool in Galileo and there is good support for many other languages. There also is the Dynamic Languages Toolkit incubator project at Eclipse.org.,



Will SWT and Swing ever merge in Eclipse? -- Fuzuli (135489)

I have to build quite complex tools using GEF and GMF, and there are many cases where I'd like to have the power of Java2D, and reuse some of the great frameworks out there built on Swing. More and more people are using AWT/SWT bridge, since SWT does not provide an underlying drawing framework as rich as Java2D. Eclipse has great things like EMF, and the platform is number one choice for tooling, but when it comes to things like Bezier curves etc, Swing is much easier to use. So are we going to see more developer friendly versions of Eclipse where Swing is more available to us?

SWT has continually improved its advanced graphics API for drawing Bezier curves, alpha blending, gradients etc. You can see it in action in the GraphicsExample (http://www.eclipse.org/swt/examples.php.) and there are several example snippets. If the current support is not sufficient, then you should file enhancement requests against the SWT component at eclipse.org.

As you mention SWT provides the support to enable the SWT/Swing integration and enables embedding an AWT hierarchy in a SWT widget hierarchy. The SWT team has currently no plans go beyond this. However, there is also the Albireo project at Eclipse.org. This is a technology project in incubation with the goal of simplifying the task of combining user interface components from the Swing and SWT toolkits.

A follow-up question -- by an anonymous reader

will SWT and the whole Eclipse workbench ever run in a Web browser? We have built a product based on SWT/Eclipse but our customers complain they cannot run it from a browser and instead have to download 200MB+ worth of plugins before they even start evaluating our product.

The eclipse e4 project has been investigating this very question. At EclipseCon 2009, the team provided an update and showed some interesting demos. You can find more details about the e4 project and a presentation covering the eclipse/desktop exploration online.

The short answer is that there is no free lunch for existing applications which generally must be re-factored to take into account that the application is now split between client and server. For your application to run in a web browser, the libraries it uses must also run in a web browser. In particular, one needs web equivalents of the workbench facilities that Eclipse RCP apps are based on. The approach currently being investigated is to provide "e4 workbench services". The e4 project is increasing support for running JavaScript on the desktop. As a consequence when the application is written against these workbench services, the same JS code can run unchanged in both the desktop and the web. In combination, this provides a path to achieving a good user experience in both the desktop and the web with some reuse.

A different approach being investigated in parallel is the eclipse Rich Ajax Project, which is also part of the Galileo release. RAP runs your SWT widgets remotely in a web browser, which have some other trade-offs as the approach used by e4.



On strong typing, and design patterns and testing -- by bADlOGIN (133391)

A number of weak typing language zealots like to point out that Design patterns is simply a way to make strongly typed languages "suck less". This can be a compelling argument in terms of simplicity and syntax in examples when you take a look at books like "Design Patterns in Ruby" compared with "Design Patterns: Elements of Reusable Object-Oriented Software". There's also an argument that strong typing is a form of tight coupling and antithetical to half of the Object Oriented axiom, "loose coupling, strong cohesion". Given the momentum in popularity that unit testing across multiple languages and development methodologies has (rightfully!) enjoyed, is it time to encourage language designers and programmers to move away from strong typing usage and substitute better testing practices?

The Design Patterns book is now over fifteen years old and it predates the Internet, Java, and XML, which is pretty amazing to me. However, it doesn't predate Smalltalk. Smalltalk is an influential and powerful dynamic object-oriented language. When working on the pattern catalog, we looked for known uses of our patterns in the Smalltalk libraries. If you study some of the pattern examples you can see how they can be implemented in Smalltalk. What is definitely true is that dynamic languages provide some interesting pattern implementation variations. I do not go as far as to say that static typing is in strong contrast to object-oriented principles. You can define loosely coupled systems in statically typed languages using interfaces and abstract classes. In addition, the more recent Dependency Injection pattern allows you to configure the dependencies of an object externally.



On the Current State of Academia? -- by eldavojohn (898314

I know a lot of people that are very vocal about what is right and wrong with education today. Especially college institutions: "No one teaches C, everyone teaches four years of Java, no one understands the theory, a CS grad doesn't even know what a model-view-controller pattern is." The list goes on. Since you have your doctorate and have probably spent a lot of time in research and academia, what's wrong with most computer science or engineering programs in general today? What would you like to see more or less of? Are there any subject directions recently taken (EJB, garbage collectors, interpreted languages) you'd like to comment on? You seem to be non-opposed to Java which, I'll admit, is rare to me for someone with a doctorate. I would like to hear your views since so often all I hear about Java is that it is slow and only good for people that want cheap software developed quick by beginner developers.

I cannot complain about the students that come out of nearby universities and that interview for positions on our team. Many of these students used Eiffel as their first language but they are all familiar with different languages using different paradigms. While they are not experts in EJBs, JFS, Dojo, Ruby on Rails or whatever, they have a solid CS background with lectures on patterns and are eager to learn. They come up to speed quickly with new technologies. This is required when joining a team like ours working on Rational Team Concert. For example getting started on the Rational Team Concert project requires a new team member to learn a mix of things such as Java, JavaScript, Dojo, CSS, C# (when working on the Visual Studio Client), Eclipse Plug-ins, REST and finally our agile development practices. One possible area of improvement is more familiarity with larger software systems and their architectures. Open Source project like Eclipse can serve as great study material. On the positive side I also observe that more students are starting to contribute to open source projects and can point to submitted patches in their CVs.

Last week you asked Jazz technical lead Erich Gamma questions about Jazz or anything else in his realm of expertise. Here are his answers, along with many external links and places to continue the conversation if you are interested. Why Jazz? -- by autophile (640621)

Could you explain, minus the marketing speak that seems to pervade the IBM site, what is Jazz, what makes it a community-oriented developer's site, why is it different from, say, sourceforge.net, and if Jazz is so community-oriented and yet apparently tied in to Rational, where are the community versions (not trials, not demos, not limited to the point of uselessness functionality) of Rational products?

Jazz is not a product but it is the name of a project that has the goal of building a new set of team products and to better integrate existing products.

The Jazz project was kicked-off in 2005. At that time we observed that the tooling situation for an individual developer using an IDE like Eclipse was pretty good. However, when it came to working as a team, our own experience and feedback from our customers indicated there are still many pain points. Our own experience comes from working for many years on Eclipse. We developed in a globally distributed team, spread across many time zones, and using many agile practices. The goal of the Jazz project was to take a fresh look at how teams work together and to build a new generation of products from the ground up that makes development more collaborative, but also more fun. We put the team at the center of all our designs. Initially we focused on development related pain points like support for iterative planning, painless build submissions, collaborating and fixing broken builds, simplifying parallel development, easy progress tracking, and finally improving transparency. Collaboration becomes more effective with increased transparency. One of the goals here is to make it easy for everybody to know what is going on in the project without having to ask. Since then we expanded the scope to cover the role of testers and business analysts. The set of new products that were built from the ground up include:

• Rational Team Concert (RTC): Provides a new customizable work item/defect tracking system, a continuous build system, a new source control system, and customizable agile planning that supports project management practices like the ones from Scrum, and dashboards and reports. Version 2.0 has actually shipped just a week ago.
• Rational Quality Manager (RQM): Provides test management, test planning, and includes a test lab management component.
• Rational Requirements Composer (RRC): Provides requirements definition for business analysts, client stakeholders and software developers using a variety of capture techniques.

These products share a common infrastructure using the building blocks we refer to as the Jazz Foundation. The Foundation provides a common set of services that can be leveraged by a Jazz tool. To enable integration with existing tools, the Jazz Foundation supports the Open Services for Lifecycle Collaboration initiative; an independent project to define a set of REST based protocols for sharing information across disparate tools. Actually, we are not only contributing to the specification, we have actually used the OSLC specifications for integrating the above tools.

Finally, we have grown a community around the Jazz project on www.jazz.net. Transparency and feedback are very important to us, not only for the tools we provide, but also for how we develop the products ourselves. To get that direct feedback, we do our development on jazz.net out in the open. On jazz.net you can interact with the development team, learn about our development plans, see our RTC powered dashboards, submit defects and enhancements, or download intermediate milestone builds.

If you want to read about how all these capabilities come together, there is a new eBook available for download. The eBook describes, using scenarios, how business analysts, development teams, and testers collaborate using the above mentioned products.

If you are interested in how we develop our products using Rational Team Concert in a globally distributed team, I did a web cast that sheds light on our development practices.

Rather than reading feature comparisons, I suggest that you jump in and give Rational Team Concert 2.0 a try. We made it very easy to kick the Team Concert tires. In less than 30 minutes you will have a running server, a client, and a sample project for a small team working on a fictitious JUnit release. There is also a community edition called Express-C (free for up to 3 users). Based on community feedback, we have made more features available in the Express-C edition. You can find the descriptions of the editions on the Jazz site. For those of you that do prefer to compare features, there is also a feature overview of RTC . If you have questions, feel free to post them to the user forum on jazz.net. Our development team is always there to answer questions.



Rational? -- by an anonymous reader

I work in a small shop that makes some use of Websphere Application Server and the Rational development tools. I basically find the entire structure of the IBM software offerings relating to the above technologies incomprehensible. Products are constantly being renamed, discontinued, bundled, unbundled and rebranded. Names are long, generic, and practically interchangeable, and so are the feature lists. How do you plan to run a community support site based around this hodge-podge? I would assume the volatile nature of IBM's software marketing makes your task something approaching impossible. How do you expect to build a strong developer community based around products that are in a constant flux? I don't see any way around ending up with a large number of granular, isolated communities that spring up around specific products and thrive for a year or two. In short, how do you plan to unify a developer community without IBM first unifying the software development platform that this community is to be built around?

Obviously the Rational portfolio has grown through acquisitions (Build Forge, Watchfire and Telelogic being the most recent), and the process of bringing these acquired products into a logical product family while minimizing disruption for existing users is an ongoing effort. One goal of the Jazz project is to improve the integration of existing products by providing the Jazz integration architecture and by contributing to the OSLC initiative as mentioned above.

The Jazz community site is the live development infrastructure for the Jazz project and the new Jazz products. We launched www.jazz.net in 2006 together with the availability of the first Rational Team Concert beta version. As you can see from the URL it is "ibm" neutral and focuses on Jazz products. Since then the community has rapidly grown and there are now over 17000 participants in Jazz forums. Customers really appreciate the direct communication channel with the development team. Given the positive feedback we have recently on-boarded two additional Jazz products on jazz.net: Rational Requirements Composer and Rational Quality Manager. This was combined with a reorganization of the site itself to optimize for the new projects, improve user experience, and create a high quality technical library of materials created by the development teams themselves to help educate and get teams set up and running and become productive very quickly. Additional Jazz products will on-board on jazz.net as they emerge. Some of the Jazz products will also be in flux, the point is that we make them available early, are transparent about their development and invite users to provide feedback.



RTC vs CQ and CC -- by SunSunich (1588709)

First of all let me congratulate you on the successful launch of version 2.0 of RTC and 1.0 JF. It is really great work, thank you and all the Jazz Team. The functionality of Rational Team Concert greatly overlaps with the ClearQuest and ClearCase. Why is it necessary to create a new product? Why not just release it as new versions of old? For customers, it could be easier to adapt. What is the future of CQ|CC, how you see it? Thank you.

With the Jazz project we are trying to do something new and do it in the open - but clearly we understand that we can't just leave the existing customers behind. As mentioned in the question about the Jazz project above, we have experienced several pain points with the existing tools. A common point of friction was the lack of integration which resulted in a lack of transparency. One lesson from Eclipse was that to achieve integration you need some common foundation or integration platform. Retrofitting a new integration platform wasn't a viable approach and in addition there were additional pressures to better support agile practices. While the Jazz project did start from the ground-up, we reused many ideas from CC and CQ. For example, the stream model from CC or the customization support from CQ. Once we went down this path it was obvious that we needed an integration solution for CC and CQ.

In RTC 1.0 we provided "synchronizer" connectors which can synchronize data between the Jazz and the CC or CQ repositories. With this functionality, an agile team can start to use RTC while periodically synchronizing their code with the "mothership" CC repository. For RTC 2.0 we have expanded the integration options with the support "bridge" connectors. A bridge doesn't synchronize the data but rather links artifacts across repositories. The CC Bridge allows linking a ClearCase UCM activity with an RTC work item. This allows CC users to continue using CC, but also benefit from the additional capabilities RTC offers such as agile planning support, work items, reports, dashboards, notifications etc. The CQ Bridge provides linking CQ Records and RTC work items. Finally, both RTC and CQ implement the Open Services for Life Cycle Collaboration specification for change management systems. This enables a third tool like the Rational Quality Manager to work with either RTC or CQ when it comes to filing defects for failed tests, for example.

To conclude, there is still a significant investment in enhancing ClearCase and ClearQuest and this will continue. RTC 2.0 provides good options for users who want to use RTC, CQ and CC together. All these options have been enriched further in 2.0 to enable gradual adoption.



Could Jazz Benefit from a Distributed Model? -- by A.K.A_Magnet (860822)

Do you think Jazz could gain from a distributed model, like git does for source control management, where the repositories can be forked and kept synchronized upstream/downstream (a bit like a "progressive fork" where fixes can be shared but the project can be forked for various reasons)? I heard there is a git connector in incubation but it seems to me more than just code artifacts should be distributed. After enjoying the many benefits of distributed SCMs, it's hard to go back, and I think at least issue management could gain from the same model.

Using the terminology from above the Git integration will be a bridge connector. It will be available as an incubator on jazz.net soon and it leverages the OSLC change management specification supported by RTC to create the linkage to RTC work items. Flowing changes across repositories is appealing and this feature is in our backlog. Some explorations to support a distributed Jazz SCM were already undertaken. Details on the current status and open issues are available on the developer wiki on jazz.net.

Cleaning Up Collaboration -- by eldavojohn (898314)

Jazz seems to rely heavily on developer community and their collaboration--and the influence for Jazz is said to be the World Wide Web. "The Jazz portfolio consists of a common platform and a set of tools that enable all of the members of the extended development team to collaborate more easily." The biggest problem I have with collaboration tools is the metadata. No one does it right. Someone writes a blog or uploads a document but doesn't tag it. Enterprise search is broken. Management hands us wikis yet no one has the time or patience to maintain them. The protective blanket of "it's agile, baby" shields us from any beat downs. And with every new tool I realize that it's not the tool that improves collaboration, it's the team. Look at Slashdot's tagging system. Does it help me that one hundred stories are tagged with "no"? Collaboration seems to spontaneously work but is often out of your control when it does and doesn't. How does Jazz fix these problems? How does Jazz improve collaboration when it seems to me that tools are such a small part of collaboration? Will a small development team be able to use such a large set of tools?

I agree that no tool can fix collaboration problems and the team plays the main part in the game. In the Jazz project, we are focusing on collaboration in the context of software artifacts like builds, change sets, test plans, defects, or baselines. Software artifacts are semantic rich, structured, and there are typically rules, permissions or approvals involved when it comes to changing artifacts. Jazz products can improve the collaboration around software artifacts by making these rules explicit. Our goal was that the tool not only acts as the police but also as a guide that helps team members conform to the rules. Let's use Rational Team Concert as an example. When a change set requires a review before it is shared with the team, the tool will not just flag you when the review is missing, it also offers to initiate the review process for you. This involves suspending the changes from the current work space, attaching them to a work item, and notifying the reviewer that there is a pending review.

Behind all this is a process component in the Jazz Foundation that allows you to configure these rules in a flexible way. The flexibility is required since otherwise tools can get easily in the way. A team operates differently during an early exploration of a product and one week before it ships. The rules can be specific to a particular role, or a particular team, and the development phase of the project. Here is an analog example to tagging a blog: checking in a change set and wanting to track the reason for the change. To guide users, you can define a precondition for the check-in operation that will ensure that the change set is linked to a work item tracking the reason for the change. When a user attempts to check-in a change set without an associated work item, the user is shown a list of work items that they own to choose from. If none of them apply, the user can easily create a new work item on the fly to complete the check-in. As a side effect the change set and the work item are now linked together. As you work with Rational Team Concert it establishes many such links between artifacts for you in the context of your work. For example, the work items that are fixed and included in a build are linked to the build result artifact. These links increase the transparency and allow everybody in the team to understand why something was changed, which will helps collaboration.

In addition to making team roles and rules more explicit, the tools improve collaboration by helping team members stay on top of changes that affect the whole team. The team's current sprint or iteration plan and the current progress are easily accessible for everybody to see. Team members are notified about events in their team and they can track event feeds using RSS readers and aggregators. Similarly, broken builds are linked to a work item where the discussion about the broken build takes place and this work item is then easily visible and accessible from the team's dashboard. These are just a few examples that illustrate how a tool can facilitate the collaboration in the context of software artifacts.

Now regarding the question on small development teams, RTC is designed to scale up from single teams working in a single release to multiple (even distributed) teams working on multiple releases and you can easily use RTC for small teams. In fact, the Express-C edition is free for teams up to three. Even a small team needs to do the backlog and sprint planning, needs continuous builds, needs to track progress, manages defects and wants to make the current state of the project visible on dashboards.

The Directions of the Eclipse Foundation -- by eldavojohn (898314)

Eclipse has been going on since the early 2000s and six days ago enjoyed the release of Galileo (v3.5). If you've had time to look at recent release, what are your opinions on what Eclipse has become? Has it made any wrong turns? How do you respond to criticisms of "bloat" or "too resource intensive"? Do you see it becoming more than what it is or transforming?

The Galileo release is quite an achievement. Over 30 projects with over 380 committers from over 40 organizations have contributed to this joint release. Obviously you do not want to consume Galileo all at once but rather pick one of the available packages that suit your needs. Now that my team's focus is on Jazz and Rational Team Concert, we have become consumers of many Eclipse projects. Having a release train with aligned project releases is a big help for us and is the right direction.

As consumers we also appreciate the API stability that Eclipse platform provides. Regarding bloat, the API stability is not free. It means that once something has surfaced as an API, you cannot remove or change it anymore. For example, if you look under the covers in the Eclipse source code, you find three different preference store mechanisms. This is the price you pay for API stability. Actually, Eclipse now includes some nice tools to track API changes and more.

The "too resource intensive" criticism depends on which packages/plug-ins you are using. Eclipse is an extensible system and is therefore vulnerable to contributions that can be too resource hungry. To keep a software system interesting to users, you need a constant flow of new features. The challenge is to preserve the performance and resource characteristics as new features are added. The Eclipse SDK team does measurements to track this. There is a set of performance JUnit tests that are run for each build. Once a test runs slower than the baseline from the previous release, the test turns red. The results are published for each build. Here is an example report from Eclipse 3.5. Based on our own use of Eclipse for developing RTC, I do not experience that Eclipse has become slower over time or more resource intensive.

Looking back, I don't necessarily see wrong turns, but rather some turns we probably could have taken but didn't. For example, the Eclipse platform is language agnostic and the Java Development tools built on top of the platform. There is a language toolkit layer (LTK) in between the platform that provides some generic infrastructure for implementing refactorings. However, this layer is thinner than implementers of new languages on Eclipse would like. They therefore have to resort to copy code from JDT. This is obviously not ideal. Even though we were aware of this issue, we didn't have the cycles to pursue a more generic language layer. Having said that, I must say that the Eclipse C Development tool is cool in Galileo and there is good support for many other languages. There also is the Dynamic Languages Toolkit incubator project at Eclipse.org.,



Will SWT and Swing ever merge in Eclipse? -- Fuzuli (135489)

I have to build quite complex tools using GEF and GMF, and there are many cases where I'd like to have the power of Java2D, and reuse some of the great frameworks out there built on Swing. More and more people are using AWT/SWT bridge, since SWT does not provide an underlying drawing framework as rich as Java2D. Eclipse has great things like EMF, and the platform is number one choice for tooling, but when it comes to things like Bezier curves etc, Swing is much easier to use. So are we going to see more developer friendly versions of Eclipse where Swing is more available to us?

SWT has continually improved its advanced graphics API for drawing Bezier curves, alpha blending, gradients etc. You can see it in action in the GraphicsExample (http://www.eclipse.org/swt/examples.php.) and there are several example snippets. If the current support is not sufficient, then you should file enhancement requests against the SWT component at eclipse.org.

As you mention SWT provides the support to enable the SWT/Swing integration and enables embedding an AWT hierarchy in a SWT widget hierarchy. The SWT team has currently no plans go beyond this. However, there is also the Albireo project at Eclipse.org. This is a technology project in incubation with the goal of simplifying the task of combining user interface components from the Swing and SWT toolkits.

A follow-up question -- by an anonymous reader

will SWT and the whole Eclipse workbench ever run in a Web browser? We have built a product based on SWT/Eclipse but our customers complain they cannot run it from a browser and instead have to download 200MB+ worth of plugins before they even start evaluating our product.

The eclipse e4 project has been investigating this very question. At EclipseCon 2009, the team provided an update and showed some interesting demos. You can find more details about the e4 project and a presentation covering the eclipse/desktop exploration online.

The short answer is that there is no free lunch for existing applications which generally must be re-factored to take into account that the application is now split between client and server. For your application to run in a web browser, the libraries it uses must also run in a web browser. In particular, one needs web equivalents of the workbench facilities that Eclipse RCP apps are based on. The approach currently being investigated is to provide "e4 workbench services". The e4 project is increasing support for running JavaScript on the desktop. As a consequence when the application is written against these workbench services, the same JS code can run unchanged in both the desktop and the web. In combination, this provides a path to achieving a good user experience in both the desktop and the web with some reuse.

A different approach being investigated in parallel is the eclipse Rich Ajax Project, which is also part of the Galileo release. RAP runs your SWT widgets remotely in a web browser, which have some other trade-offs as the approach used by e4.



On strong typing, and design patterns and testing -- by bADlOGIN (133391)

A number of weak typing language zealots like to point out that Design patterns is simply a way to make strongly typed languages "suck less". This can be a compelling argument in terms of simplicity and syntax in examples when you take a look at books like "Design Patterns in Ruby" compared with "Design Patterns: Elements of Reusable Object-Oriented Software". There's also an argument that strong typing is a form of tight coupling and antithetical to half of the Object Oriented axiom, "loose coupling, strong cohesion". Given the momentum in popularity that unit testing across multiple languages and development methodologies has (rightfully!) enjoyed, is it time to encourage language designers and programmers to move away from strong typing usage and substitute better testing practices?

The Design Patterns book is now over fifteen years old and it predates the Internet, Java, and XML, which is pretty amazing to me. However, it doesn't predate Smalltalk. Smalltalk is an influential and powerful dynamic object-oriented language. When working on the pattern catalog, we looked for known uses of our patterns in the Smalltalk libraries. If you study some of the pattern examples you can see how they can be implemented in Smalltalk. What is definitely true is that dynamic languages provide some interesting pattern implementation variations. I do not go as far as to say that static typing is in strong contrast to object-oriented principles. You can define loosely coupled systems in statically typed languages using interfaces and abstract classes. In addition, the more recent Dependency Injection pattern allows you to configure the dependencies of an object externally.



On the Current State of Academia? -- by eldavojohn (898314

I know a lot of people that are very vocal about what is right and wrong with education today. Especially college institutions: "No one teaches C, everyone teaches four years of Java, no one understands the theory, a CS grad doesn't even know what a model-view-controller pattern is." The list goes on. Since you have your doctorate and have probably spent a lot of time in research and academia, what's wrong with most computer science or engineering programs in general today? What would you like to see more or less of? Are there any subject directions recently taken (EJB, garbage collectors, interpreted languages) you'd like to comment on? You seem to be non-opposed to Java which, I'll admit, is rare to me for someone with a doctorate. I would like to hear your views since so often all I hear about Java is that it is slow and only good for people that want cheap software developed quick by beginner developers.

I cannot complain about the students that come out of nearby universities and that interview for positions on our team. Many of these students used Eiffel as their first language but they are all familiar with different languages using different paradigms. While they are not experts in EJBs, JFS, Dojo, Ruby on Rails or whatever, they have a solid CS background with lectures on patterns and are eager to learn. They come up to speed quickly with new technologies. This is required when joining a team like ours working on Rational Team Concert. For example getting started on the Rational Team Concert project requires a new team member to learn a mix of things such as Java, JavaScript, Dojo, CSS, C# (when working on the Visual Studio Client), Eclipse Plug-ins, REST and finally our agile development practices. One possible area of improvement is more familiarity with larger software systems and their architectures. Open Source project like Eclipse can serve as great study material. On the positive side I also observe that more students are starting to contribute to open source projects and can point to submitted patches in their CVs.

Last week you asked Jazz technical lead Erich Gamma questions about Jazz or anything else in his realm of expertise. Here are his answers, along with many external links and places to continue the conversation if you are interested. Why Jazz? -- by autophile (640621)

Could you explain, minus the marketing speak that seems to pervade the IBM site, what is Jazz, what makes it a community-oriented developer's site, why is it different from, say, sourceforge.net, and if Jazz is so community-oriented and yet apparently tied in to Rational, where are the community versions (not trials, not demos, not limited to the point of uselessness functionality) of Rational products?

Jazz is not a product but it is the name of a project that has the goal of building a new set of team products and to better integrate existing products.

The Jazz project was kicked-off in 2005. At that time we observed that the tooling situation for an individual developer using an IDE like Eclipse was pretty good. However, when it came to working as a team, our own experience and feedback from our customers indicated there are still many pain points. Our own experience comes from working for many years on Eclipse. We developed in a globally distributed team, spread across many time zones, and using many agile practices. The goal of the Jazz project was to take a fresh look at how teams work together and to build a new generation of products from the ground up that makes development more collaborative, but also more fun. We put the team at the center of all our designs. Initially we focused on development related pain points like support for iterative planning, painless build submissions, collaborating and fixing broken builds, simplifying parallel development, easy progress tracking, and finally improving transparency. Collaboration becomes more effective with increased transparency. One of the goals here is to make it easy for everybody to know what is going on in the project without having to ask. Since then we expanded the scope to cover the role of testers and business analysts. The set of new products that were built from the ground up include:

• Rational Team Concert (RTC): Provides a new customizable work item/defect tracking system, a continuous build system, a new source control system, and customizable agile planning that supports project management practices like the ones from Scrum, and dashboards and reports. Version 2.0 has actually shipped just a week ago.
• Rational Quality Manager (RQM): Provides test management, test planning, and includes a test lab management component.
• Rational Requirements Composer (RRC): Provides requirements definition for business analysts, client stakeholders and software developers using a variety of capture techniques.

These products share a common infrastructure using the building blocks we refer to as the Jazz Foundation. The Foundation provides a common set of services that can be leveraged by a Jazz tool. To enable integration with existing tools, the Jazz Foundation supports the Open Services for Lifecycle Collaboration initiative; an independent project to define a set of REST based protocols for sharing information across disparate tools. Actually, we are not only contributing to the specification, we have actually used the OSLC specifications for integrating the above tools.

Finally, we have grown a community around the Jazz project on www.jazz.net. Transparency and feedback are very important to us, not only for the tools we provide, but also for how we develop the products ourselves. To get that direct feedback, we do our development on jazz.net out in the open. On jazz.net you can interact with the development team, learn about our development plans, see our RTC powered dashboards, submit defects and enhancements, or download intermediate milestone builds.

If you want to read about how all these capabilities come together, there is a new eBook available for download. The eBook describes, using scenarios, how business analysts, development teams, and testers collaborate using the above mentioned products.

If you are interested in how we develop our products using Rational Team Concert in a globally distributed team, I did a web cast that sheds light on our development practices.

Rather than reading feature comparisons, I suggest that you jump in and give Rational Team Concert 2.0 a try. We made it very easy to kick the Team Concert tires. In less than 30 minutes you will have a running server, a client, and a sample project for a small team working on a fictitious JUnit release. There is also a community edition called Express-C (free for up to 3 users). Based on community feedback, we have made more features available in the Express-C edition. You can find the descriptions of the editions on the Jazz site. For those of you that do prefer to compare features, there is also a feature overview of RTC . If you have questions, feel free to post them to the user forum on jazz.net. Our development team is always there to answer questions.



Rational? -- by an anonymous reader

I work in a small shop that makes some use of Websphere Application Server and the Rational development tools. I basically find the entire structure of the IBM software offerings relating to the above technologies incomprehensible. Products are constantly being renamed, discontinued, bundled, unbundled and rebranded. Names are long, generic, and practically interchangeable, and so are the feature lists. How do you plan to run a community support site based around this hodge-podge? I would assume the volatile nature of IBM's software marketing makes your task something approaching impossible. How do you expect to build a strong developer community based around products that are in a constant flux? I don't see any way around ending up with a large number of granular, isolated communities that spring up around specific products and thrive for a year or two. In short, how do you plan to unify a developer community without IBM first unifying the software development platform that this community is to be built around?

Obviously the Rational portfolio has grown through acquisitions (Build Forge, Watchfire and Telelogic being the most recent), and the process of bringing these acquired products into a logical product family while minimizing disruption for existing users is an ongoing effort. One goal of the Jazz project is to improve the integration of existing products by providing the Jazz integration architecture and by contributing to the OSLC initiative as mentioned above.

The Jazz community site is the live development infrastructure for the Jazz project and the new Jazz products. We launched www.jazz.net in 2006 together with the availability of the first Rational Team Concert beta version. As you can see from the URL it is "ibm" neutral and focuses on Jazz products. Since then the community has rapidly grown and there are now over 17000 participants in Jazz forums. Customers really appreciate the direct communication channel with the development team. Given the positive feedback we have recently on-boarded two additional Jazz products on jazz.net: Rational Requirements Composer and Rational Quality Manager. This was combined with a reorganization of the site itself to optimize for the new projects, improve user experience, and create a high quality technical library of materials created by the development teams themselves to help educate and get teams set up and running and become productive very quickly. Additional Jazz products will on-board on jazz.net as they emerge. Some of the Jazz products will also be in flux, the point is that we make them available early, are transparent about their development and invite users to provide feedback.



RTC vs CQ and CC -- by SunSunich (1588709)

First of all let me congratulate you on the successful launch of version 2.0 of RTC and 1.0 JF. It is really great work, thank you and all the Jazz Team. The functionality of Rational Team Concert greatly overlaps with the ClearQuest and ClearCase. Why is it necessary to create a new product? Why not just release it as new versions of old? For customers, it could be easier to adapt. What is the future of CQ|CC, how you see it? Thank you.

With the Jazz project we are trying to do something new and do it in the open - but clearly we understand that we can't just leave the existing customers behind. As mentioned in the question about the Jazz project above, we have experienced several pain points with the existing tools. A common point of friction was the lack of integration which resulted in a lack of transparency. One lesson from Eclipse was that to achieve integration you need some common foundation or integration platform. Retrofitting a new integration platform wasn't a viable approach and in addition there were additional pressures to better support agile practices. While the Jazz project did start from the ground-up, we reused many ideas from CC and CQ. For example, the stream model from CC or the customization support from CQ. Once we went down this path it was obvious that we needed an integration solution for CC and CQ.

In RTC 1.0 we provided "synchronizer" connectors which can synchronize data between the Jazz and the CC or CQ repositories. With this functionality, an agile team can start to use RTC while periodically synchronizing their code with the "mothership" CC repository. For RTC 2.0 we have expanded the integration options with the support "bridge" connectors. A bridge doesn't synchronize the data but rather links artifacts across repositories. The CC Bridge allows linking a ClearCase UCM activity with an RTC work item. This allows CC users to continue using CC, but also benefit from the additional capabilities RTC offers such as agile planning support, work items, reports, dashboards, notifications etc. The CQ Bridge provides linking CQ Records and RTC work items. Finally, both RTC and CQ implement the Open Services for Life Cycle Collaboration specification for change management systems. This enables a third tool like the Rational Quality Manager to work with either RTC or CQ when it comes to filing defects for failed tests, for example.

To conclude, there is still a significant investment in enhancing ClearCase and ClearQuest and this will continue. RTC 2.0 provides good options for users who want to use RTC, CQ and CC together. All these options have been enriched further in 2.0 to enable gradual adoption.



Could Jazz Benefit from a Distributed Model? -- by A.K.A_Magnet (860822)

Do you think Jazz could gain from a distributed model, like git does for source control management, where the repositories can be forked and kept synchronized upstream/downstream (a bit like a "progressive fork" where fixes can be shared but the project can be forked for various reasons)? I heard there is a git connector in incubation but it seems to me more than just code artifacts should be distributed. After enjoying the many benefits of distributed SCMs, it's hard to go back, and I think at least issue management could gain from the same model.

Using the terminology from above the Git integration will be a bridge connector. It will be available as an incubator on jazz.net soon and it leverages the OSLC change management specification supported by RTC to create the linkage to RTC work items. Flowing changes across repositories is appealing and this feature is in our backlog. Some explorations to support a distributed Jazz SCM were already undertaken. Details on the current status and open issues are available on the developer wiki on jazz.net.

Cleaning Up Collaboration -- by eldavojohn (898314)

Jazz seems to rely heavily on developer community and their collaboration--and the influence for Jazz is said to be the World Wide Web. "The Jazz portfolio consists of a common platform and a set of tools that enable all of the members of the extended development team to collaborate more easily." The biggest problem I have with collaboration tools is the metadata. No one does it right. Someone writes a blog or uploads a document but doesn't tag it. Enterprise search is broken. Management hands us wikis yet no one has the time or patience to maintain them. The protective blanket of "it's agile, baby" shields us from any beat downs. And with every new tool I realize that it's not the tool that improves collaboration, it's the team. Look at Slashdot's tagging system. Does it help me that one hundred stories are tagged with "no"? Collaboration seems to spontaneously work but is often out of your control when it does and doesn't. How does Jazz fix these problems? How does Jazz improve collaboration when it seems to me that tools are such a small part of collaboration? Will a small development team be able to use such a large set of tools?

I agree that no tool can fix collaboration problems and the team plays the main part in the game. In the Jazz project, we are focusing on collaboration in the context of software artifacts like builds, change sets, test plans, defects, or baselines. Software artifacts are semantic rich, structured, and there are typically rules, permissions or approvals involved when it comes to changing artifacts. Jazz products can improve the collaboration around software artifacts by making these rules explicit. Our goal was that the tool not only acts as the police but also as a guide that helps team members conform to the rules. Let's use Rational Team Concert as an example. When a change set requires a review before it is shared with the team, the tool will not just flag you when the review is missing, it also offers to initiate the review process for you. This involves suspending the changes from the current work space, attaching them to a work item, and notifying the reviewer that there is a pending review.

Behind all this is a process component in the Jazz Foundation that allows you to configure these rules in a flexible way. The flexibility is required since otherwise tools can get easily in the way. A team operates differently during an early exploration of a product and one week before it ships. The rules can be specific to a particular role, or a particular team, and the development phase of the project. Here is an analog example to tagging a blog: checking in a change set and wanting to track the reason for the change. To guide users, you can define a precondition for the check-in operation that will ensure that the change set is linked to a work item tracking the reason for the change. When a user attempts to check-in a change set without an associated work item, the user is shown a list of work items that they own to choose from. If none of them apply, the user can easily create a new work item on the fly to complete the check-in. As a side effect the change set and the work item are now linked together. As you work with Rational Team Concert it establishes many such links between artifacts for you in the context of your work. For example, the work items that are fixed and included in a build are linked to the build result artifact. These links increase the transparency and allow everybody in the team to understand why something was changed, which will helps collaboration.

In addition to making team roles and rules more explicit, the tools improve collaboration by helping team members stay on top of changes that affect the whole team. The team's current sprint or iteration plan and the current progress are easily accessible for everybody to see. Team members are notified about events in their team and they can track event feeds using RSS readers and aggregators. Similarly, broken builds are linked to a work item where the discussion about the broken build takes place and this work item is then easily visible and accessible from the team's dashboard. These are just a few examples that illustrate how a tool can facilitate the collaboration in the context of software artifacts.

Now regarding the question on small development teams, RTC is designed to scale up from single teams working in a single release to multiple (even distributed) teams working on multiple releases and you can easily use RTC for small teams. In fact, the Express-C edition is free for teams up to three. Even a small team needs to do the backlog and sprint planning, needs continuous builds, needs to track progress, manages defects and wants to make the current state of the project visible on dashboards.

The Directions of the Eclipse Foundation -- by eldavojohn (898314)

Eclipse has been going on since the early 2000s and six days ago enjoyed the release of Galileo (v3.5). If you've had time to look at recent release, what are your opinions on what Eclipse has become? Has it made any wrong turns? How do you respond to criticisms of "bloat" or "too resource intensive"? Do you see it becoming more than what it is or transforming?

The Galileo release is quite an achievement. Over 30 projects with over 380 committers from over 40 organizations have contributed to this joint release. Obviously you do not want to consume Galileo all at once but rather pick one of the available packages that suit your needs. Now that my team's focus is on Jazz and Rational Team Concert, we have become consumers of many Eclipse projects. Having a release train with aligned project releases is a big help for us and is the right direction.

As consumers we also appreciate the API stability that Eclipse platform provides. Regarding bloat, the API stability is not free. It means that once something has surfaced as an API, you cannot remove or change it anymore. For example, if you look under the covers in the Eclipse source code, you find three different preference store mechanisms. This is the price you pay for API stability. Actually, Eclipse now includes some nice tools to track API changes and more.

The "too resource intensive" criticism depends on which packages/plug-ins you are using. Eclipse is an extensible system and is therefore vulnerable to contributions that can be too resource hungry. To keep a software system interesting to users, you need a constant flow of new features. The challenge is to preserve the performance and resource characteristics as new features are added. The Eclipse SDK team does measurements to track this. There is a set of performance JUnit tests that are run for each build. Once a test runs slower than the baseline from the previous release, the test turns red. The results are published for each build. Here is an example report from Eclipse 3.5. Based on our own use of Eclipse for developing RTC, I do not experience that Eclipse has become slower over time or more resource intensive.

Looking back, I don't necessarily see wrong turns, but rather some turns we probably could have taken but didn't. For example, the Eclipse platform is language agnostic and the Java Development tools built on top of the platform. There is a language toolkit layer (LTK) in between the platform that provides some generic infrastructure for implementing refactorings. However, this layer is thinner than implementers of new languages on Eclipse would like. They therefore have to resort to copy code from JDT. This is obviously not ideal. Even though we were aware of this issue, we didn't have the cycles to pursue a more generic language layer. Having said that, I must say that the Eclipse C Development tool is cool in Galileo and there is good support for many other languages. There also is the Dynamic Languages Toolkit incubator project at Eclipse.org.,



Will SWT and Swing ever merge in Eclipse? -- Fuzuli (135489)

I have to build quite complex tools using GEF and GMF, and there are many cases where I'd like to have the power of Java2D, and reuse some of the great frameworks out there built on Swing. More and more people are using AWT/SWT bridge, since SWT does not provide an underlying drawing framework as rich as Java2D. Eclipse has great things like EMF, and the platform is number one choice for tooling, but when it comes to things like Bezier curves etc, Swing is much easier to use. So are we going to see more developer friendly versions of Eclipse where Swing is more available to us?

SWT has continually improved its advanced graphics API for drawing Bezier curves, alpha blending, gradients etc. You can see it in action in the GraphicsExample (http://www.eclipse.org/swt/examples.php.) and there are several example snippets. If the current support is not sufficient, then you should file enhancement requests against the SWT component at eclipse.org.

As you mention SWT provides the support to enable the SWT/Swing integration and enables embedding an AWT hierarchy in a SWT widget hierarchy. The SWT team has currently no plans go beyond this. However, there is also the Albireo project at Eclipse.org. This is a technology project in incubation with the goal of simplifying the task of combining user interface components from the Swing and SWT toolkits.

A follow-up question -- by an anonymous reader

will SWT and the whole Eclipse workbench ever run in a Web browser? We have built a product based on SWT/Eclipse but our customers complain they cannot run it from a browser and instead have to download 200MB+ worth of plugins before they even start evaluating our product.

The eclipse e4 project has been investigating this very question. At EclipseCon 2009, the team provided an update and showed some interesting demos. You can find more details about the e4 project and a presentation covering the eclipse/desktop exploration online.

The short answer is that there is no free lunch for existing applications which generally must be re-factored to take into account that the application is now split between client and server. For your application to run in a web browser, the libraries it uses must also run in a web browser. In particular, one needs web equivalents of the workbench facilities that Eclipse RCP apps are based on. The approach currently being investigated is to provide "e4 workbench services". The e4 project is increasing support for running JavaScript on the desktop. As a consequence when the application is written against these workbench services, the same JS code can run unchanged in both the desktop and the web. In combination, this provides a path to achieving a good user experience in both the desktop and the web with some reuse.

A different approach being investigated in parallel is the eclipse Rich Ajax Project, which is also part of the Galileo release. RAP runs your SWT widgets remotely in a web browser, which have some other trade-offs as the approach used by e4.



On strong typing, and design patterns and testing -- by bADlOGIN (133391)

A number of weak typing language zealots like to point out that Design patterns is simply a way to make strongly typed languages "suck less". This can be a compelling argument in terms of simplicity and syntax in examples when you take a look at books like "Design Patterns in Ruby" compared with "Design Patterns: Elements of Reusable Object-Oriented Software". There's also an argument that strong typing is a form of tight coupling and antithetical to half of the Object Oriented axiom, "loose coupling, strong cohesion". Given the momentum in popularity that unit testing across multiple languages and development methodologies has (rightfully!) enjoyed, is it time to encourage language designers and programmers to move away from strong typing usage and substitute better testing practices?

The Design Patterns book is now over fifteen years old and it predates the Internet, Java, and XML, which is pretty amazing to me. However, it doesn't predate Smalltalk. Smalltalk is an influential and powerful dynamic object-oriented language. When working on the pattern catalog, we looked for known uses of our patterns in the Smalltalk libraries. If you study some of the pattern examples you can see how they can be implemented in Smalltalk. What is definitely true is that dynamic languages provide some interesting pattern implementation variations. I do not go as far as to say that static typing is in strong contrast to object-oriented principles. You can define loosely coupled systems in statically typed languages using interfaces and abstract classes. In addition, the more recent Dependency Injection pattern allows you to configure the dependencies of an object externally.



On the Current State of Academia? -- by eldavojohn (898314

I know a lot of people that are very vocal about what is right and wrong with education today. Especially college institutions: "No one teaches C, everyone teaches four years of Java, no one understands the theory, a CS grad doesn't even know what a model-view-controller pattern is." The list goes on. Since you have your doctorate and have probably spent a lot of time in research and academia, what's wrong with most computer science or engineering programs in general today? What would you like to see more or less of? Are there any subject directions recently taken (EJB, garbage collectors, interpreted languages) you'd like to comment on? You seem to be non-opposed to Java which, I'll admit, is rare to me for someone with a doctorate. I would like to hear your views since so often all I hear about Java is that it is slow and only good for people that want cheap software developed quick by beginner developers.

I cannot complain about the students that come out of nearby universities and that interview for positions on our team. Many of these students used Eiffel as their first language but they are all familiar with different languages using different paradigms. While they are not experts in EJBs, JFS, Dojo, Ruby on Rails or whatever, they have a solid CS background with lectures on patterns and are eager to learn. They come up to speed quickly with new technologies. This is required when joining a team like ours working on Rational Team Concert. For example getting started on the Rational Team Concert project requires a new team member to learn a mix of things such as Java, JavaScript, Dojo, CSS, C# (when working on the Visual Studio Client), Eclipse Plug-ins, REST and finally our agile development practices. One possible area of improvement is more familiarity with larger software systems and their architectures. Open Source project like Eclipse can serve as great study material. On the positive side I also observe that more students are starting to contribute to open source projects and can point to submitted patches in their CVs.

Last week you asked Jazz technical lead Erich Gamma questions about Jazz or anything else in his realm of expertise. Here are his answers, along with many external links and places to continue the conversation if you are interested. Why Jazz? -- by autophile (640621)

Could you explain, minus the marketing speak that seems to pervade the IBM site, what is Jazz, what makes it a community-oriented developer's site, why is it different from, say, sourceforge.net, and if Jazz is so community-oriented and yet apparently tied in to Rational, where are the community versions (not trials, not demos, not limited to the point of uselessness functionality) of Rational products?

Jazz is not a product but it is the name of a project that has the goal of building a new set of team products and to better integrate existing products.

The Jazz project was kicked-off in 2005. At that time we observed that the tooling situation for an individual developer using an IDE like Eclipse was pretty good. However, when it came to working as a team, our own experience and feedback from our customers indicated there are still many pain points. Our own experience comes from working for many years on Eclipse. We developed in a globally distributed team, spread across many time zones, and using many agile practices. The goal of the Jazz project was to take a fresh look at how teams work together and to build a new generation of products from the ground up that makes development more collaborative, but also more fun. We put the team at the center of all our designs. Initially we focused on development related pain points like support for iterative planning, painless build submissions, collaborating and fixing broken builds, simplifying parallel development, easy progress tracking, and finally improving transparency. Collaboration becomes more effective with increased transparency. One of the goals here is to make it easy for everybody to know what is going on in the project without having to ask. Since then we expanded the scope to cover the role of testers and business analysts. The set of new products that were built from the ground up include:

• Rational Team Concert (RTC): Provides a new customizable work item/defect tracking system, a continuous build system, a new source control system, and customizable agile planning that supports project management practices like the ones from Scrum, and dashboards and reports. Version 2.0 has actually shipped just a week ago.
• Rational Quality Manager (RQM): Provides test management, test planning, and includes a test lab management component.
• Rational Requirements Composer (RRC): Provides requirements definition for business analysts, client stakeholders and software developers using a variety of capture techniques.

These products share a common infrastructure using the building blocks we refer to as the Jazz Foundation. The Foundation provides a common set of services that can be leveraged by a Jazz tool. To enable integration with existing tools, the Jazz Foundation supports the Open Services for Lifecycle Collaboration initiative; an independent project to define a set of REST based protocols for sharing information across disparate tools. Actually, we are not only contributing to the specification, we have actually used the OSLC specifications for integrating the above tools.

Finally, we have grown a community around the Jazz project on www.jazz.net. Transparency and feedback are very important to us, not only for the tools we provide, but also for how we develop the products ourselves. To get that direct feedback, we do our development on jazz.net out in the open. On jazz.net you can interact with the development team, learn about our development plans, see our RTC powered dashboards, submit defects and enhancements, or download intermediate milestone builds.

If you want to read about how all these capabilities come together, there is a new eBook available for download. The eBook describes, using scenarios, how business analysts, development teams, and testers collaborate using the above mentioned products.

If you are interested in how we develop our products using Rational Team Concert in a globally distributed team, I did a web cast that sheds light on our development practices.

Rather than reading feature comparisons, I suggest that you jump in and give Rational Team Concert 2.0 a try. We made it very easy to kick the Team Concert tires. In less than 30 minutes you will have a running server, a client, and a sample project for a small team working on a fictitious JUnit release. There is also a community edition called Express-C (free for up to 3 users). Based on community feedback, we have made more features available in the Express-C edition. You can find the descriptions of the editions on the Jazz site. For those of you that do prefer to compare features, there is also a feature overview of RTC . If you have questions, feel free to post them to the user forum on jazz.net. Our development team is always there to answer questions.



Rational? -- by an anonymous reader

I work in a small shop that makes some use of Websphere Application Server and the Rational development tools. I basically find the entire structure of the IBM software offerings relating to the above technologies incomprehensible. Products are constantly being renamed, discontinued, bundled, unbundled and rebranded. Names are long, generic, and practically interchangeable, and so are the feature lists. How do you plan to run a community support site based around this hodge-podge? I would assume the volatile nature of IBM's software marketing makes your task something approaching impossible. How do you expect to build a strong developer community based around products that are in a constant flux? I don't see any way around ending up with a large number of granular, isolated communities that spring up around specific products and thrive for a year or two. In short, how do you plan to unify a developer community without IBM first unifying the software development platform that this community is to be built around?

Obviously the Rational portfolio has grown through acquisitions (Build Forge, Watchfire and Telelogic being the most recent), and the process of bringing these acquired products into a logical product family while minimizing disruption for existing users is an ongoing effort. One goal of the Jazz project is to improve the integration of existing products by providing the Jazz integration architecture and by contributing to the OSLC initiative as mentioned above.

The Jazz community site is the live development infrastructure for the Jazz project and the new Jazz products. We launched www.jazz.net in 2006 together with the availability of the first Rational Team Concert beta version. As you can see from the URL it is "ibm" neutral and focuses on Jazz products. Since then the community has rapidly grown and there are now over 17000 participants in Jazz forums. Customers really appreciate the direct communication channel with the development team. Given the positive feedback we have recently on-boarded two additional Jazz products on jazz.net: Rational Requirements Composer and Rational Quality Manager. This was combined with a reorganization of the site itself to optimize for the new projects, improve user experience, and create a high quality technical library of materials created by the development teams themselves to help educate and get teams set up and running and become productive very quickly. Additional Jazz products will on-board on jazz.net as they emerge. Some of the Jazz products will also be in flux, the point is that we make them available early, are transparent about their development and invite users to provide feedback.



RTC vs CQ and CC -- by SunSunich (1588709)

First of all let me congratulate you on the successful launch of version 2.0 of RTC and 1.0 JF. It is really great work, thank you and all the Jazz Team. The functionality of Rational Team Concert greatly overlaps with the ClearQuest and ClearCase. Why is it necessary to create a new product? Why not just release it as new versions of old? For customers, it could be easier to adapt. What is the future of CQ|CC, how you see it? Thank you.

With the Jazz project we are trying to do something new and do it in the open - but clearly we understand that we can't just leave the existing customers behind. As mentioned in the question about the Jazz project above, we have experienced several pain points with the existing tools. A common point of friction was the lack of integration which resulted in a lack of transparency. One lesson from Eclipse was that to achieve integration you need some common foundation or integration platform. Retrofitting a new integration platform wasn't a viable approach and in addition there were additional pressures to better support agile practices. While the Jazz project did start from the ground-up, we reused many ideas from CC and CQ. For example, the stream model from CC or the customization support from CQ. Once we went down this path it was obvious that we needed an integration solution for CC and CQ.

In RTC 1.0 we provided "synchronizer" connectors which can synchronize data between the Jazz and the CC or CQ repositories. With this functionality, an agile team can start to use RTC while periodically synchronizing their code with the "mothership" CC repository. For RTC 2.0 we have expanded the integration options with the support "bridge" connectors. A bridge doesn't synchronize the data but rather links artifacts across repositories. The CC Bridge allows linking a ClearCase UCM activity with an RTC work item. This allows CC users to continue using CC, but also benefit from the additional capabilities RTC offers such as agile planning support, work items, reports, dashboards, notifications etc. The CQ Bridge provides linking CQ Records and RTC work items. Finally, both RTC and CQ implement the Open Services for Life Cycle Collaboration specification for change management systems. This enables a third tool like the Rational Quality Manager to work with either RTC or CQ when it comes to filing defects for failed tests, for example.

To conclude, there is still a significant investment in enhancing ClearCase and ClearQuest and this will continue. RTC 2.0 provides good options for users who want to use RTC, CQ and CC together. All these options have been enriched further in 2.0 to enable gradual adoption.



Could Jazz Benefit from a Distributed Model? -- by A.K.A_Magnet (860822)

Do you think Jazz could gain from a distributed model, like git does for source control management, where the repositories can be forked and kept synchronized upstream/downstream (a bit like a "progressive fork" where fixes can be shared but the project can be forked for various reasons)? I heard there is a git connector in incubation but it seems to me more than just code artifacts should be distributed. After enjoying the many benefits of distributed SCMs, it's hard to go back, and I think at least issue management could gain from the same model.

Using the terminology from above the Git integration will be a bridge connector. It will be available as an incubator on jazz.net soon and it leverages the OSLC change management specification supported by RTC to create the linkage to RTC work items. Flowing changes across repositories is appealing and this feature is in our backlog. Some explorations to support a distributed Jazz SCM were already undertaken. Details on the current status and open issues are available on the developer wiki on jazz.net.

Cleaning Up Collaboration -- by eldavojohn (898314)

Jazz seems to rely heavily on developer community and their collaboration--and the influence for Jazz is said to be the World Wide Web. "The Jazz portfolio consists of a common platform and a set of tools that enable all of the members of the extended development team to collaborate more easily." The biggest problem I have with collaboration tools is the metadata. No one does it right. Someone writes a blog or uploads a document but doesn't tag it. Enterprise search is broken. Management hands us wikis yet no one has the time or patience to maintain them. The protective blanket of "it's agile, baby" shields us from any beat downs. And with every new tool I realize that it's not the tool that improves collaboration, it's the team. Look at Slashdot's tagging system. Does it help me that one hundred stories are tagged with "no"? Collaboration seems to spontaneously work but is often out of your control when it does and doesn't. How does Jazz fix these problems? How does Jazz improve collaboration when it seems to me that tools are such a small part of collaboration? Will a small development team be able to use such a large set of tools?

I agree that no tool can fix collaboration problems and the team plays the main part in the game. In the Jazz project, we are focusing on collaboration in the context of software artifacts like builds, change sets, test plans, defects, or baselines. Software artifacts are semantic rich, structured, and there are typically rules, permissions or approvals involved when it comes to changing artifacts. Jazz products can improve the collaboration around software artifacts by making these rules explicit. Our goal was that the tool not only acts as the police but also as a guide that helps team members conform to the rules. Let's use Rational Team Concert as an example. When a change set requires a review before it is shared with the team, the tool will not just flag you when the review is missing, it also offers to initiate the review process for you. This involves suspending the changes from the current work space, attaching them to a work item, and notifying the reviewer that there is a pending review.

Behind all this is a process component in the Jazz Foundation that allows you to configure these rules in a flexible way. The flexibility is required since otherwise tools can get easily in the way. A team operates differently during an early exploration of a product and one week before it ships. The rules can be specific to a particular role, or a particular team, and the development phase of the project. Here is an analog example to tagging a blog: checking in a change set and wanting to track the reason for the change. To guide users, you can define a precondition for the check-in operation that will ensure that the change set is linked to a work item tracking the reason for the change. When a user attempts to check-in a change set without an associated work item, the user is shown a list of work items that they own to choose from. If none of them apply, the user can easily create a new work item on the fly to complete the check-in. As a side effect the change set and the work item are now linked together. As you work with Rational Team Concert it establishes many such links between artifacts for you in the context of your work. For example, the work items that are fixed and included in a build are linked to the build result artifact. These links increase the transparency and allow everybody in the team to understand why something was changed, which will helps collaboration.

In addition to making team roles and rules more explicit, the tools improve collaboration by helping team members stay on top of changes that affect the whole team. The team's current sprint or iteration plan and the current progress are easily accessible for everybody to see. Team members are notified about events in their team and they can track event feeds using RSS readers and aggregators. Similarly, broken builds are linked to a work item where the discussion about the broken build takes place and this work item is then easily visible and accessible from the team's dashboard. These are just a few examples that illustrate how a tool can facilitate the collaboration in the context of software artifacts.

Now regarding the question on small development teams, RTC is designed to scale up from single teams working in a single release to multiple (even distributed) teams working on multiple releases and you can easily use RTC for small teams. In fact, the Express-C edition is free for teams up to three. Even a small team needs to do the backlog and sprint planning, needs continuous builds, needs to track progress, manages defects and wants to make the current state of the project visible on dashboards.

The Directions of the Eclipse Foundation -- by eldavojohn (898314)

Eclipse has been going on since the early 2000s and six days ago enjoyed the release of Galileo (v3.5). If you've had time to look at recent release, what are your opinions on what Eclipse has become? Has it made any wrong turns? How do you respond to criticisms of "bloat" or "too resource intensive"? Do you see it becoming more than what it is or transforming?

The Galileo release is quite an achievement. Over 30 projects with over 380 committers from over 40 organizations have contributed to this joint release. Obviously you do not want to consume Galileo all at once but rather pick one of the available packages that suit your needs. Now that my team's focus is on Jazz and Rational Team Concert, we have become consumers of many Eclipse projects. Having a release train with aligned project releases is a big help for us and is the right direction.

As consumers we also appreciate the API stability that Eclipse platform provides. Regarding bloat, the API stability is not free. It means that once something has surfaced as an API, you cannot remove or change it anymore. For example, if you look under the covers in the Eclipse source code, you find three different preference store mechanisms. This is the price you pay for API stability. Actually, Eclipse now includes some nice tools to track API changes and more.

The "too resource intensive" criticism depends on which packages/plug-ins you are using. Eclipse is an extensible system and is therefore vulnerable to contributions that can be too resource hungry. To keep a software system interesting to users, you need a constant flow of new features. The challenge is to preserve the performance and resource characteristics as new features are added. The Eclipse SDK team does measurements to track this. There is a set of performance JUnit tests that are run for each build. Once a test runs slower than the baseline from the previous release, the test turns red. The results are published for each build. Here is an example report from Eclipse 3.5. Based on our own use of Eclipse for developing RTC, I do not experience that Eclipse has become slower over time or more resource intensive.

Looking back, I don't necessarily see wrong turns, but rather some turns we probably could have taken but didn't. For example, the Eclipse platform is language agnostic and the Java Development tools built on top of the platform. There is a language toolkit layer (LTK) in between the platform that provides some generic infrastructure for implementing refactorings. However, this layer is thinner than implementers of new languages on Eclipse would like. They therefore have to resort to copy code from JDT. This is obviously not ideal. Even though we were aware of this issue, we didn't have the cycles to pursue a more generic language layer. Having said that, I must say that the Eclipse C Development tool is cool in Galileo and there is good support for many other languages. There also is the Dynamic Languages Toolkit incubator project at Eclipse.org.,



Will SWT and Swing ever merge in Eclipse? -- Fuzuli (135489)

I have to build quite complex tools using GEF and GMF, and there are many cases where I'd like to have the power of Java2D, and reuse some of the great frameworks out there built on Swing. More and more people are using AWT/SWT bridge, since SWT does not provide an underlying drawing framework as rich as Java2D. Eclipse has great things like EMF, and the platform is number one choice for tooling, but when it comes to things like Bezier curves etc, Swing is much easier to use. So are we going to see more developer friendly versions of Eclipse where Swing is more available to us?

SWT has continually improved its advanced graphics API for drawing Bezier curves, alpha blending, gradients etc. You can see it in action in the GraphicsExample (http://www.eclipse.org/swt/examples.php.) and there are several example snippets. If the current support is not sufficient, then you should file enhancement requests against the SWT component at eclipse.org.

As you mention SWT provides the support to enable the SWT/Swing integration and enables embedding an AWT hierarchy in a SWT widget hierarchy. The SWT team has currently no plans go beyond this. However, there is also the Albireo project at Eclipse.org. This is a technology project in incubation with the goal of simplifying the task of combining user interface components from the Swing and SWT toolkits.

A follow-up question -- by an anonymous reader

will SWT and the whole Eclipse workbench ever run in a Web browser? We have built a product based on SWT/Eclipse but our customers complain they cannot run it from a browser and instead have to download 200MB+ worth of plugins before they even start evaluating our product.

The eclipse e4 project has been investigating this very question. At EclipseCon 2009, the team provided an update and showed some interesting demos. You can find more details about the e4 project and a presentation covering the eclipse/desktop exploration online.

The short answer is that there is no free lunch for existing applications which generally must be re-factored to take into account that the application is now split between client and server. For your application to run in a web browser, the libraries it uses must also run in a web browser. In particular, one needs web equivalents of the workbench facilities that Eclipse RCP apps are based on. The approach currently being investigated is to provide "e4 workbench services". The e4 project is increasing support for running JavaScript on the desktop. As a consequence when the application is written against these workbench services, the same JS code can run unchanged in both the desktop and the web. In combination, this provides a path to achieving a good user experience in both the desktop and the web with some reuse.

A different approach being investigated in parallel is the eclipse Rich Ajax Project, which is also part of the Galileo release. RAP runs your SWT widgets remotely in a web browser, which have some other trade-offs as the approach used by e4.



On strong typing, and design patterns and testing -- by bADlOGIN (133391)

A number of weak typing language zealots like to point out that Design patterns is simply a way to make strongly typed languages "suck less". This can be a compelling argument in terms of simplicity and syntax in examples when you take a look at books like "Design Patterns in Ruby" compared with "Design Patterns: Elements of Reusable Object-Oriented Software". There's also an argument that strong typing is a form of tight coupling and antithetical to half of the Object Oriented axiom, "loose coupling, strong cohesion". Given the momentum in popularity that unit testing across multiple languages and development methodologies has (rightfully!) enjoyed, is it time to encourage language designers and programmers to move away from strong typing usage and substitute better testing practices?

The Design Patterns book is now over fifteen years old and it predates the Internet, Java, and XML, which is pretty amazing to me. However, it doesn't predate Smalltalk. Smalltalk is an influential and powerful dynamic object-oriented language. When working on the pattern catalog, we looked for known uses of our patterns in the Smalltalk libraries. If you study some of the pattern examples you can see how they can be implemented in Smalltalk. What is definitely true is that dynamic languages provide some interesting pattern implementation variations. I do not go as far as to say that static typing is in strong contrast to object-oriented principles. You can define loosely coupled systems in statically typed languages using interfaces and abstract classes. In addition, the more recent Dependency Injection pattern allows you to configure the dependencies of an object externally.



On the Current State of Academia? -- by eldavojohn (898314

I know a lot of people that are very vocal about what is right and wrong with education today. Especially college institutions: "No one teaches C, everyone teaches four years of Java, no one understands the theory, a CS grad doesn't even know what a model-view-controller pattern is." The list goes on. Since you have your doctorate and have probably spent a lot of time in research and academia, what's wrong with most computer science or engineering programs in general today? What would you like to see more or less of? Are there any subject directions recently taken (EJB, garbage collectors, interpreted languages) you'd like to comment on? You seem to be non-opposed to Java which, I'll admit, is rare to me for someone with a doctorate. I would like to hear your views since so often all I hear about Java is that it is slow and only good for people that want cheap software developed quick by beginner developers.

I cannot complain about the students that come out of nearby universities and that interview for positions on our team. Many of these students used Eiffel as their first language but they are all familiar with different languages using different paradigms. While they are not experts in EJBs, JFS, Dojo, Ruby on Rails or whatever, they have a solid CS background with lectures on patterns and are eager to learn. They come up to speed quickly with new technologies. This is required when joining a team like ours working on Rational Team Concert. For example getting started on the Rational Team Concert project requires a new team member to learn a mix of things such as Java, JavaScript, Dojo, CSS, C# (when working on the Visual Studio Client), Eclipse Plug-ins, REST and finally our agile development practices. One possible area of improvement is more familiarity with larger software systems and their architectures. Open Source project like Eclipse can serve as great study material. On the positive side I also observe that more students are starting to contribute to open source projects and can point to submitted patches in their CVs.

Last week you asked Jazz technical lead Erich Gamma questions about Jazz or anything else in his realm of expertise. Here are his answers, along with many external links and places to continue the conversation if you are interested. Why Jazz? -- by autophile (640621)

Could you explain, minus the marketing speak that seems to pervade the IBM site, what is Jazz, what makes it a community-oriented developer's site, why is it different from, say, sourceforge.net, and if Jazz is so community-oriented and yet apparently tied in to Rational, where are the community versions (not trials, not demos, not limited to the point of uselessness functionality) of Rational products?

Jazz is not a product but it is the name of a project that has the goal of building a new set of team products and to better integrate existing products.

The Jazz project was kicked-off in 2005. At that time we observed that the tooling situation for an individual developer using an IDE like Eclipse was pretty good. However, when it came to working as a team, our own experience and feedback from our customers indicated there are still many pain points. Our own experience comes from working for many years on Eclipse. We developed in a globally distributed team, spread across many time zones, and using many agile practices. The goal of the Jazz project was to take a fresh look at how teams work together and to build a new generation of products from the ground up that makes development more collaborative, but also more fun. We put the team at the center of all our designs. Initially we focused on development related pain points like support for iterative planning, painless build submissions, collaborating and fixing broken builds, simplifying parallel development, easy progress tracking, and finally improving transparency. Collaboration becomes more effective with increased transparency. One of the goals here is to make it easy for everybody to know what is going on in the project without having to ask. Since then we expanded the scope to cover the role of testers and business analysts. The set of new products that were built from the ground up include:

• Rational Team Concert (RTC): Provides a new customizable work item/defect tracking system, a continuous build system, a new source control system, and customizable agile planning that supports project management practices like the ones from Scrum, and dashboards and reports. Version 2.0 has actually shipped just a week ago.
• Rational Quality Manager (RQM): Provides test management, test planning, and includes a test lab management component.
• Rational Requirements Composer (RRC): Provides requirements definition for business analysts, client stakeholders and software developers using a variety of capture techniques.

These products share a common infrastructure using the building blocks we refer to as the Jazz Foundation. The Foundation provides a common set of services that can be leveraged by a Jazz tool. To enable integration with existing tools, the Jazz Foundation supports the Open Services for Lifecycle Collaboration initiative; an independent project to define a set of REST based protocols for sharing information across disparate tools. Actually, we are not only contributing to the specification, we have actually used the OSLC specifications for integrating the above tools.

Finally, we have grown a community around the Jazz project on www.jazz.net. Transparency and feedback are very important to us, not only for the tools we provide, but also for how we develop the products ourselves. To get that direct feedback, we do our development on jazz.net out in the open. On jazz.net you can interact with the development team, learn about our development plans, see our RTC powered dashboards, submit defects and enhancements, or download intermediate milestone builds.

If you want to read about how all these capabilities come together, there is a new eBook available for download. The eBook describes, using scenarios, how business analysts, development teams, and testers collaborate using the above mentioned products.

If you are interested in how we develop our products using Rational Team Concert in a globally distributed team, I did a web cast that sheds light on our development practices.

Rather than reading feature comparisons, I suggest that you jump in and give Rational Team Concert 2.0 a try. We made it very easy to kick the Team Concert tires. In less than 30 minutes you will have a running server, a client, and a sample project for a small team working on a fictitious JUnit release. There is also a community edition called Express-C (free for up to 3 users). Based on community feedback, we have made more features available in the Express-C edition. You can find the descriptions of the editions on the Jazz site. For those of you that do prefer to compare features, there is also a feature overview of RTC . If you have questions, feel free to post them to the user forum on jazz.net. Our development team is always there to answer questions.



Rational? -- by an anonymous reader

I work in a small shop that makes some use of Websphere Application Server and the Rational development tools. I basically find the entire structure of the IBM software offerings relating to the above technologies incomprehensible. Products are constantly being renamed, discontinued, bundled, unbundled and rebranded. Names are long, generic, and practically interchangeable, and so are the feature lists. How do you plan to run a community support site based around this hodge-podge? I would assume the volatile nature of IBM's software marketing makes your task something approaching impossible. How do you expect to build a strong developer community based around products that are in a constant flux? I don't see any way around ending up with a large number of granular, isolated communities that spring up around specific products and thrive for a year or two. In short, how do you plan to unify a developer community without IBM first unifying the software development platform that this community is to be built around?

Obviously the Rational portfolio has grown through acquisitions (Build Forge, Watchfire and Telelogic being the most recent), and the process of bringing these acquired products into a logical product family while minimizing disruption for existing users is an ongoing effort. One goal of the Jazz project is to improve the integration of existing products by providing the Jazz integration architecture and by contributing to the OSLC initiative as mentioned above.

The Jazz community site is the live development infrastructure for the Jazz project and the new Jazz products. We launched www.jazz.net in 2006 together with the availability of the first Rational Team Concert beta version. As you can see from the URL it is "ibm" neutral and focuses on Jazz products. Since then the community has rapidly grown and there are now over 17000 participants in Jazz forums. Customers really appreciate the direct communication channel with the development team. Given the positive feedback we have recently on-boarded two additional Jazz products on jazz.net: Rational Requirements Composer and Rational Quality Manager. This was combined with a reorganization of the site itself to optimize for the new projects, improve user experience, and create a high quality technical library of materials created by the development teams themselves to help educate and get teams set up and running and become productive very quickly. Additional Jazz products will on-board on jazz.net as they emerge. Some of the Jazz products will also be in flux, the point is that we make them available early, are transparent about their development and invite users to provide feedback.



RTC vs CQ and CC -- by SunSunich (1588709)

First of all let me congratulate you on the successful launch of version 2.0 of RTC and 1.0 JF. It is really great work, thank you and all the Jazz Team. The functionality of Rational Team Concert greatly overlaps with the ClearQuest and ClearCase. Why is it necessary to create a new product? Why not just release it as new versions of old? For customers, it could be easier to adapt. What is the future of CQ|CC, how you see it? Thank you.

With the Jazz project we are trying to do something new and do it in the open - but clearly we understand that we can't just leave the existing customers behind. As mentioned in the question about the Jazz project above, we have experienced several pain points with the existing tools. A common point of friction was the lack of integration which resulted in a lack of transparency. One lesson from Eclipse was that to achieve integration you need some common foundation or integration platform. Retrofitting a new integration platform wasn't a viable approach and in addition there were additional pressures to better support agile practices. While the Jazz project did start from the ground-up, we reused many ideas from CC and CQ. For example, the stream model from CC or the customization support from CQ. Once we went down this path it was obvious that we needed an integration solution for CC and CQ.

In RTC 1.0 we provided "synchronizer" connectors which can synchronize data between the Jazz and the CC or CQ repositories. With this functionality, an agile team can start to use RTC while periodically synchronizing their code with the "mothership" CC repository. For RTC 2.0 we have expanded the integration options with the support "bridge" connectors. A bridge doesn't synchronize the data but rather links artifacts across repositories. The CC Bridge allows linking a ClearCase UCM activity with an RTC work item. This allows CC users to continue using CC, but also benefit from the additional capabilities RTC offers such as agile planning support, work items, reports, dashboards, notifications etc. The CQ Bridge provides linking CQ Records and RTC work items. Finally, both RTC and CQ implement the Open Services for Life Cycle Collaboration specification for change management systems. This enables a third tool like the Rational Quality Manager to work with either RTC or CQ when it comes to filing defects for failed tests, for example.

To conclude, there is still a significant investment in enhancing ClearCase and ClearQuest and this will continue. RTC 2.0 provides good options for users who want to use RTC, CQ and CC together. All these options have been enriched further in 2.0 to enable gradual adoption.



Could Jazz Benefit from a Distributed Model? -- by A.K.A_Magnet (860822)

Do you think Jazz could gain from a distributed model, like git does for source control management, where the repositories can be forked and kept synchronized upstream/downstream (a bit like a "progressive fork" where fixes can be shared but the project can be forked for various reasons)? I heard there is a git connector in incubation but it seems to me more than just code artifacts should be distributed. After enjoying the many benefits of distributed SCMs, it's hard to go back, and I think at least issue management could gain from the same model.

Using the terminology from above the Git integration will be a bridge connector. It will be available as an incubator on jazz.net soon and it leverages the OSLC change management specification supported by RTC to create the linkage to RTC work items. Flowing changes across repositories is appealing and this feature is in our backlog. Some explorations to support a distributed Jazz SCM were already undertaken. Details on the current status and open issues are available on the developer wiki on jazz.net.

Cleaning Up Collaboration -- by eldavojohn (898314)

Jazz seems to rely heavily on developer community and their collaboration--and the influence for Jazz is said to be the World Wide Web. "The Jazz portfolio consists of a common platform and a set of tools that enable all of the members of the extended development team to collaborate more easily." The biggest problem I have with collaboration tools is the metadata. No one does it right. Someone writes a blog or uploads a document but doesn't tag it. Enterprise search is broken. Management hands us wikis yet no one has the time or patience to maintain them. The protective blanket of "it's agile, baby" shields us from any beat downs. And with every new tool I realize that it's not the tool that improves collaboration, it's the team. Look at Slashdot's tagging system. Does it help me that one hundred stories are tagged with "no"? Collaboration seems to spontaneously work but is often out of your control when it does and doesn't. How does Jazz fix these problems? How does Jazz improve collaboration when it seems to me that tools are such a small part of collaboration? Will a small development team be able to use such a large set of tools?

I agree that no tool can fix collaboration problems and the team plays the main part in the game. In the Jazz project, we are focusing on collaboration in the context of software artifacts like builds, change sets, test plans, defects, or baselines. Software artifacts are semantic rich, structured, and there are typically rules, permissions or approvals involved when it comes to changing artifacts. Jazz products can improve the collaboration around software artifacts by making these rules explicit. Our goal was that the tool not only acts as the police but also as a guide that helps team members conform to the rules. Let's use Rational Team Concert as an example. When a change set requires a review before it is shared with the team, the tool will not just flag you when the review is missing, it also offers to initiate the review process for you. This involves suspending the changes from the current work space, attaching them to a work item, and notifying the reviewer that there is a pending review.

Behind all this is a process component in the Jazz Foundation that allows you to configure these rules in a flexible way. The flexibility is required since otherwise tools can get easily in the way. A team operates differently during an early exploration of a product and one week before it ships. The rules can be specific to a particular role, or a particular team, and the development phase of the project. Here is an analog example to tagging a blog: checking in a change set and wanting to track the reason for the change. To guide users, you can define a precondition for the check-in operation that will ensure that the change set is linked to a work item tracking the reason for the change. When a user attempts to check-in a change set without an associated work item, the user is shown a list of work items that they own to choose from. If none of them apply, the user can easily create a new work item on the fly to complete the check-in. As a side effect the change set and the work item are now linked together. As you work with Rational Team Concert it establishes many such links between artifacts for you in the context of your work. For example, the work items that are fixed and included in a build are linked to the build result artifact. These links increase the transparency and allow everybody in the team to understand why something was changed, which will helps collaboration.

In addition to making team roles and rules more explicit, the tools improve collaboration by helping team members stay on top of changes that affect the whole team. The team's current sprint or iteration plan and the current progress are easily accessible for everybody to see. Team members are notified about events in their team and they can track event feeds using RSS readers and aggregators. Similarly, broken builds are linked to a work item where the discussion about the broken build takes place and this work item is then easily visible and accessible from the team's dashboard. These are just a few examples that illustrate how a tool can facilitate the collaboration in the context of software artifacts.

Now regarding the question on small development teams, RTC is designed to scale up from single teams working in a single release to multiple (even distributed) teams working on multiple releases and you can easily use RTC for small teams. In fact, the Express-C edition is free for teams up to three. Even a small team needs to do the backlog and sprint planning, needs continuous builds, needs to track progress, manages defects and wants to make the current state of the project visible on dashboards.

The Directions of the Eclipse Foundation -- by eldavojohn (898314)

Eclipse has been going on since the early 2000s and six days ago enjoyed the release of Galileo (v3.5). If you've had time to look at recent release, what are your opinions on what Eclipse has become? Has it made any wrong turns? How do you respond to criticisms of "bloat" or "too resource intensive"? Do you see it becoming more than what it is or transforming?

The Galileo release is quite an achievement. Over 30 projects with over 380 committers from over 40 organizations have contributed to this joint release. Obviously you do not want to consume Galileo all at once but rather pick one of the available packages that suit your needs. Now that my team's focus is on Jazz and Rational Team Concert, we have become consumers of many Eclipse projects. Having a release train with aligned project releases is a big help for us and is the right direction.

As consumers we also appreciate the API stability that Eclipse platform provides. Regarding bloat, the API stability is not free. It means that once something has surfaced as an API, you cannot remove or change it anymore. For example, if you look under the covers in the Eclipse source code, you find three different preference store mechanisms. This is the price you pay for API stability. Actually, Eclipse now includes some nice tools to track API changes and more.

The "too resource intensive" criticism depends on which packages/plug-ins you are using. Eclipse is an extensible system and is therefore vulnerable to contributions that can be too resource hungry. To keep a software system interesting to users, you need a constant flow of new features. The challenge is to preserve the performance and resource characteristics as new features are added. The Eclipse SDK team does measurements to track this. There is a set of performance JUnit tests that are run for each build. Once a test runs slower than the baseline from the previous release, the test turns red. The results are published for each build. Here is an example report from Eclipse 3.5. Based on our own use of Eclipse for developing RTC, I do not experience that Eclipse has become slower over time or more resource intensive.

Looking back, I don't necessarily see wrong turns, but rather some turns we probably could have taken but didn't. For example, the Eclipse platform is language agnostic and the Java Development tools built on top of the platform. There is a language toolkit layer (LTK) in between the platform that provides some generic infrastructure for implementing refactorings. However, this layer is thinner than implementers of new languages on Eclipse would like. They therefore have to resort to copy code from JDT. This is obviously not ideal. Even though we were aware of this issue, we didn't have the cycles to pursue a more generic language layer. Having said that, I must say that the Eclipse C Development tool is cool in Galileo and there is good support for many other languages. There also is the Dynamic Languages Toolkit incubator project at Eclipse.org.,



Will SWT and Swing ever merge in Eclipse? -- Fuzuli (135489)

I have to build quite complex tools using GEF and GMF, and there are many cases where I'd like to have the power of Java2D, and reuse some of the great frameworks out there built on Swing. More and more people are using AWT/SWT bridge, since SWT does not provide an underlying drawing framework as rich as Java2D. Eclipse has great things like EMF, and the platform is number one choice for tooling, but when it comes to things like Bezier curves etc, Swing is much easier to use. So are we going to see more developer friendly versions of Eclipse where Swing is more available to us?

SWT has continually improved its advanced graphics API for drawing Bezier curves, alpha blending, gradients etc. You can see it in action in the GraphicsExample (http://www.eclipse.org/swt/examples.php.) and there are several example snippets. If the current support is not sufficient, then you should file enhancement requests against the SWT component at eclipse.org.

As you mention SWT provides the support to enable the SWT/Swing integration and enables embedding an AWT hierarchy in a SWT widget hierarchy. The SWT team has currently no plans go beyond this. However, there is also the Albireo project at Eclipse.org. This is a technology project in incubation with the goal of simplifying the task of combining user interface components from the Swing and SWT toolkits.

A follow-up question -- by an anonymous reader

will SWT and the whole Eclipse workbench ever run in a Web browser? We have built a product based on SWT/Eclipse but our customers complain they cannot run it from a browser and instead have to download 200MB+ worth of plugins before they even start evaluating our product.

The eclipse e4 project has been investigating this very question. At EclipseCon 2009, the team provided an update and showed some interesting demos. You can find more details about the e4 project and a presentation covering the eclipse/desktop exploration online.

The short answer is that there is no free lunch for existing applications which generally must be re-factored to take into account that the application is now split between client and server. For your application to run in a web browser, the libraries it uses must also run in a web browser. In particular, one needs web equivalents of the workbench facilities that Eclipse RCP apps are based on. The approach currently being investigated is to provide "e4 workbench services". The e4 project is increasing support for running JavaScript on the desktop. As a consequence when the application is written against these workbench services, the same JS code can run unchanged in both the desktop and the web. In combination, this provides a path to achieving a good user experience in both the desktop and the web with some reuse.

A different approach being investigated in parallel is the eclipse Rich Ajax Project, which is also part of the Galileo release. RAP runs your SWT widgets remotely in a web browser, which have some other trade-offs as the approach used by e4.



On strong typing, and design patterns and testing -- by bADlOGIN (133391)

A number of weak typing language zealots like to point out that Design patterns is simply a way to make strongly typed languages "suck less". This can be a compelling argument in terms of simplicity and syntax in examples when you take a look at books like "Design Patterns in Ruby" compared with "Design Patterns: Elements of Reusable Object-Oriented Software". There's also an argument that strong typing is a form of tight coupling and antithetical to half of the Object Oriented axiom, "loose coupling, strong cohesion". Given the momentum in popularity that unit testing across multiple languages and development methodologies has (rightfully!) enjoyed, is it time to encourage language designers and programmers to move away from strong typing usage and substitute better testing practices?

The Design Patterns book is now over fifteen years old and it predates the Internet, Java, and XML, which is pretty amazing to me. However, it doesn't predate Smalltalk. Smalltalk is an influential and powerful dynamic object-oriented language. When working on the pattern catalog, we looked for known uses of our patterns in the Smalltalk libraries. If you study some of the pattern examples you can see how they can be implemented in Smalltalk. What is definitely true is that dynamic languages provide some interesting pattern implementation variations. I do not go as far as to say that static typing is in strong contrast to object-oriented principles. You can define loosely coupled systems in statically typed languages using interfaces and abstract classes. In addition, the more recent Dependency Injection pattern allows you to configure the dependencies of an object externally.



On the Current State of Academia? -- by eldavojohn (898314

I know a lot of people that are very vocal about what is right and wrong with education today. Especially college institutions: "No one teaches C, everyone teaches four years of Java, no one understands the theory, a CS grad doesn't even know what a model-view-controller pattern is." The list goes on. Since you have your doctorate and have probably spent a lot of time in research and academia, what's wrong with most computer science or engineering programs in general today? What would you like to see more or less of? Are there any subject directions recently taken (EJB, garbage collectors, interpreted languages) you'd like to comment on? You seem to be non-opposed to Java which, I'll admit, is rare to me for someone with a doctorate. I would like to hear your views since so often all I hear about Java is that it is slow and only good for people that want cheap software developed quick by beginner developers.

I cannot complain about the students that come out of nearby universities and that interview for positions on our team. Many of these students used Eiffel as their first language but they are all familiar with different languages using different paradigms. While they are not experts in EJBs, JFS, Dojo, Ruby on Rails or whatever, they have a solid CS background with lectures on patterns and are eager to learn. They come up to speed quickly with new technologies. This is required when joining a team like ours working on Rational Team Concert. For example getting started on the Rational Team Concert project requires a new team member to learn a mix of things such as Java, JavaScript, Dojo, CSS, C# (when working on the Visual Studio Client), Eclipse Plug-ins, REST and finally our agile development practices. One possible area of improvement is more familiarity with larger software systems and their architectures. Open Source project like Eclipse can serve as great study material. On the positive side I also observe that more students are starting to contribute to open source projects and can point to submitted patches in their CVs.

pavithran writes "Does SAP, one of the largest business companies offering software solutions, support FOSS as a movement? Why is SAP looking at closed and open source in a similar way? This shows lot of ambiguity in SAP's attitude towards open source software. I found an interesting article in Linux Journal on whether SAP is an open source friend or foe, by Glyn Moody. Here's a quote from the article: 'For an outfit that calls itself "the world's largest business software company," the German software giant SAP is relatively little-known in the open source world. With 51,500 employees, a turnover of 11.5 billion euros ($16 billion) last year, and operating profits of 2.7 billion euros ($3.8 billion), SAP is clearly one of the heavyweights in the computer world. Given that huge clout, SAP's attitude to open source is important; and yet it is hard to tell whether it is really free software's friend or its foe. ... A company that wished open source well would back these ideas. One that really supported free software would also fight against software patents. So, while SAP's involvement in Eclipse and investment in open source companies is welcome — and pretty self-interested, it has to be said, given that it presumably hopes to make a profit on them — it's not really enough cancel out its unhelpful attitude and statements elsewhere. If it wants to be a serious, respected player in the world of open source, as befits its size, it must do better.'"

casals asks: "I'm a computer engineer working at a non-IT company, and there's this thing bothering me: by the end of each job, we have to generate a huge report that's actually a composite of lots of minor reports, each one of them made using a different software. Since the softwares used don't interact at all, we have to input the same information five or six times - not too smart, I guess. The outputs are either Access databases or Excel spreadsheets (some of these reports are just Excel spreadsheets that must be filled with data); so, I was thinking about making an application that could aggregate all the input models and generate all the outputs I need, at once. Any suggestions?" "Here's the thing: it cannot be a web-based application (connectivity is a luxury at the rig), it has to run in a laptop (each employee should have it installed, stand-alone) and it must be able to import images from Excel worksheets. Crystal Reports uses spreadsheets as data sources, but it's not Open Source; I was thinking about using BIRT or JasperReports + POI, but that looks to me like inventing the wheel itself, so I decided to ask before digging into it."

Z0mb1eman asks: "My company is considering replacing our aging CrystalReports with an open source solution. We are currently doing our research, and the choices seem promising -- JasperReports, Actuate-backed BIRT, and Pentaho, which seems to combine other open-source reporting tools. All have some level of commercial support, but are they ready to replace established solutions like Crystal Reports or even Actuate? Is your company using an Open Source reporting tool, and what have been your experiences with such tools? Are there any other choices we should consider? What should we expect if we make the decision to switch?"

slashbob22 writes "IBM has decided to contribute portions of the Rational Unified Process to the Eclipse Foundation. From the article: 'RUP is a vast collection of methods and best practices for promoting quality and efficiency throughout software development projects. IBM's donation will also provide a foundation architecture and Web-based tools for the industry to engineer, collaborate on, share and reuse software development best practices.'"

jondaw writes "Builder UK says that Nokia is to become more involved in the direction of the Open Source IDE, Eclipse. 'Nokia has increased its level of involvement in the Eclipse project by becoming a board member and strategic developer. It will take the lead in developing tools for mobile applications based on the Eclipse platform. One if its aims will be to extend the Java-based IDE to have full support for J2ME.'"

Hergio writes "Eclipse 3.1, the popular IDE, has finally been released. There have been a lot of products waiting for Eclipse 3.1 to go final before progressing, so this is great news not only for the developers who use Eclipse directly, but for those who use tools built on top of Eclipse. The site and all its mirrors appear to be getting hammered, so plan on waiting a day or so to get your copy. Do any Slashdotters know of any lesser known mirrors?"

Jeff Myers writes "Eclipse version 3.1 was just released and is available for download. There are quite a few new and noteworthy features added in this release - including full support for Java 5.0 and improved support for developing rich client applications based on the Eclipse platform." Update: 06/28 21:03 GMT by Z : Denis emailed to request we use mirrors, as they're already getting hammered pretty hard.

xbsd writes "Those computer industry specialists claiming that the end of Linux is fast approaching may be interested in two recent movements inside the industry. Two weeks ago, McAfee, one of the world leaders in computer security products, launched its first commercial antivirus solution for Linux, and just yesterday, Macromedia announced that it is joining the Eclipse Foundation and plans to deliver a next-generation rich Internet application (RIA) development tool code-named Zorn based on the popular open-source IDE."

pankaj_kumar writes "'Tools are an aid to productivity, but you only get the benefits of the tool by using it for the right task; hammers bang in nails and screwdrivers are for screws.' This quote from chapter 9 ("Scripting") from Alan Monnox's Rapid J2EE Development applies not only to the choice of the programming language but to the whole array of software development activities thoroughly and eloquently covered in the book." Read on for the rest of Kumar's review. Rapid J2EE Development: An Adaptive Foundation for Enterprise Applications author Alan Monnox pages 395 publisher Prentice Hall PTR rating 8 reviewer Pankaj Kumar ISBN 0131472208 summary A telescopic view of tools, techniques and processes for boosting Java software development productivity

"Using a Hole-Hawg for the job of a homeowners drill can have deleterious effect on productivity by causing serious harm to the health of the inexperienced operator." Just identifying a tool for a task is not enough. You should also be able to match the demands of the task to the characteristics of the tool and your ability to handle the tool. The good news is that this book passes even this stringent test, suggesting very practical and hands-on approach for choosing the tool with right characteristics for the specific demands of the task.

The ever-growing body of literature on development best practices, the burgeoning ranks of supporting tools and the accompanying debates on their relative merits can easily overwhelm most practitioners. Worst, a large chunk of the developer community may never spend the time and effort and miss the opportunity to take advantage of them altogether. Rapid J2EE Development offers an easy path to such Java developers by bringing together a number development techniques, best practices and description of supporting open source tools in a single book.

Whether you are a confused Java developer, overwhelmed project leader or plain lost manager, this book has something for you. Wondering about how to design complicated class hierarchies to encapsulate the ever-changing business rules? Worry not, follow the advice of Chapter 10, "Working to Rule" and use Jess, an open-source Expert System Shell. Don't have the time or motivation to download and play with it? No problem. The coverage includes not only an overview and discussion on when and where to use it but also presents a sample session and illustrative code snippets.

If you're confused with all the hype around AOP (Aspect Oriented Programming) and uncertain about where to start, start with the chapter "Aspect Oriented Programming," which introduces the notion of crosscutting concerns in any large software project, presents the AOP terminology to nail down these concerns and associated actions, and covers AspectJ and AspectWerkz to apply AOP to your projects. The brief description of these tools may not answer each and every question, but the example- and code-driven approach will certainly make you feel a lot more comfortable and motivate to explore further.

Not able to decide whether to use XP (Extreme Programming) or RUP (Rational Unified Process) for your next project involving four different development teams in three different continents interacting with as many customer groups? The Chapter "Embracing Adaptive Methods" outlines an approach to making such methodology decisions, though it is not very obvious from the chapter title. (Of course, you will have to read the sections that talk about when XP works best and when the rigors of RUP start paying off to make your decision.) And although there is not much discussion around mixing elements of development methodologies or adapting them in the middle of an ongoing project, the author's account of a real case study does exactly this.

These are just a few examples. Other topics covered include use of UML for modeling, code generators, Model-Driven Architectures, Java-based scripting languages, Object Relational mapping, build and test automation, and use of the right IDE plug-ins for J2EE projects. Among the development tools, all the usual suspects are there: Apache Ant, Eclipse, Jython, JUnit, HttpUnit, JMeter. In fact, I also found description of tools that were somewhat new to me: MyEclipse, AndroMDA, Middlegen and few others.

I found the book to be highly readable, insightful and loaded with the right kind of details. For example, the information on debugging with Eclipse explains how to configure a J2EE program for remote debugging, and how to debug a Web application using JSPs, something that is quite hard to do without the right tools and the right methods. Even the UML primer, with its well-chosen examples, is a good refresher.

It is easy to get superficial when covering a lot of ground: a common pitfall for authors of books on new technologies is that they themselves get caught up in the hype and lose perspective, but Alan somehow manages to keep the extraneous stuff out and deliver what a hands-on professional looks for. He tempers his zeal with practical realities and conveys the same to the reader with anecdotes and discussions with colorful stories such as the Cargo Cult Software trap and Christmas Puppy Syndrome.

The book manages to introduce a number of the very best open source Java tools available to boost productivity in a very natural manner and with the appropriate context, and it succeeds in giving a "feel" for the tool by presenting hands-on sessions. Most other such efforts that I am aware of usually end up being a drab list of tools with descriptions taken from home pages.

Given the number of topics and tools covered, it would be unrealistic to expect in-depth coverage of everything. What this book does is to create the right context, introduce the appropriate topics, and generate sufficient motivation to explore further. Fair enough. In fact, I believe this is the best approach for any book in this "Google era" -- the book should tell what you should look for and let Google do the rest.

So, is there anything not to be liked about the book? Well, I was a little disappointed to not find my favorite BeanShell among various Java scripting alternatives. Another thing I noticed is that the coverage of system manageability issues, especially in a book with J2EE in its title, was quite conspicuous by its absence. Also, some of the points, especially those around use of best practices and development techniques, could be made more emphatically with help of focused and concrete anecdotes.

Of course, no book can cover everything, especially on topics that are open-ended by nature. Overall, I think it does justice to the subject matter and is worth reading by anyone even remotely connected to the business of creating, maintaining or operating Java/J2EE software.

You can purchase Rapid J2EE Development from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

gManZboy writes "Developers who want a flexible, configurable, IDE have long preferred plug-in architectures such as Eclipse over what they might view as the bloated, monolithic alternatives. Ever wondered how it all works? Well, ACM Queue just posted an article by someone who has worked on Eclipse since its inception, Dorian Birsan. He gives a great explanation of the Eclipse architecture as well as a thorough analysis of things to watch out for when developing or working with pure plug-in architectures."

Node and Edge asks: "Many interesting problem domains involve some form of graph-based or graph-like information: network activity visualizations; social software; workflow management; P2P software development; and version control with branching, just to name a few. It is notoriously difficult for people to visualize a graph structure - unless it happens to be a strictly hierarchical tree-like structure, such as what we know from file-system explorers. Now, with all of that said, what graph libraries can you recommend? The following criteria apply, though they're not absolute: Java or Java bindings; simple to use for simple applications; and polished, extensible UI components. I'm familiar with JGraph, JUNG, Prefuse, OpenJGraph, Tigris GEF, Eclipse GEF, Graphviz, but have not had a chance to evaluate them all. Have you used any of these extensively? If so, can you provide any constructive advice? If not, can you recommend something else, ?"

An anonymous reader writes "Various news sources are reporting the 4.0 release of the free Java-based NetBeans IDE. You can read the anouncement, or proceed directly to the downloads. Perhaps the most significant improvement is that the IDE's native build system is the latest version of Apache Ant. I see this as a distinct advantage over its competitor Eclipse (and NetBeans is pure Java). If you create desktop applications in Java, you may wish to read up on the NetBeans 'platform' as well. Enjoy."

SuperBanana writes "After what seems like an eternity, Netatalk (an Appletalk server suite for unix) has caught up with the latest version of the Apple Filing Protocol (aka Appleshare). This means long filenames, files larger than 2GB, and other goodies that will bring much happiness for Unix sysadmins supporting Macintosh users (check out the human-friendly release notes for the full list). As with any major release, even though this has been through several release candidates- read the gotchas, review the known bugs in their bug tracker, test it out on something non-critical...and help stabilize the release by reporting any bugs you find. Of course, make sure you read a guide to reporting bugs first!"

Torulf writes "I just ran across an announcement on the Eclipse project frontpage that they have released CDT 2.0. CDT is the C/C++ development project at Eclipse. The CDT provides a full IDE that uses gcc for compiling. Find out what's new in this version here. Downloads available."

Torulf writes "I just ran across an announcement on the Eclipse project frontpage that they have released CDT 2.0. CDT is the C/C++ development project at Eclipse. The CDT provides a full IDE that uses gcc for compiling. Find out what's new in this version here. Downloads available."

Torulf writes "I just ran across an announcement on the Eclipse project frontpage that they have released CDT 2.0. CDT is the C/C++ development project at Eclipse. The CDT provides a full IDE that uses gcc for compiling. Find out what's new in this version here. Downloads available."

Tarantolato writes "The Eclipse Foundation has released version 3.0 of its open-source Java-based IDE. Eclipse backers like IBM say the program offers not only increased productivity and ease of use, but also a plugin-based architecture for creating 'rich client' applications with the networking capabilities of web-based apps and the persistence and native widgets of desktop applications. The Lotus Workplace platform is already Eclipse-based. Some in the Java community, however, are concerned with Eclipse's use of SWT rather than the standard Swing widget set, and some analysts think that project is part of a 'broader challenge to Microsoft's entire .Net development framework' from IBM. Meanwhile, Eclipse executives are attempting to woo Microsoft into joining the foundation."

Tarantolato writes "The Eclipse Foundation has released version 3.0 of its open-source Java-based IDE. Eclipse backers like IBM say the program offers not only increased productivity and ease of use, but also a plugin-based architecture for creating 'rich client' applications with the networking capabilities of web-based apps and the persistence and native widgets of desktop applications. The Lotus Workplace platform is already Eclipse-based. Some in the Java community, however, are concerned with Eclipse's use of SWT rather than the standard Swing widget set, and some analysts think that project is part of a 'broader challenge to Microsoft's entire .Net development framework' from IBM. Meanwhile, Eclipse executives are attempting to woo Microsoft into joining the foundation."

Tarantolato writes "The Eclipse Foundation has released version 3.0 of its open-source Java-based IDE. Eclipse backers like IBM say the program offers not only increased productivity and ease of use, but also a plugin-based architecture for creating 'rich client' applications with the networking capabilities of web-based apps and the persistence and native widgets of desktop applications. The Lotus Workplace platform is already Eclipse-based. Some in the Java community, however, are concerned with Eclipse's use of SWT rather than the standard Swing widget set, and some analysts think that project is part of a 'broader challenge to Microsoft's entire .Net development framework' from IBM. Meanwhile, Eclipse executives are attempting to woo Microsoft into joining the foundation."

Tarantolato writes "The Eclipse Foundation has released version 3.0 of its open-source Java-based IDE. Eclipse backers like IBM say the program offers not only increased productivity and ease of use, but also a plugin-based architecture for creating 'rich client' applications with the networking capabilities of web-based apps and the persistence and native widgets of desktop applications. The Lotus Workplace platform is already Eclipse-based. Some in the Java community, however, are concerned with Eclipse's use of SWT rather than the standard Swing widget set, and some analysts think that project is part of a 'broader challenge to Microsoft's entire .Net development framework' from IBM. Meanwhile, Eclipse executives are attempting to woo Microsoft into joining the foundation."

binarysearch writes "Code folding is finally in the Eclipse project! After more than two years open, Eclipse's Bug 9355 has finally been marked FIXED. Code Folding was the most-voted for bug in Eclipse, with support for J2SE 1.5 features in a close second. Check out the I20040504 Integration build for folding in the Compilation Unit Editor (Class File Editor support is in HEAD). For those who dislike the implementation, it is requested that you create a new bug, rather than reopening 9355."

binarysearch writes "Code folding is finally in the Eclipse project! After more than two years open, Eclipse's Bug 9355 has finally been marked FIXED. Code Folding was the most-voted for bug in Eclipse, with support for J2SE 1.5 features in a close second. Check out the I20040504 Integration build for folding in the Compilation Unit Editor (Class File Editor support is in HEAD). For those who dislike the implementation, it is requested that you create a new bug, rather than reopening 9355."

binarysearch writes "Code folding is finally in the Eclipse project! After more than two years open, Eclipse's Bug 9355 has finally been marked FIXED. Code Folding was the most-voted for bug in Eclipse, with support for J2SE 1.5 features in a close second. Check out the I20040504 Integration build for folding in the Compilation Unit Editor (Class File Editor support is in HEAD). For those who dislike the implementation, it is requested that you create a new bug, rather than reopening 9355."

ilovestuff writes "According to ZDNet, Sun Microsystems has decided not to join the Eclipse open-source tools effort backed by rival IBM. In addition to dropping the plan to join Eclipse, Sun said Wednesday that it will no longer try to merge the Sun-sponsored NetBeans.org open-source Java tools project with Eclipse. The Eclipse open-source project, founded by IBM in 2001, is an IBM-owned consortium which has gained the membership of several development tools companies over the past year."

Flu writes "Finally, a free (as in speech and beer) and official GUI designer has been released for Eclipse! Just a few days before the Eclipse 3.0 M5 build was released, a complete plugin for creating GUI's was released as well, as one of the Eclipse tools projects. Check it all out on the official site for the Visual Editor Project. At last, the (probably) best free IDE for Java (and C) contains a GUI editor! Personally, I intend to put up an IBM logo to worship next to my desk, as a thank you for the Eclipse! :-)"

Flu writes "Finally, a free (as in speech and beer) and official GUI designer has been released for Eclipse! Just a few days before the Eclipse 3.0 M5 build was released, a complete plugin for creating GUI's was released as well, as one of the Eclipse tools projects. Check it all out on the official site for the Visual Editor Project. At last, the (probably) best free IDE for Java (and C) contains a GUI editor! Personally, I intend to put up an IBM logo to worship next to my desk, as a thank you for the Eclipse! :-)"

ebresie writes "It seems with the possible movement by the Eclipse project towards a more independent entity, Sun may join the Eclipse Effort."