Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Now we're going to be charged for test submissions, I'm wondering if it's ok to submit a BREW 1.1 SDK app for a BREW 2.0 handset.

I don't want to get charged twice for one app, simply because I have to submit a 1.1 app for the T720, VX4400, etc, and then make a separate 2.0 submission for the VX6000.

Any comments?
Thanks

Can't say I'm a huge fan of this test policy. What a way to kill mounting interest in the platform by not only changing the test fee system, but raising the price. Bravo. The incremental retest thing, while vaguely interesting, is fairly useless and no concession for now having to pay $1000 a pop regardless--even for pre-commercial handsets. I'm definitely going to temper how many handsets I release an app for now--I could end up blowing $10k in test fees just to get my game out on most current BREW phones.

Can't say I'm a huge fan of this test policy. What a way to kill mounting interest in the platform by not only changing the test fee system, but raising the price. Bravo. The incremental retest thing, while vaguely interesting, is fairly useless and no concession for now having to pay $1000 a pop regardless--even for pre-commercial handsets. I'm definitely going to temper how many handsets I release an app for now--I could end up blowing $10k in test fees just to get my game out on most current BREW phones.

This is REALLY bad! What a braniac move...
Clearly this will keep new developer entries out - which is probably the goal so that a few developers with deep pockets dominate the market.
The biggest problem is that now you're getting charged MAJOR bucks whenever a new handset enters the market. That means many develoeprs will not support them once they are launched but may wait until they have a bulk submission to reduce the per-version cost.
All in all it's definitely a big step backwards for all developers once again. Why is it that Qualcomm hardly ever really sides with the developers? After all it's developers who provide the content.
Why is it that we constantly get the short end of the stick then and have to put up with stuff like this, just because it's more convenient for OEMs, carriers, certification companies and who-knows-who-else?

This is REALLY bad! What a braniac move...
Clearly this will keep new developer entries out - which is probably the goal so that a few developers with deep pockets dominate the market.
The biggest problem is that now you're getting charged MAJOR bucks whenever a new handset enters the market. That means many develoeprs will not support them once they are launched but may wait until they have a bulk submission to reduce the per-version cost.
All in all it's definitely a big step backwards for all developers once again. Why is it that Qualcomm hardly ever really sides with the developers? After all it's developers who provide the content.
Why is it that we constantly get the short end of the stick then and have to put up with stuff like this, just because it's more convenient for OEMs, carriers, certification companies and who-knows-who-else?

With 3 free submissions the barrier to entry for new developers isn't that vastly changed. If their first three titles make so little money that they can't afford $1000 for their fourth title, then it's probably best that they don't release any more ;)
The big change that can hurt new people is that this new style effectively causes everyone to submit for all handsets at once instead of submitting for a single handset to work out the bugs before submitting for the rest of the handsets. This puts a much larger testing burden on the developer which can be difficult for new developers. However, the reduced rate for resubmissions helps to offset this to some degree.
The one thing that I want more information on is how newly released handsets are handled. For example, you have a game out on 4 different color handsets and Verizon releases a new handset. If I understand things properly, you then port your game to this new handset and have to spend $1000 to submit it to NSTL. This happens for each existing title, and each new handset. I'm hoping Qualcomm puts something in place to deal with newly released devices at a greatly reduced rate or something.
Tom

With 3 free submissions the barrier to entry for new developers isn't that vastly changed. If their first three titles make so little money that they can't afford $1000 for their fourth title, then it's probably best that they don't release any more ;)
The big change that can hurt new people is that this new style effectively causes everyone to submit for all handsets at once instead of submitting for a single handset to work out the bugs before submitting for the rest of the handsets. This puts a much larger testing burden on the developer which can be difficult for new developers. However, the reduced rate for resubmissions helps to offset this to some degree.
The one thing that I want more information on is how newly released handsets are handled. For example, you have a game out on 4 different color handsets and Verizon releases a new handset. If I understand things properly, you then port your game to this new handset and have to spend $1000 to submit it to NSTL. This happens for each existing title, and each new handset. I'm hoping Qualcomm puts something in place to deal with newly released devices at a greatly reduced rate or something.
Tom

