This idea has been brought up before, but so far it has not really been an issue. However, this looks like the time when it would be possible to accomplish this.

JSPWiki code base is old, and it needs some refactoring. This refactoring includes things like moving to Java 5, fixing the metadata engine, replacing the backend with something scalable, and in general removing all the cruft that has been accumulated over time. This requires that we break compatibility with existing plugins and other components. Not badly, but to some degree.

Also, JSPWiki as an open source software project is growing slowly but steadily. However, the wiki world is moving rapidly, and wikis have been adopted widely. JSPWiki has become a tool for a great many companies, who are relying on it in their daily business. This is a lot for a hobby project lead by a "benevolent dictator" -model. Therefore, it is time for JSPWiki to mature to a "real" open source software project to be a serious contender in the wiki world.

To accomplish both of these goals needs a major shift in how JSPWiki is managed and who "owns" it, in a sense. Therefore, we (the people who have been committing source code) think that Apache would be a good choice, and have decided that we will try to submit JSPWiki into the Apache incubation process, with the goal of graduating as a top-level project.

The proposal is currently being drafted at ApacheJSPWikiProposal, and discussion is done in the jspwiki-dev mailing list.

-- JanneJalkanen, AndrewJaquith, ErikBunn, DirkFrederickx, JuanPabloSantosRodriguez, MurrayAltheim, ChristophSauer, 07-Aug-07


FAQs#

What will happen to existing JSPWiki?#

Well, the current idea is to release JSPWiki 2.6 as a LGPL project from our web site. After that, we'll move JSPWiki source code to the Apache SVN, and start working on the licenses and dependencies. The aim would be that JSPWiki 3.0 would be an Apache release.

What about plugins?#

The thing is that we're gonna need to change the package names, so all existing plugins and modules will break. However, hopefully this can be accomplished in such a way that basic string-replace of "com.ecyrd" to "org.apache" would be enough.

Some of the APIs are full of crud, though, so we might want to refactor them.

How will this benefit my company?#

Well, assuming Apache accepts us, you should be getting a piece of software which has strong community support, and is no longer susceptible to random fits of a couple of lead developers. This means that building your business on top of JSPWiki will be a lot safer than it used to be.

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-4) was last changed on 19-Oct-2007 23:15 by 84.194.120.63