[Manifold-l] Manifold reference clients

[Dimitri Rotow]

> I had been thinking - a year ago - that Manifold was really 
> retreating into a silo-like data formatting mentality, and 

More an undesired side effect of expanding technology. If you do a lot and
want to put a lot of different things (vectors, rasters, surfaces, scripts,
comments, queries, themes, etc, etc) you end up storing things that are
specific to one package.   Everyone knows the the line about the road to
you-know-where being paved with good intentions.  People want to build a
safe and convenient storage space for data and they end up building a silo.

Even going to a neutral format for vector storage, formatting and
projections doesn't solve the whole thing.  But it is a step in the right
direction.    We have an idea how to solve the ultimate requirement, to
really open things up, and are working to make that happen.

> 
> Back to the matter of its being an illuminating post: how 
> about formalizing this sort of thing into a "roadmap" of 
> where Manifold is heading? I really cannot see that you need 

A statement like in that post, for example, about our objective being
neutrality and transparency, is as far as we go.  We hope to provide
accurate, exact information you can take to the bank, and that is best done
by looking at actual deliverables and not trusting to hoped-for futures.

I've seen a lot of "roadmaps" over the years and they tend to be even
semi-accurate only very close in, say, six months before what is described
is supposed to be delivered.  I've yet to see a roadmap where what ended up
being delivered was exactly what was promised, even if the promise was only
for six months out.  There have always been significant differences in the
actual deliverables.

Given that a roadmap is only even remotely accurate, say, within six months,
what do you lose by waiting six months to see what actually happens?
Nothing.  You can still do whatever it is you wanted to do, you can still
make whatever decisions needed to be made.  You're just making them six
months later.   

OK... so the other question is, do you gain anything by waiting to see what
actually happens?

Yes, you gain a lot, because you completely eliminate any guesswork.  No
spinning wheels, no wasted time designing to a hoped-for spec that doesn't
materialize or does so in a way that involves significant re-writes or
disappoints you because it is not exactly what you expected.  In fact,
although I'm not claiming this on the basis of a scientific study, my gut
feel is that the adjustments necessary in coding projects to shift gears
based on changes in the actual deliverable as opposed to what was promised
in a roadmap will often use up a significant part of a six month time span.
In reality, I bet that waiting to see what actually happens might not delay
a deployment by much and in some cases might actually accelerate it.

Let's consider the case where someone is interested in a roadmap not because
they intend to write code on speculation that the roadmap will actually get
done, but instead is interested in a roadmap more to guide corporate
procurement decisions. For example, "I'm leaning towards Manifold but I
really need 64 bits so if I'm assured that will happen in the next six
months I will buy Manifold." In that case as well there is no significant
downside to waiting six months to see what actually happens.

You may say, "Well, here is a customer who would buy the product if they
only knew that six months from now there would be feature A or feature B."
I say, no problem.  They should make their buy decision on what is in the
product today.  If what is there today is not good enough for them they
should buy something else.  

It is very important to understand there is no net loss of business because
six months before today there were people who might have not been interested
in buying Manifold unless it had a particular feature that is here today but
was not here six months ago.  For example, there are lots of people buying
Manifold today because it has 64-bit code who would not have bought the
product if they had decided to buy a GIS six months ago because it did not
have 64-bit code.  When they come into the market today they see Manifold
has 64-bit code and so they buy.

The sales strategy of using roadmaps to attempt to time-shift future sales
into present purchases is highly risky business both for customer and for
the vendor.  The risks for a customer are obvious, as they don't call it
"vaporware" for nothing. But it is very risky for a vendor as well.

The biggest risk is that making present promises about future work ends up
preventing the vendor from making the best possible product.  Just like from
the customer side the information becomes better the closer you get to a
hoped-for release date of a long-awaited promise, just so on the vendor side
the closer you get to a release date the more you know about that release.
This is often forgotten but it is critically important for truly efficient
development.

It is important to retain the freedom to make the best possible product
using the best information at hand.  During the course of a one or two year
new technology campaign we'll learn a lot of things we didn't know, there
will be a lot of results from experiments to produce true facts to replace
initial conjectures, the industry will change, the technology choices of our
partners will change and the desires of our customers will change.   And
along the way if you are really running a flat organization with a lot of
responsibility and authority distributed out to a talented engineering staff
there will arise previously undreamed-of opportunities that once seen will
be immediately recognized as taking top priority.

A typical build cycle for Manifold involves consideration of around 5000
wishlist items.  These get selected into about 750 candidate items for the
new release.  From those 750 candidates about 150 targets are named.
Those 150 targets tend to end up expanding into about 600 different specific
engineering tasks, which ends up about the same number of items listed in
the release notes.  