This is a HUGE difference. 3 free tests is nothing compared to one free test for EACH new application for EACH handset. Also, the amount of notice given prior to implementation of this new policy is WAY too short.
Is this what we can expect in the future? 2 weeks to retool our development effort on multiple new projects?
I also think that counting the 3 free tests retroactively is wrong.
It penalizes those of us that have submitted apps before the new policy was announced.
Using the old policy I submitted my app for one handset only
(which passed on the first time BTW), to start, because originally the tests for subsequent handsets were also not charged. Now I have wasted one of my three that could have been used to submit for all handsets.

This is a HUGE difference. 3 free tests is nothing compared to one free test for EACH new application for EACH handset. Also, the amount of notice given prior to implementation of this new policy is WAY too short.
Is this what we can expect in the future? 2 weeks to retool our development effort on multiple new projects?
I also think that counting the 3 free tests retroactively is wrong.
It penalizes those of us that have submitted apps before the new policy was announced.
Using the old policy I submitted my app for one handset only
(which passed on the first time BTW), to start, because originally the tests for subsequent handsets were also not charged. Now I have wasted one of my three that could have been used to submit for all handsets.

Does any one know how the $250 incremental retest fee is applied? If an application is released to testing for a new group of phones, does that count as $1000 or $250?
-Aaron

Does any one know how the $250 incremental retest fee is applied? If an application is released to testing for a new group of phones, does that count as $1000 or $250?
-Aaron

