Subversion Repositories tendra.SVN

Target Audience
===============

This document provides an overview of which target audience is
currently appropriate, how it conveniently works to our advantage, and
how we plan to increase our appeal in that area.


Demographics
------------

Currently the only point of interest is development. The product is not
ready for general use for many reasons (not least of which is having an
outdated implementations of standards). Hence it would appeal only to
niche demographics at best.

The general user is currently better served by other compilers, as they
provide mature and stable tools.

For the near to mid future, mostly owing to our small number of
developers and limited time with which to apply ourselves to the
project, we cannot compete with the maturity of the other compilers
(most notably the gcc) in either features or stability.

However, we have an advantage in our small size, in both response to
individual requests, and accessibility of our code base. TenDRA has
a beautiful, clear structure, which is unusually understandable for
a C compiler. This alone attracts people for whom "working" is not the
only thing that matters. The project is founded on the patient,
long-term investments in thought that these people bring.

Right now, we need all the help we can get. As our target audience is
not the general user, this leaves only niche groups. By the very nature
of the implementation and design both being beautiful to behold, we
are well-set to attract these people: this niche is developers.

Having only developers interested in the project also works to our
advantage: it relieves the pressure of maintaining a stable branch - we
simply do not have the resources to do that.

See also donations, for a discussion on putting money to use at
attracting developers.


Increasing Appeal
-----------------

So, our goal for appeal in the near future is to attract this specific
type of developer. I believe this is best done by making our products
applicable to their own projects.

On the assumption that they are not re-implementing wheels, their
projects will have unique requirements. We have particularly wonderful
implementations of proven technologies in the form of sid, lexi, and
TDF.

I propose that these are certainly applicable outside of the TenDRA
project - as indeed they were, originally - and that these should be
pushed as independently useful items.

Furthermore, components of TenDRA itself may be modularised. The
advantages here are twofold:

 1. To not "scare off" prospective developers, who would be otherwise
    uncertain about committing patches to a relatively large project.

    Modularisation allows these developers to work on only the parts
    which interest them, and to not worry about having to maintain
    unrelated code simply because it is present.

    This also lowers the barrier to entry: there is less to learn
    before a person becomes useful.

 2. To attract developers by providing exactly the tools they need, and
    no more. This is a perfect way to avoid bloat. Briefly, all tools
    useful to TenDRA are not necessarily useful to the developer in
    question.

The technical plans for the process of migrating to this modularised
system are beyond the scope of this document: they are discussed in the
components and restructure documents.