ApacheCon EU 09 is history, but there's a second chance to see and hear Betrtrand Delacretaz' talk "Open Source Collaboration Tools are Good For You!": Bertrand will be at the OpenExpo in Berne this week. For the meantime, here are the ApacheCon talk slide decks of Day's engineers:

Bertrand Delacretaz: Rapid JCR applications development with Sling

Carsten Ziegeler: Embrace OSGi

Felix Meschberger: Scripting Yor Java Application with BSF3

Jukka Zitting: Content Storage With Apache Jackrabbit

About a week ago we started the CMS Vendor Meme. It's time for a little roundup on how the meme got around:

The amount of responses that were published since last week completely blew me away. So far, the vendors that have responded are (in chronological order):

Magnolia, Alfresco, Jahia, Escenic, GX, CoreMedia, Infopark, dotCMS, Midgard, Vignette, Nuxeo, OpenText, EPiServer, Sitecore, Interwoven, Alterian, Hippo, Ektron, Knowledge Tree, and ez Systems

Also, the meme received quite some attention from CMS users and analysts: on Twitter look for hash tags #cmsmeme and #realitycheck. In the blogosphere Irina Guseva picked it up first, Jon Marks brilliantly commented on the meme as it evolved (here, here and here), Julian Wraith kept an eye on the scores (also correcting the scores of the vendors that did not add up correctly) and commented on individual responses, Bertrand Delacretaz suggested the ID and Juerg Stuker blogged about it in German. Make sure you also check out the discussions: in some of the blog post's comments Kas Thomas, the author of the original list, showed up. And, finally, if you are the type of person that enjoys extensive stats: Cedric Huesler has collected all sorts of data about the answers and compiled this spreadheet.

This has been a thoroughly enjoyable excercise so far, but I believe that there is real value in it as well. As Kas Thomas wrote: the responses reveal the vendor's DNA.

Oh, almost forgot. 9c56d0fcf93175d70e1c9b9d188167cf

Update: added Ektron to the list - thanks Kas for the hint. (30/03/09).

Update: synched the list with Jon's and added Knowledge Tree and ez Systems (07/04/09).

The Apache Software Foundation (ASF) celebrates its tenth birthday today. On March 25 in 1999 Roy Fielding signed the foundation's incorporation papers. Happy birthday!

A lot of successful and industry-changing software has been developed within the ASF in the last 10 years: see here for some of the ASF's highlights and the very well written "How the ASF works" page.

Day has strong relations with the ASF: we heavily contribute to and base our products upon the projects Jackrabbit and Sling. Moreover, many of Day's employees are involved in other Apache projects or serve in other ASF functions (see here for more information about Day's open source activities).

Therefore, I was more than happy to take this opportunity for an interview with Roy Fielding and Bertrand Delacretaz where they share some of their insights about the ASF's past and future. Day's Chief Scientist Roy is co-founder of the ASF and its former chairman. Roy also wrote the Apache License 2.0. Currently, he is V.P. for the Apache http server project. Bertrand (Senior Software Developer at Day) is a member of the Apache Software Foundation and an active committer on the Sling and Tika projects. He is also committer but currently inactive on the Cocoon, FOP, and Solr projects. Bertrand is also on the ASF's board of directors.

Roy Fielding

Founding the Apache Software Fondation was extraordinary for an open source project at that time (in 1999). The history pages of the ASF describe the reasons for founding the ASF as a kind of defensive act to protect individuals against legal threats. Was this the only reason or were there other ideas involved?

There were several reasons for incorporating. Although the Apache Group had been successful operating as a group of individuals, it was becoming increasingly difficult to deal with the outside world without a formal legal entity. We wanted to protect the Apache brand name against abuse by other organizations. People wanted to donate money to the project, but we had no way to accept it other than as individual income. Some of us wanted to organize a conference, which later became ApacheCon '98, but the liability issues required that it be produced by one of the companies that employed some of our volunteers. Most of all, it was the fact that we couldn't make non-technical decisions quickly: we actually started to discuss incorporation in September 1996, two and a half years before I signed those final papers.

