The Kitware Blog

ParaView 3.12.0 Released

David Partyka — Tue, 08 Nov 2011 19:10:24 -0500

The ParaView team is pleased to announce the availability of the ParaView 3.12.0 final binaries for download on the ParaView Download Page. ParaView 3.12 can be considered as a bug-fix release with over 190 issues resolved. The detailed list can be found on the change-log page.

With Python being one of the preferred means of interacting with ParaView, we've added support to create animation tracks that use Python scripts to build highly customized animations.

Plugins support is one of the strong points of ParaView and with this release, we've made it easier to load deployed plugins on the server processes as well. All distributed plugins are now listed on the client as well as the server side.'

The release includes updates to LANL's streaming framework. The multiresolution streaming view now automatically adjusts resolution to match the projected image size. Also, VTK filters are now able to modify meta-information which means they can modify the data while still allowing the streaming framework to cull and prioritize pieces. An example is a new spherical warp filter that projects flat data onto the globe while correctly tracking piece bounding boxes.

Also, there are updates to support users of the cosmology and windblade formats. For example the MaskPoints filter (used to place glyphs and in other places) was updated with new options that improve random sampling in parallel. Likewise VTK's Gaussian Splatter filter is now exposed in ParaView which makes it easy to visualize point set data with imaging filters. The cosmo and windblade readers have also been revised.

This version includes some major changes under the covers. ParaView 3.12 includes improvements to the underpinnings of ParaView ServerManager. The communication layer under the ParaView ServerManager was upgraded to minimize communication as well as making it easier to debug and trace messages being exchanged between client and server. We now use Google Protocol Buffers, for example, to exchange messages between client and server.

In addition, there are several small but notable improvements included in this release for example, the views now use caching to avoid re-renders from repaints due to menus and dialogs popup up on the screen; volume rendering of uniform grids now supports shading; ability to enable specular highlights when using scalar coloring and others.

The updated userguide can be accessed on the ParaView Wiki (pdf)

The development team has adopted a git-workflow-based development process that is integrated with the ParaView Bug Tracker. The workflow enables us to track every change that goes into ParaView and maintain a stable repository.

We value your feedback. Please use uservoice or click on the "Tell us what you think" link on paraview.org to leave your feedback and vote for new features.

ParaView at the Large-Scale Data Analysis and Visualization (LDAV) Symposium

Utkarsh Ayachit — Mon, 07 Nov 2011 23:21:31 -0500

If you strayed into the corridors of Kitware or one of the ParaView developer meetings, you could not miss hearing talk about ParaView 4.0. As the team actively discusses new features and improvements we want to include in this major release for ParaView, I couldn’t help but remember some of the early meetings we had when we were planning for ParaView 3.0. There were many improvements discussed with 3.0, but one of the major ones was the support for customization. Our goal was to make a framework that would allow the development of sophisticated, high-end parallel visualization applications based on the ParaView infrastructure as well as a plugin-based architecture allowing developer add new features and enhancements to ParaView with ease. Through various releases since, this infrastructure has undergone several evolutions, but the underpinnings remain the same. For the longest time, all this seemed hypothetical, until my recent visit to IEEE VisWeek.

I was at the first ever IEEE Symposium on Large-Scale Data Analysis and Visualization (LDAV) held in conjunction with VisWeek 2011. The symposium focused on “bringing together domain scientists, data analytics and visualization researchers, and users, and fostering the needed exchange to develop the next-generation data-intensive analysis and visualization technology”. In a day that was very well attended until the fat lady sang -- so to speak -- over 14 papers were presented ranging from novel approaches to dealing with visualization challenges for new architectures to understanding how architectural decisions affect visualization and analysis. It was expected to be an interesting day; what was a pleasant surprise, for me at the least, was that several of the presenters mentioned customizations for ParaView! Some demonstrated their capabilities by integrating code into ParaView, a couple discussed how ParaView can be extended using proposed enhancements to a greater benefit. In this article, I give a quick overview of the papers that refer ParaView. Basically, a summary of the cool things the community is doing with ParaView.

