My name is Andrew van Breda and I work as a self-employed developer for Indicia. Just to give you a little background, I have been working on Indicia related projects for exactly 5 years now, and before that I worked as a tester which included working on Recorder 2002 and 6.
Hopefully I can answer a few of your queries for you.
Keeping in mind that I only know what you have written here, my initial instinct is telling me that the best way forward would be to gather up all your requirements into a list and try to work exactly what Indicia already does, and exactly what it doesn’t do.
I know you have said you have requirements in addition to standard Indicia functionality, but does that take into account that Indicia can be configured and extended, you don’t want to spend effort doing something that you find is built in.
Perhaps you are confident that you have already done this, in which case I would be interested to know what the new tables you envision would contain in more detail, so I can understand in what way what you are suggesting differs from built-in Indicia.
Indicia is actually very extendable without the need of programming, you might find you need to do less programming than you think.
Indicia has a very flexible attribute system that allows data to be saved against samples, occurrences, taxa, locations, people and we can even save information about individual terms in termlists these days.
I think when you are referring .to characters it is what I would refer to as an attribute within Indicia (correct me if I am wrong)
I have been involved with more than one project lately which has involved importing taxa attribute data into an Indicia database (for these particular projects we referred to the attributes as traits), but almost all projects deal with custom attributes in some way.
For instance, you could have a data entry form, and your administrator could come along to the warehouse and add an attribute for habitat along with allowed values without any programming required, just basic Indicia configuration.
This is the most basic example, you can do quite a lot without additional programming.
I am not saying you don’t need any additional programming, I am just making sure you don’t go off and do something for certain requirements that could be done quickly with configuration.
I would certainly be aiming to use in Indicia if you can, it has so much useful built in functionality.
Indicia does many sophisticated things, but a lot of advantage lies in the simple things it does. If you decided to not use Indicia, you might find you want to do something simple but actually it involves a lot of programming, often simple things are not quite so simple when you start from scratch.
Indicia has the advantage that it has been going quite a while now, so a lot of the simple things (and more complex ones) are already built in.
I think it would be too early for me to say how much what you are after would cost, partly as I am not sure how much of what you are after we already can do with some built-in configuration.
What I would say about the Kohana issue is this, Indicia is an involving system, a community, it evolves as needed, people add new functionality as required, we address issues as they are identified such as supporting several Drupal versions.
These are obviously addressed gradually and on a priority basis.
If the Kohana issue was a major problem it would have already been addressed. It will gradually be addressed along with the other issues.
You won’t find a cliff edge scenery where one day you suddenly wake up and find your Indicia system isn’t working anymore. Indicia involves slowly, and your changes will evolve with it.
Also you may find that a lot of your work is not directly related to Kohana, a lot of the logic could be ported or directly linked to Indicia rather than Kohana, so that when Indicia one day moves from Kohana your changes will go with it.
OK, I think that is all for now.
Hope that helps, let me know if you have any questions or think I misunderstood anything (or everything!)