Any client can sponsor a new feature, by paying the "development cost" of that feature, and we would add the feature to the software or create a new addon to add the feature. Note that we will still only add features that benefit the software as a whole, for instance we aren't going to add built-in forums since it does not relate to classifieds or auctions. But we may add a bridge to an outside forum software to allow users to be shared!

When you sponsor a feature, you are paying us to add a new feature to the software that might not have been added otherwise for a much longer time, or perhaps not added at all. Sponsored features get top priority. If we have multiple sponsored features at once, we will work on them in the order that they were paid for. Once the feature is complete, we will make a beta version of the software available to you so that you can start using the new feature right away. You would also have the option of just waiting for the next feature release to come out if you did not want to use a beta version and you didn't need the feature right away.

But note that sponsoring a feature is not obligatory for a feature to get added, it is merely an option you have if you wish to take advantage of it to ensure a feature you want gets added right away and customized to fit your specific business plan/process. See the next section to read about how we decide on what features to add when they are not sponsored.

Many clients have approached with requests to develop a feature for them but that the client would own or control/resell that feature themselves instead of the feature being included freely within the base software. We turn down such requests for several reasons which we list below.

Such requests require us to keep custom code separate from the base file set we work with. Managing different code bases in an active coding environment is time consuming, not cost efficient and eventually one branch of the code gets abandoned…and the code base abandoned is not the base Geo file set. The custom development work is the code abandoned to fall behind the base software. It's not worth the cost for us or you to maintain a separate code base.

Once a piece of code is separate from the base code set it quickly falls behind the base software. The base software is under constant development and those changes can have affect in different parts of the code. And later when you do try to include separated feature back into a current installation there are always issues to be dealt with. In many cases some pieces of the custom development need to be recreated just to bring the custom feature up to current code. That's development time the owner of the separate feature would need to pay for. As we include all sponsored development into the code base we by practice keep the feature up to date free once included in the base file set. We basically eat the cost of keeping the sponsored feature up to date in the base code from day one. So while we share a cost to create the feature with you we solely eat the cost of keeping that feature in the base file set. This can save quite a bit in maintaining a feature as an changing and improving base file set requires constant change in features attached to it.

Another reason is that the feature actually gets used. Once a feature is in the code base other clients eyes see it and can use it. We've seen many times where once a feature was released issues in the feature are quickly found and fixed because of other clients poking and testing the sponsored code. The feature gets "stressed" by different environments, different minds and different business plans using it. Other clients may also see an opportunity and even sponsor their own improvements to the feature. All this keeps the feature in use and improves upon an improvement. With sponsored development of a feature you do have the ability to have the feature coded to fit your business processes exactly which in almost all cases provides you a "head start" to using that feature in an active environment if a head start is needed. In many features most clients can't see a use for it in their business models. Sponsoring a feature makes for a feature that meets your needs exactly. In many cases there is a wrinkle within the sponsored feature that simply makes it unusable within another business plan. And then again any other clients that do find a use for the sponsored feature generally find a very different use for it so as not to interfere with your plans.

We as a software company must keep our software competitive with other software in the industry. If we were to separate code out for specific clients for their own ownership we would be limiting the directions our software sometimes must go to stay competitive. After all you are relying on our software for your business needs and we wish to be here to supply those needs for a long time. Doing custom work that the client solely owns limits where we can grow as a company to stay alive in a competitive marketplace providing software support for your current projects and for future projects. Even if you were to own a feature in our software that doesn't stop others buying software from other companies and adding that same feature to that software.

We do not want to place limits where the software can go in the future and providing "rights to a feature in the software to one client" severely limits where the software and even we as a company can go. We are approached with ideas all the time and do not want to limit the software because someone "holds rights" to a specific feature or a specific way something is done. We cannot limit the possibilities in the software for one project. We've also found that while some features in the code are similar the business processes using them are vastly different. So while two or more clients are using the same feature they do so from very different business processes leaving all clients mutually happy with the same feature and never really in "competition".

Please note also that the cost we give for adding a sponsored feature is not the whole cost of that feature. In almost cases we are eating some of the development cost because the software does benefit. We know that others may find a use for the feature and do eat up some of that cost. And when that feature is included in the base file set we keep that feature up to date with the base software which is another long term cost.

There are a few different factors that go into the decision of what features we will add next:

• Demand for the feature¹⁾<
• Feature offered by competitor or popular website ²⁾<
• Features that keep our software at the top of the industry. There may be zero "demand" for a feature simply because no one has "thought of it yet". These are the types of features we add that continue to put our software at the top of the industry; the features that help to define us as the guys to "catch up to".<