Joe Insley, in his paper “Visualizing Multiscale, Multiphysics Simulation: Brain Blood Flow”, discussed how he and his team developed visualization tools for data from coupled continuum-atomistic simulations. They developed a ParaView reader plugin for processing macro-scale continuum data computed by a high-order spectral element solver. The reader plugin will be distributed with the official 3.12 ParaView binaries.

Venkat Vishwanath presented their work on GLEAN in “Toward Simulation-Time Data Analysis and I/O Acceleration on Leadership-class Systems”. GLEAN is a “flexible framework for data-analysis and I/O acceleration at extreme scale”. In a nutshell, GLEAN provides extensions to the I/O libraries that make it possible to leverage the network topology and other parameters for efficient I/O. At the same time, GLEAN enables in-situ analysis as the data is being streamed out for I/O. They demonstrated GLEAN’s co-visualization capabilities by connecting PHASTA (a CFD code) to ParaView through GLEAN.

As data sizes keep growing, fast, interactive visualization and analysis becomes a challenge. John Patchett, presenting the paper by Jon Woodring et. al. titled “Revisiting Wavelet Compression for Large-Scale Climate Data using JPEG 2000 and Ensuring Data Precision”, argued that the majority of these bottlenecks are due to data movement and associated bandwidth limitations. Using wavelet compression in JPEG 2000, John presented a mechanism to achieve improved data-transfer times by sacrificing data quality to varying extents. The team, in collaboration with Kitware, developed a working prototype within ParaView that uses reader plugins and new streaming views and enhancements to the VTK pipeline.

Nathan Fabian’s “The ParaView Coprocessing Library: A Scalable, General Purpose In Situ Visualization Library”, another paper involving contributing from members of the scientific visualization team at Kitware, presented ParaView’s coprocessing library. It is a framework for in situ visualization and analysis. The coprocessing algorithms can be directly linked and executed within the simulation code. The paper presented results from integrating the ParaView coprocessing library into various simulation codes such as PHASTA, CTH, S3D.

Oddly enough, it seemed like I was one of the few presenters at the symposium not talking about ParaView at all (I was there presenting the Dax Toolkit)! I suppose after talking ParaView day in and day out, it’s refreshing to shut up and listen to what others have to say about ParaView.

ParaView 3.12.0 RC-3 released

David Partyka — Thu, 03 Nov 2011 08:05:22 -0400

Kitware is pleased to announce the release of ParaView 3.12 release candidate 3. This release can be considered a bug-fix release that addresses over 180 issues; the full list can be found at http://www.paraview.org/Bug/changelog_page.php?version_id=85. Binaries for Windows, Linux, and Mac operating systems are now available for download on the ParaView download page and a revised user guide can be accessed on the ParaView Wiki, or in PDF form.

As Python continues to be one of the most preferred means of interacting with ParaView, release candidate 3 contains new support for creating animation tracks that use Python scripts to build highly-customizable animations. We’ve also added new capabilities to our plugin support, making it easier to load deployed plugins on server processes. All distributed plugins are now listed on the client side as well as the server side.

Updates have also been made to the streaming framework at Los Alamos National Laboratory (LANL). The multi-resolution view now adjusts the resolution to match the projected image size. Additionally, VTK filters can now modify meta-information, allowing users to modify data while the streaming framework culls and prioritizes pieces; for example, the new spherical warp filter projects flat data onto a globe while successfully tracking bounding box pieces.

Additionally, support updates have made for users of the cosmology and windblade formats. For example, the MaskPoints filter for placing glyphs, etc. was updated with new options for improving random sampling in parallel. VTK’s Gaussian Splatter filter was likewise exposed in ParaView, making it easier to visualize point set data with imaging filters. The cosmology and windblade readers have also been revised.

ParaView 3.12 also includes major improvements to the underpinnings of the ParaView ServerManager. The communication layer beneath the ServerManager was upgraded to minimize communication and make it easier to debug and track messages exchanged between the client and server.

