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

Developer

Forums

Forums:

One of the biggest shortcomings we have seen in application distribution in the BREW environment is that the entire model assumes that virtually all applications developed are ones that are either in a consumer or retail marketplace. It is assumed that the developer is by default, marketing their application to the subscribers of the operator. The subscriber base becomes viewed as an asset that the developer must be given permission to access. Permission in this case, is an application that has broad appeal to the consumer base, and more importantly, one that can be heavily monetized by the operator. Unfortunately, the model fails to realize that not all developers are necessarily interested in the existing subscriber base of the operator. Nor are they in need or want of being listed in an operator catalog for broad, consumer distribution.

In our own case, and I'm sure is the case for many other developers, we provide a full enterprise solution, of which the wireless application is only one component. Handsets and data plans are often bundled with our suite (as the clients do not have handsets prior to buying our solution) and consequently it is the developer bringing users to the carrier, and not the other way around as is the assumed norm in most of the BREW community.

This is my main complaint. Qualcomm and carriers assume handset users drive applications. That applications can drive handset users never seems to be even considered as a possibility in this market space.

Applications that can increase productivity, or deliver data in real-time, especially remotely, has the potential to penetrate market spaces that standard mobile devices may not have. It is precisely these types of niche markets that the enterprise developer has the capacity to ferret out and bring to the carrier. It is leveraging the power of mobile applications to make the device have more market appeal.

The monetization of these markets to the carriers lies not within application sales (these sales volumes are small in comparison to retail applications) but within the line revenue generated as a result of new users coming to the carrier. This revenue is not insignificant, and even more importantly, is recurrent.

