Forum OpenACS Q&A: OpenACS/Interbase - aD meeting 8/7/2000

Well, I can't think of anything to say that you've not heard of before, nor haven't thought of yourself, for that matter...

The key is to try to do whatever can reasonably be done to minimize the divergence of the source tree.  "minimize", not "prevent" because the latter's not possible unless they give up the usage of SQLJ, etc.

I think an important point to stress is that we understand the above, and have realistic hopes in this area.  Stress that even small steps in that direction can greatly reduce the hours of effort needed to maintain a port for another RDBMS.  I wonder sometimes if this hasn't been missed, if instead there's a feeling that it must be "all or nothing".

Of course, the db_* API is an "accidental" step in that direction since we can massage all queries from within the API ...

Since aD just went through the exercise of hacking through each and every source file, switching to the new db_* API and ad_page_contract scheme, they probably have a much better sense of the effort required to port to another RDBMS.  Hopefully this will translate into a better  appreciation for just how much leverage they can gain by modestly supporting OpenACS.

If aD is serious about supporting OpenACS and an InterBase port (and I think it's foolish to start an InterBase port outside of the OpenACS effort, but that's just my opinion), they should consider funding a technical coordinator along with Adam's non-technical slot.  With logistical support from aD, I think our community can come up with plenty of help supporting both IB and PG.  A techical person could help with a lot of the stuff Ben's done, i.e. CVS tree maintenance, scheduling and making releases, Q&A (!), keeping the OpenACS community  apprised of upcoming work that will have an impact on the IB and PG ports while at the same time helping aD engineers understand what hurts and what helps us, etc etc.

These are just some things off the top of my head ...

I think it's important that we destroy another "all or nothing" false choice--namely, that a project needs to be either all aD's or all OpenACS's. Having an aD employee (like Sebastian) either lead a crew of OpenACSers on a project or simply participate as a team member will do more to break down communications barriers than anything else I can think of. This meeting on the 7th could be an ideal moment to extend an invitation to aD.

Also, as I mentioned on the ASJ board, I do believe it is possible for us to seek sources of funding for the ongoing porting efforts. There's no reason why OpenACS has to rely completely on donations, volunteers, and aD's fiscal largesse. We should be actively talking about a business model.

Even more importantly, perhaps, is talking about how the OpenACS project benefits aD's existing business model. Right now they see it mainly as a community service with a little PR thrown in. But if they can come to see OpenACS as an avenue to really evangelize ACS (and therefore aD, whose name, after all, is on the product), then perhaps the OpenACS needs will carry a bit more weight when aD is balancing a simple source tree vs. using all the Oracle stuff. I know Ben has made this argument to them before, but now we have a bit more data in the form of OpenACS community participation, number of OpenACS downloads, and so on. If GreatBridge and/or Borland could be actively enlisted in this conversation as well, then supporting OpenACS should become a no-brainer for aD. The faster we grow, the easier it will be to persuade aD that it's in their interest to actively support our efforts.

On this note, perhaps we need to start an "evangelism" board to support efforts to spread OpenACS.

Adam, it might help if you could give us a run-down of what aD sees as the current and potential drivers for supporting this effort. What are your corporate priorities and goals? What can we do to maximize the boost that we can give to aD's business (thereby maximizing the amount of energy that aD can afford to put into supporting us)?