MapTool: Refined

[Lee]

Hi all,

This thread is to give notice to the community regarding my project MapTool: Refined; a fork of the code I've been working on since October (2012) up till the end of January (2013).

Several parts, primarily bug fixes and a couple of new features, have been submitted for evaluation for inclusion into the official MapTool code. This has affected my intentions to introduce new stuff into the code as bug fixing and new features are no longer parallel goals due to the feature freeze. It came as good news to me then that Azhrei has taken some time off to work hard at doing b89 and, possibly, b90. This means I can focus solely on feature coding moving forward.

It is evident and understandable that several of my submissions will/might not make it into the official code (e.g. Path fixing, Snapped/Unsnapped movement fixes, Input function expansion the Repository update through FTP, Undo/Redo fix, and FoW lag etc., just to name a few). All of these touch multiple parts of the code and some are not in a stage of maturity that can coincide with the idea of a "final MT build". That is all well and good, and I'm happy that I was able to contribute. All of these, along with several other items, will be earmarked in my fork as new features.

Which brings me to the heart of the matter, I'm under contract right now with very little time for anything else. Moreover, after this one expires, I'm set to either take on another contract that's waiting on the wings, or to accept a permanent spot from a company I've been turning down for years. If there's anything I've noticed with regard to development for the MapTool source, it is definitely a volunteer-based effort which lives and "dies" by this model, ever dependent on the time Java devs in the community can give. I want to put a solution of sorts on the table.

I can make time to get my fork to a stable version, with the help of the community and beyond. This comes at the cost of sustaining the project while it reaches that goal. I'm as altruistic as any other contributor to the community, and I do love Maptool, and RPTools in general, but accountability, adherence to timeliness, and volunteer-based projects, do not exactly form a self-sustaining cycle; not to mention, in terms of development, free and full-time are anathema to each other.

I'm currently mulling how to deploy this development campaign, the options for fundraising for MT: Refined are: offering it as donate-ware, or structuring it against more aggressive approaches such as those found in KickStarter or Indiegogo. For the latter context, alone, I'm confident I can drive success to something akin to Roll20's; with the help of the community and beyond, it may even become greater.

Out of respect to this community, however, I am asking its opinion first and promise to keep an open mind about the things I read/hear. I want to state, however, that I am not looking to profit off of this work but, rather, raise funds to keep external (i.e. financial) issues out of sight and mind while I drive development and interest in the project with what is accrued. Ultimately, once I'm satisfied with whatever refinements I've made, these will be open sourced for perusal and application to the official MT source. Several items might even be compatible with MT 1.4.

To the drive the point home, this is just an offer to develop full time for MT. Whatever goals I have in mind for MT: Refined can certainly make its way out into the world in due time without needing any funding at all. From the looks of things, however, it will take a very, very long time if it stays a volunteer effort on my part, and (as stated in posts elsewhere) I am unwilling to release "immature" code to the wild for others to continue (a quirk of mine when it comes to forked projects, sorry). Also note that, while I will be open to suggestions for features, I will primarily be working on the "to-do" queue laid out toward getting to my first stable release. People should not be bummed out by this statement. The major items on the list are outstanding IMO. More on these when I get the time to provide proof of concept/existence (i.e. vids etc.)

I want people to know that I did not want to take away from the push for the final MT build, I certainly wanted to springboard off what everyone considers as official and stable. But as I've mentioned above, my schedule necessitated this announcement seeing that the release of b89+ will not be in sync with arrival of my offered free time. I would like to commence once I get that opening, and I can only do so under appropriate conditions. Anyway, I hope this comes as positive news for the community, and I would certainly like to hear from you all.

Well then, it's back to work for me More details to follow the next time I come up for air.

[Lee]

[reserved for details]

[Jagged]

I don't think anyone should see a code fork as anything other than the sign of an active community. So I would see this as good news.

Plus we've plenty of evidence to show that the lack of new builds convinces newcomers that Maptool is dead, so given that there will have to be a significant delay between a final "official" version of 1.3 and the first new 1.4 version, independent development should be encouraged, if for no other reason than to keep the fires stoked.

The question of funding is harder to answer. I have no idea whether or not a particular approach would be successful or not or what effect it might have on the "core." I wouldn't be against an attempt. I only wish I had the time to add to the coding effort.

[Vhex]