The above factors are balanced against the amount of development time the feature will take to add. If a feature does not have much demand, but would be a "quick change" to add the feature in a way that adheres to our high development standards, we may go ahead and add it even if there is another feature that has "more demand" but might take 10 times more work to add. In other words, the demand for a feature, along with the other factors mentioned above, has to be able to justify the amount of development time it is going to take to add the feature.

If you are interested in sponsoring a feature, just send us an e-mail to [email protected] that explains exactly what you want to have added. It helps if you make the title something like "quote request for …" so that we can easily identify the quote request. We will also use e-mail records for reference later, for that reason we typically will need you to e-mail us the request rather than requesting through chat.

The quote process is a multi-step process, below is the general steps a quote request will go through:

1. First, you send in the request to [email protected] with exactly what you would like to do. Note: Do not start a new bug inside Bugzilla for the quote request, we will do that for you, send your request to the [email protected] e-mail. <
2. Follow-up questions: Sometimes we will need to ask questions about exactly what you need. We want to make sure we understand exactly what you want to have added. Or we may think of a different way to accomplish what you need that might make it work for more situations than just yours, in which case we'll check with you to make sure that would work. <
3. Once we have a clear understanding of what you want to have added, if we already have a quote for that feature or a similar one we'll send the quote directly. If it requires a new quote to be generated however, we will tell you the rough "project size" before generating the quote, along with a very rough idea of what the cost might be. There are 3 main "project sizes" listed below:

^ Project Size ^ Ballpark development time ^ Ballpark Cost ^

NOTE: At this stage, the project size is not guaranteed, it is just a way to give you an idea of the size and make sure you are interested before we invest time to generate a quote, the final quoted price may end up being much larger. <

1. When you verify that you are still interested after we give you the rough project size ballpark, we will create an accurate price quote. In order to be as accurate as possible, this process can take a lot of time to generate. While we do not charge for price quotes, and you are under no obligation to accept the quote we give you; we ask that you only request a quote if you are interested in sponsoring the feature, since it does take significant amount of time away from the developer(s) to generate each accurate quote. <
2. To generate the most accurate price quote possible, we typically follow these steps:
   1. We first add the feature inside Bugzilla, what we use for issue / feature tracking.<
   2. Then we create a "task list" and try to calculate every technical "task" that is required to add the feature, and we will usually post that task list in the Bugzilla bug entry for the feature.<
   3. Once we have the task list, we will calculate how much time each task will take, add it up, and that is the quote. The cost is usually $100 per estimated hour of development work. <
   4. Features that have been quoted this way, we will record the "estimated time" in the Bugzilla bug for reference later, so that if you do not accept the quote, we have a pre-made quote if anyone else requests the feature later. <

<

1. We will send you the price quote, along with the detailed "task list" that was generated as part of the quote process. You will need to go over the quote task list, and make sure nothing is missing. Anything that is not part of the official quote task list, is not included in the price. If there is anything not part of the quote that you want it may cost extra to have it added. If the quote price is good let us know and we will send you any paperwork to sign³⁾ and create an invoice. <

Because of the process explained above, we are usually very accurate with the estimate, so once we quote adding a feature the price stands even if the "actual" time goes under or over. In other words, the final price quote we send does not change (unless the specs of the quote change). The quote is guaranteed to be good for at least one month. It may still be good after that time, but it may change if things that would affect the feature have changed in the software.⁴⁾

Also be aware that depending on how complicated the feature is, the more time it would take to add the feature, the more the feature is going to cost. The more complex the feature is, the longer it might take to generate the quote for that feature.

Between accepted sponsored features, and features that we plan to add without sponsorship, sometimes our development schedule is just too full to accept any new sponsored features. This can happen if we feel we won't be able to even start on a new feature for several months. When this happens, we'll let you know when you make the request, and give you the option to be in the "long term queue". What this means is we will add you to a queue, so that later down the road when our development schedule is freed up enough to take on a new sponsored feature, we will contact you back and see if you are still interested to pick up the quote process where it left off. When this is the case, the quote is "on hold" until we are sure that we would be able to work on the feature in a timely manner. We do not generate the accurate price quote⁵⁾ until we know that we can work on the feature. We want to make sure you are still interested in sponsoring the feature at the time we can work on it, before taking the time to generate the price quote for you.

One common misunderstanding when it comes to having a feature added, is the development cost for adding the feature. The most common reply we get when people are surprised that a feature will cost so much, is "That is more than I paid for the software!". So just be aware, when you sponsor a feature, the cost is based on the "development cost" for the feature not the "retail cost". With the "retail cost", meaning the cost you pay for a pre-made software, you are only paying a small fraction of what the full cost to create the software was. That is because that cost is "spread out" by selling the software to multiple clients. The development cost is always going to be significantly more than the retail cost for that reason.

By sponsoring a feature, you are helping to cover the development cost, meaning the amount of time a Geodesic developer has to spend working on adding that feature that they might otherwise be spending on something else.