Smaller yet notable improvements included in ParaView 3.12 include views now using caching to avoid re-renders from repairs due to menus and dialog popups on the screen; volume rendering of uniform grids to support shading; and the ability to enable specular highlights when using scalar coloring, etc.

The following updates have also been addressed since release candidate 2:

12670 SPTimeseries tests failing
12636 fix incompatibility with OCCT 6.5.2
12678 Build issues using external png on OSX
12667 cross compilation fails
12671 Prism now working correctly in client-server mode.
12630 Default PARAVIEW_INSTALL_THIRD_PARTY_LIBRARIES to OFF
12652 coprocessing writers menu is not enabled after creating a filter and hitting the Apply button
12650 Multiple file plot over line seg faults
12651 Crash toggling displayed variables plot over line.
12638 ServerConfiguration XML (PVSC) not correctly using random default values.
12626 remove cosmo plugin

We value your feedback. Please use http://paraview.uservoice.com or click on the "Tell us what you think" link on paraview.org to leave your feedback and vote for new features.

What's New in VES?

Katie Sharkey — Tue, 25 Oct 2011 13:15:12 -0400

Pat Marion recently posted VES: Development in Iterations, which included a demo of VES using KiwiViewer. This post will discuss some of the back-end features that enabled the demo.

The VES library is the backbone of the KiwiViewer. It provides a framework for developing visualizations on mobile platforms using OpenGL ES 2.0. Recent developments in VES were made with two important considerations in mind:

Performance
Having a nice API

Since VES uses OpenGL ES 2.0, it forced us to implement features a bit differently than if we had developed them for desktops. This is so because OpenGL ES 2.0 is a subset of OpenGL for desktops. Still, OpenGL ES 2.0 provides enough capabilities to create a very usable visualization running at interactive frame rates.

So, what's new in VES?

1. New Rendering Pipeline:

VES adopted scene graph early on. Scene graph provides two important features: it allows objects to be put together in relation to each other and provides opportunities for optimizations. In this new version of VES, implementation has been changed to achieve both of these desired features of scene graph. Instead of rendering while traversing earlier, drawable entities are now placed in a render stage. The render stage makes sure to minimize state changes to achieve performance. This particular approach also allowed us to provide a framework for features such as render-to-texture and other multipass rendering techniques.

2. Generalized Uniform and Vertex Attribute Support:

Since OpenGL ES 2.0 follows the core profile of OpenGL, glLoadMatrix, glBegin()/End(), and other GL commands are gone (for better). Now, all matrices (model view, projection, etc) and vertex data (position, normal, color), etc. have to go through shaders via uniform and vertex attributes. We have provided an extensible framework using VES uniform and vertex attribute objects to make it easier to deal with this change. It also allows dynamic updates to uniforms, which can be used for animations.

3. Use of VBOs for Performance:

If you want performance, Vertex Buffer Object (VBO) is the way to go and that's exactly what we are doing now. Thanks to Brad Davis, we split our VBO data into smaller chunks to achieve higher rendering performance.

4. Multiple Shader Support:

The framework now allows for switching shaders, as shown below in a test program (Gouraud shading, Blinn-phong shading, Toon shading).

5. Generalized Texture Support:

VES now allows the creation of generalized texture objects (textures are material attributes in VES) and use of them wherever required. There is work-in-progress to support different texture environments.

6. Render-to-Texture:

This feature was recently added to allow for rendering a scene to a texture and for later use of the texture for other purposes in the same scene or a different one. We wanted to show this as a part of the demo found in the Iterations post, but didn't get enough time.

7. Color by Scalars:

Using generalized texture support, it is possible now to create a one-dimensional texture and use it to look-up a table in the shaders. This test uses default values for vtkLookupTable.

8. Support for Rendering Overlay Objects:

Using the new VES framework made it quite easy to add support for rendering overlay objects such as screen texts. Thanks Pat!

9. Support for Rendering Transparent Objects:

The framework sorts objects based on their bin property, which natively adds supports for rendering transparent objects. In the future, we will add support for order independent transparency.