I like MapTool a lot and I think that a full time development effort would be worth paying for. I mean, worst case scenario, you start a Kickstarter and don't reach funding and then you know there's not enough in it.

I didn't fund Roll20, but that's because it was closed source and I didn't have an interest in that. I'd have happily funded a Roll20 open source.

[Rumble]

I have to reserve judgment on it until I know what the refinements are, but I would expect a pretty significant revamp of the product, if we're talking about full-time development on it.

For the latter context, alone, I'm confident I can drive success to something akin to Roll20's; with the help of the community and beyond, it may even become greater.

That's fairly ambitious (Roll20's been riding the gravy train on biscuit wheels since day 1), but just having a successful Kickstarter would be a good way to maybe reawaken some awareness of MapTool.

[Full Bleed]

First, I'll admit that when Lee came on the scene here and started contributing I had high hopes that he would end up being a pretty significant player. A lot of the core guys that took the reigns after Trevor faded have, in turn, faded from development. The project has, as a result, visibly ground to near halt.

That said, we've had a number of other capable developers enter the fray in all that time, shine brightly for a few months and then poof. Enough that my enormous amount of respect for the guys that have been around, contributing through the long haul, has only grown... even if they aren't finding much time to drive the project any more.

My personal caveats on Lee's proposal are this:

1) For all I've seen of Lee on the forums, I really don't know what he's really capable of. How good he is, how responsive he will be to the needs/interest of the community, how committed he is to the project, etc. This isn't a knock on Lee at all. The fact that much of his work hasn't made it into production may (probably) have nothing to do with him at all. And I've feared that the lack of responsiveness to his contributions would be likely to drive him away... leaving the community with a missed opportunity to embrace someone who is showing the same kind of fire the second wave of developers showed when they first took the reigns from Trevor. But it is an honest observation that the MT community hasn't been actively using a build of MT where Lee's contributions have played a role. There just isn't a track record of his development contributions to lean on. Truth is, if AZ or Craig (or even Trevor!) was making the same offer I'd support it without hesitation. But Lee, for all the spark I've seen lately, is a bit of an unknown quantity to me. [Granted, I don't spend as much time on the forums as I once did, so this is probably a slightly more that casual observation.]

2) So for me to really get behind this effort I think I'd like to see some/most of the core developers ENDORSE it. Craig, AZ, jfrazierjr... heck, maybe Phergus and Jay as well for that matter. Seeing support from lead community contributors like CiF, Aliasmask, Wolph, Rumble, etc... would also be nice. [If I left anyone's name out, and I'm sure I did, my apologies.]

3) The beauty of Maptool has really been built on the selfless contributions that people have made. There was a "Feature Wall" experiment that lit up brightly near the end of Trevor's reign where contributions helped set a pecking order of development/features. But, in the end, I don't think it really contributed to the long-term health of the project. There was an initial spark of enthusiasm... but, like the say, the candle that burns twice as bright burns half as long. Granted, the candle around here has been pretty dim lately... so maybe some ignition, no matter how short-lived, would still be a good thing.


So, my core fear is this: If a Kickstarter blew up and a large quantity of funds went to a relatively new MT developer for a fork, how would that affect the LONG TERM development of the program and all the guys that have been here for so long? I could make some predictions, but I don't want to muddy the water too much at this point.

I'd almost rather see a group kickstarter with Craig, AZ, and (maybe) Lee on it (or whatever core committee of developers the primaries thought should be in place.) It should include transparency for what would need to be raised to put Lee (or another if they deemed) developer on the project Full Time for a specific trial period of time (i.e. 3-6 months.) And if/when funds exceeded that mark, the overage could go into a RESERVE fund that would take 2 of 3 of the trustees to allocate for future development (i.e. contract to keep the lead on)... hopefully, with continued input from the very community that help raise the funds. Contributors should kind of feel like shareholders.

I like the idea of a capable, motivated, developer leveraging crowd funding to go full-time on MT... but as a project that has been community driven for so long, and so successfully, I'd like to see the community, and it's core constituents, play a bigger role in keeping that spirit alive or taking a step into the wilds of crowd funding. Otherwise, it could get very ugly and dysfunctional as a pseudo capitalistic endeavor without some consensus.

[JamzTheMan]

I pretty much agree with Full Bleed. I always thought if we could get a full time (more or less) developer paid via KickStarter, it would be the kick in the pants this project needs.

However, I would still want it to be open source and would require a list of enhancements that would be accomplished for said project.