The final straw came in 1998, when folks at IBM contacted the Apache Group in private to investigate contributing as part of the team of developers (IBM's first exposure to open source development). Before we could talk, however, IBM demanded that each of us sign a non-disclosure agreement, which is standard practice for any large public company. It would have been easy to do so if we were a legal entity, but instead we had to obtain written signatures from every single person in the core group, located all over the world.

An aspect that sets the ASF apart from many open source efforts is the invention of "incubation of projects" and, even more revolutionary, the "retirement of projects". What was the background of coming up with these concepts? Were there concrete projects that triggered this idea?

The Apache way of developing software is ideal for collaborations among developers regardless of their individual employers. Once we had incorporated and formalized the licensing agreements, the ASF grew very quickly as new projects were proposed. At first, the board created projects that covered entire areas, such as Java (later renamed Apache Jakarta), XML, and Perl. The Jakarta project, in particular, attracted hundreds of developers that wanted to contribute their own libraries and applications to Apache, and so each project started to act like the board and created sub-projects of their own.

However, there is more to the Apache way of development than just starting a project and letting the developers run wild. We have learned over the years that each team must be organized for peer review and formally vote on all releases, which requires some cultural learning on the part of new developers. Likewise, we need to ensure that we have sufficient legal paperwork for any software that is licensed to the foundation for further development, since copyright laws are applicable for seventy years (or more), far beyond the normal memory of any project. The early projects grew so fast, however, that it was impossible for the experienced Apache developers to keep track of the growth and mentor new volunteers.

The Incubator was the board's way of adjusting the organization to that rapid growth: by forcing all new projects to learn about the Apache way of development and actively engage ASF members as new project mentors, we found a way to grow the organization at the same rate that we were growing projects and volunteers. Of course, there are also many negatives to that approach: it can often seem to new projects that Apache is dominated by bureaucracy and process, since much of that process is only needed when conflicts emerge.

You wrote the Apache License 2.0. One key feature of the license is its commercial friendliness. Was that an explicit design decision of yours or is it a by-product of other design considerations you had in mind?

Apache has always used a commercial-friendly license, since we were founded by a diverse group of individuals from both academia and industry. Many of us had prior experience with the BSD license, which does not place restrictions on other software distributed with the product. Furthermore, since one of our original goals was to enable standards-based interoperability on the Web, we encouraged the other software-producing organizations to use our code instead of their own (often buggy and nonstandard) implementations.

This openness to collaboration among developers, no matter why they are interested in participating, is one of the key virtues that make Apache projects both fun and educational. Our licensing goal was to ensure that the final work product would be usable and redistributable by anyone, for any purpose, but without any warrantee. That is why we used a variant of the BSD license for the first five years.

The 2.0 license came about as an attempt to clarify both what the license grants under copyright law and what the contributors had agreed to grant under both copyright and patent laws. We wanted to protect ourselves and our users against deliberate contribution of works under "submarine patents" or other license that were more restrictive than our own. We also wanted to enable compatibility with GPL-based free software by providing an innovative way to acknowledge the original developers (if they so desired) without exceeding the restrictions in the GPL.

Ultimately, we measure the success of our license by how many organizations and individuals can safely redistribute our software without entangling the Apache developers in lawsuits. So far, we've been 100% successful.

Looking back at the ASF's history: what surprises you the most? What did you least expect to happen?

I think what has been most surprising is the ability of Apache projects to persist and evolve as the individual volunteers change their interests and move on to other things. In every way, Apache is entirely dependent on the imagination and effort of individuals. We are often working on problems that are only indirectly perceived by everyone else, and each is only working on Apache part-time.

We've had at least six different technical leaders within the HTTP server project over the past fourteen years, each of whom led the group in implementing massive improvements to the software in relatively short periods of time and then moved on to other problems within or outside the ASF. We have designed an organization that is able to make use of the vast numbers of volunteers on the Internet, and yet remain cohesive enough to retain its unique project culture and freedom to innovate.

I think what I least expected to happen is that I would still be involved in the project after all these years. I have been less involved in the code than I was in the past, but I still managed to fix a few issues this year and look forward to trying out a massive redesign in the coming year.

Over the years I've stretched into the various roles of just being one of the hackers to becoming the standards cop, from resolving technical conflicts into codifying the voting rules, from people management into project historian, and from release manager into semi-retirement status (only to come back again). To incorporate the ASF, I had to become familiar with corporate law and learn to communicate with corporate lawyers, create bylaws and a board to enforce them, learn how to be a Chairman, and teach a bunch of techies how to use the organization to make non-technical decisions in a business-like manner, preferably without turning the foundation into another work environment. The 2.0 licensing work required an understanding of copyright and patent law, starting Apache Jackrabbit meant learning how to be a mentor for contributors (and co-workers) new to Apache, and becoming chair of my old HTTP server project has been a challenge to motivate the revival of a project that had become complacent and overburdened by its own success. I am proud of each of those roles, though there is plenty of work still left to do.

Staying involved in Apache has proven to be the most consistent educational experience of my career -- I learn something new every week, especially when new volunteers enter the project and add their own perspectives and experience.

ASF's software has been integrated in endless commercial offerings. How should interested companies give back to the ASF? Day's approach of paying wages for open source developers is only one way. Straight payments, sponsoring events, but also opening patents or evangelizing the open source idea come to my mind. What is your thoughts on this?

First, I always encourage companies in our industry to hire the developers on Apache projects. How could they possibly go wrong in hiring a person who develops software for fun and has already proven their ability to produce peer-reviewed quality software as part of a self-selecting and meritocratic team?

However, there are many other ways to directly contribute to the Apache Software Foundation that are explained on the ASF website. The ASF is a nonprofit US corporation (IRS 501(c)(3) charity), so individual donations are often tax-deductible. In addition, we have a corporate sponsorship program that contributes the bulk of funds needed to run our Internet infrastructure and the other non-sexy parts of running a major foundation.

In terms of evangelizing open source, I actually encourage folks to do that within other organizations, such as OSI or the EFF, rather than at Apache. I think what Apache does best is to lead by example rather than by publicity or marketing. We do that by producing collaborative software development projects in a safe and consistent fashion, by producing software that is better than any single person or company could produce on its own, and to do all that while having fun.

Bertrand Delacretaz

Thanks for your questions. Please let me note that the answers below are my personal opinion, and do not necessarily represent an "official" position of the ASF. Nobody voted +1 on those yet ;-)

