 |
| Welcome
Sign Up Log On |
|
|
Messages: (41) 1
Lots of stuff happening right now at Macrobyte (in case you hadn't noticed). All of the software we've been working on for the last few months or years is being released, and Macrobyte (and Friends) is trying to chart a path we're not quite used to.
It's a little nerve-wracking, frankly.
One of my friends has been -- and continues to be -- very outspoken against my preferred course of action. He thinks he's annoying me, but in fact I appreciate the fact that he's really forcing me to think about how the future could go.
I'm tired of not having a place to talk about this stuff, so I'm going to break my own rule and talk about it here, now.
The situation is that we have a lot of software to release. Now that it's all been announced, at least, I'll list it:
So how do we make a living? That's the question.
Sales of our software. Support constracts? (How much?) Non-free developers program? (How much?) Hosting services? Consulting services for continuing to improve our software?
I don't believe that charging a lot for the software will work. We don't have a sales or marketing budget. That means we have to build a community, and work with the other developers to "get the word out".
My friend (or possibly two of them) thinks that we should charge more for the software, simply because its so good. It's worth it, so charge for it. The point has been made that we'll have to sell quite a few copies of Conversant at an annual subscription, in order to keep the business growing.
I counter with the fact that a higher price makes it a much harder sell. (In fact, the same friend has told me to both raise the price *and* do more to cater to the low-end of the customer spectrum. Update: that's not what he meant, I misunderstood.)
I want to trust the developers to work with us, to be honorable and help us all to succeed. This may be a weakness, a flaw.
This is a crazy way to do business, I know, but I'm looking for opinions. If you're a developer who might be interested in working with our software (anything I listed), or a user who might want to install it (at your company), please speak up. Your opinions may help shape Macrobyte's future.
Do you have a site of your own? I invite you to post your thoughts there, and send me the URL. I'll link to it. If not, then feel free to reply here.
If nothing else, speaking up now will give you a chance to say, "See, I was right!" when we succeed -- or fail -- with whatever plan we go with.
Thanks for listening. Now I'm listening.
[Top]
My comments are to price your products according to value.
People will pay fair prices and you deserve fair prices for the years of work you put into the products.
When I was the CFO at EDO, my partners wanted to charge $65/hour to clients (1995 dollars). I vetoed that idea and set the price at $85/hour. The next year they wanted to hold the line at $95/hour. I vetoed that and raised the price to $125/hour and made it stick. Result, we made money.
We provided good value for the price and had no problems collecting the fees we charged. That's how companies grow and prosper.
Years later, now one of my former partners is now a partner in another firm. They charge accordingly and they make lots of money. The old tried and true ways of business work. They have for centuries.
Go with the flow. Of money that is...
Don
[Top]
There's an old saying "the only one afraid of the price is the salesman."
The hassle here is that the customers aren't going to educate themselves on this sort of stuff. Someone's going to have to sell them on the idea. This is an incredibly tricky process. One that I daresay has been really unbalanced by vendor behavior. Seth's asked me to "be civil" here so I'll leave it at that.
What's needed is a good old-fashioned sales effort. Someone's got to package the solution and go sell it. Otherwise it's just a consulting effort. Granted, the consulting effort can be lucrative but it too has it's own sales cycle.
Perhaps it's best to look at having a liberal evaluation edition that defines clear limits on what can and can't be done with the code. If anyone's going to take the time to steal the code there's little you could ever do to stop them. So for the rest of the customers it's got to be something they can get their head around at a reasonably low point of entry. Evals with realistic time and data limitations are probably the best hope for building mindshare.
But you're still going to have to sell it. It will never just jump off the shelves. It won't even drag it's lazy ass out off the UPS truck and out of the box. Someone's going to have to pound the ground, press the flesh, and make those sales. This concept seems to be completely lost on the dot.bomb people.
Make an eval package. Make it genuinely work and be installable by mere mortals (or even IT guys). Give serious consideration to how the most likely first contact is going to view this process. If that's the infamous "IT department" then pay close heed to what they perceive as their important issues.
Look at how badly many of the existing programs treat their install process. Is it any wonder they're installed with all sorts of default security or other important settings? The effort of just getting them running was so complicated that the users just gave up once the rickety beast looked like it was working.
Next take serious stock of what the customer's maintenance of it is going to be like. Make sure there's a good understanding of the disaster recovery scenarios. Document and actually test them. If you're going to push something out the door, you'd better be sure of how it's going to behave in the field.
If you're treating this like a consulting project then a lot of these steps seem less important. After all, the more it breaks the more you can charge for support, right? The truth is somewhere closer to the customers just jumping ship.
Ah, I could go on. The point is there's a lot of really hard work that needs to be done in the sales area. Decide whether that's what you want to do. Without it this has all been just a really cool technical exercise.
-Bill Kearney
[Top]
[Top]
On 3/20/02, Brian Carnell said:
>>I don't believe that charging a lot for the software will work. We
>>don't have a sales or marketing budget. That means we have to
>>build a community, and work with the other developers to "get the
>>word out".
>
>I just wanted to make something clear before giving my $.02. Am I
>correct in thinking that Conversant runs exclusively on Frontier so
>that anyone want to use it or develop within it would first have to
>already have or purchase a Frontier license?
Ah, finally somebody asks the question in a way that I can't squirm out of answering it.
Fine, I'll say it. Conversant also runs on Radio, which is really just Frontier with a different face.
That wasn't so hard after all. I've been dropping hints about that for over a month.
Seth
[Top]
[Top]
Some of us just don't listen too good, then, do we?
So the price (to me) just dropped by $899.
How much does it cost--I'll buy it...
- Sam
[Top]
[Top]
Zope Corporation seems to be thriving on the kind of model you propose (check out http://www.zope.com/ [not .org] for their angle). Ars Digita did and then changed its business plan, and consequently went bust. You can obviously read way too much into that.
One thing that is different about your situation is the $40 entry fee (Radio Userland). However, Radio provides its own rationale and is likely to see lots of investigation, so that may not be a big deal. The question might become how to get people from Radio to Conversant.
I think you have the built-in developer community ready and waiting.
You lose some advantages of Open Source because you're dependent on a third party (Userland) still being around and supporting Frontier.
John VanDyk is absolutely right about support being a black hole if you don't charge for it.
The problem around a support-based model is that there's no incentive to make things easy! If anything there's an incentive to make things complex. I'm beginning to think that Zope is an example of that, but others may differ.
Sales of our software. Support constracts? (How much?) Non-free developers program? (How much?) Hosting services? Consulting services for continuing to improve our software?
I don't believe that charging a lot for the software will work. We don't have a sales or marketing budget. That means we have to build a community, and work with the other developers to "get the word out".
I'm inclined to recommend consulting, support, and hosting as your sources of revenue - although I'm not 100% certain about hosting - you'd have a better idea about that than anyone.
I hope this helps.
David
[Top]
On Tuesday, March 19, 2002, at 11:34 PM, Seth Dillingham wrote:
> My "preferred course of action," as I mentioned above, is to keep the > prices for everything low, and build a developer (and user!) community > around our software.
Understandable, especially from a geek's POV. We always tend to undervalue or work - it's too much fun!
> So how do we make a living? That's the question. > > Sales of our software. Support constracts? (How much?) Non-free > developers program? (How much?) Hosting services? Consulting services > for continuing to improve our software?
Hard for me to say, and easy. Easy in that b/c I'm mostly a hosting client, the other areas do not affect me financially. harder, b/c I'm mostly a hosting client, and I can't tell how these will affect me as a hosting client. But I'll try ;-).
> I don't believe that charging a lot for the software will work. We > don't have a sales or marketing budget. That means we have to build a > community, and work with the other developers to "get the word out".
I don't think these are mutually exclusive. You could release the code to developers in a development-only/non-deployable form, and work with them on it, but still charge when that developer has a client who actually wants to deploy Conversant.
> My friend (or possibly two of them) thinks that we should charge more > for the software, simply because its so good. It's worth it, so charge > for it.
I tend to agree; UserLand makes things tricky because they charge strange prices for their software, ($900/$0/$40?), but most of your clients don't move in those circles (I'm guessing here) so that may not affect you. After seeing Conversant in action I would expect it to run a company, oh, say, $1k-3k. But that's a WAG on my part.
> The point has been made that we'll have to sell quite a few copies of > Conversant at an annual subscription, in order to keep the business > growing. > > I counter with the fact that a higher price makes it a much harder > sell. (In fact, the same friend has told me to both raise the price > *and* do more to cater to the low-end of the customer spectrum.)
Also not mutually exclusive; MR has made great inroads recently into the RU mindshare, with the release of RC/TLS/ASE - users who begin to be (heh) conversant in Conversant from the client/Radio end may be its best evangelists to their corporate masters.
> Thanks for listening. Now I'm listening.
Thanks for asking. ;-)
--Steve
[Top]
On 3/20/02, Steve Ivy said:
>On Tuesday, March 19, 2002, at 11:34 PM, Seth Dillingham wrote:
>
>>My "preferred course of action," as I mentioned above, is to keep
>>the prices for everything low, and build a developer (and user!)
>>community around our software.
>
>Understandable, especially from a geek's POV. We always tend to
>undervalue or work - it's too much fun!
This is my problem with writing so late at night: I lost some of my clarity. When I said, "keep the prices for everything low," I meant the price for the software, not actually "everything."
In other words, the software would be inexpensive, relative to other software in the same space.
>>I don't believe that charging a lot for the software will work. We
>>don't have a sales or marketing budget. That means we have to
>>build a community, and work with the other developers to "get the
>>word out".
>
>I don't think these are mutually exclusive. You could release the
>code to developers in a development-only/non-deployable form, and
>work with them on it, but still charge when that developer has a
>client who actually wants to deploy Conversant.
Yes, that's already part of the plan. The details haven't been worked out yet, but see the license for AttSearchEngine for a clue to what's being planned. (But only a clue.)
>>My friend (or possibly two of them) thinks that we should charge
>>more for the software, simply because its so good. It's worth it,
>>so charge for it.
>
>I tend to agree; UserLand makes things tricky because they charge
>strange prices for their software, ($900/$0/$40?), but most of your
>clients don't move in those circles (I'm guessing here) so that may
>not affect you.
I want clients in all circles. :-)
>After seeing Conversant in action I would expect it to run a >company, oh, say, $1k-3k. But that's a WAG on my part.
Hmm. Thanks, you've given me more to think about.
Seth
[Top]
John vanDyk posted his thoughts on the issues Macrobyte is facing.
First, John said:
The fundamental issue is that support comes at a high developer cost. Seth, you will not be able to keep coding and support users. There must be a mechanism in place for that. If that mechanism involves support contracts, that just means there's money involved. It doesn't change the fundamental reality that when you're doing support, you're not coding.
Yes, this is a given, though it's something I may not think about enough.
What I perhaps didn't make clear is that I want to get back to a team of seven developers, or six developers and a full-time support person.
Also, developer-support would be a lot like sales-support, as a few of the developers that I've spoken to have said that they would like to be resellers/vars.
Support contracts with production installations would be, or will be, one of the revenue streams. If they're priced correctly, they'll a way to support additional staff (see above).
John's second point:
Charge what the software's worth. Don't give it away for less than it's worth if you intend to make a living at it or are trying to saturate a market
Unfortunately, the worth/cost/value of a product is determined by market forces, not by the company that makes or sells the product.
How much can we charge for production licenses to Conversant, without crossing the hard-sell barrier? As soon as that's done, the time involved with each sale goes through the roof.
John's second point:
Marketing. You hate it. I hate it. But it has to happen. Conversant is not currently the talk of the net. It needs to be! You've got a killer application there. Roll it out right.
Blech. Next point. ;-)
No, seriously... I meant what I said about not having a marketing budget. It's just not going to happen, at least in the short term. Something needs to bootstrap Conversant's success, and that first little thread of success is going to have to come from developer adoption.
Okay, last point:
Do PDF documentation (time spent on documentation saves user support issues -- not because they'll read it before contacting you, but because you can zip back an e-mail saying See section 3.1.4. rather than explaining to them what a Resource is)
That's a very good idea. There are other ways to accomplish the same thing. For example, we could deliver a radio-based set of HTML docs for the developers. Then we could just refer to the docs on their own machine, by URL.
PDF might be a better idea.
Of course, this has nothing to do with the pricing issue, but I apprecaite the thought he put into it. Thanks, John
[Top]
I think the key is here. Since Macrobyte developed Conversant, a good guess is that if the "word is out", you might get a lot of contracts to install, support and customise Conversant. There is so much powerful stuff that are free now (HTML::Mason, AXkit, Zope) and a lot of business are just doing that, sell services on Open Source software.
Another solution, but it might turn out as a nightmare, if to have a two tracks development, a free Conversant and paying Conversant Pro that add other values to the package.
But, IMO, the bottom line is just that, choose the best strategies to "get the word out".
Cheers -Emmanuel
[Top]
On 3/20/02, Emmanuel said:
>I think the key is here. Since Macrobyte developed Conversant, a >good guess is that if the "word is out", you might get a lot of >contracts to install, support and customise Conversant. There is so >much powerful stuff that are free now (HTML::Mason, AXkit, Zope) >and a lot of business are just doing that, sell services on Open >Source software.
Yes, there's an awful lot of competition in some of the spaces that Conversant will be slotted into.
>Another solution, but it might turn out as a nightmare, if to have >a two tracks development, a free Conversant and paying Conversant >Pro that add other values to the package.
That certainly sounds like a nightmare.
>But, IMO, the bottom line is just that, choose the best strategies >to "get the word out".
Thanks for your comments, Emmanuel. I hope you'll be ready to take a look in a few weeks. :-)
Seth
[Top]
I face the same problem, as I have indicated to you previously. The Frontier market is small and likely shrinking, IMO that's because Userland doesn't really encourage its developers . I don't see that radio Userland will change that, the strategy that they seems to be pursuing is to go for large volumes sales of Radio. Some simple arithmetic shows that to cover plausible costs the volume of Radio sales would have to be order 10,000/year (actually more). is this plausible? I think not.
So we the developers are left with the prospects of
- increasing Frontier (and maybe Radio) sales despite Userland
- adding a lot of value to Userland s/w. and hoping for the best
Not a great choice, but of the 2 , the second has some chance of working. However, it seems to me that if you sell Conversant as something-like-manila served by Radio, the unit cost of radio sets a limit to what you can charge for Conversant. So even if you think Radio will succeed, its not a smart way to go.
That leaves adding value to Frontier and Manila or Frontier and Conversant or Frontier + XXX. I know Conversant isn't Manila, but it is in the same space. You are essentially competing with Manila. if i comes to a crunch who has the muscle to survive? I have considered a rewrite (that's the XXX option) , but I know the cost, and I know that the synergy I enjoy now, even with all the bad vibes, is worth a lot.
I also think that for all its faults, Manila is a better developer bet than Conversant. If I add features to Manila, it can leverage on all the good parts of Manila - and there are many . Until now I haven't even seen the innards of Conversant, and even if I didn't have reasons to be cautious about doing so, there going to be another learning curve. Looking at things from my p.o.v., what is there about Conversant to make me wish to be a Conversant developer?
Not the message you want to hear, but you did ask.
[Top]
[Top]
Manila, or Conversant, or Zope--all are somewhat limited pools to swim in. But hook into all three, and there may be enough room to paddle.
- Sam
[Top]
Of course, so far, I (almost) have one contract. And out of concern for the mortgage, I deliberately underbid it. And now the (almost) client is talking about a larger followup project for 4X the work at 4X [not the necessary 10X!] the money.
The way I see it is this: I may not get enough contracts to pay the bills and keep the house if I charge what I think I need and am worth; but I certainly won't make the bills, regardless of how much I work, if I don't.
My "preferred course of action," as I mentioned above, is to keep the prices low for everything (the software), and build a developer (and user!) community around our software.
From the point of view of someone who'd like to sell clients on your software, and on solutions built atop your software, I like this approach. But I have some notion of how much it actually costs to develop software, and you have to either pay the bills or find another line of work.
Of course, not knowing what you charge now (or plan to charge), I don't know what your idea of "low prices" is. And I haven't spent much time with Conversant, to find out what it's actually worth to me, or might be worth to a client.
Anyway, I hope this ramble is of some help.
- Sam
[Top]
1. Hosting is evil. Maybe that's just me. But people expect hosting to be very low cost if not free and they expect performance and uptime and quick response to trouble (or perceived trouble).
When you're hosting you're also answering people's questions about the software -- How do I?... kind of questions. So you can't do hosting without software support.
It seems to me that people (in general) don't value a CMS when they can't see it. If they interact with it only via the Web, they sort of assume that it must be very cheap to run. It's not, of course.
2. That Conversant runs in Radio is of huge importance. That means people only need $40 for the platform. Excellent.
But you run into this serious issue -- you're competing with two UserLand CMSes, not just one. Radio contains a CMS. And of course UserLand wants people to buy Manila/Frontier.
With such a small community, having the support of UserLand is important. What would selling Conversant for Radio do to your relationship with UserLand? I won't guess, but if I were you I'd probably want to have a good idea in advance.
3. The Zope guys had funding. If I recall correctly, it was their VCs that convinced them to open-source Zope.
4. When attracting developers, consider in advance how you'll answer the following questions that might reasonably be asked:
a. Can I write in Perl/Python/Java -- some language I know already?
b. Does the database support transactions?
c. Why tie up my data in a proprietary database format?
d. Why use a database that doesn't understand SQL? SQL is totally a standard.
e. Ummmmm, Linux?
f. Can I run it behind Apache?
g. Is the SAX API available? I'm a SAX fan.
h. My boss says we have to do XSLT. Does it do XSLT?
i. How many connections/second can it handle?
j. Are you going to disappear? Is UserLand going to disapper?
k. Why should we pay anything at all when the stuff from the Apache group (or whatever) is so damn good?
l. Does it import from Quark?
m. Can I create PDFs from my Conversant websites?
n. Does it do document management, not just content management? In other words, everyone at the office writes in Word, and we want to serve those files and be able to discuss them. We want the Word docs to be readable as HTML in a Web browser.
o. Isn't Manila easier to use for the novice? We have a bunch of less-than-savvy folks here at the office.
p. Would you consider changing the name to something sexier so I can convince my boss to buy it? He would like "Vignette StoryServer" as a name better than "Macrobyte Conversant."
q. What the hell's the difference between an "object database" and an "object-oriented database" and which do you use?
[Top]
[Top]
On 3/20/02, Brent Simmons said:
>1. Hosting is evil. Maybe that's just me. But people expect hosting >to be very low cost if not free and they expect performance and >uptime and quick response to trouble (or perceived trouble). > >When you're hosting you're also answering people's questions about >the software -- How do I?... kind of questions. So you can't do >hosting without software support. > >It seems to me that people (in general) don't value a CMS when they >can't see it. If they interact with it only via the Web, they sort >of assume that it must be very cheap to run. It's not, of course.
We're doing a lot of hosting already... some people haven't been paying attention to us, I know, but we have a number of servers all running paid Conversant sites, hosted at Macrobyte.
>2. That Conversant runs in Radio is of huge importance. That means >people only need $40 for the platform. Excellent. > >But you run into this serious issue -- you're competing with two >UserLand CMSes, not just one. Radio contains a CMS. And of course >UserLand wants people to buy Manila/Frontier. > >With such a small community, having the support of UserLand is >important. What would selling Conversant for Radio do to your >relationship with UserLand? I won't guess, but if I were you I'd >probably want to have a good idea in advance.
I agree that this could be a problem.
However, Dave already knows, and he didn't seem to upset about.
>3. The Zope guys had funding. If I recall correctly, it was their >VCs that convinced them to open-source Zope.
That definitely fits the "random comment" description. ;-)
>4. When attracting developers, consider in advance how you'll >answer the following questions that might reasonably be asked:
First, please understand that the developers we're trying to attract, first, are Frontier developers like you, Emmanuel, Sam Taylor, Bill Kearney, David Bayly, Jim Roepcke, etc., etc.
>a. Can I write in Perl/Python/Java -- some language I know already?
You could certainly write plugins which uses those languages, yes, but they'd have to be called by something written in UserTalk, via COM, AppleEvents, or TCP.
>b. Does the database support transactions?
Depends on which database you're using.
>c. Why tie up my data in a proprietary database format?
So don't, use mySQL, MS SQL, Oracle, PostGRES, or text files in the file system, if you want to. Conversant doesn't mind.
I told you this already, but I guess you forgot.
>d. Why use a database that doesn't understand SQL? SQL is totally a >standard.
I happen to agree. So, use a SQL database, that's fine.
>e. Ummmmm, Linux?
Nope.
>f. Can I run it behind Apache?
Not at the moment, so, no.
>g. Is the SAX API available? I'm a SAX fan.
Not yet, so, no. Plugin! Somebody write a plugin!
>h. My boss says we have to do XSLT. Does it do XSLT?
Sounds like a good idea for a plugin.
>i. How many connections/second can it handle?
Yeah, I've been faced with that one before.
>j. Are you going to disappear? Is UserLand going to disapper?
No. (I really hate that question. Last year a customer was partnering with another company, and they decided to use someone else's services because Macrobyte might not be around in a year. We're still here, the "bigger company" they went with isn't.)
>k. Why should we pay anything at all when the stuff from the Apache >group (or whatever) is so damn good?
Because the stuff from Macrobyte is that good.
>l. Does it import from Quark?
Sounds like a plugin.
>m. Can I create PDFs from my Conversant websites?
Sounds like a plugin.
>n. Does it do document management, not just content management? In >other words, everyone at the office writes in Word, and we want to >serve those files and be able to discuss them. We want the Word >docs to be readable as HTML in a Web browser.
Actually, we started on a plugin for that, but never got there. So the answer is no, but it's a plugin which I know could be written.
>o. Isn't Manila easier to use for the novice? We have a bunch of >less-than-savvy folks here at the office.
Nope. It might be at the moment, but we're working on that and I'm hoping it'll be at least partially solved by the time Conversant is released.
>p. Would you consider changing the name to something sexier so I >can convince my boss to buy it? He would like "Vignette >StoryServer" as a name better than "Macrobyte Conversant."
Sure, we'll do up a special version for you with whatever name you want, and we'll be happy to give you a break on the cost compared to that other Vignette StoryTeller, too.
>q. What the hell's the difference between an "object database" and >an "object-oriented database" and which do you use?
The ones are all the same, but the zeros are rounder in object-oriented databases than they are in object databases, because the former have more "oh's" in the name.
Seth
[Top]
[Top]
Jim said:
>I've been evaluating Conversant at work, and I've already managed to >create a simple plugin that extends Conversant's power in my direction
Bad Jim. I believe we agreed that you wouldn't share that fact with anybody. I appreciate what you've said, but I'm afraid you're going to have to be punished.
As Bill Cosby's father used to say, "Go get me something to beat you with!"
[Top]
[Top]
Of course, I think the whole Conversant package should ultimatley be ported to Java using something like WebObjects. That has lots of advantages and brings freedom in ways that currently don't exist. :-)
Don
[Top]
André is working on that.
Yesterday, I started working on such a DLL for Frontier (and Radio) based on the Gnome project's libxml2 and libxslt libraries. Earlier today, I managed to apply an XSL stylesheet to an XML document from inside Frontier for the first time.
<http://www.spicynoodles.net/2002/03/21.html>
Cheers
-Emmanuel
[Top]
[Top]
On 3/21/02, Duncan Smeed said:
>Perhaps a sliding (upward) scale of subscription for self-hosted >(ISP) sites that resell their Conversant cycles.
This has been suggested a number of times.
The nature of Frontier-based scripts is that they're very difficult to put "controls" on, as I'm sure you know. So, we'll either have to dependon on the honesty of the users, or do something difficult and awkward.
I prefer the former.
Regardless of which approach we take, the sliding-scale issue fits with the plan to get the software into the hands of the developers very cheaply, and charge more for production servers. I think this is going to happen.
>I think some form of educational discount would be a very good idea >- but then I'd say that wouldn't I?
Though nobody else from Macrobyte responded to this comment, I think a few probably smiled or nodded their heads in agreement. This was already decided, and in fact I'd like to really support the educators.
>>So how do we make a living? That's the question.
>>
>>Sales of our software. Support constracts? (How much?) Non-free
>>developers program? (How much?) Hosting services? Consulting
>>services for continuing to improve our software?
>
>I suppose some of this depends on the overheads of keeping
>Conversant going on on your own server rather than hosted with
>you. I have no idea how much babysitting Conversant requires for
>example. Since it's built on Frontier/Radio you have both the
>advantages and disadvantages of that particular platform.
Very little babysitting, but of course that depends on what else you have "going on" with your server.
>Does Digital Creations, for instance, actually make money with Zope >consultation now they've 'open-sourced' Zope?
I don't think there's any way to get an honest answer to that question.
>Can Conversant 'compete' in the same space as >Radio/RCS/Frontier/Manila?
First of all, I truly believe that those are all very different products and in very different spaces.
We don't compete with Frontier or Radio. Well, I suppose if you were considering Conversant-the-groupware-platform for ONLY a personal weblog running on your own server then it might compete... but that's a bit like swatting flies with bazookas. If you ONLY want to do one thing, there are always tools for doing exactly that one thing.
RCS? I'll comment on that below.
Manila? Yes, it's true, we compete with Manila. I don't like that fact, but people view us as living in the same space and that's all that matters.
Hopefully that'll change when the developers get a chance to look at the code and start developing more specialized applications in Conversant.
>There's no doubt that Macrobyte (and friends) have an excellent >reputation for support and responsiveness to user requests. Can >this be scaled and still maintain that excellent reputation. I >doubt it unless a supportive community develops. Perhaps that >community is Script Meridian?
Perhaps.
>You may recall a private e-mail I sent some months ago in which I >questioned the long-term viability of UserTalk and other Userland >proprietary technologies. To a great exten that's been resolved by >the Userland and their aggressive push based on the $0 RCS (and the >pricing of Radio). > >Rather ironically, it's the $0 mindbombshell that looks likely to >do most collateral damage to Conversant's prospects.
I disagree about RCS, but not Radio.
Radio's been a huge boost to the UserTalk community.
What has RCS done? Fine, it just came out this week, but it doesn't have nearly the buzz that Radio has/had. Why is that? Has anyone looked at what it actually does?
1. It replicates an FTP server
2. It provides notification features, hit tracking, logging,
bottlenecking, etc.
It installs very easily and is very simple to run, but does it do much more than what I've listed? No. It doesn't provide any sort of groupware functionality, at least nothing in the traditional sense of groupware.
On the other hand, I *like* RCS, for the same reasons that I like Radio. It does just a few things, and it does them very well and is very easy to use. But it's not a developer's tool, and it's not groupware.
I can imagine scenarios where we'll either recommend running RCS on the same server as Conversant, or where an RCS-like plugin would be a good feature to have on a Conversant server. (The latter has some very interesting possibilities for deeply integrating Radio with Conversant.)
>If I interpret correctly what you've said elsewhere, you are less >reliant on some of these technologies than we might imagine. Some >sort of exit/port strategy would be good insurance - both for >Macrobyte and its customers.
We've kicked around porting Conversant to JSP or WO a number of times, but there's still so much we can do with it on UserTalk. We still haven't implemented a caching engine or static rendering, for example... both of those ideas *really* get me excited. I have to stop thinking about them or I won't get any of the short term work done.
Plus... I love Frontier. It's true, I do. I love the community, too, and I want to help it succeed. UserLand doesn't work directly with the developer community very much, but I think that it should be possible for the developer community to work with itself, if it has some more great products to work with.
People often ask me what we'll do if UserLand shuts down or Dave Winer decides one day to just close up shop. Well, first of all, it's not like Frontier will stop working if that happens. We'd have time to do a port to another platform. But I don't think it's going to happen. UserLand has been at this for a long time now, and while Dave's direction isn't always clear, he's never indicated that he would abandon his life's work.
>Does/can Conversant compete with and/or augment Manila/RCS?
Compete? Uh, yes.
Augment Manila? Not really, no... it's like asking if one car can augment another.
Can it augment RCS? Other than providing the comments feature, I can't imagine how. The other way around, definitely.
>Would you want it to? As has already been pointed in other >replies, the pricing of Radio and RCS places constraints on the >pricing of Conversant. But these questions aren't helpful to you. >I'm sorry for digressing....
Actually, I would say that it REMOVES constraints on the pricing. Radio is very inexpensive, essentially free, so that means that the cost of Conversant is just the cost of Conversant, not Conversant + the scripting engine.
[SNIP]
>How Conversant fits into a developer's portfolio is an interesting, >and thorny, question. I don't know, not being a developer, but here >are some suggestions:
I'm not sure why you said it's a thorny issue.
>* Developers adopt Conversant as their primary support tool to >support bug-tracking, feature-requests, internal team coordination, >documentation, etc. Any developer worth their salt will be able to >host their own Conversant site(s).
Any developer with a server. If server == salt, then I agree.
It sound slike you're talking about project-based extranets, which is definitely one of our primary uses.
>* Introduce some sort of sliding scale price structure that
[SNIP]
> Like your appraoch to hosting options for instance.
Good idea.
>* Create some typical support site type templates. Make it a >no-brainer choice for small developers. Conversant can be tailored >to create great looking support sites with lots of options. The >thing I value most about Conversant is how it saves my time. That's >my most precious commodity. Offer to work with some developers to >create these time-saving features.
I think you might be looking at the wrong picture. When I say that we want to build a community of developers around the software, I don't mean that I want them to be the (only) end-users. Rather, the developers will do what they do now: create solutions for their clients. Conversant will be another big tool in their toolbox.
[SNIP]
>Other suggestions: > >* Try to consolidate the Conversant documentation into a manual/PDF >format. Encourage existing Conversanters to write up their >experience and produce some case studies that can be used to 'sell' >Conversant. Some have already done this. Others, like me, have >been full of good intentions but need "go fetch a stick" ;-)
The PDF docs are definitely needed. There's at least one case-study in the works already, although the case still needs to answer a few questions. ;-)
>* Write some white papers about the architecture of Conversant and >how/where developers may tailor it to their own devices and >incorporate it into their own work-flows. Push the XML-RPC >interoperability angle.
Definitely, but thank you for pointing out this need.
>* Update the home page of www.macrobyte.net ;-) At the moment it >doesn't look like you eat you own dogfood there!
That's finally in progress. We've been razzed about this so much in the last month it's not even funny.
Frankly, I often forget about the macrobyte.net web site.
Having that site updated will give me a place to talk about the business, finally, and this site can go back to being my personal home page. It feels very weird to talk so much about Macrobyte, here.
[SNIP]
>* Have a story/plan of how Conversant might interplay/support >Radio-generated sites, and provide discussion capabilities. A >tricky one this since it competes in the same space as RCS/Manila.
RCS doesn't offer any discussion capabilities. Manila only offers Radio a place for comments.
Thanks for your thoughts, Duncan, and I'm sorry it took me a couple days to make the time for this response!
Seth
[Top]
[Top]
[Top]
[Top]
Daniel Berlinger responded to my questions about Macrobyte's future, on his site. This is my response.
>He'd like to keep the cost of his software "low" and build a >community of developers and users around it. If this is the case >then it is a consulting company he's building and software >sales, and developer support, are income streams alongside of >his client work. (There's still a balance to achieve, but >still.)
That's essentially the wording that I've used internally, but switched around. Quoting from something I posted to Macrobyte's intenal list, "The perfect situation, in my opinion, would be a slow-but-steady flow of software sales to provide the bottom end of Macrobyte's income scale, with custom development and consulting work provding the high end." Of course that omits support contracts and hosting fees. I'd slot hosting fees into the bottom end, with software sales, and support contracts at the top with consulting.
>I'm not sure that this is what he wants. I get the impression >(and this a weak stab considering my impression is over the >internet) he'd prefer to be a software developer.
Well, not really, no. Consulting is what Macrobyte is all about. Conversant was written to be a consultant's/developer's tool, something that can be easily customized for any situation.
[SNIP]
>There's other possible revenue streams even if you are a >developer... you can employ your own software and host the >resulting services for end users even as you sell the product >to var's and developers.
Yes, we're already doing that, and would like to do more of it.
[SNIP]
>Each of these has different support requirements. End user >support (even for the most excellent of products) requires >patience. Understand that there's a lot of venting and rage that >gets loaded onto support people that has nothing to do with your >product or your level of service.
See the earlier comments by Jim, Greg, and Brian Andresen on Macrobyte's technical support. This is something that I think the developers are really going to like about working with us. Some of us, myself include, actually enjoy helping other people code almost as much as we enjoy writing our own code.
Yes, we'll be dealing with a lot more than just developers. There will be users... like Brian Carnell, for example, whose Conversant-based sites currently have about 50,000 pages and who has asked a different question or made a different feature request for almost every one of them.
(Just teasing, Brian!)
>Dealing with professionals has a different tone, but there's the >clock ticking, "I've got my own clients to satisfy" tumult of >professional "I rely on you" pressure. Macrobyte might be more >or less suited to one or the other of these.
I hope the developers/professionals will give us the benefit of the doubt and see what we can do.
>So I think the first question is, what business do you prefer to >be in? What style suits you best? What would you rather do given >the choice?
Hopefully, this has now been answered.
>These dilemmas are close to my heart right now. I've been a >consultant for a long time, interspersed with attempts to find >the right company and working for them full time. The last job >ended back in October. And after taking some time to rest and >regroup, I started thinking about what I'd like to do. > >I've thought about all these things as I burn through my >savings...
Yeah, I know what that feels like.
>I've also been working on my own software and considering the >various ways it could be sold. On its own, bundled with site >software/hosting, through the folks who create server software >(ahem). All of the above?
That's very interesting. Of course, in order to bundle it with a piece of server software, it should inter-operate with that software very well. I know you've started working on that.
>Joel of JoelOnSoftware has also talked a little about this. >About how his company and been doing consulting work to pay >bills while the software business gets going... but that they >expect to be in the software business, not the consulting >business.
I'm hoping for something like a 30/70 split in favor of consulting. Enough sales to justify the product's continuation, and enough consulting to pay for lots of improvements and additions to the software.
Thanks Daniel!
Seth
[Top]
Second, sell the base software at a very decent and affordable price. This will build the proper community.
Third, license the advanced stuff on a yearly basis, or propose a sale + 20% maintenance/year. For example, you could license at $1000/year, but sell at $2000 + $400/year. This will allow those who want to own the software to pay for it and choose whether or not they want upgrades later on, and will let those who are on a cash-flow bind to license it yearly and defer some of the costs. Of course the dollar amounts I threw in are just to illustrate my point, they have nothing to do with a potential price point for any of the Macrobyte software.
Finally, one last point to remember is that once the software is created, the profit margin on any additional sale is close to 100%. So it's very important to gage the potential total market (number of Userland clients for example) and try to calculate penetration percentage at different price points, then see what total max revenue can be made. And following on what I said earlier about getting hooked on the software, if it has very high swiching costs (due to unique features for example), then the bait-and-hook strategy of first-year at 50% discount or whatnots works very well.
Henri.
[Top]
Truly, if any technology is to go beyond workgroup stuff and into the great wide yonder, you have to ditch UserTalk in some way or another (i.e. use SQL stored procedures, DLLs, Perl/Python RPC, etc..), otherwise you'll quickly alienate the heavy-duty developers who want to take your platform into the realm of StoryServer and others (not that StoryServer is good, it totally sucks but it's made for big sites).
Not knowing Conversant but knowing that the folks at Macrobyte are talented and good Software Architects (capital "A"), I think there's a market for a solid, extensible, based-on-standards CMS system in the <$100,000 range that will scale infintely. That would eat up Vignette's market, especially now that companies are on a budget and have seen the FUD of those large companies.
And don't go telling me that for example $80,000 is a lot, it's barely the price of a fully-burdened regular programmer for a year.
H
[Top]
And don't go telling me that for example $80,000 is a lot...
Yes, the corporate mindset is far different from consumer/user mindsets.
When I was consulting in BigCo's, a product priced "cheaply" (Mac hardware/software) was frowned upon in favor of high-priced products (min-computer stuff). Instead of arguing with consultant logic 15 years ago in such circumstances, I should have become a VAR and make huge profits in the markup by selling the cheaper products at corporate prices. ;-)
"Perspective is more important than reality." A wise and painful lesson learned by me at A.T. Kearney in years gone bye...
Don
[Top]
[Top]
On 3/21/02, Jim Roepcke said:
>> And don't go telling me that for example $80,000 is a lot, it's barely
>> the price of a fully-burdened regular programmer for a year.
>
>I like Henri. :-) Preach the reality!
That's an immensely more difficult market to break into.
That $80,000 is also a lot less than the salaries that would be required for the team of sales people we'd need.
Not going to happen. I don't want a product that costs that much.
Seth
[Top]
[Top]
Not going to happen. I don't want a product that costs that much.
Okay, at some point I may want to be an VAR/OEM for Conversant Suite of Tools from Macrobyte Resources. ;-)
Don
[Top]
I think you're heading in the right direction. Yes the "apps" you guys have developed are worth a lot, but it looks like they are being used by developers as frameworks/platforms/enablers to allow them to develop custom solutions. That means that you are selling tools, and trying to build a community. I know of no better way to start building that community then by giving away the tools.
I think you should definitely look into charging something to be a "Conversant Developer", at least for those people not in Edu/non-profit. Maybe you could offer a "charter membership" rate for those developers that sign up early, and then a normal rate after some level has been reached. Or something like that.
-Brian
[Top]
About a year ago, I was looking for an intranet CMS for our company. I wanted weblog/calendar functionality, in-the-browser editing, and a discussion group. I had a hard time figuring out exactly what Frontier, Manila, and Conversant each did, their relationship to each other, and what they were each good for. The whole hairball (now with Radio and RCS) is difficult to get your arms around. It's part of the nature of the "do everything tool", and platforms like Zope have the same difficulty, but there's definitely room to craft a description & graceful introduction for each of these systems!
Ultimately, I thought that Manila gave me the 3 features I needed (calendar, editing, discussion group), and I didn't see that adding a 3rd party product (Conversant) was going to add anything. I also wanted behind-the-firewall functionality, not a hosted solution.
We messed around with Frontier & Manila for weeks, customizing the code for our intranet needs. We even took a Frontier class. We always had performance problems, and after mucking around for weeks, it became apparent that Dave @ Userland was off in a different direction (with what became Radio), and that he was not interested in continuing to develop and support what we needed -- a low-cost intranet CMS solution. As a fellow software developer, Dave's daily software update cycle and cavalier attitude towards planning frightened me. We eventually abandoned the work.
So a vendor who (1) had a clear vision of what kind of product they were making and (2) was more regular about support/updates than userland is what would appeal to me.
So here's my advice. It's worth what you paid for it:
Package up the 9 different products into one. Give it a single useful benefit, even if it's still a toolkit that's harder to describe than an app. I have no idea what that would be -- makes Radio development faster, makes it more robust, makes it easier to use, better UI, gives you the out-of-the-box functionality to do bug tracking or sales pipeline management or whatever's appropriate. Market it to Userland/Radio users as some super duper useful add-on of some sort, and market it to normal people just for the functionality, and make Frontier optional.
As a final note, good guerilla marketing doesn't take a lot of money. It takes very clearly explaining what your product is good for, and making it deep and useful and fun to use. Most software companies have a very hard time describing what they do. If you're doing something new, it's hard. We've been at it for three years and are still making our product description clearer.
Good luck!
John Troyer
Neomar
[Top]
<- Previous Thread:
RCSearch
Next Thread: ->
ORBZ: Good Riddance, Now Who's Next?
Until August 31
My Amazon sales
benefit the PMC
Apr 1 - Aug 31
Ad revenue
benefits the PMC
|
TruerWords
is Seth Dillingham's personal web site. More than the sum of my parts. |
