> Again to combat this we just need additional developer/s so that we
> can dedicate one to maintenance and the other/s to innovation.
So you have a single developer who is working full-time on the
product, and the maintenance of the product takes an entire
person-day? Like on every given day, you spend the whole day making
sure the existing feature set works with the then-current version of
IMail and SmarterMail?
Dunno, man, I think some of Andy's comments about the rate of
development of new features sound more plausible. Uncomfortable though
it is to point fingers at other developers, the bottom line is that
you seem like *less* than a one-man-show. And even a
part-time-one-man-show setup might be perfectly fine! But the obvious
presence of other management "players" that make it seem a lot less
pure. I would guess that a lot of us knowingly put our faith in
one-man-shows (I will proudly come out as a user of CrushFTP, which is
blatantly supported by one guy, Ben -- but he throws his life into it
as Scott once did, for better or worse), because we want people to
have that same faith in our small companies. But everything needs to
be up front.
> Yes that community was (and what is left) is extremely helpful and useful.
I can speak as someone who verrrrry lightly supports Declude at one
distant customer at this point (like, an hour per 6 months), but who
once was very active here. Once Declude decided it was going to go
"big-time" without building a GUI configurator, I knew this wouldn't
work. It is that very strange class of Windows-based product that
is/was loved by the most technical fringe of the Windows/SMTP
community for its flexibility, though it sometimes seemed to have
opacity just short of Sendmail macros! But once you stop building
features, knowing the secret world isn't fun anymore. There were just
so many misapprehensions about the promise of the product at the point
that you went corporate that I felt it was all downhill. An ex-partner
of mine once whined, "Why can't *we* be a giant software company?"
"Because," I said, "there are two of us working [then] on a product to
sell to maybe 200 people."
> time. But if I should speak for myself. I realize I can't make everyone
> happy its part of my job. Here is a case in point, let's use this scenario.
> 1. AVG fails
> 2. IMail release version 11 which is incompatible with Declude
This is an incomplete scenario by a long shot. How many person-hours
must be committed for each fix? Do you find out about IMail
incompatibility in a pre-release beta version, before anyone can
reasonably squawk about 0day incompatibility?
> If I choose to fix AVG first - IMail users scream
If you found about a non-working antivirus _in production_, but
non-working IMail _in beta_, there is no choice!
Also, it would appear that non-working AV is not only more urgent in
its own right, but would affect ALL users -- so this is really bad
example for your viewpoint.
> The only thing that would change this current situation is revenues which
> means price increase. (Maybe it is time?)
Maybe it is time to
[a] dissolve the company as is
[b] sell the product to a developer
[c] (re)package it as an owner-maintained, purpose-built software tool
[d] build up from there as needed
I would hope there is enough revenue to keep a single developer
supported at an industry-standard income + do some marketing. I mean,
not every product is meant to beat the world financially. Some
products just are destined to lead technically.
This E-mail came from the Declude.Virus mailing list. To
unsubscribe, just send an E-mail to imail...@declude.com, and
type "unsubscribe Declude.Virus". The archives can be found