From reading the doc, it seems like that will cost another $1000. The incremental re-test is for stuff like changing a file in the distribution. It's hilarious that they give as an example, changing a splash screen, yet it states you need to pay the full re-test fee if you change the BAR or MOD. Then how are you supposed to change the splash screen?
This new test fee structure is utterly ridiculous. There's not enough revenue coming in for these games to justify spending this kind of money on testing. I really have no idea how they came up with this absurd numbers. I think Motorola's new J2ME certification program is about $200 or so a pop. That's fine, even without a first time free plan.
If I have to resubmit every version because of a bug (and I'd have to do that because they force me to submit all my builds at once now), I can in no way justify spending $1000 a version. While the sales figures for my games have been good...they're not that good. Compound that with having to wait until the end of the year to get my royalty distribution from Qualcomm--it makes BREW a very unattractive platform to develop on all of a sudden.
I'm sure the motivation is now that there are a lot of BREW developer submitting apps, Qualcomm doesn't want to foot the bill for the first test run.
But there's got to be a better way to do this, even if it's just partial subsidization.
After this game, I'll be dramatically reducing the # of handsets I put stuff out on, that's for sure.

From reading the doc, it seems like that will cost another $1000. The incremental re-test is for stuff like changing a file in the distribution. It's hilarious that they give as an example, changing a splash screen, yet it states you need to pay the full re-test fee if you change the BAR or MOD. Then how are you supposed to change the splash screen?
This new test fee structure is utterly ridiculous. There's not enough revenue coming in for these games to justify spending this kind of money on testing. I really have no idea how they came up with this absurd numbers. I think Motorola's new J2ME certification program is about $200 or so a pop. That's fine, even without a first time free plan.
If I have to resubmit every version because of a bug (and I'd have to do that because they force me to submit all my builds at once now), I can in no way justify spending $1000 a version. While the sales figures for my games have been good...they're not that good. Compound that with having to wait until the end of the year to get my royalty distribution from Qualcomm--it makes BREW a very unattractive platform to develop on all of a sudden.
I'm sure the motivation is now that there are a lot of BREW developer submitting apps, Qualcomm doesn't want to foot the bill for the first test run.
But there's got to be a better way to do this, even if it's just partial subsidization.
After this game, I'll be dramatically reducing the # of handsets I put stuff out on, that's for sure.

I appreciate the comments guys. However, I am still wondering if I can submit one app for all the handsets (1.1 and 2.0), or if I am forced to pay for two tests?
The app architecture might require that NSTL replace the MIF and BAR files for each handset, but the MOD would remain the same. Is this possible for a single test submission?
Yes, it is worrisome that we will have to pay every time a new handset comes out if our previously released app doesn't run on it.
I don't mind paying $1000 per app. I just don't want to pay multiple times that amount just because a random handset was released or some other serendipitious event occurs. I am looking for a strategy that will allow me to minimize my cost to $1000 per app.
If we don't get a standard approach that allows us to do so, I would not be surprised to see developers set up a production company for each title, simply to take advantage of the free 3 submissions.

I appreciate the comments guys. However, I am still wondering if I can submit one app for all the handsets (1.1 and 2.0), or if I am forced to pay for two tests?
The app architecture might require that NSTL replace the MIF and BAR files for each handset, but the MOD would remain the same. Is this possible for a single test submission?
Yes, it is worrisome that we will have to pay every time a new handset comes out if our previously released app doesn't run on it.
I don't mind paying $1000 per app. I just don't want to pay multiple times that amount just because a random handset was released or some other serendipitious event occurs. I am looking for a strategy that will allow me to minimize my cost to $1000 per app.
If we don't get a standard approach that allows us to do so, I would not be surprised to see developers set up a production company for each title, simply to take advantage of the free 3 submissions.

I submitted a 1.1 version of Poker Solitaire on the VX6000 and it passed no problem. So I don't see why you can't submit a 1.1 binary on a 2.0 phone.

I submitted a 1.1 version of Poker Solitaire on the VX6000 and it passed no problem. So I don't see why you can't submit a 1.1 binary on a 2.0 phone.

One thing I believe is als worth menitioning, becasue it is VERY painful.
The $250 cost for the incremental re-test is only for apps that have previsouly been certified and are now slightly modified. As Flarb pointed out, that is ludicrous at the very best.
The re-test for an application that fails certification will be ANOTHER $1000. It is nice to give developers an incentive to sail through their certification on the first try but penalizing them like this is truly counterproductive.
I agree with Flarb and I repeat what I said before. I'm not willing to constantly get shortchanged as a developer. There is a huge J2ME market out there in Europe and Asia, which is just as easily accessible to us as the US Brew market, and I for one will put more focus on that. Maybe it's also time to give Symbian a bit of a boost, just to make sure everyone at Qualcomm understands that there is more to the mobile market than only Brew!

One thing I believe is als worth menitioning, becasue it is VERY painful.
The $250 cost for the incremental re-test is only for apps that have previsouly been certified and are now slightly modified. As Flarb pointed out, that is ludicrous at the very best.
The re-test for an application that fails certification will be ANOTHER $1000. It is nice to give developers an incentive to sail through their certification on the first try but penalizing them like this is truly counterproductive.
I agree with Flarb and I repeat what I said before. I'm not willing to constantly get shortchanged as a developer. There is a huge J2ME market out there in Europe and Asia, which is just as easily accessible to us as the US Brew market, and I for one will put more focus on that. Maybe it's also time to give Symbian a bit of a boost, just to make sure everyone at Qualcomm understands that there is more to the mobile market than only Brew!

whoa, whoa, whoa, where are you guys getting this information?
The way I interpret the new pricing (based on that email from Developer Relations) is that each submission that has not been tested yet is $1000 and a retest is $250.
So if I submit a new app for handset a, b, and c it cost $1000 total. If it fails, I can resubmit for handset a, b, and c for $250 total. Then if handset d comes out and I submit my app to handset d, it costs $1000.
Is that not correct?
Also Flarb, where did you get the data cable for the VX6000 and was your mif file generated with mif editor 1.1 or 2.0 when you submitted the VX6000?
Thanks!

whoa, whoa, whoa, where are you guys getting this information?
The way I interpret the new pricing (based on that email from Developer Relations) is that each submission that has not been tested yet is $1000 and a retest is $250.
So if I submit a new app for handset a, b, and c it cost $1000 total. If it fails, I can resubmit for handset a, b, and c for $250 total. Then if handset d comes out and I submit my app to handset d, it costs $1000.
Is that not correct?
Also Flarb, where did you get the data cable for the VX6000 and was your mif file generated with mif editor 1.1 or 2.0 when you submitted the VX6000?
Thanks!

Oops, I think I deleted the message Qualcomm sent out. But it very explicity stated only resubmissions that don't change the BAR or MOD are $250. You have to pay $1000 for any other submissions that have different BAR or MOD files. Anyone got the original email they can forward me?
Anyway, I just used a 1.1 MIF. And the cable/phone was from a publisher--I guess they got it from their big time connects inside Verizon. :) The cable looked similar to the serial VX4400--but I don't think that actually fit when I tried it. But I can't be sure. I don't have the phone or the cable anymore so I can't actually see for myself.

Oops, I think I deleted the message Qualcomm sent out. But it very explicity stated only resubmissions that don't change the BAR or MOD are $250. You have to pay $1000 for any other submissions that have different BAR or MOD files. Anyone got the original email they can forward me?
Anyway, I just used a 1.1 MIF. And the cable/phone was from a publisher--I guess they got it from their big time connects inside Verizon. :) The cable looked similar to the serial VX4400--but I don't think that actually fit when I tried it. But I can't be sure. I don't have the phone or the cable anymore so I can't actually see for myself.