10. Clip Planes and Two-sided Lighting:

This is all done in shaders.

11. Gradient Background:

Actual algorithm-to-render for gradient backgrounds is straightforward, but supporting different backgrounds for each camera (there could be more than one and or in parent / child relationship) so that we can provide a generalized support for backgrounds (skydome, plane, textured, and gradient) is bit tricky. We implemented this feature based on the work done for the render-to-texture feature.

12. Testing:

We added few tests to ensure software quality and plan to add more in near future.

We are working towards making a release, but would like to handle one or more issues, add couple of new features, and provide documentation (there is none right now) before then.

VTK, Google Summer of Code and the Mentor Summit

Marcus Hanwell — Sat, 22 Oct 2011 11:17:32 -0400

I have taken part in several Google Summers of Code, beginning back in 2007 as a student, then a mentor, and this year a mentor and organization admin. We recently published an article in the Source summing up the results of our two student projects. I would like to thank our students once again, and congratulate them both on completing two successful projects. In about ten minutes I will be heading out to the Googleplex for my first Mentor Summit, where the mentors from the projects that took part gather and share their experiences and arrange sessions to discuss how we might improve things in the future.

I think for any community to survive it must grow, and encourage new ideas. For me the Google Summer of Code program has been a great catalyst for growth, and I am looking forward to discussing the impact this can have. My own personal opinion is that open source is one very important aspect in the bigger picture of opening up scientific research. Something the science code manifesto clearly states, but I think it also relates to the fact that for science to move forward we must all be free to raise ourselves up on the shoulders of giants. As software becomes an increasingly important element of research, we need high quality open codes that we can examine, modify and redistribute.

If you are at the Mentor Summit and want to talk about open source, or open science, please find me. I am looking forward to a very interesting weekend, after what has been a very busy summer with lots of exciting developments (hopefully I will find time to write about a few more of these later).

VES: Development in Iterations

Pat Marion — Fri, 21 Oct 2011 17:18:55 -0400

My name Is Pat Marion; I’m an engineer at Kitware and part of the VES team. VES is the VTK OpenGL ES 2.0 Rendering Toolkit. We’ve already released a 0.0.2 version of KiwiViewer, the demonstration app for VES, on iPhone and iPad, available in the App store. We have a lot of things coming soon, including KiwiViewer for the Android market and new demos to show at VisWeek 2011. Here's a sneak peak at one of the demos-

The VES git repo will be released early next month after another round or two of iterations. We’ve been doing a lot of iterations (usually just one or two weeks in length) for the past eight weeks to push VES forward as quickly as possible.

Here’s how the iterations proceed in our git repo: a new a topic branch is created and owned by one of the VES team members. Work-in-progress on the topic is staged so that other team members can try the feature, or simply read through the code. Next, iterate (duh!) - the topic is merged to master as soon as we’re comfortable so that everyone can base new work on it.

At this early stage in development, it is to everyone’s benefit to merge early. We keep a close eye on valgrind and benchmark the frames-per-second so that we never lose performance. Who cares if the merge comes with a few loose ends; those will be tied up in the next iteration, which starts now!

And so, here we are, iterating on our code at high speed to prepare demos for VisWeek. Last week I added support for 2D text annotations using VTK’s freetype classes. The annotations can be anchored to 3D points on a mesh, allowing for updated annotation positions as the camera moves around the scene. This feature was demonstrated in the demo video linked above.

Another demo in the iteration pipeline is basic animation support. Using ParaView’s animation controls, you can export animation geometries for viewing on mobile devices. The animation timeline is controlled with touch interaction, and in the next iteration we want to flex the VES render-to-texture functionality to generate keyframe thumbnails along the timeline.

We’ll be showing these demos and more at VisWeek, including a 3D image slice widget and a mesh clipping widget, so we’ll see you there in Rhode Island! Come find us and our iPad and Android tablets at the Kitware table and stay tuned for a source code release announcement. As always, if you are interested in learning more about VES and our mobile visualization capabilities, please contact Kitware for more information.

