You highlight some key points: quality, risk, transparency, and business model
Quality: ..How do we know that the software we are using or intend to use has a high degree of quality and can withstand installation in a mission critical enterprise?
The development process needs to be explicitly described, including stating values and principles used in technical decision making, and why those are used --including how results are verified. The documentation is working towards that, but is only valuable if it gets used. The feedback loop needs to be optimized. Perhaps at the end of each page there should be a link to create a context specific comment in the bugtracker instead of general comments?
Risk: Organizations are increasingly concerned about legal liability and exposure while using open source software. ..the consortium will be taking steps to diminish legal risks.
Is there some sort of explicit statement that code contributors can agree to, to help minimize the appearance of risk?
Transparency: Organizations will not adopt OpenACS and .LRN in mission critical environments unless they know with confidence that the software release process is predictable and well managed. This ranges from everything to an accurate and up-to-date bugtracker to clear statements and status of active projects.
I believe there should be a list of questions or checks that should be used to verify project phases, such as when issuing new versions etc. I'm sure that Joel et al are addressing these now. These just need to be reviewable by others. Again, documentation can help with this.
Business Model: the project will not be viable---in the sense of gaining adoption and interest in the enterprise market---unless vendors and companies are able to realize profit and a business model around the software.
The collective interests of business are represented in the concerns that are voiced in the forums. Getting those into the process is part of quality initiatives and improving transparency of the projects. However, if OpenACS is to be represented by a nonprofit, then I believe the business model of OpenACS still needs to be addressed in the context of risk. There needs to be some kind of for-profit representation of OpenACS to minimize risk and integrate with the corporate culture.
I doubt an enterprise level forprofit company will ever seriously consider choosing a nonprofit's product over a profit's one in a bidding process, because nonprofits are not permitted to compete against forprofits in their main markets. There are legal and economic risks that the enterprise avoids by choosing a product from a forprofit.