Bertrand, like most of Day's engineers you are a long time Apache committer. Currently, you are most active in the Apache Sling project. What would you say in how far the "Apache way" of software development influences development within Day in terms of process and product.

The Apache Way is very present in our development team's way of working, at Day. We use similar collaboration tools internally as in our Apache projects (source code control, issue trackers, mailing lists, wikis, continuous integration, etc.), decision-making principles are similar (including the "+1 / +0 / -1" way of voting), and in general all the necessary project information is available in self service mode for our developers. No need to run around the office to find out who wrote a particular piece of code or why it is needed - all this info is available in the "central knowledge base" that these collaboration tools manage without much intervention on our part. Among other benefits, this allows us to work efficiently from anywhere and at any time. We can also make much better use of face-to-face meetings, when they happen, without needing to first exchange that basic day-to-day information which is flowing automatically all the time.

You are one of the nine members of the board of directors and that job probably gets you to look at many aspects of Apache projects. What are the common struggles for projects and what are the upcoming challenges for the ASF as a whole?

I would say that, as a general rule, the ASF's projects have many more successes than struggles. Most of our projects are doing very good, thanks to a very good understanding, among developers and users, of what it takes for their communities to thrive. The overall well-being of our projects has improved in the last few years,in my opinion, thanks to developers getting more familiar with the open source way of working. That's remarkable, considering people who collaborate in our projects often come from different cultural backgrounds, speak different languages and usually meet only rarely, if ever. That would usually be a recipe for failures, but our communities work very well!