What I would donate would be in proportion to what we would get. I'd only donate a few bucks for bug fixes, etc, and somewhere in the 50$ range for complete retooling/enhancements (VBL density, new UI/android compatiblity, etc).

And I would also feel a LOT better if it was an official kickstarter by the core "team" where it was 2-4 members driving the development process. ie Az/Craig would "contract" said developer (Lee) and/or additional developers and if it didn't work out, have the ability to contract someone else. (Although I have no reason to doubt Lee's ability and has done some great work so far, but we all know 'life' gets in the way, and if there was only 1 developer and he/she got into a car accident, poof goes the money/effort)

Bottom line, yes, I would give $$ towards development efforts. How much is directly tied to list of enhancements and timeline and team members.

[Lee]

Man. I hate it when the forum times out on you after hitting submit on a detailed reply, asking you to log in, but not returning to the originating page, or worse, not having something to salvage to when hitting "back" on the browser. While I usually copy to the clipboard prior to submitting, one cannot always be perfect. Sigh.

Anyway, I did my best on that lost post to answer the concerns addressed here. Understandably, it'll be briefer this time around, and I can't guarantee if my responses would be as courteous or tactful.

I must stress the fact that this is a non-profit effort, and that whether that happens or not, will only mean the fork I'm developing comes sooner rather than much later. (sheesh, I'm really regretting losing the other post.).

The donate-ware route, more often than not, takes a longer time to get to critical mass, though it focuses on sustaining the developer while he/she gets the job done; whereas the project funding approach gets to critical mass a lot quicker. It also takes prepares for contingencies such as needing a bigger team (something donate-ware can never fund for full-time development over the long term) etc etc. Personally, the latter is a better motivator as well, at least from my point of view.

Again, the end result would be open sourced and returned to the fold for the RPTools team to pick the meat out of. I only stated my preference for not having my code reviewed during development as one has but to look at the official MT code in order to see a range of disparate styles, mine included; I find it that if coding standards are to be discussed, it should always be laid out at official project start, evolving during development, but not for mature projects like official MT.

In any case, this preference allows me to develop quicker and end users will eventually be able to critique and improve on my code once I am through with the project.

On the question of skill level, while I am not as immersed in knowledge of the MT code as Trevor, Azhrei, Craig, and JFJ are, I consider myself competent, owing to my degrees in Computer Sciences and I.T., not to mention my 20+ years in the industry. I learn quick, and I am tenacious to a fault. All these are moot points, however, as I'd rather have my output speak for itself.

The fact remains that if things are done differently, we can expect different results. Shifting momentum from volunteer-based work to product oriented development is a definite example of this. Figuratively speaking, if I were not myself, and commercializing MT was my goal, I have firm belief that I will modest success, at the very least. Off the top of my head I'd:

• Match key competitor product features and improve the user experience with the tool. This will then put MT ahead as it has features not easily matched as it is.
• Tool an advertising campaign targeting robust communities formed around successful VTTs like Roll20 (and MapTool of course)
• Target RPG review entities with stable release copies, leaving it to them to disseminate the virtues of the enhanced VTT.
• Take a page off Roll20 and create a more accessible asset (e.g. image, frameworks) market. Funnel profit portions to contributors.
• Know what to decentralize. In terms of assets, users should be free to determine their sound and music sources.
• Fund and ready teams to do initial client and framework customization, which can be offered as funding level rewards.
• etc etc.

Honestly, if I were such a person, I would not even bother to ask for community input prior to project start, much less listen to it But, all in all, I'm a competitive person and I appreciate MapTool enough to want to make it competitive to current star, Roll20.

Going to Jamz' input, I already have a team. Like me, they're just working on different projects ATM. Asking for a team to do this project would scale up the offer's requirements, and certainly cannot be funded on a donate-ware stream, which means this project is committed to the project funding route. Does the community want this? Let me know.

I didn't want to divulge the project path until I can post proofs of working concept. But since IDK when I'll be able to sit down and do that, here're the top 10 on a very long list, all of which I've worked on my own to make:

