FarCry Core Changes
It's possible to accelerate the development of core features, the repair of specific issues and so on through "Sponsoring Enhancements". Although open source, the Daemon engineering team works daily with the FarCry code base and so is ideally positioned to address and prioritize product specific issues on behalf of clients.
Sponsoring changes to core are a little bit different to standard consulting/development for the following reasons:
- the IP and copyright for all contributions is ceded to Daemon and subsequently released under the GNU Public License (GPL) to the greater community
- any changes made need to take into consideration issues of backward compatability, and upgradability for other users of the code base, and so a change may be a little more time consuming than doing it for a specific project
- only those changes that are generic enough to be of benefit to the majority of the community and/or reflect the "farcry way" (for want of a better term) will be considered
- sponsored changes effectively have no warranty as a consequence of the license under which they are released.
This has certain ramifications.
Mainly from a corporate ownership view point, once built you really lose any sense of control over these features and as the product evolves they may be modified (even removed) depending on the community forces behind the code base. Of course these are extreme scenarios and where possible we endeavour to make sure FarCry, as it changes, benefits those people who have invested in it.
Really this type of sponsorship tends to be suitable for those companies who understand "open source". So certainly don't want to scare you off but I think its important to understand these things upfront.
That said, FarCry is specifically designed to be extended so there is plenty of opportunity to sponsor specific project development without the need to change core or to minimise the need for core changes.
Some clients who are very confident in the process will even contribute to this sort of development with no specific expectation of a completed deliverable beyond the best efforts of the developers being sponsored. For example, "we know you're working on this issue amongst several others, and we're happy to pay for 100 hours of development to prioritise its completion".
For these reasons we prefer to work on the basis of time and materials for these types of changes rather than a fixed cost price. Typically we make estimates of the time we believe it will take to complete a task. And if, for whatever reason, we feel we are in danger of exceeding the estimate we call to discuss the issues and how you'd like to proceed. This way we attempt to minimise your costs, and set the right expectations with regard to the deliverable.
Fixed cost projects set a different type of expectation with regard to the deliverable; there's an implied warranty for the work. Obviously many companies prefer "fixed cost" but given the nature of the work involved this represents substantially more risk to Daemon. So we need to consider each fixed cost deliverable carefully and typically charge a lot more for it.