|
Approaching the Market |
SCOTT PATERSON: We're going to wait for a
second to get some sound. Hello. Test. Great.
All right. Everybody open their textbooks to page 232 of Marketing On The New Electronic Frontier. I wish it were that easy because I could just plagiarize all my slides.
We're going to be talking about a bunch of new stuff here that hasn't really been delved into in a traditional marketing sense. My name is Scott Paterson. I'm a Be Evangelist. Other than being a new term for marketing, I try to help developers any way I can to get their applications to the market. As Mark Gonzales mentioned, we're really doing two things this year centering around proliferation of the OS. You get a lot of seats and a reason to develop applications. And the second thing is get those applications. We need to do that and that's what my job is to help you.
So that's why I've done this presentation to help you think through areas that you might consider when you're done doing your software and you're going to bring it to market, and actually Be has a lot of experience in this area, and that's where a lot of Be information comes from in this document. So what I'm going to do is go through the areas we've kind of come up with you need to think about when you bring your software to market. That's production, accepting aware from the the electronic, producing disks, physical media. Awareness, create awareness. Nobody knows you have a product. You're going to have a hard time finding customers.
The decision making process to actually purchase software, when you've done that, how to make a transaction, exchanging money for software. Installation, registration, if you want to target future customers, delivery of updates, and finally, technical support.
However, before I get into that, I don't want to be left out here so I'm going to bring up my codes -- whoops. Let's do it this way. Here we go. Okay. And I'll just show a few things here. We've got some new parts of the BeOS API that nobody else has talked about. Especially Be, "show me the money." This is what's really the most important thing in considering developing the product on the BeOS. You want return on the investment and hopefully I'll get you through that.
All right. To get serious, let's go through
that. I'm going to start with production. A couple
things to consider here in production when you're doing
hard media, you want to try to have larger quantities and
you've got to balance a number of factors as you do
that. The idea is to spread the one-time costs that are
associated with producing things like CD's across as many
units as you can, reduces, you know, add-on cost to each
piece of software.
Some things you can do to help that is reduce software revision. That's a good thing and bad thing. It's nice when you're doing updates on a regular cycle, delivering them to your customers. However, you can take it to the extreme and, you know, wait for five years and try to throw everything into a single release. Sure, you're going to save money on your CD production, but you've probably lost a lot of customers in the process. You want to optimize your production runs. Of course, larger runs have a greater associated obsolescence risk. So if you create a whole bunch of CDs and then two weeks later add a new feature to your software, you end up having to throw away a lot of CDs.
Some things you can do in that area is in the other hard materials of your kits, you've got your CD, you've got your packaging, you've got printed manuals you can have your -- outside the software, you can have your manuals be revisioned, not revision specific. If you can do that, packaging, it's a lot easier. Packaging doesn't have to be associated to a particular revision of software.
There are other strategies like having a software box and use printed labels for software revisions so when you go and do a new renew revision of software, you can print new labels, put them over the old ones and reuse those boxes. So you may have some loss, may lose out on a few of the CD's, but reuse other portions of your kit that make up your whole package. And it is actually a nice thing to have a whole package, and Be is planning on doing that as well.
There are some people that like to hold the box in their hands and open it up and pull out the CD, and they get great satisfaction from that, and oftentimes they're willing to pay a bit of a premium to get that kind of product.
Also designed to your channel a lot of this talk is going to focus on electronic delivery software. As you know, we always talk about going back to the original business plan at Be. We have the concept of delivering electronic information and updates about fixes, over that medium. And you can do things -- if -- if that's going to be your target, distribution, then you can do things there as well. You certainly don't have to have packaging that has, you know, six colors and is trying to jump out on a shelf space because you're not really on a shelf space. That virtual shelf space can be a nice graphic on a web page.
When you actually deliver that box to the customer, they probably don't care too much how many colors are on the box. Traditionally, colors in packaging and single-color manuals printed in black and whites. These are ways to reduce your cost to actually getting your product out to customers.
Okay. Creating awareness for your software.
There's a number of things you can do. We found at Be
that our web site has done a lot for us. So we are
encouraging people, you know, create your own web site or
post your information on a web site somewhere and make it
available. More information is better. Leverage
existing Be-related web sites.
For example, I have got some up here, BeForever
web site, BeMacForever web site. Spreading information
by word of mouth was a very effective means to
communicate your product's existence these days. The
BeDepot by StarCode folks. It can have an on-line
catalogue of products that are available for the BeOS
going all the way from freeware, shareware to commercial
applications. In fact, these guys are going to talk a
little bit during this presentation.
The BeSpecific web site is another example. They have a lot of the BeWare. The Be FTP archives are all in their site. They have all the BeTalk. All BeHive from Mac User, Mac Week. We have Henry Bortman here today. At the end of the talk he's going to come up and talk about some of the directions that BeHive is going to be taking.
I have trial software available. It means in many cases a lot of extra work. But there's nothing like actually trying out a piece of software before you decide to buy it.
Be Evangelism. I'm not the only evangelist at Be. Michael Hopwood is also an evangelist. And we're available and actually love to get new software. A lot of time we're on the road doing demo tours all over the country and internationally. There's nothing like a good application to show off the BeOS. A couple apps, "reggae write" and the summit spread sheet application, they are nice applications that show off multi-threading, but also productivity, and people are glad to see, impressed to see those types of applications are available for the BeOS.
In addition, what does a mundane word processor gain from a multi-threaded system? We like to show off that stuff. If you would like software for us to demo, we will accept it heartily.
Be user groups, we have a listing at the web site. You should try to get involved in user groups. They're looking for material to present on a regular basis. They love to demo apps just as the evangelists do.
Finally, create a great demo. There's nothing better than generating excitement and enthusiasm for your software than actually showing it. You are the most knowledgeable person about your own software. And you know where its strengths and weaknesses lie. And, you know, there are strengths in the BeOS. My God, there are weaknesses, too. But you can create a great demo around them, and as many of you have probably seen, the demos at Mac World we do, if you come in for a Friday demo day, we put together a pretty impressive demo. People walk away, and from a user standpoint, very enthused and definitely give the BeOS a trial.
From a developer standpoint, developers become attracted to the BeOS. I know the guys doing the X server when I went to Princeton, they heard about the BeOS, the generic, but when they saw it, it convinced them to start developing for the BeOS platform and three months later we had it.
So also look in a few weeks -- I know I see on Valerie's white board I'm supposed to do another news article. I think what I'm going to do is actually go through and point out, you know, areas that make a great demo. How to make a great demo, essentially. Things that you should consider doing.
Okay. The decision process. People know about
your software, starting to look at it. Are they going to
buy it? As I said before, more information is better.
You might want to consider actually doing some dreaded
marketing collateral where you actually do -- it doesn't
have to be print pieces, but you can do it on a --
through a web site. You have some written material that
describes what your software does, the advantages of it,
the things it does great, requirements, stuff like that.
If you come and look at our web site, we have a
spec sheet. It's printed and it's on our web site. You
can use that as a template. I have web links. That's
where your information has web links to where they can
order that product or that software. You want to make
that transition from decision to transaction as easy as
possible. So if they have that impulse to purchase,
there's no barriers or no extra steps to actually making
the end purchase.
I mentioned trial software. I won't mention it again.
Documentation, good documentation is important. There's simple ways to deliver it on the BeOS. You can use stylized edit. If they double click on it, up it comes, they can start reading it or use HTML. We've seen a lot of third parties provide electronic documentation in this method as well.
I can't stress enough, and you'll see as we get towards the end of the presentation when we hit technical support area, but frequently asked questions are very important. In this area it's more like what are the requirements to run your software. And try to answer. As you go through this process, you're going to get a lot of questions, and it will be very clear which ones are asked over and over again. And maybe head them off at the pass and answer them in advance through frequently asked question sheets. And you can come and see the Be web site where there's really extensive facts and use those as templates.
Finally, you know, we're kind of working our way down to well, okay, do some of this or if you can't, you know, how about access Be electronic mail. Most people, especially in the BeOS area, BeOS market as users, are going to have access to electronic mail, so maybe you can have them be able to request information over electronic mail. You don't have to be answering that on an ongoing basis. If you're not going to answer it in a really timely fashion, then you might want to provide some kind of service where it automatically replies, at least acknowledge that you've received the request for information and we will get in touch with you shortly. The nice thing about electronic mail, it's nonblocking, people can deal with it at their convenience.
And then, oh, my God, maybe actually have a phone number for those users that have to have some hand, you know, holding to get information on the product. That's one that I would say is pretty optional nowadays.
Okay. Talk about a couple areas dealing with
the actual transaction where you want to exchange money
for the software. I'm going to talk about some example
transaction costs here. And these numbers, along with
some of the numbers I use in technical support, are
courtesy of Ed Romson, our director of customer support
who actually gave me quite a bit of support in these
areas.
So our Webmaster Ron Theis has a little clip-out article up in his cube and it details how to implement a fully transactional web site for electronic distribution of software for your company and the associated costs with that. And on his little article it says, yeah, it's typically around $3,000,000 to implement that for yourself. I think what he's trying to imply there, the difference between his salary and that amount, where is that money actually going and can he get some of that.
But anyway, here is some example transaction costs. To actually set up some hardware, buy the software, get appropriate net access to deliver your software electronically, the administrative costs. If you're going to do it, it's going to take away time from development. You're going to have an extended delivery to market for software or else you're going to hire somebody to do that. That's going to cost money. So, you know, of course your mileage may vary. These numbers don't apply to all parts of the world. But about $53,000 for a year. Some of those are ongoing costs and some of those are one-time costs.
On the other hand, if you're going to go through a third party to do your transactions -- and I have some examples I'll talk about in just a second -- for example, I know one of them has a 15 percent transaction fee, based on, say, 7,000 copies at $50 each, well, you get -- that's your kind of break even point, 52.5 K. If you're going to do more than 7,000 copies on that fee rate, then that's where you might start -- that's where you actually might start saving some money.
Okay. Here are the examples of some services
that provide transaction services. Some of them do it
better than others and will do it better than others.
Some of them provide very basic services, some provide
extended services, some are more expensive.
BeDepot from the StarCode folks, they're going to provide an area in the web site where you can do the transaction, pay for software, where they'll deliver it to you electronically. We'll see an example of that in just a minute.
Kagi, it started a share only, but mostly a collection of money for shareware. Registration programs that you run, you can give a credit card and pay to register for shareware. They don't offer too many extended services. You have to find your own place to host your software. They won't actually provide -- they will, but it will be for extra money. They don't typically do it and people don't really ask them to do it. You have to provide your own area on the Internet to have your software downloaded from.
And then software.net is the other extreme.
They have a very glitzy site and cost there is somewhat
higher for distribution through their channel. Actually,
significantly higher.
Okay. I'm going to talk about the first part
of the slide and then into the demo. Package demo and
Software Valet, they actually go all the way from
transaction through installation, into registration, into
updates, but I had to put them somewhere in the
presentation, so here they are. It gives you the ability
to have a customized installation, very simple for an
end-user to do a correct installation. That's important
because if you have an installation method where files
can be misplaced, then that's going to increase your
technical support costs. Your software is not going to
get installed properly, it won't run properly. You have
to satisfy customers. You want the installation, maybe
not too much of your own software, but you want it
smooth. The very first interaction the end-user has is
pleasurable.
Actually, right here I'll invite the StarCode
folks up. Michael is getting his microphone, before we
get into the less glamourous duty.
MICHAEL KLINGBEIL: Hi there. I'm Michael Klingbeil from StarCode and I'm going to talk a bit about and demonstrate Package Builder, which is an installer builder that integrates with Software Valet and also allows you to build self-extracting installations, so let me launch up the application. Please excuse any of the cosmetic problems.
This is a DR9 port that was done quite recently. So what we see here is essentially an archiving type window that you can add files and folders to that will be installed. So you can either do a drag and drop type install or you can add the files and folders. I think that's -- I'm sorry. There was a little problem with that. You can add the files and folders through standard select file dialogue. For each file you can choose a variety of settings.
The first thing you might want to do is divide the installation into a set of groups so that the user can choose the portions of each installation, so there is some default groups for this. So you can add and delete groups and re-order them as desired. You can add, separate items, give a visual cue for the user using the installer. For each group you can set a description, give you some idea what the install does. You can specify additional help for a group to give the user more information about what that does. And then you can go ahead and assign the groups for the various files.
And then you can choose where special files might be installed, such as add-ons or shared libraries, documentation. You can also set your own custom paths for where things will be installed so you can add a path and enter where that will be installed. These path names are relative to the installation disk that the user chooses. You can also enter it in absolute path names beginning, say, with slash and a volume name. But that would generally be discouraged since that volume might not exist on a particular user's drive, but for special applications perhaps that might be useful. And then you can choose replacement options if the file is found, that it already exists. Either the user can make a choice from a dialogue box or you can choose to replace the file, depending on attributes, version, creation date.
And we also give you a little information about shared libraries that may be required for the specific items that you have added to the installation. So I can see that here I have these are just standard Be libraries so I don't need to add any shared libraries to my installation. So once you're finished creating the installer, you can set a variety of global installation settings. This currently doesn't work on DR9, but it will.
And then For sort of global installer settings, create an installation folder, and everything will be placed inside, and enter a larger description such as a copyright. Let me open up an existing package so you can see better how these would be used. So you might enter information such as a copyright. You can add additional help, default help here. And you can choose to display a license agreement file that will be displayed as the installer is launched.
And then finally, you can set information for the package. This is used to display the Software Valet. This allows the user to sort of have a view of the software. It allows things like version comparison when checking for updates from the BeDepot site. What we actually do is allow versions. You can specify any string desired and we do comparison of versions dependent on the release date you specify, so we avoid any of the potentially nasty issues of trying to compare strange versions of strings. Then a description. So once you've finished creating the entire package, you can either just save the file, and that file is compatible with a Software Valet, which I will bring up. When using the Software Valet, the user has a little bit more control over the installation.
Specifically, they can see a preview of what the installation will look like. Or you can build a self-extracting installer. The installer that you will build is not quite as full featured in order to save on the overhead, the transmission time. But it has essentially the same interface as the regular installer. So you don't have some of the features like the help buttons or the previewing, but it will function the same way. So whether you need to distribute something that you know is self-extracting or if you want to go through the Software Valet, which will be a free tool, either way it will work. So I think that gives you an overview of what we're doing with this. Thank you.
CARLIN WEIGNER: Hi, I'm Carlin Weigner, also of StarCode, and I'm going to talk a little bit about BeDepot and how it relates to you helping ship your applications, and also in comparison to the other sales channels that are going to be out there. First off, let's just kind of go through some of the things that we do, especially since Scott gave a good breakdown of that.
First off, one of our jobs is to generate demand for your applications, an on-line catalogue. It's our job to get other BeOS users to the site, as well as other Macintosh users, to convince them the BeOS does have apps. We also have a weekly newsletter sending out updates when new applications are available, pricing changes and so on.
The second thing we do, which Scott mentioned, is that we actually do do the Internet transactions, handle secure Internet payments, real time credit card based anywhere in the world, so we'll handle all the European back tax issues and currency transactions, things like that. We will also handle electronically distributed software.
The next thing we do is we are -- a lot of people think we are just focused on electronic delivery of software, but that's not really the case. We do believe electronic delivery of software is very important for Be developers, because of the fact packaging is very expensive to make and a lot of hard decisions in there. But we do believe for software that costs 200 bucks, you're not going to be able to say, "Hey, no CD, your drive is lost. That's tough." So we do have fulfillment to houses, of your application. So you can choose between whichever delivery method is best for you.
We do handle automated registrations, in a little different way than most other channels do, which either have the printed cards or the web forms. We believe our registration system will result in a higher number of people registering software, and as everybody knows, those are your best customers, the people that have already made the decision to use your software and are likely to pay for upgrades and the like.
And finally, we have a kind of cool sort of push-based update system. We beam down software at night, depending on the preferences set in the Valet. We think this will really help lower support costs, don't have to worry about users patrolling around your busy sites to see if versions are available. We really think that's going to help out.
How much does it cost? Well, we take about 15 percent of the sales of your software, which, in comparison to things like Kagi, is more. Kagi runs about 7 or 8 percent, I think. But in comparison to software.net and other bigger players, 30 to 40 percent, we're obviously, a lot less.
A SPEAKER: Wow!
CARLIN WEIGNER: Now, a little word about our positioning. We think 15 percent is a good figure. We don't think it dents too heavily into revenues. We really, really try to offer a lot of services for that. Kagi does not do the actual delivery of software. They do not handle publishing of updates the same way we do. Once this market gets bigger, we have no problem moving our fees down. We definitely think developers are going to have multi channels. Kagi is more popular in Europe than we are. Some people go through CD's, some people go through bars. Do your research on this stuff. It's really confusing sometimes, but, you know, a lot of sales channels would be a good thing.
I think that covers it.
SCOTT PATTERSON: Okay. There's always do-it-yourself. We've seen this method done quite often in the early phase of the existence of BeOS, Zip, add-ons was a nice thing to explode those archive files. But you really need a more technical user to handle this kind of installation method, and actually, that's where we're kind of moving a little bit away from that as we move more towards an end-user release. We feel that a great developer knows how to open up a terminal window and type Tar, X, Zip, VF, set file and run it. But to expect an end-user to do that is unrealistic. In fact, an end-user may not try this software to go through that. Then, of course, a chance for improper installation, files being placed in the proper places and higher associated technical support costs.
Okay. There are a number of ways to do
registration. And it is important to do registration
because this is your lowest cost target customer. These
are people who have already decided to purchase your
software. They think it's that good. Later on they're
probably -- they'll probably ante up and purchase updates
of your software. This is a crowd you want to capture.
You want to have their contact information. Depending on
the way you do this, better response rates on
registration.
Now, I used to work in a messaging group at a large networking company and I was always perplexed that we did a messaging engine, you know. What do you use a messaging engine for? Mostly electronic mail. We put a little card in the box. That was the only way you could register you purchased the product. So we had the corresponding return rate of about 8 percent. So we knew about 8 percent of our end-users. We wanted to do marketing for enough products. That was not -- we weren't going to contact very many people.
Fax is also kind of difficult and yucky. People don't like -- probably a fax machine they could use, but just the thought, got to pay to fax, and an extra hurdle, barrier to actually register. That doesn't have very much better results. E-mail is pretty good, especially if you build it into your software. You can collect them electronically. Most people do have access. You kind of don't address the home market, although that's changing over time as more and more people get connected at home.
There's also the web. That's very nice because you can have a form and you can gather all kinds of information on the form, including, say, do a graphics program, what kinds of printers people are using, say if a color printer comes up, a certain kind more often than not, you can test and make sure your software works with that type of printer.
And automated, the best of all, because in some cases, depending on how users configure their systems, the Software Valet, it makes it so easy to register the software. It almost always happens. That's a good thing.
Updates, I just had a briefing up here. It goes back to doing production and stuff like that. You want to consider when you do an update, is it free or does it cost money? And that's mostly, you know, I can say, "Well, okay, it should be free if it only does bug fixes." But that's not always true. You may have major bug fixes that, you know, maybe increase performance of your particular software dramatically. I guess typically what we see is bug fixes are free upgrades. Adding major or some kind of new functionality to a new software would be a cost update and then there's your delivery cycle. If you know your registered customers, easy to deliver to them. If you've done something like these are Software Valet, deliveries can happen automatically for end-users.
Okay. Some technical support considerations.
Should I provide technical support for my product and how
am I going to do that? My focus is on developing
software. How much time am I going to take away from
that to do technical support which I may or may not have
any experience with?
Here is some examples of technical support costs, and again, numbers can totally vary depending on your circumstances. But just for exercise, two people, salary benefits, total costs, everything included, $200,000. They do 30 contacts per day per person. And let me step back at this point to say, probably industry average, or the lower ends or lowest ends of industry average, is you're going to have a 35 percent contact rate for technical support on your products, so for every hundred copies of software you sell, you can probably expect 35 people to contact you for maybe a minor thing or maybe a major thing. That will cost you cycles of time.
So anyway, 30 contacts per day per person, so 60 contacts. And 80 percent efficiency rating. 260 work days they can handle and 12,480 calls per year. So the cost per contact in this case ends up being a little over $16. That, you know, actually seems like a lot of money.
So when you're building up your own technical marketing department, you know, this is one thing to consider. Are you going to spend this money to do first line support?
Another consideration is, okay, if I don't want
to go through that exercise, I just want to have my head
buried and produce good code and good software for the
BeOS, well, you can out-source your technical support,
and Be is looking at this. This is a table indicative of
some of the bids we've received to do third-party
support. And this doesn't mean you can automatically
forget about support, I've hired somebody to do it and I
won't have to worry about it. You probably will have to
manage the out-sourcing from the third party some way.
That's really only for first line support.
For things that need, you know, more technical
support, more in depth problems, you still will have to
be at least somewhat available to do that as well. But
you can get an idea. Whereas, setting up my own
department with two people, is a little over $16 per
contact. You can see that some of these contacts,
contact rates are a little bit less depending on the
volume you might expect.
Just going back a second to do-it-yourself, if
you decide to do it yourself, some things to consider are
FAQs, FAQs, FAQs. That's what we've tried to do at Be.
I know the webmaster mailbox has a very large number of
megabytes of mail it receives all the time. And one
thing we've done is, thanks to Michael Daretti, is
produce, you know, really extensive FAQs on the BeOS, the
Be web site. That has helped to significantly reduce the
number of contacts that both Michael and Ron have had to
deal with, and even our developer support team to free up
some of their time.
Have a web based interface. Like registration, you can collect the information you need to know. What kind of machine are you running on, what version of OS do you have, what version of software do you have, what are the times I can contact you? You can collect this information in advance and jump-start and hopefully shorten it down.
Of course, E-mail, and as I mentioned before, depending on how responsive, you might want some kind of automated response and the dreaded phone support.
Some Be resources to consider, all this was
drawn from a white paper I've written that I noticed went
live on the web site, so if you look at the front site of
the Be web site, a title, just add customer, but there's
an approaching the market, white paper, and it goes into
a lot more detail than I did during this talk.
So you can actually see what the breakdown on what some of the costs of those services like Kagi as well as software.net. You can actually see how expensive software.net is. You can contact the Be Evangelistz, scottpatterson@be.com, Michael Hopwood at hopwood@be.com. And we're very responsible at electronic mail. And Ed Romson stopped by my cube Thursday and Friday and said, "You can go ahead and mention my name," so I'm going to go ahead and mention it. He said he would be happy to talk to people about out-source, doing third party production of your media and packaging and manuals, that kind of stuff, as well as technical support, things that you would consider that I talk about. He's happy to discuss those things with you and help you out in those areas as well.
And then finally, the last thing that I'll kind of leave you with before I invite Henry Bortman up, is we've kind of stumbled onto this -- I don't want to call it really a theory, but this thing we're calling the greenfield effect, and I have to attribute it to Michael Hopwood. He actually named it for having a little marketing meeting. And what we're finding is we talked to people who have BeOS as more end-users get it through the Mac Tech magazine, and not just developers that we're able to get a hold of, that as people are trying out the BeOS and that as we see them and talk to them at trade shows, they're saying, "This is great stuff. I really like it. What application can I buy today? I'll buy any application. I just want to buy an application for the BeOS." They'll try anything.
So it's kind of strange because it's not -- it doesn't seem that logical, but it's what's happening. What we're seeing is in this early phase of the BeOS it's going to increase as we go distribute out through PowerComputing license. But people initially are going to go, "I just want to buy an application for the BeOS."
So those applications there early are actually going to experience this greenfield effect, this kind of sales that happened because there are a lack of products to purchase initially. Eventually that will fade as more products come to market and people get lots of choices, but it's something to consider as you do your software. So right now I'll ask Henry Bortman to come up and speak a little bit about BeHive. BeHive. And after that we'll go into general Q and A and you can have questions for myself or Henry and the StarCode folks.
HENRY BORTMAN: Is this live?
SCOTT PATTERSON: Yeah.
HENRY BORTMAN: I'm Henry Bortman, technical director of Mac User Magazine. Mac User has been a phantom of BeOS since we first heard about it. We did an article late last year talking about its advantages and at the time when everybody thought that it was going to be Apple's choice, we actually thought it should have been Apple's choice, but here we are. We're still fans of the BeOS and we plan to consider coverage of the BeOS in the magazine. Mac Week I believe also plans to do that.
We also have built a site. That's part of ZDNet. It's run by Mac User, but encompasses all the magazines published, PC Magazine, PC Week, Mac User, Mac Week, et cetera, et cetera, et cetera. So it is one of the most frequently visited sites on the entire Internet. And Mac User site is one of the most frequently visited within mac.net, even though there are ten times the PC users. We are up there with how many people visit our site.
We have a very extensive software library on the Mac site. We plan to do the same thing with the BeHive, which is our Be site. BeHive has been up there several months now. All the articles in the print magazines go up on BeHive and a guy named Scot Hacker, who I believe is with Internet Life Magazine, who is also doing sort of an ongoing journal of his experiences with a BeBox, and those go up there as well. There's a section called BeBuzz where people can post comments and, you know, discussion can get going. That's been a little dead for a while, but we expect it to pick up soon now that DR9 is out.
So what I want to let you all know about, and there should have been a flier in the handouts you got when you registered, is that we would like any shareware, freeware or demoware that you have for the BeHive site. We will put it up there, not charge you a penny, contact Philip Dyer at Mac User. His E-mail address is pdyer@macuser.com.
We are not a service for selling software. We're not competing with anybody in that sense. On the other hand, we're totally free. So it's a very good place to get awareness of your product out there into the market.
The other thing I might mention is I am writing an end-user book with the BeOS, one chapter of which will cover some of the early BeOS applications. So if you are working on a BeOS application and would like to get a mention of it in the book, please contact me. My E-mail address is hbortman@pobox.com.
A SPEAKER: Can you spell that?
HENRY BORTMAN: H B O R T M A N, at, P O B O X, dot, com. Thanks.
A SPEAKER: BeWare has the transaction site?
SCOTT PATTERSON: Right now we do have our own site. I did neglect to mention it. Be has an area on the web site called BeWare. For a long time we've been hosting all available software people who have willingly uploaded to our site. The process is more developer-intensive because you have to go through -- we don't go out and look for the software, but you come and register software and upload it with us. But that's available and I think going forward for that will be available. We haven't had any further discussions for that.
A SPEAKER: Be will take part at one time?
SCOTT PATTERSON: Yeah. We haven't really discussed that much more. You know, we knew that a long time ago that the electronic delivery of software is very important, and if nobody else would address that, we would have to address that. But it looks like maybe there are third parties using this as an opportunity and our focus is really on software. So right now we haven't had any further discussions on that. All of our focus has been on delivering a new version of the software.
MARK GONZALES: Scott, since he's dancing around a subject since he doesn't know how far he can go, there are various discussions we are in with a number of people. Obviously, StarCode has been one of our long-time developers. We just haven't made a final decision exactly where to take be.com yet. I would expect something. You should see something from us in the next six weeks, I would say, on exactly where www.be.com plays in the distribution of Be software.
SCOTT PATTERSON: Any other questions? All right. Go ahead. Then we'll wrap it up.
A SPEAKER: A question on the outside. Explain how to make money as a developer. I don't see how Be is going to make money and make it survive as a basis to make money. Are you going to change the pricing of the OS dramatically or what's going to happen?
SCOTT PATTERSON: If you come to our web site, we sell T-shirts. Yeah, eventually the operating system will be sold and that will be it.
A SPEAKER: What range are you thinking of? In the thousands of dollars?
SCOTT PATTERSON: You know, again, we haven't had this discussion yet.
MARK GONZALES: It's not thousands. And obviously, we have to keep in mind the competitive positioning of software. Probably on the high end, Windows NT sells for -- well, lists for 319, usually sold for about 250, depends on where you're buying it. And, you know, Windows as a whole package is 199. As an upgrade, $99. Of course, we are adopting a -- what we call the Metrowerks model. That's a nice segue to your talks. The Metrowerks, when you buy one copy of the operating system, you get the next two updates for free, so that will affect pricing, too. I will expect we'll set final pricing as we go out this fall, but I would expect the OS single copy with upgrade rights to be in the range of a couple hundred dollars, maximum. We don't have any worries as far as our own financial motto. That's fine.
SCOTT PATTERSON: All right. Thank you very
much.
Home | About Be | Be Products | BeWare | Purchase | Events | Developers | Be User Groups | Support