• Headless mode - 100% complete. More details when proof of working concept is finished.
• Cross-client sound (+music) management - 85% done.
• Internal macro script editor w/ syntax highlighting etc - in terms of basic functionality, it's 90% complete. But I've pushed on tooling toward parametric + contextual auto completion, which makes it about 50% complete if taken into consideration
• On a related note, a macro execution debugger - 10% complete. The basic PoC works, but I haven't gotten around to writing a variable watch. No plans as of yet for expression evaluation, but we'll see.
• UI makeover - At first, I weighed trying to divorce MT from the docking manager, but opted to keep it in favor of an earlier future release. Still Swing, of course. In general, I made the UI more intuitive and easier to use. I also strove toward providing a seamless feeling. I leave it to the end-user to decide if I'm going the right direction with it. 85% complete.
• Table management and alternate table structure - MT tables can now be managed through macros. 100% complete. I also put in a 2nd table type for generic use, e.g. data structure display, data storage, etc. 25% done.
• Integrating a faster geometry library - I have 2 candidates, but no integration as of yet. With all the area computations MT does, I'm hoping for performance increases. 0% atm.
• New macro functions - these either provide access to MT internal functionality previously hidden from the user, or extends the capabilities of MTScript. Examples are: impersonation, table management macros, sound management macros, view toggles etc etc. 100% but more to be added.
• Divorcing Individual FoW from the Token - It's still under conceptualization, but I believe it'll work and performance increases will be accrued. More on this when I actually get around to writing for it. 0% atm.
• User wizards, initial setup assistance, and in-app help in general - a must-do that I'll probably leave for last. About 20% complete.

I don't know if anyone will agree with me but, IMO, this body of work borders on the massive. I assure that I didn't pull that list above out of my nether regions, video proofs will get done eventually. In any case, I leave it to the community on whether it thinks these deserve funding toward completion, or not. Do let me know so I can plan accordingly

Thanks for reading.

[wolph42]

I've been following this thread from post one and decided to give my input after your last post. My issue is a huge conflict of interest. The thing is, and I'm talking from a highly subjective point of view here, that initially I thought that branching was not a good idea as it means twice the effort for the 'same' product, it at least *sounds* counterproductive.

However, the trunk development will include a complete redo of the macro language, that is: a switch to jscript. For the long haul I *think* its for the best, for me personally however it means goodbye. I've invested a massive amount of time in developing both my framework(s), the bag of tricks and numerous wiki articles and I won't be redoing that, so i will stick to whatever the last version of 1.3 it gets to and maybe in the future when I start playing a different game maybe switch to 1.4+. Hence having someone or even a team willing to spend time on a fork that keeps the current macro language as is and improve whats there makes me very happy. I also think however that I'm quite unique in that regard. New framework are created each month(?) so a switch of language should not bother most and the ones that created the *old* frameworks are either not or very little active here anymore so it won't bother them as well. Given this: you have my blessing.

There are of course other matters that play a role and that is that I agree with most (if not all) what is said on this topic before me: I'd rather see the core team managing the funds and contracting others to work on the tool. When that happens however I'm pretty sure that no effort will put in a branch but that all focus is put in the trunk and this will be against my personal and quite unique wishes... sigh...

Still, I think you will have my (financial) support when you start working on a branch on the condition that any personal risk is mitigated. With that I mean that there has to be a non-human legal entity (foundation? no clue how that works in the US) that manages the funds so that should anything happen to one member, the whole thing does not collapse. But again I would only do this because of my own quite selfish needs... Would the core team decide to do this, they'll likely also have my (financial) support but only because MT has given me much the last few years and even though they'll be going in a direction away from me, I still would like to say 'Thank you' in a more tangible way.

[Rumble]

I've been thinking about this at more length, and in light of what wolph was talking about, I'm beginning to lean toward the idea that the effort put into this fork would be better spent doing active development on the 1.4 version -- that is, I don't object to the idea of looking for funding (via crowdsourcing, donation, whatever) but I think that money should be put toward active development on the next official version, rather than a fork of 1.3.

The basic reason for this is that I'm of the opinion that 1.3 has run its course; it's old product at this point and it seems like the major focus of your work has been in areas that are also under consideration for the official next version. I'd rather fund a project to pay for people -- including you -- to commit serious time to MapTool 2.0* than incremental revving on the current version.



* It occurs to me that what you're doing, Lee, seems better labeled Version 1.4 than the primary "new version" efforts -- those should be MapTool 2.

[Vhex]

I've seen so many projects fizzle out trying to reach a golden ideal that I'm actually on the other end of the spectrum. Yeah, there's a lot wonky, but I'm fine with fixing and upgrading the current version. It does work, after all.

