One school of thought would be to time the updates to the module to relate to the preportion of donations recieved.... ?

Many thanks Brash for your input.

David, i like your idea of updates released upon donatition level. I.e. the beta version gets released, once $100 is made then the proper full version would be released and after every $50 or so a new upgrade would be made. I think this could work!

What do others think? At least this way, i would have got enough money to cover my loses before people can release the script out in the public?

Many thanks!

Its only a thought - but I'm not sure of the ethical nature (or not) of it.

I think Mit is right when he says that a module like this is something a few people may pay more than 10 dollars for.. and as such, is worth asking for a few key people to donate.

Demonstating the module on a live site would encorage donators perhaps?

I will take this all into consideration. I am meeting up with the guy designing this for me tomorow so i'll see what he recommends.

If $100 is all you need to get this show on the road, consider it done.

However, I would be very surprised if you could get anyone to do this for less than $500. But comparing your earlier statements that it would cost you a lot of money and your idea of $100 and $50 donation levels for release of full and upgrade versions, respectively, I see a mismatch (unless $50 is a lot of money to you... I know it is to some, but $50 is not much more than a round of beer at the pub to an Englishman, is it?)

No, remember that i am putting a contribution towards this myself and that was only an example.

I may be interested in donating myself - depending on a customers requirements - but if its possible to see a demo then that'd sway things... (It doesnt have to be downloadable - but perhaps to play with on the admin side as well?)

What people must understand is that it is not a matter of paying for the product - it is paying for the development.

It's not like Cuckston will make this module and then subsequently sell it or receive donations for it. If there are not enough donations, it will not be made (as I understand Cuckston). If not, it will not be developed.

So... I say that I have 200 US dollars to give for a module that satisfies these requirements:

- Registered users can buy memberships
- It shall be possible to set several memberships to buy
- A membership has a price and one (or more?) group(s), the user will be put in upon payment. These must be configurable through the administration
- Payment gateways should be modular, so it is possible to easily add others later

My suggestion is that if you want the same requirements, chip in. If you want more requirements, name them and say what you would be willing to pay for it and then Cuckston can see how many of the requirements he can get fulfilled by his developer for the pledged money and we are good to go.

Mithrandir, thanks for the suggestions and i will definatly take the donation into much consideration. I originally didnt think about having multiple memberships however that makes a lot of sence. I will defenatly put that in as an extra feature.

The price and currency will be variable within the admin pannel. That has already been discused with the programmer.

As for the payment gateways, will try and get him to make it easy to add in more payment gateways however orignally, it will be made with PayPal. As you are willing to contribute a lot towards this project though i will make sure your wanted gateway gets added aswell.

Many thanks

Quote:
I wouldn't dream of asking for other gateways than PayPal - however, I do want it to be easy to add later, when I will have to add support for a Danish payment gateway.

So as long as it is not a major deal to add a new gateway, I am happy. I just don't want to be forced to change a lot of files when more gateways are to be added.

I think multiple memberships is a must. In my head, there must be a hierarchy of access levels to both give small-spenders an easy and affordable way to check out the deeper layers (while still generating revenue) and give big-spenders (the pillar of the website revenue gathering) something extra.

I do think that membership should not be intertwined with the registration process. Both because it will make it so much simpler to make (don't have to worry about username and email checks - and in 2.1/2.2 there will be dynamic user profiles in which case the registration form in this membership module may be outdated... it's just too much hazzle that could be taken out) and because it will retain the freedom to have user registrations for free (giving just the benefits of login and user profile to the user) and payment for further access and possibilities.

Since we are talking subscriptions, I would like to make an addition to the requirements: Log the payment time, so I can see how long a user has subscribed. I don't want to ask for automatic removal from membership groups upon subscription expiry until later, when the core has better support for such automation.