Hi everyone,
Thanks Indigo for bringing this thread to my attention (as it might have taken me a long time to spot it myself) and for clarifying some things about Spriter.
There's a few matter's I'd like to further clarify which I hope will be useful to anyone interested. (DISCLAIMER: I'm the founding member of BrashMonkey and co-creator of Spriter, so HUGE pro-Spriter bias is a definite possibility.

)
Image deforming/warping: While image deforming was introduced as an experimental/proof of concept feature several builds back, it's not yet finished. The UI and even data format are going to change drastically, so in it's current state, its only useful to play with and provide us with feedback and feature additions/requests. It's a feature we're very excited about, but must take our time to arrive at the most intuitive and flexible UI and data format possible. Luckily The initial release of Spriter 1.0 is almost ready, and finishing this deform feature will be a very high priority after that point.
Are Spriter and Spine redundant products?: Even if the two tools completely overlapped in features (which they do not), the drastically different work-flow and UI alone can make each tool more or less appealing to any particular user depending on their own preferences. On top of this, the large differences in price-point also separate Spriter and Spine into two different sub-markets. Spriter Pro is substantially less expensive, and the free version of Spriter is not crippleware, in that all core features are fully functional and there is no legal/licensing limitations on any original work you create using the free version. Luckily, on top of all this, there are several distinct feature differences which definitely can make one tool more appropriate than the other depending on the specific technical and artistic requirements for a specific project.
This video explains the overall feature-set of Spriter, and how it offers great flexibility to work-flow animation technique and animation style:
One of the most important differences (in my opinion) is that Spriter offers a pixel-art friendly mode, which not only uses nearest neighbor scaling (no filtering), but also forces sprite coordinates to integer (whole pixel) coordinates as opposed to "floats"(partial pixel coordinates).
Even for those precreating all animations as full frame sequential images in their 3d or 2d tool of choice, Spriter can offer many benefits, All individual frames can be instantly loaded in as animations, where per-frame durations can be set, along with triggering sound effects at any point in the time-line (even between frames), as well as placing and setting limitless collision boxes, variables and spawning/anchoring points at any point in the time line...all tweened or not, according to your needs.
Modular animation VS pixel art?: I use Spriter frequently as fast and efficient intermediate part of my process to create low-res, indexed color per frame sprite animations. The benefits to this method are numerous, especially in the profession, where deadlines and compensation vs time spent ratio are critical factors.
Here's a video showing my general process and examples. Please note this video was recorded before pixel art mode and export to sprite-sheet or .gif was added to Spriter Pro:
Another important note, Spriter can be used to create high-res, tweened modular animation, or actual per frame pixel art animation sprite sheets or gifs, or to actually create a hybrid of the two, where pixel art is animated on the fly (tweened or not) in a manner that perfectly preserves every last pixel of the original art. This last option is perfect for creating retro style games, especially modular pixel art bosses such as those seen in classic games by Treasure, but also to recreate methods similar to those used to animate countless classic video game characters (Rayman, Vectorman, Alien Soldier etc).
Spriter's late. (very late): It's hard to discuss or explain such situations without coming across as defensive or making excuses, and most importantly, words mean very little compared to actions and the results of those actions...so ultimately our goal is to not excuse our lateness with words, but to actually make the wait worthwhile, and provide the most useful, fun to use, and best supported tool we possibly can, as soon as possible, and with focus on the long term.
For those interested in the actual facts behind the massive delay in releasing version 1.0, the best way is to surf through the official Kickstarter updates on our Kickstarter page, but long story short, The very long hours and very infrequent breaks Edgar (Spriter's programmer) endured while developing Spriter prior to and during the Kickstarter campaign exacerbated shoulder and back injuries from a past automobile accident...suddenly forcing lots of visits to medical specialists, unpleasant and risky injections, and basically a distressingly prolonged amount of time away from any keyboard...causing a massive initial delay, followed by many months of drastically reduced production speed until physical therapy and carefully controlled work environment and work habits finally allowed Edgar to get back to full speed development.
But again, we don't care about the reasons or excuses, our goal was and is to firstly make modular animation methods available to (and common knowledge to) all game developers, no matter how new to the art form or how small their budget, and then secondly, to make Spriter a highly useful and affordable tool towards those ends. Despite technically still not having released Spriter version 1.0, It is important to keep in mind that the expectations and standards for what Spriter 1.0 would need to be drastically expanded during the entire process of it's development (which obviously also further delayed the release of 1.0), and even the beta version of Spriter for the last several months actually surpasses the originally promised feature set and accessibility (cross platform, for PC, mac and Linux) by a very large degree.
I do cringe to discuss this topic, because firstly of course we do feel terrible about the delay but also because, as I mentioned, I find excuse-making and being defensive to be very distasteful and hope I am not coming across that way.
I just wanted to make it clear that we are very committed to Spriter, and always have (except when medically forbidden) worked very hard and long hours to make Spriter a better tool, and to support its users in as timely and courteously a manner possible. Any day not directly contributing to Spriter's development is spent helping users (of Pro or free), fixing bugs, responding to forum posts and emails, and discussing (often with our users), how we can make Spriter a more useful tool for everyone...not just to paying customers.
Sorry this ended up so long, but before I stop typing, in a final effort to counter-balance the obvious bias I might have in the favor of Spriter, let me just add the following: It was during that really tough time of the injury induced delay that Spine was introduced...and despite the obvious and detrimental financial ramifications of suddenly having a very polished and much more complete competitor, Edgar and I were relieved that anyone who needed to create modular animations at that moment wold not have to endure the delay in Spriter without having a very viable alternative. For those who need to do something now, and not "some day down the line", a polished and immediately useable (and supported) tool is drastically more useful and attractive than an unfinished and not yet supported tool. Luckily this is finally beginning to change. There's very few features left to be added to this first release of Spriter Pro, and the list of known bugs is very short and Edgar is going through them at a fantastic speed. Once Spriter 1.0 is released, we'll be switching gears to perfecting the image deforming features, fully documenting the data format, and working with the developers and communities of all popular game authoring systems in order to get complete Spriter support implemented as quickly as possible. Things are already shaping up nicely for Unity and Construct2 in that regard, with several other authoring systems Spriter support making excellent progress as well.
That's all for now, but I'll be sure to check back in on this thread from time to time to respond to any questions or requests, and to keep you all updated on Spriter's development and impending 1.0 release.
cheers,
Mike