That said, a timeline is the important part of what I'd be interested in putting money on. If the devs want to get together and do a funding drive to get 1.4 in a few months rather than a few years, I'm on board. Else, I like the idea of funding a current development fork to get new stuff.

[JamzTheMan]

That's a pretty good list Lee! I'm also torn with the whole 1.4/fork/2.0 thing. On one side, I'd rather all efforts go to a 1/4/2.0, but on the other side, it's been talked about for so long that it feels like vaporware.

So, if given a choice between donating some $$ to get "something" new this year or continue talking about about 1.4 I'll pony up some $$. Now, if 1.4 starts to make some serious headway and it conflicts with the fork, so be it, I can make my choice THEN on which version to host my game on.

Now given that, I prefer the "kickstarter" model where we can see what you realistically need and it's all or nothing. I'd rather donate 50$ towards 100k goal knowing that "hey, if this guy gets a 100k, it's going to get done" and not "well, here's 20$. What? Only 2 guys gave you 20$? so you can't do it eh? bummer, can I have my 20$ back?" OK, I wouldn't ask for my 20$ back but I would donate more.

Not sure if you would have any donation levels, but you could have tiers, where 5k min you get what's done plus... for 10k I will do xyz, for 2 million you get MT 2.0 that creates full campaigns for you and a GM to run your game!

[Full Bleed]

In response to supporting 1.4/2.0 over a fork, I will say this: A fork of 1.3 is inevitable.

So, for me, the real question isn't "if", but "who, when, and how" a 1.3 fork proceeds.

Moreover, Craig/Az/currentTeam() are not making the offer Lee is. They haven't said, "With X money we can do Y on schedule Z." And while those X, Y ,Z variables are still mostly missing from Lee's offer (though we have a little Y in the last post)... it does seem like that's where his proposal is going.

We have to be honest about MT 2.0. If the last year is any indication, we all should have pretty low expectations about when we might see a useable version of 2.0. Lee's offer, on the other hand, is on the table now.

To continue Wolph's sentiments... 2.0 *is* extremely divergent. And for the reasons he mentioned (which are practical, not selfish), there will be many of us that won't be willing to make the leap anytime soon due to our investment in 1.3 and the lack of an upgrade path. 2.0 will need to have a "super-feature" to lure the grognards away. And super features seem pretty low on the priority list from what I've seen... with most development seeming to focus on data structures and building something that will be easier to program and build on in the future. Under-the-hood stuff that's probably super sexy to the developers but won't be as shiny for the users for quite some time.

Lee, on the other hand, is talking about very tangible additions to 1.3.Refined. And he's talking about a tangible timeline.

What I need to see more of is what the financial goals are and what will be done with "overage" once those goals are reached. I'm still concerned that the selfless sweat equity of Maptool's current core team and framework builders could very well be the primary reason that a forked MT Kickstarter could exceed expectations. We don't know what the pent-up support for MT might be, and I'm not sure that Lee alone should reap the "reward" (and cash to work on MT full-time would be seen as a reward.) Further, the proper endorsement from the core team, with some of the controls I mentioned above, would give any potential Kickstarter MUCH larger wings. Without it, the community response will be diluted and confused and we're likely to see something pretty unspectacular come of it all.

If the Kickstarter can be promoted more as a support of MT as a whole (with the initial focus being the refinement of 1.3 with a full-time lead developer, since that's the real onus for the kickstarter in the first place, while development of 2.0 and future relevance continues at it's normal pace) we might be able to avoid unnecessary fragmentation (at least on this initial fund raiser.) The work that goes into 1.3.Refined could be mined for 2.0. And, even more important, the whole exercise could turn out to be a Proof-of-Concept in driving bursts of MT productivity and features for years to come.

While MT users could turn out to be the cheapest bastards on the block, they might also turn out at levels much higher than anyone is considering for the scope of this proposal.


If the work on a 1.3 fork is really going to pass the altruistic smell test though I really think we need transparency and scope. A "3-6 month Full Time Developer" contract should be the focus... or something like a 50/50 split of funds to the two parties: 1) Lead Developer of the fork and 2) a Reserve for MT's future development. I firmly believe that completely decoupling the two with the fundraiser would be a mistake. And if this initial seed bears fruit, then the core team and fork developer will be able to go back to that well to move forward in a manner that best suits the project or make a clean break.

[Dracones]