Enterprise developers (ED's) therefore, have much different needs than their retail counterparts. The business relationship between developer and carrier in an enterprise environment tends to be (or should be) far more transparent. Sales channels are often handled internally, as our clients either do not have handsets, or are being given one to be used specifically for a business purpose. Since the ED is dealing with a niche space on users who have no wireless handsets, virtually all sales channels, licensing, payment plans and carrier representation present in the BREW world is non-applicable.

While ED's fully wish to respect the security and performance of the carrier's network, most of the other carrier concerns with wireless applications (having the 'right' applications on the catalog, marketability, etc) are largely viewed as unnecessary barriers to entry, given that ED's are pursuing their own sales channels.

I would therefore ask that Qualcomm strongly consider this market, as their are a number of developers who work outside of the normal operator marketing scheme. We have the potential to bring large revenue to carriers, but unfortunately nothing seems to be structured with us in mind.

Aecalculin wrote:One of the biggest shortcomings we have seen in application distribution in the BREW environment is that the entire model assumes that virtually all applications developed are ones that are either in a consumer or retail marketplace. It is assumed that the developer is by default, marketing their application to the subscribers of the operator. The subscriber base becomes viewed as an asset that the developer must be given permission to access. Permission in this case, is an application that has broad appeal to the consumer base, and more importantly, one that can be heavily monetized by the operator. Unfortunately, the model fails to realize that not all developers are necessarily interested in the existing subscriber base of the operator. Nor are they in need or want of being listed in an operator catalog for broad, consumer distribution.
In our own case, and I'm sure is the case for many other developers, we provide a full enterprise solution, of which the wireless application is only one component. Handsets and data plans are often bundled with our suite (as the clients do not have handsets prior to buying our solution) and consequently it is the developer bringing users to the carrier, and not the other way around as is the assumed norm in most of the BREW community.
This is my main complaint. Qualcomm and carriers assume handset users drive applications. That applications can drive handset users never seems to be even considered as a possibility in this market space.
Applications that can increase productivity, or deliver data in real-time, especially remotely, has the potential to penetrate market spaces that standard mobile devices may not have. It is precisely these types of niche markets that the enterprise developer has the capacity to ferret out and bring to the carrier. It is leveraging the power of mobile applications to make the device have more market appeal.
The monetization of these markets to the carriers lies not within application sales (these sales volumes are small in comparison to retail applications) but within the line revenue generated as a result of new users coming to the carrier. This revenue is not insignificant, and even more importantly, is recurrent.
Enterprise developers (ED's) therefore, have much different needs than their retail counterparts. The business relationship between developer and carrier in an enterprise environment tends to be (or should be) far more transparent. Sales channels are often handled internally, as our clients either do not have handsets, or are being given one to be used specifically for a business purpose. Since the ED is dealing with a niche space on users who have no wireless handsets, virtually all sales channels, licensing, payment plans and carrier representation present in the BREW world is non-applicable.
While ED's fully wish to respect the security and performance of the carrier's network, most of the other carrier concerns with wireless applications (having the 'right' applications on the catalog, marketability, etc) are largely viewed as unnecessary barriers to entry, given that ED's are pursuing their own sales channels.
I would therefore ask that Qualcomm strongly consider this market, as their are a number of developers who work outside of the normal operator marketing scheme. We have the potential to bring large revenue to carriers, but unfortunately nothing seems to be structured with us in mind.
Why not use another platform? There are a bunch of Windows Mobile Phones out there.

Aecalculin wrote:One of the biggest shortcomings we have seen in application distribution in the BREW environment is that the entire model assumes that virtually all applications developed are ones that are either in a consumer or retail marketplace. It is assumed that the developer is by default, marketing their application to the subscribers of the operator. The subscriber base becomes viewed as an asset that the developer must be given permission to access. Permission in this case, is an application that has broad appeal to the consumer base, and more importantly, one that can be heavily monetized by the operator. Unfortunately, the model fails to realize that not all developers are necessarily interested in the existing subscriber base of the operator. Nor are they in need or want of being listed in an operator catalog for broad, consumer distribution.
In our own case, and I'm sure is the case for many other developers, we provide a full enterprise solution, of which the wireless application is only one component. Handsets and data plans are often bundled with our suite (as the clients do not have handsets prior to buying our solution) and consequently it is the developer bringing users to the carrier, and not the other way around as is the assumed norm in most of the BREW community.
This is my main complaint. Qualcomm and carriers assume handset users drive applications. That applications can drive handset users never seems to be even considered as a possibility in this market space.
Applications that can increase productivity, or deliver data in real-time, especially remotely, has the potential to penetrate market spaces that standard mobile devices may not have. It is precisely these types of niche markets that the enterprise developer has the capacity to ferret out and bring to the carrier. It is leveraging the power of mobile applications to make the device have more market appeal.
The monetization of these markets to the carriers lies not within application sales (these sales volumes are small in comparison to retail applications) but within the line revenue generated as a result of new users coming to the carrier. This revenue is not insignificant, and even more importantly, is recurrent.
Enterprise developers (ED's) therefore, have much different needs than their retail counterparts. The business relationship between developer and carrier in an enterprise environment tends to be (or should be) far more transparent. Sales channels are often handled internally, as our clients either do not have handsets, or are being given one to be used specifically for a business purpose. Since the ED is dealing with a niche space on users who have no wireless handsets, virtually all sales channels, licensing, payment plans and carrier representation present in the BREW world is non-applicable.
While ED's fully wish to respect the security and performance of the carrier's network, most of the other carrier concerns with wireless applications (having the 'right' applications on the catalog, marketability, etc) are largely viewed as unnecessary barriers to entry, given that ED's are pursuing their own sales channels.
I would therefore ask that Qualcomm strongly consider this market, as their are a number of developers who work outside of the normal operator marketing scheme. We have the potential to bring large revenue to carriers, but unfortunately nothing seems to be structured with us in mind.
Why not use another platform? There are a bunch of Windows Mobile Phones out there.

Why not use another platform? There are a bunch of Windows Mobile Phones out there.
True, however upper-end platforms such as Windows Mobile and Blackberry are more expensive handsets. Being able to target lower-end or base mobile handsets that are cheap and ubiquitous makes the entire solution more attractive to prospective buyers. These high-end handsets also typically have more expensive data plans or contracts associated with them than their base counterparts, so the whole proposition becomes far more costly to the client.
Additionally, high-end handsets are often far more complex to operate and have trouble gaining sufficient adoption rates amongst target users who are not technically savvy. Base cellphones that have very simple controls do not have this issue (or as much).
We also find that clients are reluctant to purchase expensive handsets where employee churn rates are high (cost potential to have to replace handsets that are not returned). All of this again, goes back to the potential advantage of being able to deploy an enterprise app on base handsets, the client does not large capital expenditures for employee hardware.

Why not use another platform? There are a bunch of Windows Mobile Phones out there.
True, however upper-end platforms such as Windows Mobile and Blackberry are more expensive handsets. Being able to target lower-end or base mobile handsets that are cheap and ubiquitous makes the entire solution more attractive to prospective buyers. These high-end handsets also typically have more expensive data plans or contracts associated with them than their base counterparts, so the whole proposition becomes far more costly to the client.
Additionally, high-end handsets are often far more complex to operate and have trouble gaining sufficient adoption rates amongst target users who are not technically savvy. Base cellphones that have very simple controls do not have this issue (or as much).
We also find that clients are reluctant to purchase expensive handsets where employee churn rates are high (cost potential to have to replace handsets that are not returned). All of this again, goes back to the potential advantage of being able to deploy an enterprise app on base handsets, the client does not large capital expenditures for employee hardware.

As this forum is a suggestion for enhancements, I'd like to recommend the following:
In our own particular case, as I'm sure is the case for other enterprise developers, a user is acquiring a handset from the operator specifically for the purpose of running the business application . Therefore, the operator's BMC is largely a superfluous component (superfluous in the sense that it is not needed as a marketing instrument to find additional users).
What if there was a mechanism in place, such that when a new handset is being activated for an operator, the user can provide a "coupon" or some kind of activation code to the operator. This coupon is provided by the enterprise app and signifies the handset is being activated as a result of the application.
The enterprise app would be present on the VMP, but not necessarily listed in the operator's BMC catalog. When the device is activated, and the coupon code is presented, a link to the developer app on the VMP is enabled. Note that this code is only valid at the time of device activation, so even if a user knew the coupon code they could not use it to access content on a pre-existing device.
The advantages of such a system are as follows:
One, the system is far less cumbersome and expensive than the installation of content from the device OEM. Two, the system is far more trustworthy than a developer based OTA, since the developer must pass through TBT to install content on the VMP. Three, it bypasses unneeded barriers to entry on operator BMC's. Four, operators and Qualcomm could track usage metrics on such a system and have additional monetization mechanisms. Five, the operator needs not be concerned with content dilution on their own BMC. Six, the operator would not be burdened with support costs from such an app, since the acquisition of it is explicitly from the developer.
Obviously, the acquisition of this "coupon code" by the enterprise developer would not only require passing TBT but operator permission as well (offering further security to the operator). I don't know if such a system is already being considered. I do know from attending BREW 2008 that OTA support is being considered for future versions of BREW. However true, open OTA might not necessarily be palatable to operators. The system described above could relieve operators of these concerns and also remove barriers for developers in the current distribution scheme.
Thoughts?

As this forum is a suggestion for enhancements, I'd like to recommend the following:
In our own particular case, as I'm sure is the case for other enterprise developers, a user is acquiring a handset from the operator specifically for the purpose of running the business application . Therefore, the operator's BMC is largely a superfluous component (superfluous in the sense that it is not needed as a marketing instrument to find additional users).
What if there was a mechanism in place, such that when a new handset is being activated for an operator, the user can provide a "coupon" or some kind of activation code to the operator. This coupon is provided by the enterprise app and signifies the handset is being activated as a result of the application.
The enterprise app would be present on the VMP, but not necessarily listed in the operator's BMC catalog. When the device is activated, and the coupon code is presented, a link to the developer app on the VMP is enabled. Note that this code is only valid at the time of device activation, so even if a user knew the coupon code they could not use it to access content on a pre-existing device.
The advantages of such a system are as follows:
One, the system is far less cumbersome and expensive than the installation of content from the device OEM. Two, the system is far more trustworthy than a developer based OTA, since the developer must pass through TBT to install content on the VMP. Three, it bypasses unneeded barriers to entry on operator BMC's. Four, operators and Qualcomm could track usage metrics on such a system and have additional monetization mechanisms. Five, the operator needs not be concerned with content dilution on their own BMC. Six, the operator would not be burdened with support costs from such an app, since the acquisition of it is explicitly from the developer.
Obviously, the acquisition of this "coupon code" by the enterprise developer would not only require passing TBT but operator permission as well (offering further security to the operator). I don't know if such a system is already being considered. I do know from attending BREW 2008 that OTA support is being considered for future versions of BREW. However true, open OTA might not necessarily be palatable to operators. The system described above could relieve operators of these concerns and also remove barriers for developers in the current distribution scheme.
Thoughts?

Aecalculin wrote:Why not use another platform? There are a bunch of Windows Mobile Phones out there.
True, however upper-end platforms such as Windows Mobile and Blackberry are more expensive handsets. Being able to target lower-end or base mobile handsets that are cheap and ubiquitous makes the entire solution more attractive to prospective buyers. These high-end handsets also typically have more expensive data plans or contracts associated with them than their base counterparts, so the whole proposition becomes far more costly to the client.
Additionally, high-end handsets are often far more complex to operate and have trouble gaining sufficient adoption rates amongst target users who are not technically savvy. Base cellphones that have very simple controls do not have this issue (or as much).
We also find that clients are reluctant to purchase expensive handsets where employee churn rates are high (cost potential to have to replace handsets that are not returned). All of this again, goes back to the potential advantage of being able to deploy an enterprise app on base handsets, the client does not
large capital expenditures for employee hardware.
There are some pretty inexpensive deals on Windows Mobile phones now
(I got my MotoQ for Free 20 months ago),
and the complexity of use can probably be solved with your app and proper
device configuration. Though honestly, I'd be looking at iPhone as an
enterprise platform. Of course I'm biased because I've spent time on
porting tools that allow us to write the code to BREW and then run it
on those other platforms.
But, this being a BREW forum, I have to ask, have you contacted Qualcomm
directly to ask about Enterprise distribution using generated sigs? This
would seem to be the best way to go with the present limitations
(e.g. BREW 3.x devices that don't require test enabling and would
run your app with a generated sig via cable load). At least if you exhaust
that avenue you can be clear on the position and not waste anymore
time.

Aecalculin wrote:Why not use another platform? There are a bunch of Windows Mobile Phones out there.
True, however upper-end platforms such as Windows Mobile and Blackberry are more expensive handsets. Being able to target lower-end or base mobile handsets that are cheap and ubiquitous makes the entire solution more attractive to prospective buyers. These high-end handsets also typically have more expensive data plans or contracts associated with them than their base counterparts, so the whole proposition becomes far more costly to the client.
Additionally, high-end handsets are often far more complex to operate and have trouble gaining sufficient adoption rates amongst target users who are not technically savvy. Base cellphones that have very simple controls do not have this issue (or as much).
We also find that clients are reluctant to purchase expensive handsets where employee churn rates are high (cost potential to have to replace handsets that are not returned). All of this again, goes back to the potential advantage of being able to deploy an enterprise app on base handsets, the client does not
large capital expenditures for employee hardware.
There are some pretty inexpensive deals on Windows Mobile phones now
(I got my MotoQ for Free 20 months ago),
and the complexity of use can probably be solved with your app and proper
device configuration. Though honestly, I'd be looking at iPhone as an
enterprise platform. Of course I'm biased because I've spent time on
porting tools that allow us to write the code to BREW and then run it
on those other platforms.
But, this being a BREW forum, I have to ask, have you contacted Qualcomm
directly to ask about Enterprise distribution using generated sigs? This
would seem to be the best way to go with the present limitations
(e.g. BREW 3.x devices that don't require test enabling and would
run your app with a generated sig via cable load). At least if you exhaust
that avenue you can be clear on the position and not waste anymore
time.