Questions we need to address before we build the upgrade path for existing ebase users to get into the next release:

• Should we do it in the context of the existing (2.20) user interface for data import, or as a separate area of the user interface?

Allen Poole - I like the idea of keeping it in the UI developed for data import, provided we can bring Matthew's code base forward into 2.80 successfully.

• How will we help users address dealing with their customizations?

Allen Poole - We need some way of helping people know if they have customizations, first of all. Larry developed an automated process for detecting customizations to ebase 1.0x, but I'm not sure it'd be easy to adapt for v. 2.x. We could always say "try the upgrade, and if it fails [in some specific fashion] then you must have customizations, and so you'll need a consultant to help you work it all out."

• Who is available to write the automation, who is available for testing, and who can write the documentation?

Allen Poole - I can work on all three, but I'll need a bunch of help!

• What support options, paid or volunteer, should we offer to groups needing help upgrading?

Allen Poole - I propose to develop technical doc. as we develop the automation, and make this available as premium content on ebase.org. Users requiring additional support can consult the forums and listservs, and/or hire a consultant.

• [additional items like this]

Additional questions that we've tabled in the past, that need resolution:

• Do we require ebase users to contribute money (or time) at any point? Is there any quid pro quo?

Allen Poole - my preference is to provide the software and documentation free of charge, but to fundraise as follows:
-Ask for donations from new adopters.
-Ask for donations annually from users.
-Require a donation (in the past 12 months) for access to the support forums and other "premium content" at ebase.org.
-Ask consultants to commit to only do paid work with groups that are current contributors, except in cases of great financial limitations.
This puts the burden for fiscal support on users, who contribute the least relative to their numbers, and yet allows super-low-budget users to adopt ebase for free.

Marshall Mayer - I think the upgrade/migration tools should be available free to paid-up members of the community site. Of course, the software itself should be available as 2.20 is now.

To raise funds for the migration/upgrade development,
- all members that have joined the community through PayPal since 9/20/07 will automatically be renewed by PayPal (if they do not opt out). That's about 75 members.
- there are 1125 more community members that need to be approached for renewals (we've never asked them). Once we get them on the PayPal subscription option, then they will get renewed automatically each hear (until they opt out). This is by far the easiest way to raise money quickly. Even if the renewal rate is only 10%, that will raise at least $5,000.
- for those that do not renew, we'll have to disable their membership access to the community site after one month, with a final notice.
- there are probably a bunch of subscribers to one or more of the support lists that are not now members. They need to be approached.
- I suspect that all developers and other consultants are already members, but special appeals could be made to those constituencies.
-finally, there is a list of email addresses of downloaders that may or may not be using the software but never joined. A lot of these email addresses will be dead (and a lot more than that will not be using ebasae), but they should be approached.

I don't know how the membership system works now, except for the PayPal processing, so we'll need to revise the above based on reality. Also, we'll need to review the processes to be sure that revenues are at least steady based on the new interest we'll get with 2.8.

• [additional items like this]