What's interesting about those 150 targets is that they are targets, not
committed promises.  They are not promises to ourselves or anyone else even
though internally we use them to guide the release.  At the time the build
cycle gets launched they are our working objectives, always subject to
revision.  It turns out we will end up doing about 150 targets in a build,
but about 50 of those end up being different than what was in the original
list.  That happens because during the build cycle some stuff originally
thought necessary is seen to be unnecessary, new and better ideas replace
old ideas and so on.

Given that we don't want to make promises we don't keep, we do not want to
get on the hook for doing something less optimal than what could be because
we promised it to someone way back in the beginning of the cycle.  It's just
not an efficient way of doing engineering.  Better to work to do our best,
retain flexibility and deliver an optimized, integrated new release that
people can look at and see in a concrete way exactly what it does or does
not do for them.

And the risks are more than simple loss of inoptimality.  I've been inside
companies where even the best-intentioned "roadmap" promises ended up
involving something that just did not make sense as time went on but
nonetheless ended up causing total chaos as the company tried to make good
on the promised roadmap.  What usually ends up happening in such situations,
after a vast waste of money, resources and morale for both vendor and
customer, is the result satisfies no one and the price is months or years of
wasted opportunity cost that could have been better used for more effective
product that made more people happier.

All those problems are easily avoided by basing procurement decisions on
actual delivered product instead of on forecasts.   I grant you there are
cases where promises have been made and deliverables done on time as
everyone expected.  But that is not usually the rule when we're talking
complex technology in rapidly-changing businesses with predictions made a
year or two out.  And if it is only six months out I say the discipline of
looking at what is real today doesn't lose you anything in the big scheme of
things while it does gain both vendor and customers a lot. 

> divulge commercially sensitive information, and I doubt if 
> Manifold would be accused of promulgating "blue sky" - 
> Manifold (the company) delivers, and that's a fact. 
> 

That's a true compliment and it's welcomed.  But one reason people Manifold
has a reputation for delivering on promises is because we load the dice in
our favor - we only make promises about those things that have already been
done.  :-)  I believe it is Niels Bohr who said, "Making predictions is a
risky business, especially about the future!"  So much easier and more
accurate to make predictions about the past. 

I do agree that some statement of future intent is good to reveal what a
company's aspirations are, so that one can get a sense of the company's
corporate culture and general intentions.  In that respect, manifold.net has
made some statements of broad intent, albeit few and very broad.  None of
the following are guarantees.  It is all statements of aspirations with no
timelines.  Could happen now, or in ten years, or never:

1. We will focus on Microsoft technologies, standard Microsoft languages and
standard Windows releases.

2. We think there is a big role for desktop software and we don't intend to
abandon desktops to chase a "net PC" dream working exclusively over
Internet. 

3. We nonetheless believe in Internet as a way of delivering publication (as
in image servers), interactive IMS, updates and the like.

4. We strongly support .NET and will do all in our power to assure that
Manifold becomes entirely managed code and seamlessly works with .NET in all
instances.

5. We believe in vendor-neutral interchange if it can be achieved in a
practical way.  We like Oracle Spatial for that and don't like GML for that.

6. We want to support Oracle Spatial in a totally transparent way. 

7. Manifold wants no limitations on size of local projects, either in
capacity or display/rendering restrictions.

8. We want to evolve our product into not just being the most powerful but
known first for being the fastest as well as being the most powerful.

9. We believe in 64-bits, multicore processors and multiprocessing.

10. We want to drive prices lower, not higher.

11. We want to make sure everything within Manifold can be reached through
the API either for programming or for IMS applications.

12. We want to expand the programmability of Manifold with continued better
features for applications developers and taking IMS totally into the .NET
world.

13. Sooner or later, most likely later, we'll have a technology solution for
Manifold in languages other than English.

14. We don't see any artificial borders between GIS and CAD and graphics
arts editing, etc.  So we expect to keep moving Manifold forward until you
won't need things like AutoCAD or Illustrator.

15. From a business perspective we will continue to focus everything on the
product, on making the technical wishlists of our users come true.  We are
here to build your dream GIS, to make it as easy to use, as powerful and as
inexpensive as humanly possible.

16. From a marketing perspective, we won't rest until we eliminate ESRI and
other GIS competitors from GIS desktop and GIS enterprise markets.  Whatever
it takes, however many features, however low price, however great capacity
and speed and power, that's what we will do.

There's probably more than the above, but I think that's about what has been
suggested as a broad roadmap.  It's certainly plenty enough to keep a
company busy. :-)

Cheers,

Dimitri