Ahh here it is:
Incremental Retesting Policy:
- BAR and MOD file must not be modified (previous and current BAR and MOD files will be compared)
- MIF file can be modified
- Standalone configuration files can be modified as long as they are human readable and contain a limited set of information (e.g. a CFG file that only contains the IP address of a content server)

Ahh here it is:
Incremental Retesting Policy:
- BAR and MOD file must not be modified (previous and current BAR and MOD files will be compared)
- MIF file can be modified
- Standalone configuration files can be modified as long as they are human readable and contain a limited set of information (e.g. a CFG file that only contains the IP address of a content server)

Ok thanks. Yeah the cable is different. Suckage.
Where did you read about the "Incremental Retesting Policy"? That wasn't part of the email I got.
So does that mean I can submit previously submitted apps to a new hadset for $250 if the mod and bar don't change?
If that's the case why doesn't NSTL allow you to submit the same version number more than once? You can't change anything but you have to change the version number which causes you to make a change!!!!! ARGGGGGG!!!!!! It makes no sense!!!!
edit: Whoops, that was part of the email. I didn't notice the attachment.

Ok thanks. Yeah the cable is different. Suckage.
Where did you read about the "Incremental Retesting Policy"? That wasn't part of the email I got.
So does that mean I can submit previously submitted apps to a new hadset for $250 if the mod and bar don't change?
If that's the case why doesn't NSTL allow you to submit the same version number more than once? You can't change anything but you have to change the version number which causes you to make a change!!!!! ARGGGGGG!!!!!! It makes no sense!!!!
edit: Whoops, that was part of the email. I didn't notice the attachment.

So .. lets summarize how things have gotten screwed up with this change:
1. When making a game, I currently use a single mod file for all handsets, but different bar files. This is because I want to be able to provide a good set of graphics for each handset. With this change I can:
A: Pay $1000 for each handset because the bar file is different.
B: Use the same graphics for all handsets (most likely resulting in a centered 120x112 game on the larger displays)
C: Try to find some way to make the game scale on the various display sizes. This is only realistic for a very small subset of games.
D. Include graphics for all handsets in a single bar file. This is only realistic for a very small subset of games.
Most likely, I'll start with B and resubmit with new grahpics for certain handsets if the game seems to sell decently.
This also doesn't deal with the different graphics and sound formats available on the different phones. With sound especially, it seems highly likely you'll need to have different formats for the different handsets so B might not even be an option for some handsets.
2. If I made an error, I have to pay ANOTHER $1000 to resubmit the game (assuming the fix requires a mod or bar change). While I don't think it should be free and I don't think a developer should use the certifiction process for testing, $1000 for resubmissions of bug fixes is excessive given the initial $1000 cost for the first submission.
3. When a new handset comes out, I either pay $1000 or don't support it at all.
The end result is going to be a poorer crop of games and worse coverage of the handsets as developers try to minimize costs.
As it stands, games are looking to spend $5000 or more in submission costs to function reasonably well on multiple handsets, just because they have different art / audio content. If we could submit different bar files for different handsets with a single mod file as a $1000 submission, that would go a LONG way towards making this situation tolerable.
I also think there should be a way to re-submit for a newly released phone at a reduced rate. It seems fairly disgusting to me that we would have to spend an additional $1000 to resubmit for the A530 because we had to change code to work around the 150ms timer bug (see 1.1 forum for A530 crash in dog.c).
If things stay the way they are, I have to say that I'm with Dragon and flarb on this one. BREW isn't that much of a better platform to work for that we'll enjoy being raked over the coals on submission costs and I know I'll be spending a lot more time working wth J2ME providers.
Up until today, I was very excited about working with BREW and had plans to release several titles in the coming months. Now I have to stop and re-evaluate the options.
Tom

