Forum OpenACS Q&A: Re: Reuse in the large is an unsolved problem !?

Janine, this makes me wonder. Are you chasing the wrong clients? So far (knock on wood), none of our clients ever asked *how* we were going to implement it. They only ask if there are other people that can do the job, I point them to the active community and offer to bring them in touch with others so they can get a second opinion on our work *and* get to know others who could maintain the site if I fall over the bridge. Additionally we usually offer training for their developers if they a) have any free / available and b) want to. Usually they already stop at a), but definitely stop at b).

Now, what is the alternative to our stack? None. The effort to port OpenACS is just to big. So we can either stick with what we got and target to those million companies and potential users which care about a working system no matter how it is implemented (I usually face the uphill battle of convincing them to use Linux, this is what our clients are passionate about as they usually have a Windows IT guy) or we should choose a LAMP combination (though I'm not even sure this would be successful).

Last but not least, if we look at a long term perspective and look how much things change even at monster.com, for sure TCL is out of the mainstream, but what will be in the mainstream for some time? People start talking about Java being overtaken by ROR. Others say this is the advent of PHP. Then there is the struggle around middleware, service oriented architectures, enterprise integration applications and so on and so forth. IT consultants are thriving on this. One thing which would be really awesome would be if we could devise a standard way to promote OpenACS as a cool middleware with benefits. A portal system which integrates all those business applications and let's you talk about them. A workflow system which combines data and actions from various sources.

Try not to bring radioactive material to the IT department. Convince the IT department that you provide cheap energy and they don't have to deal with the side effects unless a catastrophy happens. It is not their core competency and they have (more important) stuff they are passionate and care about. And if they are willing to learn something new, offer them a workshop and training (which usually makes more money than to offer development services).

Sadly OpenACS could use a horde of interns who take the time to learn OpenACS and keep the documentation up to date, post about their findings and do all those burdensome tasks that noone else is willing to do (did I mention a nicer website, positioning discussions and papers as .LRN has them). We also need to offer bootcamps again. But one reason at least we at cognovís are unable to do it lies in the fact that we are stretched to the limit with client work, so we only take the time to commit things back to OpenACS. Which is probably more than some others can afford, knowing of the busy schedule.

Here again a joined effort getting motivated interns et. al. to take the code that has been developed and make a reusable package out of it, along with excellent documentation, can break grounds.

BUT.... This becomes totally off topic so I'll shut up now...

P.S.: No disrespect to any interns out there. We value your work and your ideas. But interns are usually the only ones who have the (paid) motivation to learn OpenACS from scratch and write about it. And are cheap enought to be affordable (taking into account that the majority of OCT members are located in high labour cost markets and proximity to experienced developers is a must in our experience).