VTK Google Summer of Code Projects

Marcus Hanwell — Fri, 17 Jun 2011 14:06:05 -0400

This is VTK's first year as a Google Summer of Code mentoring organization, and we are very pleased to be here. During the application period we received a large number of very high-quality proposals, and I would like to thank all of the students who applied. As it is our first year we were limited to two slots, which made choosing our students even more difficult. After much deliberation we made our decisions and I am very happy to welcome David Lonie and Tharindu De Silva as our first Google Summer of Code students!

David is working on chemistry visualization in VTK, and Tharindu is working on implementing select algorithms from IEEE VisWeek in VTK. They were both very quick to start coding, and already have code up for us to review. David was also able to come and visit us at Kitware HQ for a few days, and meet many of the core VTK and ParaView developers. I hope you will welcome David and Tharindu to the VTK community, and I look forward to seeing what they accomplish over the summer. I have seen results from both students, and they are already taking shape after only a few weeks of active development.

This is a very exciting year for the VTK community with our Google Summer of Code participation, modularization of our source tree and refresh of the build system. There are also lots of great new features going into VTK such as new charts, improved interaction and much more that I will talk about soon.

The Architecture of Open Source Applications

Bill Hoffman — Fri, 27 May 2011 19:47:42 -0400

Two of Kitware’s open source software packages were featured in a sequel book to O'Reilly's "Beautiful Code". In the new book "The Architecture of Open Source Applications" there are two chapters by Kitware authors: Berk Geveci and Will Schroeder wrote about VTK, and Bill Hoffman and Ken Martin wrote about CMake. The book is meant to give detailed insight into the development process of some popular open source projects. Readers are given valuable insights into the engineering trade-offs made during development process.

The book should prove useful to developers of both open and closed source software. The instructional value of the book further demonstrates the power of open source development. The valuable insights given into the development of complicated powerful software systems would not be possible with closed projects. The book content is available for free under a Creative Commons license and the book can be purchased from various online retailers.

The official press release for the book follows:

New Book Gives Insight Into How Leading Software Developers Think

Toronto, ON, May 25, 2011 -- A new book about the design of open source software, released this week under a Creative Commons license, provides unique insight into how leading developers think. Titled "The Architecture
of Open Source Applications", the book contains chapter-length descriptions of the design of over two dozen significant projects, along with their creators' explanations of why things are the way they are, and what they learned along the way.

Software developers have long complained about the fact that while architects study thousands of buildings during their training, most programmers only ever get to see a handful of large programs---usually programs they wrote
themselves. As a result, they repeat one another's mistakes rather than building on one another's successes. "The Architecture of Open Source Applications" seeks to change that, and by doing so, help developers at all levels learn more about how to create complex systems well.

The book is published by Lulu.com, and is available there [1] and through other online retailers. All royalties from sales will be donated to Amnesty International to support their worldwide campaign for basic human rights. The book's content is also available online at its web site [2]. For more information, contact Greg Wilson at aosa@aosabook.org

"...a wonderful book and a wonderful contribution to the industry."
- Grady Booch (co-inventor of UML)

[1] http://www.lulu.com/content/paperback-book/the-architecture-of-open-source-applications/10559746

[2] http://www.aosabook.org

The Architecture of Open Source Applications

Bill Hoffman — Fri, 27 May 2011 11:41:27 -0400

Two of Kitware’s open source software packages were featured in a sequel book to the O'Reilly's "Beautiful Code". In the new book "The Architecture of Open Source Applications" there are two chapters by Kitware authors: Berk Geveci and Will Schroeder wrote about VTK, and Bill Hoffman and Ken Martin wrote about CMake. The book is meant to give detailed insight into the development process of some popular open source projects. Readers are given valuable insights into the engineering trade-offs made during development process.

The book should prove useful to developers of both open and closed source software. The instructional value of the book further demonstrates the power of open source development. The valuable insights given into the development of complicated powerful software systems would not be possible with closed projects. The book content is available for free under a Creative Commons license and the book can be purchased from various online retailers.