So .. lets summarize how things have gotten screwed up with this change:
1. When making a game, I currently use a single mod file for all handsets, but different bar files. This is because I want to be able to provide a good set of graphics for each handset. With this change I can:
A: Pay $1000 for each handset because the bar file is different.
B: Use the same graphics for all handsets (most likely resulting in a centered 120x112 game on the larger displays)
C: Try to find some way to make the game scale on the various display sizes. This is only realistic for a very small subset of games.
D. Include graphics for all handsets in a single bar file. This is only realistic for a very small subset of games.
Most likely, I'll start with B and resubmit with new grahpics for certain handsets if the game seems to sell decently.
This also doesn't deal with the different graphics and sound formats available on the different phones. With sound especially, it seems highly likely you'll need to have different formats for the different handsets so B might not even be an option for some handsets.
2. If I made an error, I have to pay ANOTHER $1000 to resubmit the game (assuming the fix requires a mod or bar change). While I don't think it should be free and I don't think a developer should use the certifiction process for testing, $1000 for resubmissions of bug fixes is excessive given the initial $1000 cost for the first submission.
3. When a new handset comes out, I either pay $1000 or don't support it at all.
The end result is going to be a poorer crop of games and worse coverage of the handsets as developers try to minimize costs.
As it stands, games are looking to spend $5000 or more in submission costs to function reasonably well on multiple handsets, just because they have different art / audio content. If we could submit different bar files for different handsets with a single mod file as a $1000 submission, that would go a LONG way towards making this situation tolerable.
I also think there should be a way to re-submit for a newly released phone at a reduced rate. It seems fairly disgusting to me that we would have to spend an additional $1000 to resubmit for the A530 because we had to change code to work around the 150ms timer bug (see 1.1 forum for A530 crash in dog.c).
If things stay the way they are, I have to say that I'm with Dragon and flarb on this one. BREW isn't that much of a better platform to work for that we'll enjoy being raked over the coals on submission costs and I know I'll be spending a lot more time working wth J2ME providers.
Up until today, I was very excited about working with BREW and had plans to release several titles in the coming months. Now I have to stop and re-evaluate the options.
Tom

>[3. When a new handset comes out, I either pay $1000 or don't >support it at all.
Yup...and no sense supporting it until there are enough users.
This policy will backfire, in that new handset users will be
left out even though their device has more capabilities.

>[3. When a new handset comes out, I either pay $1000 or don't >support it at all.
Yup...and no sense supporting it until there are enough users.
This policy will backfire, in that new handset users will be
left out even though their device has more capabilities.

Ok, after reading the Incremental Retesting Fees, it looks like that is only good for apps that have passed TBT. So if your app fails testing it's gonna cost you another $1000 no matter what. If you port to a new handset it's gonna cost you $1000 no matter what.
Hmmm, I think I liked the free testing better. ;)

Ok, after reading the Incremental Retesting Fees, it looks like that is only good for apps that have passed TBT. So if your app fails testing it's gonna cost you another $1000 no matter what. If you port to a new handset it's gonna cost you $1000 no matter what.
Hmmm, I think I liked the free testing better. ;)

Well, I'm with everyone else. It sure does seem like Qualcomm doesn't want to invest anymore $$$ into new apps and games for new and old handsets.
I've read a good deal now about how much it costs to develop (VStudio, Cross Compiler, Versign Cert, Testing Fees). What I haven't read is how well programs are doing. My first program is an APP and not a Game. I have absolutey no idea how much it will make. I assume I'll just have to take a guess at how much I should charge.
It would be great if people could post some info on how well their programs are doing and the details (i.e. operatores the submitted to, handsets, number of sales). This would help others make better decisions. Qualcomm hasn't been very helpful in providing this information.
Kirk

Well, I'm with everyone else. It sure does seem like Qualcomm doesn't want to invest anymore $$$ into new apps and games for new and old handsets.
I've read a good deal now about how much it costs to develop (VStudio, Cross Compiler, Versign Cert, Testing Fees). What I haven't read is how well programs are doing. My first program is an APP and not a Game. I have absolutey no idea how much it will make. I assume I'll just have to take a guess at how much I should charge.
It would be great if people could post some info on how well their programs are doing and the details (i.e. operatores the submitted to, handsets, number of sales). This would help others make better decisions. Qualcomm hasn't been very helpful in providing this information.
Kirk