I think someone forking 1.3 and running with it would be a good thing. It's not uncommon to see old code branches sustained while new ones are getting the kinks worked out. Python 3 has been out forever and most people are still using Python 2.7 with a slow migration happening as the libraries they need finally become 3 compatible.

But a problem with any Kickstarter is you want to avoid any butthurt in the community(innocent meaning stuff can blow up on you) and you wouldn't want to kill any steam/plans that might be in the works for a 1.4/2.0 Kickstarter. It'll also help if you come in with a solid reputation as someone who's done work on the project.

That said, I've kicked in for Roll20 and Tabletopforge kickstarts and I'd gladly kick in for a Maptool one.

[Lee]

Thank you once again for all the constructive input. I'm sorry to have left the subject hanging on my end, but I assure you all that I had a detailed response to the most points brought up since last, but opted to weigh in more upon this response to be sure it had been given enough thought. In light of the release of b89, and perhaps soon-to-follow b90 (final?), I also did not want to distract the community efforts to test it out, and its enthusiasm for this long awaited development, in general. So, for now, I'll make the responses brief.

@Rumble: The thing there is active development under the current environment is volunteer-based. While it has done tremendous work over the years, it has taken years to get to this point. I have no doubt the key members of the official development team have more lucrative means of personal financing and would prefer things remain as they are (i.e. not answering to a funding crowd) because this passion is a hobby, and not work. For the sake of argument, yes, with funding, a new VTT could very well be built from scratch, but this then deviates from the goal of keeping the community intact and returning newly developed stuff back into the fold; not to mention fragmenting from the next-generation goals for MT.

I was thinking of the project to be in lieu of the actual need for official 1.4/ 2.0 (let's call it 1.4) to showcase some features that have long been in demand, "protecting" the official devs while they lay the groundwork/fundamentals for 1.4. True, this does set expectations, but most of these are de- facto standards in newer VTTs these days. Again, several key features in the fork can certainly find a home in 1.4, depending on its planned architecture, of course, as well as their compatibility with 1.4 internals.

For example, the macro editor. Currently, it not only supports HTML, CSS, and MapToolScript, but also JavaScript, which is the planned scripting language for 1.4. While it currently outputs to Swing, it shouldn't be a problem to make it work with whatever JavaFX component 1.4 employs in the future. Another is the sound manager, something which I believe can be taken out of the fork and put into 1.4; depending (again), of course, on the planned architecture. But even if they weren't to make it in (1.4), that users get a tangible experience through 1.3 can motivate development priorities, is, something worth pursuing, IMO.

@Jamz, FullBleed: Yes, the idea is to have tiered developmental offering, as opposed to a long list of pledge rewards, since what is really being offered here is tool enhancement. Off the top of my head, while framework assistance/creation and MT client customization might be attractive offerings, I also want to pitch the idea of putting that out to the community and letting interested parties reap the rewards of that instead, sort of that more accessible asset/framework market I mentioned above (at least I think I did). If I had more time in the past, I'd write a lot more system agnostic scripts to support an endeavor such as this, as opposed to earmarking it as plausible reward offerings. If the community wants to be leveraged and rewarded, then the topic is always on the table.

@wolph, Full Bleed: I have no objections to whatever fair (financial) controls may be put in place, though I won't be volunteering to do the legwork for that as I'd rather be developing my projects. If none are to be found, you all will just have to trust me .

Regardless of whatever path this takes and the scale of its implementation, the initial idea (and the current one I'm offering) is simply to support me in finishing and furnishing work I've started. But, as I've mentioned before, I do not doubt that the project is capable of gaining a lot of momentum, especially when it is assured that a good portion of the proceeds (financial, or otherwise), is intended to assist RPTools next-gen efforts, and drive community (and product?) growth. I do have to mention, however, that such things, what seem to be gifts to most, may be a burden to the official team, and the RPTools spirit, in general, since volunteering is the norm, and the spirit is of free and open software. Should the results be unwanted, such a context will necessitate an external entity to drive the initiative forward, while keeping the community intact. Hard, I know, but not impossible.

Anyway, let's enjoy the excitement of b89 and the anticipation of b90. With what little time I have right now, I'll plod along to get the fork to a readier state. The goal is to reach the stage of near-completion, so important details like a clear timeline, and what can be provided as incentives to invest, can be made clear to all.

Do keep your thoughts coming in as I do appreciate hearing them and the efforts it took to write them down