Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[JimH]

I'm starting this topic to describe how JRiver does development and sells its product.  I may move this to the wiki.

Before the Internet gained dominance, most software companies had very methodical development cycles.  They would get the team together, set a list of features, consider customer requests, and after refining the list, they would begin development.  Things were a little more leisurely then, so development might take a year or more.  Then beta copies would be released to a few customers.  After several cycles of fixes and releases, a "release candidate" would be issued.  Any small remaining problems might be fixed before calling it good to go, and then the product would be launched.

Microsoft still uses a process a lot like this.  It is a little more interactive, but it is still a pretty rigid process.

Google and JRiver use a different process.  It is more iterative, meaning that many more releases are made and often the changes from one release to the next are small.  There is no real beta and no real release.  There is only a series of gradually improving releases.

A couple of things affect this though.

1.  Adding new features almost always creates new bugs, sometimes a lot of bugs.  This means that, if the software is changing a lot, it will also be buggier.  In order to polish the software, to put out releases that generally work for most customers, the changes must be reduced or eliminated.  It often takes a month or two after we stop making changes for the software to become generally trouble free.

2.  The market changes all the time.  Netflix and Hulu are good examples.  If they make a change it may affect our work, and we may have to scramble.  New OS releases do the same.  New devices also.  The market doesn't stand still.

3.  #2 causes us to revisit #1.  Market changes mean new or revised features in our software.

If you think about that, you can probably see why we're constantly at risk of sliding down the slippery feature slope into instability.  You want it.  We add it.  Something breaks.  We fix it.  And so on.

So that's the environment we operate in.  Here's what we do.

About once a year, we release a new major version and we charge for upgrades from older versions, but we try to make the price very attractive, especially in the early stages.

About three or four times a week, we release a new build for beta testing.  A few times each month, we move it to the forum, and it's free if you've paid for that major version.

We do this by cleverly using a very strong beta group and an equally useful group of early adopters, who always want the latest, even if it has a few problems.

We have:
1.  BETA -- A beta group of about 100 users, who get builds on a private board.  They find many of the problems and we fix them.  When we think it's safe, we move a build to:

2.  LATEST -- The MC board where perhaps 1500 people get it and sometimes find a few more problems.  What they find gets fixed.  When the build doesn't have many problems after a few days, we move it to:

3.  STABLE -- This should always be the safest choice, the most reliable software we have.

[JimH]

During the year, we move through several phases.

Early in the process, we pile on features we've been planning, things users suggest, and responses to market changes.  This makes the software less stable, but it changes more quickly.

In the middle of the year, we start to make fewer changes.  We still make enhancements, but they are often smaller, and sometimes they are in response to other changes we've made.  Doing one thing can make it obvious that something else needs to be done.

In the final months, we try to stop adding and changing, and just concentrate on polish and bug fixes.

The hardest time of the year is the time when we've pretty much finished one major version, and only begun the next.  There are lots of possible problems with the changeover, but we've learned to minimize them.

Customers are sometimes confused by this, but it is pretty simple.  At any time of year, you can choose your comfort level of stability vs features.  

If you need stability above all else, you just subscribe to the Stable build.  You don't buy the next version until you're pretty sure it's wrung out and ready.  We usually do a newsletter to announce the Stable releases.

If you want features above all else, you use Latest.  You put up with a few problems.  You learn how to reinstall an older build once in a while, when something you need is broken.

I'll edit this in the next couple of days.  Suggestions are welcome.

Links:
http://wiki.jriver.com/index.php/Updates

[MrC]

Not so un-serious suggestion...

How about using labels that reflect your non-old school approach.  Ex:

Beta --> Vanguard
Latest --> Bleeding Edge
Stable --> Stable

The term Beta is always going to get you in trouble.  Your methods are more closely aligned with an agile or extreme rapid development model where old terminology has no meaning.  Why not embrace this?

[astromo]

Not so un-serious suggestion...

How about using labels that reflect your non-old school approach.  Ex:

Beta --> Vanguard
Latest --> Bleeding Edge
Stable --> Stable

The term Beta is always going to get you in trouble.  You methods are more closely aligned with an agile or extreme rapid development model where old terminology has no meaning.  Why not embrace this?

Agree with MrC, immerse yourself in the paradigm difference and use some different terminology. "Vanguard" sounds a lot cooler than "Beta". All you need are matching trumpets when you use the word and that would be perfect. "Latest" and "Stable" are fine by me.

This is a good thread and deserves to be elevated to explain how you guys do your thing in an "About Us" kind of way. Thanks for the read, I got some real value out of it.

[Charles Hansen]

As a hardware manufacturer, the only thing that I would like to point out is that the development team at JRiver is stupidly fast!!

As in, I make a request and less than 24 hours later I have a fix in my hands and I am left in a stupor, scratching my head asking myself, "How the heck did they do that so quickly?"