There are challenges related to our growth, and to the fact that the foundation has grown into a federation of projects that don't always know each other very well. It is the members and the board's duty to make sure our values are actively promoted in all of the ASF's projects, and until now that works quite well. But staying true to our values despite with the kind of growth that we're experiencing does require constant vigilance and regular adjustments to the way we communicate and share those values.

The ASF has grown from 200 committers to about 2000 (acording to the Wednesday's State of the Feather at ApacheCon). Do you expect this trend of rather strong growth to continue? What would you consider the limits of organizational scalability of the foundation - if there are any?

The trend will certainly continue, and the federated way in which the ASF is structured makes it possible to grow to larger numbers. The board of directors currently reviews about 20-30 project reports every month, to keep the oversight, and that works as we do trust our projects, try not to interfere with them unless really needed, and ask them for reports on specific topics (mostly community and development events, and issues that might require board attention). The members of the foundation (about 300 of them) do a very good job in keeping an eye on things at all levels and raising alarms when needed, which is not very often.

We are making some minor organizational changes, like hiring outside help for administrative tasks, to cope with this growth, but from a structural point of view the ASF is ready to grow more. As long as we have enough active members that we can trust, and sustainable mechanisms to allow the board of directors to keep the oversight as we have now, we should be fine.

There are some Apache projects that collaborate with Google's summer of code program. Do further plans exist within the ASF to assist in the education of the young about open source development?

We don't have specific plans, as far as I know, but the people who lead the Summer of Code effort in the ASF are members of the Press Relations Committee, who is also tasked with outreach in general. I have talked to many of our members and committers who are willing to help youngsters get on board and understand our way of working, so we can probably expect more activity in this area in the future.

Projecting your views of the ASF into the future, say, 5-10 years: what do you think will change, what will stay the same?

The ASF projects are mostly about web infrastructure, and I don't see that changing soon. Like developers in the last few years, I think more companies will learn how to collaborate efficiently with the ASF, while respecting our basic principles, and that will help them and us work together in a sustainable way in the long term.

The Apache Way is here to stay, even though tools will evolve; distributed source code control is probably the next important thing that will happen in our toolset, and although that will change some aspects of how we work, I don't expect a revolution.

It is impossible to say exactly how the ASF will look in ten years, but I'm quite convinced that we will stay true to our basic principles, and continue to be a successful neutral ground for people and companies to collaborate on creating great software, often with a global impact.

All this looks like a bright future, and the amount of dedication that I see in so many volunteers involved in the ASF gives me every reason to be optimistic about it.

Today's Link Of The Day is Joerg Hoh's excellent Communique blog "Things on a content management system - Tips and tricks for Day Communique".

In his latest post Joerg publishes a little Perl script to help determine average response times (and provide a visual indicator of the system's performance status).

Although the blog started only recently there is already a good number of performance-related posts. All of them are worth the read since they clearly reflect Joerg's first hand experiences in tuning CQ (so do his hands-on sys mgmt topics like: how to lock out the users).

@davidnuescheler you might want to check out Joerg's take on your 5 rules for performance tuning.

In the last weeks the "7 things about me"-meme has been all over the blogosphere (here are some random examples.). In case you missed it, here's how it works: a blogger reveals 7 previously unknown things about himself. That permits him to "tag" other bloggers, i.e. to publicly challenge them to reveal 7 things as well. If the tagged blogger accepts the challenge he:

1. blogs about the 7 things he wants to reveal,
2. provides a backlink to the blogger that tagged him,
3. and tags some other bloggers he wants to challenge.

It is in this great tradition that we herewith introduce: the

"CMS Vendor" Meme

Tadaa!

The rules:

• A CMS vendor is challenged to honestly answer all items on the "Reality checklist for vendors" suggested by CMSWatch's Kas Thomas (aka the "we-get-it checklist for vendors").
• If possible the vendor has supply screenshots, links or other means to make it easy to verify the answers.
• The answers also need to be supplied in a short form of one to three stars (denoting "no", "sort-of", "yes").
• Answering all questions on his blog allows the vendor tag some other WCMS vendors.
• A tagged vendor should provide a link back to the blog that tagged him.

So here we go:

1. Our software comes with an installer program.

Sure, one double click: installed. One folder removed: uninstalled. There are no strings attached.(see the screencast here)

2. Installing or uninstalling our software does not require a reboot of your machine.

Of course not. Installing is one double-click only, no reboot needed.

3. You can choose your locale and language at install time, and never have to see English again after that.

Well, there is really no install time.. But after that, you change the language in the preferences.

Hmm. Not perfect. Will settle for "sort-of".

4. Eval versions of the latest edition(s) of our software are always available for download from the company website.

CRX (our content infrastructure platform upon which our WCM, DAM, and Social Collaboration application are built) is available for free download by developers for non-production use. Our CQ WCM, DAM, and Social Collaboration applications are available upon request under an eval license. 2 stars only.

5. Our WCM software comes with a fully templated "sample web site" and sample workflows, which work out-of-the-box.

Yes

6. We ship a tutorial.

Yes, it is part of the help files.

7. You can raise a support issue via a button, link, or menu command in our administrative interface.

Ermhh.... Good idea :). Well, in CRX there is a direct link to the mailing list where support is provided. But I'll settle for 1 star.

8. All help files and documentation for the product are laid down as part of the install.

Yep.

9. We run our entire company website using the latest version of our own WCMproducts.

Of course (we updated www.day.com to CQ5 on the day of the release). dev.day.com is running on CRX and Sling at the moment (will be running on CQ SocialCollab when that's released)

10. Our salespeople understand how our products work.

As part of our product launch process, no product goes GA without our internal Sales, Consulting, and Support staff having downloaded, installed, and trained on the new product capabilities.

I know this for sure because I did parts of the training.

11. Our software does what we say it does.

12. We don't charge extra for our SDK.

There is no extra charge for CQDE (our IDE for CQ development). For lower level JCR development anyone can download our Eclipse plugin. Finally, CQ5 is built upon Sling which is open source, hence the APIs are free and open.

13. Our licensing model is simple enough for a 5-year-old to understand.

Make it a nine year old, but we are working on it... however, it is much easier than the usual industry level enterprise pricing... A "sort-of".

14. We have one price sheet for all customers.

Same pricelist, different currencies though.

15. Our top executives are on Skype, Twitter, or some similar channel, and: Feel free to contact them directly at any time.

Absolutely, all email addresses are on the web. The addresses also work as Jabber/GTalk addresses. Moreover, there is:

David Nuescheler (CTO): Slideshare, Xing, LinkedIn, david.nuescheler on Skype

Roy Fielding (Chief Scientist): Slideshare, @fielding on Twitter, Blog, LinkedIn

Kevin Cochrane (CMO): @kevinc2003 on Twitter, LinkedIn, kevinvcochrane on Skype, YIM: kevinvcochrane, Facebook: kevinc2003

So our final score is:

And we are tagging:OpenText, Coremedia, Interwoven, Vignette (where's your blog?), Fatwire (where's your blog?), Nuxeo, Magnolia and Tridion (where's your blog?)

Come on, guys. Don't be shy.

Update: adding the meme ID 9c56d0fcf93175d70e1c9b9d188167cf suggested by Bertrand. Google is our friend.

How many times do you setup a server software? Once! ... hmm.. wait. On my laptop, on the dev server, the load testing setup, live servers. We think that task such as install, updates, backup, setup cluster should be easy, so you can do it anytime you need it (and you will be surprised how many time that is, once it's just a few clicks). In the unlikely event that you need to recover from a total disaster - such as a data loss or hardware defect - we added a few more tweaks to help you out. But what do I write here.. just watch the screencast for yourself....

Update: the screencast is valid for CQ5 and CRX, so if you want to give those features a quick try download CRX.

It was only yesterday evening that I became aware of the "140 Characters Webapp Challenge" - just when it was closed. The challenge consisted of, well, writing a web app with a 140 characters code base (140 characters is the limit imposed on Twitter's status updates).

I could not resist giving it a try anyway. Naturally, using Sling. So here's the result: a micro-Twitter app that lets you update your status and displays the last status update in 136 characters (so there is even some space left for commenting the code):

<form method="POST"><input type="hidden" name=":redirect" value="t.html"><input name="w"><input type="submit"></form><%=currentNode.w%>

(the line needs to be put in /apps/t/html.esp and there needs to be an unstructured node at /content/t. The generated html is not for purists.).

If you can beat that (or have another funky sub-140 characters Sling app): tweet the code to @daysoftware or leave a comment with a link.

(from Geek and Poke)

This year's ApacheCon EU will take place in Amsterdam in two weeks. If you are there, check out the talks given by Day's engineers:

Bertrand Delacretaz: Rapid JCR applications development with Sling: Apache Sling is a scriptable applications layer, built on the Apache Felix OSGi framework, that provides a RESTful interface to a JCR content repository. In this talk, we'll see how Sling enables rapid development of JCR-based content applications, by leveraging the JSR 223 scripting framework along with the rich set of OSGi components provided by Sling. We will create a simple application from scratch in a few minutes, and explain a more complex multimedia application that does a lot with few lines of code. This talk will help you get started with Sling and understand how the different components fit together.

Open Source Collaboration Tools are Good For You!: What are the core requirements for a set of team collaboration tools? Looking at how ASF project communities collaborate online, we have identified four core drivers that help these projects succeed. We will show how the collaboration tools used by the ASF can allow any project team to move from an "ask around the office" collaboration model to our efficient "distributed self service information" model, while focusing on those core drivers to avoid being distracted by the tools themselves. Our analysis will help you estimate the effort and expected benefits of such a move.

Tales from the OSGi trenches: In this talk we share our experience with the Apache Felix OSGi framework, used for a major rewrite of Day's family of content management products. After more than two years working with OSGi, the impact on our products, developers, customers and service people is very high, in a positive way. OSGi is no silver bullet either. The extreme modularization and dynamic service deployment features of OSGi make our products much more robust and maintainable, but the costs associated with changing people's way of thinking about code and modules, and with testing and debugging highly dynamic systems, must not be underestimated. Based on real-life code samples, we will show how OSGi is used at several levels in our products, from low-level interactions with the framework to very simple creation of (compiled or scripted) services. We will also present some of the automated testing techniques used in our project. Sharing our experience will help you decide if OSGi is for you, and more importantly at which level you should use it.

Regarding OSGI: If you use OSGi and have some (positive or negative) feedback to share Bertrand is eager to hear from you.

Carsten Ziegeler: Embrace OSGi - A Developer's Quickstart: The first choice for highly modular, dynamic, and extensible applications is the OSGi technology. However the theory sounds very tempting but what about the real world? Starting with the basics of OSGi this session is focused on practical examples, tools, and procedures for a rapid adaption of OSGi in own projects. Learn how to avoid the typical traps and how to use the advantages of OSGi.

Meet Carsten at the Portals Meetup.

Felix Meschberger: Scripting your Java Application with BSF 3.0: One very important functionality of modern extensible applications is support for developping such extensions in any scripting languages. Many scripting languages available today provide some sort of Java integration but each integration is different making it very difficult for the vendor of the application to support more than one scripting language. Enter the Java Script API as defined in JSR-223. This API provides support for standardized integration of scripting languages in Java applications. Bindings already exist for a number fo scripting languages such as Groovy, JavaScript, Python, Ruby, Tcl. This session will show how easy it is to add scripting support to a Java application using the Java Scripting API and thus support whatever scripting language the user of the application likes to use. Practical demonstrations using Apache BSF 3.0 as the Java Scripting API implementation and Apache Sling as a Java application to be scripted will show how easy it is to add scripting support and to add scripting languages quickly and at runtime without even restarting the application.

Jukka Zitting: Content storage with Apache Jackrabbit: Hierarchical database or a transactional file system? Apache Jackrabbit combines some of the best features of relational databases and traditional file systems to implement a flexible high level storage solution for a wide range of applications. Jackrabbit, a fully conforming implementation of the Content Repository for Java Technology API (JCR), comes packed with features like full text search, versioning, and transactions. Built-in HTTP mappings with WebDAV extensions make content stored in Jackrabbit easily accessible in network environments. This presentation introduces you to the key concepts of JCR and shows how to use Apache Jackrabbit and related projects to build various types of content applications like wiki and blog engines, email archives or image galleries. Special emphasis is placed on a data-first approach to content design that helps make your applications extensible with little or no extra code.

Here's a useless nice to look at visualization of the Apache Jackrabbit svn commits. It was generated using "code_swarm". The dots denote committed files and the names are the developers' login names:

This visualization, [...], shows the history of commits in a software project. [...] Both developers and files are represented as moving elements. When a developer commits a file, it lights up and flies towards that developer. Files are colored according to their purpose, such as whether they are source code or a document. If files or developers have not been active for a while, they will fade away. A histogram at the bottom keeps a reminder of what has come before.

The Quicktime rendition looks best, but here's also a Flash version and an avi. Be warned if you are in an office: there is music (creative commons track from SuperNova)

jr.avi

jr.mov

Day's Chief Scientist Roy Fielding will speak at the SofTech 2009 conference in Milan (26 March). In this context Roy has been interviewed by Alessandro Giacchino about REST, SOA, JCR, and content management.

The Italian version of the interview has been published in the ToolNews magazine (here's a PDF of the article). Find the English version below (as a teaser: the interview contains the first definition of the term "SOA" that I can grok).

First of all, you contributed to the HTTP, REST and URI definition. What did take you to Day Software, a small swiss company working on Content Management solutions? Are you still working on the Java Content Repository or are you working on new "concept/project"?

Day Software has a much more international breadth and perspective than most companies. I met David Nuescheler, Day's CTO, in December 2001, when he was first exploring the idea of a standard Java API for content repositories and wanted my advice on the JSR process. After talking over dinner, it was clear to both of us that we shared a vision of how the Web architecture could be utilized by software and the role that standards development can play in establishing future infrastructure.

The REST architectural style is about making use of standard data formats and an "everything is a resource" conceptual view in order to tie together network-based applications into a reusable system of long-term resources.

Content management software is about managing the content of standard data formats and an "everything is content" conceptual view to tie together all of the content generated by an enterprise into a reusable system of long-term assets.

It is, in fact, exactly the same problem space with only a minor change in terminology and a realization that the software is content too. A content management system is an ideal RESTful application development environment if it remains true to the architecture of the Web.

I helped David with the process associated with starting and evangelizing the Java Content Repository (JCR) API in its first two years, but the technical work of JCR has been accomplished by David's work and that of our outstanding developers in Basel. My role has been to grease the gears and make it possible for Day to expand that work into open development projects at the Apache Software Foundation.

My current work is split between representing Day at various conferences/meetings around the world and developing the next generation of Web standards. I am currently revising the standard for HTTP within the IETF and am chair of the Apache HTTP server project, an important component not just for all of our customers but for the entire Web. I am also working on a longer-term project to create a new protocol that may eventually replace HTTP.

According to some analysts, instead of booming on the market, and evolving to 2.0, SOA seems to be in and "hold" position, slowing down all development and investment on it. Do you agree on this? If yes, why do you consider this happened? If no, what do you think will be the next drivers? Do you see any relations between SOA and Cloud Computing?

"SOA" has become all things to all people, and thus has no useful definition other than "stuff that you can access on servers." I don't think there has been any reduction in services. If anything, I find that there has been a huge move by companies onto outsourced services such as Gmail, Salesforce, and Amazon. I expect that trend to continue.

What has been moved to a "hold" position is the antiquated architecture of tightly coupled services that was promoted as "Web Services" (in spite of the fact that it had nothing to do with the Web) and SOAP. I think customers finally reached the end of their tolerance for software pixie dust frameworks that did not interoperate across multiple vendors. The architectures were insufficiently constrained for interoperability and reuse.

Cloud computing is another term that is often being misused. In my opinion, it means "outsourcing your data centers." There is significant value in doing so for many customers that do not want to be in the business of managing servers, power, etc. It also represents a significant challenge to enterprise software developers, since we need to incorporate secured access, remote deployment, and high-availability management into the core software architecture.

That is why Day's products have an emphasis on easy installation and automatic clustering support: we see the cloud computing environment to be the dominant platform for our customers, whether that "cloud" be in the form of a third-party, like Amazon Web Services, or an internally managed network like those currently being used by some of our larger customers.

Most of your project have been around Java and Open Source. Now, it happens that one of the best supporter of REST is Microsoft, while you are working for a company that "uses" Open Source, but sells commercial products. How do you consider will be moving in the future borders between this two totally different models to go to the market?

Day Software doesn't just "use" open source. We actively create and participate in the major infrastructure projects that are important to our customers. For example, Apache Jackrabbit, Apache Sling, and Apache Felix are major components of CQ5 (our flagship product for web content management). Likewise, Apache HTTP Server and Apache APR are used by all of our customers, often without knowing it, and our active participation in these communities allows us to leverage the experience and brainpower of hundreds of developers.

We develop our open source products under the banner of the Apache Software Foundation, rather than hosting our own open source projects, because we have found that a richer community of software developers can be formed around a nonprofit foundation like Apache. It allows everyone, even some of our competitors in the content management industry, to participate on an equal footing and ensures that the software won't be subject to any single company's moods. In turn, a larger community means more bugs are found and fixed quickly, more features are added by others, and more leverage is obtained for our commercial products that depend on open source.

The only software that Day has not open sourced is our application software, which is often highly integrated with specific customer needs. In addition to paying our salaries and supporting all of those open source infrastructure costs, keeping the application software private allows us to incorporate third-party products, such as components that integrate with legacy data sources and professionally designed user interface modules.

Microsoft has a quite different model. Microsoft gains much of its platform sales based on developer mindshare: their primary revenue stream is a proprietary infrastructure platform and the only way they can keep people buying that platform is to encourage developers to program for it. Microsoft's recent interest in REST is therefore just a reaction to where they see the developers moving -- it is a reaction to having lost the mindshare associated with Web Services.

What do you think about "Web 2.0", considering it in terms of Social Networking and new Client paradigms (Ajax, Silverlight), where all become "content" for informations, transactions and relations. Is it ready to fill its promises or should we wait for Web 3.0, 4.0 and so on? What will be "the next big thing"?

Web 2.0 is just a marketing phrase for the second wave in venture capital funding. I think that has clearly ended, at least within the Silicon Valley environment. The funny thing about these version numbers is that the "2.0" paradigms (AJAX, javascript, CSS, etc.) are all technologies invented back in 1997. It has only been the sad state of browser software that held back those advances for so long, and it only took one big company (Google, via Google Maps) to turn that around.

The Web architecture is currently on version 3.2, rapidly moving to 3.3, and my work is on 4.0. The biggest changes in the coming year will be in the nature of authentication systems and security, both of which haven't been improved significantly since 1995.

Did I miss the "right" question? Which one should you consider that it had to be?

I need to keep something in reserve for my presentation. See you in Milan.

Here's some Sling news highlights from the last weeks:

There have been two interesting contributions in the authentication and authorization area:

• Rory Douglas contributed code for OpenID-based authentication in Sling.
• Eric Norman has written a bundle that allows users management like:

  These custom SlingPostOperations are provided:
  1. createUser
  2. createGroup
  3. changePassword
  4. updateAuthorizable
  5. deleteAuthorizable
  

It would be cool to see them combined such that users logged in through OpenID became repository-based users on the fly (rather than be known as a technical user to the repository).

Notable news from the "Give them enough rope" department include:

• Support for scripting in the Scala language has been added.
• Now that Groovy 1.6 has been released the Groovy script engine has been added to the default collection of bundles that get installed with Sling.

Last, but not least I was delighted to see that Sling and JCR are being taught in a university course in Grenoble (thanks to @keepthebyte for the tip).