What to do?
Don't split this community in two. You know that is going to happen if you make this "Ardor3D" a completely seperate project from jME. I could describe an example scenario, but I imagine that would be easy enough to do on your own. "Ardor3D" would become the new "next", while jME would remain the more mature and well known engine of the two for quite some time => You just got yourself a split community.
Instead, I recommend the following:
#1 - Re-assemble your team
You're doing this already with "Ardor3D", just without being directly in touch with the community that you yourself helped build from scratch. There might be complications in terms of server and domain ownership, third-party projects, loss of credits, you name it. No biggy, just deal with it, for the sake of your community.
- Make sure your website has got a proper teamlist where every active core member is accounted for in necessary detail (Nickname + Real name, Time of joining, main responsibility).
- Define roles in a proper manner. Make it very clear who is supposed to be doing what. Delegate responsibility.
- Expand team-member. Contributors could have the honour of being part of your team even if they're not actively submitting patches or whatnot. What about roles like Doc Writer and Support Specialist?
Whether or not you should have a defined hierarchy is up to you, but I would definately recommend it. A group of "department leaders", "heads of staff" or whatever you'd like to call them will always come in handy when there's a decision to be made that can't easily be settled through a consensus among several individuals. The leaders are the ones who carry the extra load, knowing the project inside out,
usually knowing what's best for the project. You might be against a hierarchy, but the simple fact is that some people always stand out as the more influential and respected than others, and their words will weigh heavy, more so than others'.
With that in mind, I see no harm in making clear statements of who's really in charge at the end of the day.
#2 - Add a
Project Manager to your team
A 3D engine is a major endeavour, and you obviously have plans to expand your team and establish a community surrounding this new engine of yours. If you hope to use words like "smooth", "without a hitch" and "positive growth" when describing your team and community, you will, without any shred of doubt, need an individual who can dedicate his time
solely to the act of project & community management. Most likely you would need more than just one soon enough, but that shouldn't be too hard to deal with as long as you got the one essential guy for starters. In other words, this member of your team would not be doing any programming at all; he wouldn't even
have to understand it very well, as all you'd really need of him would be his excellent administrative skills.
I'll gladly apply for the position myself, but I'm sure there's got to be someone among the hundreds, maybe thousands, of people out there who know so much better than me what jME is all about, as a 3D engine, a (open source) project, and a community. Just don't expect you'll be able to manage this project "on the side", or have everyone "do their part". It just doesn't work that way.
The project manager is equally important as the architect.
#3 - New domain and label
You wanted a new label, so go get it, just don't abandon your loyal supporters in the progress. I would suggest that you keep the forum, while the website itself should be considered for partial or complete remake. Yes, again. Why? Because even though it might look more appealing with an improved first-impression now, I don't see all that many improvements in terms of more elaborate wiki-pages, improved navigation and internal restructure.
So what would "Ardor3D" really
be? That's simple:
"We're making a next-generation Java 3D Engine, codenamed jMonkeyEngine 3.0".
=> Discussion, development and documentation could go on as usual. A new section in the (ore a whole new-) wiki would be created, dedicated to the remade 3.0-line. Once the new engine is worth releasing to the public, the change of domain and label (and possibly licensing???) would concurrently follow.
#4 - Drop 1.0 support, round off 2.0, initiate 3.0
1.0
Presentation
It's time to put an end to the 1.0-line of jME. 2.0
was a push for the better, so why dwell on it any further? 1.0 is old now, and will rapidly seem a whole lot older, even deprecated when "remakes from scratch" such as "Ardor3D" starts appearing. The 1.0-line should become just another part of jMonkeyEngine's
history, not something developers should bother having a look at for reasons beyond curiosity.
Development
Stop giving 1.0-related support on your forum. Make it very clear that the 1.0-line is now discontinued and feature-frozen. Projects depending on 1.0's code should be strongly encouraged to port over to 2.0. Should they however wish to keep using 1.0 they can't be stopped. Maybe there's a 1.0 enthusiast out there who would be willing to keep monitoring and maintaining the 1.0-line, but if not, I'd suggest you just leave it there everyone to use it as-is, without the possibility of submitting changes to the code. The less superfluous management-assignments the better.
Documentation
1.0's documentation should be compiled and put into some archive-like section of your wiki, or removed entirely, leaving a downloadable .txt-file or something where all the old documentation is stored.
Add an (hidden) archive to your forum. Move all 1.0-related threads in there to avoid revival of old and irrelevant topics.
2.0
Presentation
The 2.0 version of jME however is another story. As long as you leave it in the hands of the community, you don't really have to develop it any further, but you should keep up your support for it. The important part is that you stop downplaying 2.0's potential as an actual engine to-date and the future ahead of it, as I would easily argue that this is something you have indeed been doing through some of your recent commentaries.
jME 2.0 needs more appraisal. jME's improvements from 1.0 to 2.0 are poorly explained at best. I'm having a hard time finding the page that tells me "this is why 2.0 is so much better, and deserves a jump from 1.0 to 2.0 in versioning" and "this is why
you should port your code to be compatible with 2.0's improvements, and continue development of your project from there".
Development
The development of jME 2.0 should take place in its own 2.0 category, seperate from any 3.0 advancements. In my opinion the suggestion-board should be for the 3.0-line only, seeing as whatever changes are commited to the 2.0-line would be those of projects who originally made these changes for their own needs, but realized that their changes proved to be useful overall in a general context.
Documentation
Seeing as 2.0 is where jMonkeyEngine is currently at, 2.0 would compose the "forefront documentation" so to speak. 2.0's documentation should still be kept seperated as strictly 2.0 documentation however, allowing 3.0 documentation to be created on the side. Whatever documentation that turns out to be identical for the two should still remain as cloned pages, and not one shared page, enforcing complete seperation. More general pages (e.g. resource links) should of course be made unreliant of either version, but the content within should be clearly labeled if 2.0/3.0 compatibility is relevant.
3.0
Presentation
For 3.0, explain every change that surrounds it. 3.0 would represent more than just a new beginning in terms of code, which is basically what 2.0 was all about if I understood correctly. 3.0 would be a new project alltogether, re-assembling the core team, re-labeling, re-writing of the code with the help of new new principles and standards in mind...
"Ardor3D" is not just the future of Java 3D engines, but jMonkeyEngine's future => The next step.
Development
So clearly, the 3.0-line would be what every core developer of soon-to-be re-labeled jMonkeyEngine is now working on. The 1.0 line is discontinued, and the 2.0 line is left in the hands of the community for continuous maintainance for as long as they are willing.
Documentation
3.0's documentation would be started from scratch. If a new type of documentation is desired, e.g. a new type of wiki or a different tool alltogether, then that could be done.