The press release for the book is as follows:

New Book Gives Insight Into How Leading Software Developers Think

Toronto, ON, May 25, 2011 -- A new book about the design of open source software, released this week under a Creative Commons license, provides unique insight into how leading developers think. Titled "The Architecture
of Open Source Applications", the book contains chapter-length descriptions of the design of over two dozen significant projects, along with their creators' explanations of why things are the way they are, and what they learned along the way.

Software developers have long complained about the fact that while architects study thousands of buildings during their training, most programmers only ever get to see a handful of large programs---usually programs they wrote
themselves. As a result, they repeat one another's mistakes rather than building on one another's successes. "The Architecture of Open Source Applications" seeks to change that, and by doing so, help developers at all levels learn more about how to create complex systems well.

The book is published by Lulu.com, and is available there [1] and through other online retailers. All royalties from sales will be donated to Amnesty International to support their worldwide campaign for basic human rights. The book's content is also available online at its web site [2]. For more information, contact Greg Wilson at aosa@aosabook.org

The web site for the book is here:

http://www.aosabook.org/en/index.html

The press release for the book is as follows:

New Book Gives Insight Into How Leading Software Developers Think

Toronto, ON, May 25, 2011 -- A new book about the design of open
source software, released this week under a Creative Commons license,
provides unique insight into how leading developers think.  Titled
"The Architecture of Open Source Applications", the book contains
chapter-length descriptions of the design of over two dozen
significant projects, along with their creators' explanations of why
things are the way they are, and what they learned along the way.

Software developers have long complained about the fact that while
architects study thousands of buildings during their training, most
programmers only ever get to see a handful of large programs---usually
programs they wrote themselves.  As a result, they repeat one
another's mistakes rather than building on one another's successes.
"The Architecture of Open Source Applications" seeks to change that,
and by doing so, help developers at all levels learn more about how
to create complex systems well.

The book is published by Lulu.com, and is available there [1] and
through other online retailers.  All royalties from sales will be
donated to Amnesty International to support their worldwide campaign
for basic human rights.  The book's content is also available online
at its web site [2].  For more information, contact Greg Wilson at
aosa@aosabook.org

Open Source Visionaries

Will Schroeder — Fri, 20 May 2011 15:24:38 -0400

Creating, extending and maintaining modern computational tools is really hard. It used to be that a motivated person could envision a solution, knock out some code, and have a useful prototype running in a short time (days or weeks). The resulting code was simple (and short), the build environment was typically a brief makefile (if that), cross-platform issues were ignored, and the narrowly focused solution didn't require much of an architecture. While this approach is still in limitied use today, serious users and developers of computational software are addressing daunting new challenges: algorithmic complexity, cross-platform development, extensive integration requirements, new computing models (distributed, multi-core, GPU) and computing environments (client/server, cloud, web-based, mobile), and a plethora of computing languages. What used to be a relatively quick process to create something useful has now become a focused effort of months or years.

As a result I think we've come to the point where open source approaches are the only viable way to build and sustain large-scale computational tools. Many others have made similar claims arguing along the lines of intellectual freedom and engineering process. For example, it has become increasingly evident that the lofty philosophical roots of open source freedom are absolutely essential to the practice of Open Science (and the resulting innovation). And if you are a pragmatist, there are clear engineering benefits including scalable software development (ref cathedral and the bazaar), agile software processes, and community maintenance. However, there is another critical argument to make in favor of open source -- its power to create, implement and sustain a long term Collaborative Vision -- which I believe is underappreciated yet essential to the future of scientific computing software.

Let me put it this way: How are we going to create and pay for the advanced computational tools of the future? While the long answer is complex, I think there are two key issues that must be addressed in any solution: the need to create and sustain a long-term vision, and the ability to pay for it. In both these areas, I believe that open approaches carry decided advantages.