The BREW Testing Policy indicates that adding a new handset to an existing application will incur a full test charge! This is the only thing I will complain about in the new policy.
If my app never fails, and I architect my app to use the same MOD/BAR files for all devices, I still won't get a $250 resubmission charge for new handsets. I am charged a full $1000 per handset as if it is a completely changed app. This is BRAIN-DEAD.
J2ME was already more open than BREW, but now this seals it. Testing, of all things, is clearly going to allow J2ME to kill BREW. Hopefully in the future J2ME apps for the BREW platform will not cost as much to test as BREW C/C++ apps, and thus will solve this issue.
--t

The BREW Testing Policy indicates that adding a new handset to an existing application will incur a full test charge! This is the only thing I will complain about in the new policy.
If my app never fails, and I architect my app to use the same MOD/BAR files for all devices, I still won't get a $250 resubmission charge for new handsets. I am charged a full $1000 per handset as if it is a completely changed app. This is BRAIN-DEAD.
J2ME was already more open than BREW, but now this seals it. Testing, of all things, is clearly going to allow J2ME to kill BREW. Hopefully in the future J2ME apps for the BREW platform will not cost as much to test as BREW C/C++ apps, and thus will solve this issue.
--t

Overall it is clear to me that this was another academic decision by Qualcomm and no one with some real-life experience has ever thought through the full consquences this may have.
I agree that certification is a good thing, and I fully understand that there are costs involved with the certification process, especially given the thoroughness with which NSTL is approaching them. I also understand that Qualcomm can't pick up all the tabs all the time. However, to roll it all over onto the developers is just a knee-jerk decision.
Who benefits most from the certification? Not the developers and not the publishers, so much is clear. The reason we have the certification is because of... the carriers. They however don't pay a dime for it. How about making them subsidize the certification costs? They want the assurance that the software that is rolled out is safe and stable, and quite frankly I feel that they should be covering a majority of the costs involved to do that.
Incidentally, I think that proper certification of OEMs would also be in order - a request by many develoeprs that has been rigorously ignored by Qualcomm to this date. I see more bugs in handset implementations and firmware than in all third-party Brew applications together. But no, they're getting the long leash, as usual... and the lowly developers are being penalized for it. We always get the short end. WE have to work around firmware bugs - without proper information no less! WE have to pay for the support of new handsets. WE have to deal with crappy, incomplete and unfunctional tools. WE have to pick up the scraps that everyone else leaves for us.
It is a disgusting show of disrespect.

Overall it is clear to me that this was another academic decision by Qualcomm and no one with some real-life experience has ever thought through the full consquences this may have.
I agree that certification is a good thing, and I fully understand that there are costs involved with the certification process, especially given the thoroughness with which NSTL is approaching them. I also understand that Qualcomm can't pick up all the tabs all the time. However, to roll it all over onto the developers is just a knee-jerk decision.
Who benefits most from the certification? Not the developers and not the publishers, so much is clear. The reason we have the certification is because of... the carriers. They however don't pay a dime for it. How about making them subsidize the certification costs? They want the assurance that the software that is rolled out is safe and stable, and quite frankly I feel that they should be covering a majority of the costs involved to do that.
Incidentally, I think that proper certification of OEMs would also be in order - a request by many develoeprs that has been rigorously ignored by Qualcomm to this date. I see more bugs in handset implementations and firmware than in all third-party Brew applications together. But no, they're getting the long leash, as usual... and the lowly developers are being penalized for it. We always get the short end. WE have to work around firmware bugs - without proper information no less! WE have to pay for the support of new handsets. WE have to deal with crappy, incomplete and unfunctional tools. WE have to pick up the scraps that everyone else leaves for us.
It is a disgusting show of disrespect.

