Forum OpenACS Q&A: Response to Summary of the Sloan - Berklee dotLRN meeting

* Berklee and Sloan will be working together expanding the Survey Package.

Recently one of Michael Feldstein's acquaintences, a fellow named Dean Des Rosiers, e-mailed me to tell me he has broad experience developing web-based knowledge management systems, and that he wanted to start an effort to provide such tools for the OpenACS 4 community. He said he felt that a good place to start would be a "general ratings" package.

I suggested that he post to the forum, as I know there's interest here in such things.

In short order he

• Got pointed to a couple of examples of specific things folks had done with either OpenACS 3 or 4 - a source of ideas for Dean
• Got a tarball from Lars Pinds of a simple one-dimensional rating package he'd put together very recently for his own site, which Dean may very well be able to use as a base for his more general "general ratings" package
• Some answers to questions about how to structure the package to best fit within the OpenACS 4 framework
• etc

Now contrast this with how Sloan typically approaches module design. Sloan's needs are spec'd internally, people like myself (the Homework dropbox, as Caroline mentions, and it's really Furfly not "me"), OF or others are invited to make a proposal, and off we go.

There's nothing intrinsically wrong with this last approach, and certainly since Sloan's spending the money and is deploying the result in a real-world situation the institution must ensure that its needs are being met (and since I've worked with Sloan in the past, I think Sloan understands I am very serious about making sure their needs are met when I do contract with them).

But think about the survey package for a moment. Berklee's involved so the above scenario is slightly modified. Two institutions must be satisified.

But imagine for a moment that Sloan and Berklee raised questions about the survey package here first, rather than later on. "It falls short in the following areas, we have these needs that aren't being met" etc.

What might happen?

Well, what might happen could be that

• Others in the community have been working on similar enhancements that could be shared and serve as a starting point
• Others may point out other shortcomings that Sloan/Berklee haven't thought of
• Folks may have suggestions for improvements in the user interface, etc
• It might be met with total and stunning silence on the part of the community. It might be that no one else cares about the survey module.

What would be in implications of floating ideas for comment in the beginning of the process, then? Certainly no obligations on Sloan's part. People might float additional interesting ideas that Sloan/Berklee have no interest in funding. On the other hand, you might just see an idea pop up taht would make you folks say, "hey, wish we'd thought of that, let's do it!"

Being a more active participant in the community, then, has potential benefits for both sides. It seems that every few weeks, someone pops up here asking about "OpenACS 4 vs. ACS 4.2", or "OpenACS 4 vs. Java ACS", etc. Each time, at least one respondant says something like "one of the most important things about OpenACS is the dynamic and helpful community"

Sloan already gets some of the benefit from such feedback, because Sloan has contracted with folks like OF and Furfly. Speaking for myself - and Dee Dee would confirm this, I'm sure - specs you guys send my way generally come back with suggested changes. I make those suggestions with a view towards making the feature work better for you folks. For instance, my response to the Homework package will include two or three suggestions.

Why not get the benefit of even wider community feedback? Why limit it to folks who might be interested in formally contracting to do the work?

Of course, there are all sorts of questions about "process", in other words I personally wouldn't want to see more open discussion about design and plans result in Sloan (or Berklee or anyone else) getting bogged down in endless overhead.