Some insights into our development process
As many of you have noticed, the process for getting Imprudence 1.4 beta 1 out has been a long one, so I wanted to take some time tonight to explain our process as developers behind it–what we intended to do, how we got there, and where we go from here.
Imprudence is something of a unique project for me in that we’re all volunteers scratching our itches, yet somehow despite this we’re able to come together and make things work. I know this sounds horribly cheesy and cliche, but I really have never worked with a more heartfelt and kind-hearted group of people. What makes an ImpDev unique, I think, is that we’d have just as much fun sitting around chatting for hours as we do hacking on the viewer source. We care a lot about what we do, and ironically that’s partly why the 1.4 process has been so frustrating for us.
After the release of 1.3, something became clear: our Quality Assurance process was far too long. We would fix an issue, then it would sit on the repo for weeks without being properly tested on all the environments we want to support (OpenSim, Second Life, InWorldz, and now Aurora grids). We changed that up with releasing the Weeklies (later renamed “Experimentals”). The idea was to get fixes as fast as possible into user’s hands in order to get important feedback. A LOT of the major bugs in 1.3 were fixed in this manner, and thanks to residents who were willing to track down bugs with us we really made a lot of progress. The 10.23 Experimental release is a highlight for people, I know, and that’s largely thanks to residents all over the metaverse being involved in the development process (one of my favorite stories is how many of us it took to track down what we called the Infamous Wright Plaza Crash of Doom. Fixing this eventually led to a patch that made all other 1.x viewers more stable).
But we’ve had problems. The QA process started to take on a life of its own, and as we got sucked into releasing quick updates the gap between our Stable and Experimental branches widened. When our doors were flooded with tens of thousands of new users after another viewer was banned on Second Life, we were thrust into a quandry: do we push to include all the new feature requests, or continue to focus on stability and workflow improvement? In the end, the Experimental line got lengthened again by a rush of new features (and fixes for those features), further widening the gap between the two branches. Looking back, that was probably a mistake. We should’ve kept to our core mission of releasing solid incremental viewers without the feature bloat that other viewers have. But, as I said, we’re a group who cares passionately about our users, and it was important to us to address what we felt were significant needs.
This brings me to the subject of beta 1. The release notes for 1.4 are longer than any release we’ve done to date (and if you follow our commits on github, you know how much work we put into the viewer on a regular basis). It’s been something of a culture shock for us, trying to resolve issues while still moving forward. The Imprudence development process is much like that of a UI designer. We make a change we think is useful, then release it to the community, gather feedback, and refine. Over the course of several iterations, you get a release like 1.3.2, which many people still prefer due its stability. With 1.4, though, this process is much harder for us. We’re giving the community a lot to look through, and we’ve received a lot of feedback. In a way, it’s almost intimidating, because 1.4–as the last of the Imprudence line–is very dear to us, and as I mentioned, we’re all personally dedicated to giving you guys the best viewer we can.
So, where we go from here might be a bit of a struggle for some. There’s obviously work left to do, but I want to point out that releasing the beta (i.e. moving Experimental features into the stable line) has pushed us to focus back on core issues. Based on early feedback, the inworld audio issues on Windows seem to be fixed. Inventory loading’s been vastly improved. More crash fixes have been pushed. The texture cache will hopefully be improved next if time allows before beta 2. Likewise, we’ve also had to balance our need to work on big issues with our desire to make sure everyone who submits a bug report at least gets their voices heard, which is why it’s so important for us that you use the issue tracker and promote it among yourselves. Commenting there brings issues to our attention much faster than commenting in other places. Particularly with this release, there’s so much going on it’s hard for us to give you guys the one-on-one time we’d normally like to. For example, I only recently learned about the “disappearing prim” issue from a forum post and a comment from a friend (currently, it looks setting RunMultipleThreads to FALSE in the debug settings fixes the issue; let us know if this works it for you or not).
Most of all, I want to make a personal appeal to the community to be patient with us as we work on all these issues. We have Imprudence 1.4 to finish up, then a huge merge to do with Kokua followed by the many features/improvements we want to implement there. This is no easy task, believe me. As a user of our software myself, I know how frustrating it can feel to use an unfinished product, but it’s our hope that at the end of a concerted effort 1.4 will be the best version of Imprudence yet–one you all can look back upon as a journey that was worth the destination, and Kokua will grow into the same.
In short, we’re here, focused on getting this done. You guys are still the primary reason we do this, and while we haven’t been interacting with the community much lately, you guys are always on our minds. I hope you’ll keep with us as we continue to fine tune our process. In the meantime, I also encourage you to check out our new support system. I think it’s really nifty, and Codebastard Redrave has done an awesome job at making it easier to get answers from your fellow users. Check it out at http://support.kokuaviewer.org/qa/.
Cheers 