Quote:Originally posted by Dragon
Who benefits most from the certification? Not the developers and not the publishers, so much is clear. The reason we have the certification is because of... the carriers. They however don't pay a dime for it. How about making them subsidize the certification costs?Qualcomm is the beneficiary because the process provides them with tested apps to distribute to their customers (the carriers).
TBT is a filtering process, and i think the smaller carriers rely on it a lot. Verizon has its own testing process which seems to take as long or longer than NSTL.
It does make sense for developers/publishers to pay for certification. The problem is that the testing fees are not applied in ways that make sense in all cases (e.g. your proven app is unchanged but it costs as much to test on a new handset as if it's a completely different app).
I would like to see some competition between independent certified testing labs. Why are we stuck with only NSTL? We need some incentive for innovation in testing, and better automated testing procedures, etc. I think I'll propose a paper on automated testing for the next BREW conference.
--t

Quote:Originally posted by Dragon
Who benefits most from the certification? Not the developers and not the publishers, so much is clear. The reason we have the certification is because of... the carriers. They however don't pay a dime for it. How about making them subsidize the certification costs?Qualcomm is the beneficiary because the process provides them with tested apps to distribute to their customers (the carriers).
TBT is a filtering process, and i think the smaller carriers rely on it a lot. Verizon has its own testing process which seems to take as long or longer than NSTL.
It does make sense for developers/publishers to pay for certification. The problem is that the testing fees are not applied in ways that make sense in all cases (e.g. your proven app is unchanged but it costs as much to test on a new handset as if it's a completely different app).
I would like to see some competition between independent certified testing labs. Why are we stuck with only NSTL? We need some incentive for innovation in testing, and better automated testing procedures, etc. I think I'll propose a paper on automated testing for the next BREW conference.
--t

The respectful thing to do would have been to issue a proposal to the developers with the ability for us to voice our concerns.
Maybe Kevin can relay our complaints. Hopefully, Qualcomm will concider a revision to the new policy. Preferably one that makes it cheaper to submit for additional handsets.

The respectful thing to do would have been to issue a proposal to the developers with the ability for us to voice our concerns.
Maybe Kevin can relay our complaints. Hopefully, Qualcomm will concider a revision to the new policy. Preferably one that makes it cheaper to submit for additional handsets.

What do the non-BREW (J2ME) carriers require? Is testing required for J2ME distribution? If so, who is responsible for J2ME testing? Do they have competition among testing houses?

What do the non-BREW (J2ME) carriers require? Is testing required for J2ME distribution? If so, who is responsible for J2ME testing? Do they have competition among testing houses?

I agree it would have been nice to ask the developers their thoughts on test pricing. Submitting the same app to new handsets really should be discounted.
I have a feeling the multiple handsets per submission is going to get too confusing and cause a lot of problems. (e.g. Every time someone submits an app they click every handset with the hopes of squeaking by). I don't think it will be too long before Qualcomm changes to a 1 app/per 1 handset fee. I wouldn't mind that if it were something like $250 per app/per handset.

I agree it would have been nice to ask the developers their thoughts on test pricing. Submitting the same app to new handsets really should be discounted.
I have a feeling the multiple handsets per submission is going to get too confusing and cause a lot of problems. (e.g. Every time someone submits an app they click every handset with the hopes of squeaking by). I don't think it will be too long before Qualcomm changes to a 1 app/per 1 handset fee. I wouldn't mind that if it were something like $250 per app/per handset.

Quote:Originally posted by aisaksen
What do the non-BREW (J2ME) carriers require? Is testing required for J2ME distribution? If so, who is responsible for J2ME testing? Do they have competition among testing houses? J2ME is safer, so it's no big deal. If you want to put your app on the carrier's storefront, then it might have to be tested.
However, in general, it's so much easier for consumers to put an app on a J2ME phone. Many carriers have no limitations on OTA download of any J2ME app to the phone. You could sell apps from your own website if you wanted.
For developers: Nextel sells cables for downloading apps, and the Motorola java application loader is available to any registered developer. I download J2ME apps by cable or OTA to my AT&T Nokia phones all the time. To download to Sprint phones, you must provision OTA (no cable), but that just means putting it on a webserver somewhere. It just requires setting the mime types on the webserver.

Quote:Originally posted by aisaksen
What do the non-BREW (J2ME) carriers require? Is testing required for J2ME distribution? If so, who is responsible for J2ME testing? Do they have competition among testing houses? J2ME is safer, so it's no big deal. If you want to put your app on the carrier's storefront, then it might have to be tested.
However, in general, it's so much easier for consumers to put an app on a J2ME phone. Many carriers have no limitations on OTA download of any J2ME app to the phone. You could sell apps from your own website if you wanted.
For developers: Nextel sells cables for downloading apps, and the Motorola java application loader is available to any registered developer. I download J2ME apps by cable or OTA to my AT&T Nokia phones all the time. To download to Sprint phones, you must provision OTA (no cable), but that just means putting it on a webserver somewhere. It just requires setting the mime types on the webserver.

Quote:Originally posted by polygonsheep
(e.g. Every time someone submits an app they click every handset with the hopes of squeaking by).Actually, one publisher i deal with always asks me if i think it's okay to do this. Every time we've submitted. I'm serious. I always say no, because i don't ever want to fail. But if it's actually cheaper to do it this way, then i'm going to start saying yes.
Quote:I don't think it will be too long before Qualcomm changes to a 1 app/per 1 handset fee. I wouldn't mind that if it were something like $250 per app/per handset. Agreed. To both points.

Quote:Originally posted by polygonsheep
(e.g. Every time someone submits an app they click every handset with the hopes of squeaking by).Actually, one publisher i deal with always asks me if i think it's okay to do this. Every time we've submitted. I'm serious. I always say no, because i don't ever want to fail. But if it's actually cheaper to do it this way, then i'm going to start saying yes.
Quote:I don't think it will be too long before Qualcomm changes to a 1 app/per 1 handset fee. I wouldn't mind that if it were something like $250 per app/per handset. Agreed. To both points.

I am concerned that folks with games in the catalog do not feel there are enough sales to justify a $10k investment, or even $1,000 for each new phone. Is this true?
We all knew that the NSTL subsidisation would not last, however, these fee's should be a small fraction of the total development cost for an application. If the margins are so tight that you would consider not paying $1,000 to get your application on every new phone, I certainly want to know right now that we are chasing after nickels and dimes.
I've heard there's a good future in plastic. :)

I am concerned that folks with games in the catalog do not feel there are enough sales to justify a $10k investment, or even $1,000 for each new phone. Is this true?
We all knew that the NSTL subsidisation would not last, however, these fee's should be a small fraction of the total development cost for an application. If the margins are so tight that you would consider not paying $1,000 to get your application on every new phone, I certainly want to know right now that we are chasing after nickels and dimes.
I've heard there's a good future in plastic. :)