Take vision for example. Without clear vision a software system is doomed to cluttered, fragmented and clumsy implementations. However with too rigid a vision, or a vision that cannot adapt and change, a system soon becomes obsolete and eventually dies. Large systems often begin with a modest vision and a few developers, but as it succeeds and grows the corresponding vision must also grow (not to mention the community). To accomplish this you can't do it behind closed doors (well maybe you can if you're big enough and rich enough but this is not common). For most of us, the only way to really grow the vision is to mix the visionary technologies and ideas that others have created into our software stew and make it part of the recipe. In other words you need a community to provide its collective intelligence to hold and grow the vision, which of course is a hallmark of open source practices.

Now how to pay to manifest the vision? For example, tools like VTK and ITK are conservatively estimated to have cost tens of millions of dollars to develop over decades [ref]. How many venture firms, angel investors, funding agencies, and companies do you think would have the patience and resources for that kind of effort? Especially when we are talking about complex computational tools whose commercial potential is murky at best (unless you are a company that is smart enough to turn computational infrastructure into a service ;-)). In an open approach, once you have developed the vision, it is possible for thousands of users and developers, for their own particular reasons, to contribute to implementing the vision--some simply volunteering for the intellectual challenge; others committed to building a scientific and engineering infrastructure to avoid reinventing the wheel over and over again; still others joining forces and attacking grand scientific challenges; and even commercial entitites who wish to reduce maintenance costs by contributing code to the community. Whatever the reason, each of these parties contributes time, money and knowledge which inexorably builds towards realization of the vision. Of course, this only works in an open environment.

So I would add to the current list of advantages of open source systems, intellectual freedom and scalable engineering process, Collaborative Vision--the ability to envision and manifest advanced technologies over extended periods while efficiently combining the resources of many people and organizations. I believe it is the ability of open source communities to create, hold, and evolve their combined vision, along with the efficient capture of contributions, that will eventually overtake closed approaches and create an open, sustainable computing infrastructure.

Creating, extending and maintaining modern computational tools is really hard. It used to be that a motivated person could envision a solution, knock out some code, and have a useful prototype running in a short time (days or weeks). The resulting code was simple (and short), the build environment was typically a brief makefile (if that), cross-platform issues were ignored, and the narrowly focused solution didn't require much of an architecture. While this approach is still in limited use today, serious users and developers of computational software are addressing daunting new challenges: algorithmic complexity, cross-platform development, extensive integration requirements, new computing models (distributed, multi-core, GPU) and computing environments (client/server, cloud, web-based, mobile), and a plethora of computing languages. What used to be a relatively quick process to create something useful has now become a focused effort of months or years.

As a result I think we've come to the point where open source approaches are the only viable way to build and sustain large-scale computational tools. Many others have made similar claims arguing along the lines of intellectual freedom and engineering process. For example, it has become increasingly evident that the lofty philosophical roots of open source freedom are absolutely essential to the practice of Open Science (and the resulting innovation). And if you are a pragmatist, there are clear engineering benefits including scalable software development (The Cathedral and the Bazaar), agile software processes, and community maintenance. However, there is another critical argument to make in favor of open source -- its power to create, implement and sustain a long term Collaborative Vision -- which I believe is under appreciated yet essential to the future of scientific computing software.

Now how to pay to manifest the vision? For example, tools like VTK and ITK are conservatively estimated to have cost tens of millions of dollars to develop over decades (see the bottom of the page describing the NA-MIC Kit). How many venture firms, angel investors, funding agencies, and companies do you think would have the patience and resources for that kind of effort? Especially when we are talking about complex computational tools whose commercial potential is murky at best (unless you are a company that is smart enough to turn computational infrastructure into a service ;-)). In an open approach, once you have developed the vision, it is possible for thousands of users and developers, for their own particular reasons, to contribute to implementing the vision--some simply volunteering for the intellectual challenge; others committed to building a scientific and engineering infrastructure to avoid reinventing the wheel over and over again; still others joining forces and attacking grand scientific challenges; and even commercial entitites who wish to reduce maintenance costs by contributing code to the community. Whatever the reason, each of these parties contributes time, money and knowledge which inexorably builds towards realization of the vision. Of course, this only works in an open environment.