6 |
7u83 |
1 |
Target Audience
|
|
|
2 |
===============
|
|
|
3 |
|
|
|
4 |
This document provides an overview of which target audience is
|
|
|
5 |
currently appropriate, how it conveniently works to our advantage, and
|
|
|
6 |
how we plan to increase our appeal in that area.
|
|
|
7 |
|
|
|
8 |
|
|
|
9 |
Demographics
|
|
|
10 |
------------
|
|
|
11 |
|
|
|
12 |
Currently the only point of interest is development. The product is not
|
|
|
13 |
ready for general use for many reasons (not least of which is having an
|
|
|
14 |
outdated implementations of standards). Hence it would appeal only to
|
|
|
15 |
niche demographics at best.
|
|
|
16 |
|
|
|
17 |
The general user is currently better served by other compilers, as they
|
|
|
18 |
provide mature and stable tools.
|
|
|
19 |
|
|
|
20 |
For the near to mid future, mostly owing to our small number of
|
|
|
21 |
developers and limited time with which to apply ourselves to the
|
|
|
22 |
project, we cannot compete with the maturity of the other compilers
|
|
|
23 |
(most notably the gcc) in either features or stability.
|
|
|
24 |
|
|
|
25 |
However, we have an advantage in our small size, in both response to
|
|
|
26 |
individual requests, and accessibility of our code base. TenDRA has
|
|
|
27 |
a beautiful, clear structure, which is unusually understandable for
|
|
|
28 |
a C compiler. This alone attracts people for whom "working" is not the
|
|
|
29 |
only thing that matters. The project is founded on the patient,
|
|
|
30 |
long-term investments in thought that these people bring.
|
|
|
31 |
|
|
|
32 |
Right now, we need all the help we can get. As our target audience is
|
|
|
33 |
not the general user, this leaves only niche groups. By the very nature
|
|
|
34 |
of the implementation and design both being beautiful to behold, we
|
|
|
35 |
are well-set to attract these people: this niche is developers.
|
|
|
36 |
|
|
|
37 |
Having only developers interested in the project also works to our
|
|
|
38 |
advantage: it relieves the pressure of maintaining a stable branch - we
|
|
|
39 |
simply do not have the resources to do that.
|
|
|
40 |
|
|
|
41 |
See also donations, for a discussion on putting money to use at
|
|
|
42 |
attracting developers.
|
|
|
43 |
|
|
|
44 |
|
|
|
45 |
Increasing Appeal
|
|
|
46 |
-----------------
|
|
|
47 |
|
|
|
48 |
So, our goal for appeal in the near future is to attract this specific
|
|
|
49 |
type of developer. I believe this is best done by making our products
|
|
|
50 |
applicable to their own projects.
|
|
|
51 |
|
|
|
52 |
On the assumption that they are not re-implementing wheels, their
|
|
|
53 |
projects will have unique requirements. We have particularly wonderful
|
|
|
54 |
implementations of proven technologies in the form of sid, lexi, and
|
|
|
55 |
TDF.
|
|
|
56 |
|
|
|
57 |
I propose that these are certainly applicable outside of the TenDRA
|
|
|
58 |
project - as indeed they were, originally - and that these should be
|
|
|
59 |
pushed as independently useful items.
|
|
|
60 |
|
|
|
61 |
Furthermore, components of TenDRA itself may be modularised. The
|
|
|
62 |
advantages here are twofold:
|
|
|
63 |
|
|
|
64 |
1. To not "scare off" prospective developers, who would be otherwise
|
|
|
65 |
uncertain about committing patches to a relatively large project.
|
|
|
66 |
|
|
|
67 |
Modularisation allows these developers to work on only the parts
|
|
|
68 |
which interest them, and to not worry about having to maintain
|
|
|
69 |
unrelated code simply because it is present.
|
|
|
70 |
|
|
|
71 |
This also lowers the barrier to entry: there is less to learn
|
|
|
72 |
before a person becomes useful.
|
|
|
73 |
|
|
|
74 |
2. To attract developers by providing exactly the tools they need, and
|
|
|
75 |
no more. This is a perfect way to avoid bloat. Briefly, all tools
|
|
|
76 |
useful to TenDRA are not necessarily useful to the developer in
|
|
|
77 |
question.
|
|
|
78 |
|
|
|
79 |
The technical plans for the process of migrating to this modularised
|
|
|
80 |
system are beyond the scope of this document: they are discussed in the
|
|
|
81 |
components and restructure documents.
|
|
|
82 |
|