I don't think it's all that easy, really, though in a sense you do have a point.
Many of us do a lot of contract work and with this new pricing model I see a lot of that becoming problematic. Currently a publisher is paying amount $X for a port from one handset to another. That's the only cost they have. Suddenly however there's a definite $1000 in additional charges - an amount that by far exceeds the amount they actually pay the developer to do the port. So, doing a port will suddenly be about 2.5x more expensive than it used to be. You know what's happening next. In order to reduce cost publishers will start arm-wrestling the developers over the cost and they will no longer be able/willing to pay as much for the port.
The same is essentially true for all other contract work. So far, publisher could get a game in the market with $0 publishing cost involved because they could get free certification. Now you're looking at something in the neighborhood of $10,000 as most games roll out on about 6 handsets initially, followed by a series of pre-market devices sometime down the road. That is a lot of money and you can be assured that in the end developers will find the bill for that once again in reduced royalties, reduced guarantees etc.

I don't think it's all that easy, really, though in a sense you do have a point.
Many of us do a lot of contract work and with this new pricing model I see a lot of that becoming problematic. Currently a publisher is paying amount $X for a port from one handset to another. That's the only cost they have. Suddenly however there's a definite $1000 in additional charges - an amount that by far exceeds the amount they actually pay the developer to do the port. So, doing a port will suddenly be about 2.5x more expensive than it used to be. You know what's happening next. In order to reduce cost publishers will start arm-wrestling the developers over the cost and they will no longer be able/willing to pay as much for the port.
The same is essentially true for all other contract work. So far, publisher could get a game in the market with $0 publishing cost involved because they could get free certification. Now you're looking at something in the neighborhood of $10,000 as most games roll out on about 6 handsets initially, followed by a series of pre-market devices sometime down the road. That is a lot of money and you can be assured that in the end developers will find the bill for that once again in reduced royalties, reduced guarantees etc.