Cooperative Funding of Geo Development

[chrison600]

Hi all,

I was just sitting here debating on whether or not to commit funds to having Geo do some custom development for me, when it hit me that more than just "me" want the functionality.

Why don't we compile our "wish list" then prioritize it and submit the top few issues to Geo for bidding (we'll need to separate our respective environments, i.e. Enterprise vs. Premier)? We can then take the bid and defer the costs to those who participate in the planning.

I know, some people will sit on the sidelines and wait for the standard update without contributing, but I'm willing to bear that burden for accelerating the incorporation of additional features.

What say you?

[Robertc]

Not a bad idea.......but my issue is with the priotisation of adding new features and the types.....

What is really needed is a maintained list of new features coming.... when they will be available and requested features that have not been approved yet. This would allow use poeple who have paid the oporunity to cast our vote on what is added next.

[carpman]

I use a gallery script that has a beta forum and suggestion forum. The suggestion forum is for feature wants, the beta forum is to chat about and help develop the beta version which is released to users. We have a suggestion forum 'Ideas & Wishes'.

The lead developer at start of new beta will post list new features, inprovements to be added which have been taken from the suggestion forum, users can then make final suggestion to this list before features for the new beta are frozen and development takes place.

I think what we could do with here is roadmap of features planned and at what version their introduction is planned.

If this was in place we could then decide if some of us wish to get together for custom additions, what this also raises is what happens if the changes we pay for make their way into mainstrean version?

Maybe the enterprize version could have the ability to accept and work with external modules thus allowing others to develop modules which would extend GC.

[Robertc]

Coming back to this post as I think this is an idea that needs to be discussed more and looked at in detail.....As i am interested.

[GSspider]

Content of this post has been relocated to http://SpecDeal.com and is being expanded into a formal offering.

[identity]

I've always thought that there could be some other kind of "model" for things like this, whether it is Geo or any other script. In Geo's case, other than Equineads, I don't know of any other third party developers for mods, so things are very limited.

The model that has rattled around in my head is a form of patron/sponsor kind of idea. The idea is to encourage sponsored development. So if someone wanted a specific feature, they could help front the development expenses up front, and then when that mod is offered to the world, they would draw a percentage back from sales. If it is a very specific, limited mod that you need, you may not draw much or anything on the backend, but if you really need it, then that doesn't really change anything. If it is a great idea that others may also like, then there is a potential upside that you may recover your investment and perhaps make some. Or it could be capped at recovery, though the other approach might be even more encouraging and prompt a little more risk taking. Of course, there would be no guarantees since no one would ever know if it would be adopted by others. This could also help to keep the cost of mods down, since Geo would be immediately covering at least part of the development costs on the front end.

Part of the challenge right now would be that Geo has very few in-house mods and most new features seem to get rolled into the product upgrades. This has benefits and drawbacks. On one hand, it is great bringing in all these features, but on the other, it also starts to weigh down the code and in some cases, may be at the addition of several features that you may not be interested in. This certainly seems to be part of the issue with much of the open-source/free ecommerce packages... a one-size fits all, we'll add every feature under the sun so no one is left out.

The idea would be easier to integrate with standalone mods as you could then track their purchases separately.

In the end, everyone benefits as it continues to improve the product, development costs are kept down, or covered quicker allowing more development, costs are kept down, and in the end, more buyers are attracted to the product.

[GSspider]

Greetings...

The problems rear their ugly heads immediately: Which version do the mods work on? How many people want the same features? Who owns the resulting code? Who pays up front? How do you account for and distribute any profits?

There has to be an investment vehicle that defines all that or it just keeps on being an idea and not a reality. Of course, all you have to work with is all you have, so it may be the only approach for some.

[Robertc]

Having worked in the software support industry since 91 and having to be on the receiving end of 'policy' and also customers 'requests' (read demands or i want my money back)......

Code bloat is an issue that can be designed around to keep all the functionality and features loaded inteo one package, config files just turn them on/off. Keeping all the code inside on package side steps the version issues and also makes upgrades easier as you avoide the the requests for 'I only want to upgrade this moduel and pay for only that' problems.

The exisitng model of paying an upgrade fee each year has over time worked out as the easiest one to manage and work within, the only catch that has to be looked for and be carefull of is over charging for only little change/features and keeping the updates regular and easy to access.

This regular source of income becomes the means to finace the continued development of the product, releasing gradual incremental feature updates, bug fixes and 'Regulated/Legal' changes. The development of a new 'major' feature is a new product / upgrade that is purchasable at a price.

The funding such a new product is normally done by the development house and a few chosen customers who put up the cash to get what they want sooner and who get some share of the revenue from the new product in the form of reduced yearly fees for the life of the product.

I have helped customers arrange these deals in the past with programming companies and found that they only fail whn either party gets greedy cause the orginal agreements were made between people who nolonger have a vested interest in making it work. (ie company take overs where its seen as giving away too much money to the orginal sponsor).

My 10 cents