My mind has been boggled on many more than one occasion.....

Charles Hansen
Ayre Acoustics, Inc.

[javidan]

As a hardware manufacturer, the only thing that I would like to point out is that the development team at JRiver is stupidly fast!!

As in, I make a request and less than 24 hours later I have a fix in my hands and I am left in a stupor, scratching my head asking myself, "How the heck did they do that so quickly?"

My mind has been boggled on many more than one occasion.....

Charles Hansen
Ayre Acoustics, Inc.

Actually, having worked in the software industry before, I am equally surprised at just how amazing JRiver keeps improving.
There are plenty of examples where I had files in the past which could only be played by software from an open fan community that JRiver has "caught up" simply with time.

Since this is a topic on the business model, JRiver remains one of the *very very* few software companies (There are a couple of others out there, and they appear to be independent software companies which haven't grown too bloated.) where I find myself a happy and willing customer paying for upgrades with each new release. If we were to look at just how many companies have been corrupted with "We will release a new software version with minimum/no upgrades or even remove some features (e.g. A particular OS which hit version 8 ) and force our users to pay for it", the numbers are quite scary.

Thanks guys and keep improving!

[larryrup]

Jim:  Good insight.  Below are two blog posts from the CTO and desktop software guru at the firm I work for.  He's been pretty special since he's been here. (It's a  big ass organization). I couldn't find a public link to it, so I've removed his name in case privacy could be an issue, but the story is worth reading.  I was going to edit for brevity, but thought that not right:

 I recently came across a story that seems to have originally been reported in the book Art & Fear but has since been widely cited in a variety of other books and blogs.  The story goes like this (my paraphrase):A pottery teacher divides his introductory pottery class into two groups.  He tells the first group that for their final grade, they will need to make just one pot and it will be graded on how perfect it is, ie on quality.  The second group he tells that he will grade them simply on the quantity of pots they make over the semester.  The first group spends the course really planning out their perfect pots, thinking of how they will make something truly spectacular.  The second group immediately starts cranking out pot after pot after pot.  At the end of the term, the teacher in fact judges the quality of all the pots and demonstrates that the "quantity" group in fact had made better pots at the end of the term than the "quality" group.  Of course the "quantity" students had spent the entire term practicing. By the end, their craftsmanship and inventiveness had really developed.  The "quality" group on the other hand had spent all their time thinking about their great pots, but when it came time to make them, they were not that great -- after all, those were the first pots they had made...


"In a conversation with a colleague last week, I realized that there may be some misconception of what Agile development is.  It is not about flying headlong forward in order to be faster.  In fact it is fundamentally about removing risk from your projects.  That's it.  That's what it's about. Period. But that focus has far-flung ramifications.
 
Agile helps you remove risk by forcing you to break the project up into manageable minimum pieces that you deliver completely before moving on to the next manageable minimum piece that builds on what you have already delivered.  So you "release early and release often".  By fully delivering these little chunks, you gain tremendous confidence that the project is on track and you are building on a solid foundation.  It also gives you the chance to try out what you have built so far, stand back and make sure you like the direction, and - even more valuable - you can do that exercise with actual customers, ensuring the direction you are heading in meets their needs.  If any little batch goes off course, or requirements change along the way, you catch that early and there is not a huge investment to course correct.  That's the "agile" part.
 
Because you are delivering early and often, you will likely have some pieces you can start to engage your customers with, giving them a comforting feeling of tangible progress.  And because you are building such confidence in the direction and quality of your product along the way, you greatly reduce the chances that you will have gotten something massively wrong and have to back up and start again.  Remember that if you spend huge amounts of time planning upfront, and then toil for many months to produce your masterpiece, it will be the first pot you have made, and you face grave risks that it will not be very good.
 
So, by focusing on reducing risk through the application of 'small batch' philosophy, you do actually dramatically increase the speed with which you deliver a complete product to customers.


 
'

[MrC]

Funny how we pay CEO's millions to deliver time-tested, sage advice: Practice Makes Perfect.

Check please.

[imcardle]

Thanks, this has been a very interesting read.  However, the information is 3 years old now and that, in software terms, is a lifetime!  I would be interested to read about what you've changed (or improved) in your development process during these 3 years?

For me, some transparency regarding forthcoming features would help me to decide if I want to pre-order the next major version.  I don't expect a fixed list because, as you've explained above, you need to be flexible when there are changes in the market - but a few hints about the items that are top of your "backlog" would be helpful, IMHO.

I've seen other companies operate a kind of voting system where the users can voice their opinions about which features are the "most wanted".  Have you also considered such a system?

Edit:  OK, I found the list of proposed features for MC22:

http://yabb.jriver.com/interact/index.php?topic=104805.0