Forum .LRN Q&A: Request for Comment: dotLRN Technology Governance

Here is my proposal for dotLRN governance:

http:// https://web.archive.org/web/20020810194617/dotlrn.openforce.net/

You'll notice a number of common points (Al and I went back and forth on these proposals), but a noticeable difference on the overall philosophy of who drives development and how. Please send comments!

Although the views of TAB are not strictly binding on the gatekeepers, TAB will exert a "persuasive" influence.

-- Al Essa

technically, each contributor of code - patches and such - owns the copyright on their individual contribution of code. This is generally made irrelevant by the terms of the GPL. To be precise, what the above paragraph means is that MIT owns the vast majority of the copyright on dotLRN v1.0.

-- Ben Adida

In some way, the consortium governance rules, and in particular the rules directly (or *indirectly*) related to the copyright ownership issue, reminds me of the policy ArsDigita used to have that they did not accept external contributions (where aD had no copyright ownership) so that they had full control of the copyright, thus being able to do whatever they wanted with their (the *official*) distribution of the toolkit.

I'm not suggesting that there is any intention on the consortium's behalf on doing exactly what aD did or even further. Rather, I suggest that the governance rules take note of this inherent problem and proactively act to prevent such a case.

Finally, I would appreciate if Al Essa could comment on this one. [Also, Al's document only mentions copyright ownership for applets but AFAICS there is no reference about the copyright of future versions of the "dotLRN-core" and the policy that the consortium might follow on this issue.]

More comments to follow.

Who retains copyright for a new applet? The individual developer, company or organization which owns the code. Once the ".LRN Consortium" is established we would encourage transferring the copyright to the consortium.

An applet writer owns the copyright to their code. We encourage applet writers to release their code under the GPL. The TAB will also encourage contributors to assign copyright to an impartial third party, but this will not be a requirement in any way.

Open Force's vision does not include any notion of forming anything like the consortium but note that it does suggest that the TAB will encourage assignment of copyright to an unamed impartial third party.

Al originally mentioned perhaps recommending the FSF. My comment to him was that there are people out there, for better or worse, who don't care for Richard Stallman in particular and by association perhaps the FSF. I thought the consortium might be more acceptible to some. Perhaps I'm wrong. But I know that this proposal wasn't made with the kind of motive Neophytos is worried about.

As you can see both proposals are actually very close on this particular point.

The key differences lie in different areas. One very major difference is that MIT proposes the establishment of something similar to the X Consortium and a solid business plan for establishing dotLRN. This implies some top-down structure to governance, with broad direction being set by the consortium ("the people who fund it").

Open Force's is much more bottom-up - a technical committee sets direction, and if user groups form around future releases and decide to market it, that's fine. If not, that's fine. There's no official hook on which to hang a request for foundation funding, nothing like that. There's no notion of an "official" distribution.

In other words even more decentralized than OpenACS is today.

Personally I think the consortium approach would work very well for dotLRN, and in particular I think the chances of broadening the funding base significantly is much higher under this approach than under the technical-driven, decentralized, bottom-up, almost free-for-all type approach proposed by Open Force.

Also a legal entity such as MIT proposes can apply for and receive grants directly. There are advantages to this. The reasoning is similar to that which led to the Apache Foundation being formed. Here's something from the Apache Foundation page:

The Project Management Committee (PMC) is a group of committers who take responsibility for the long-term direction of the projects in their area. There is a single PMC for each parent project (Jakarta, XML, HTTP Server, etc) which is commissioned directly by the Apache Software Foundation Board of Directors. The PMC is in turn responsible for many sub-projects, each with its own group of committers.

Actually the Apache Foundation page on mangement is worth looking at ...

What happens, if OpenACS 4.7 comes out and some packages have been improved over the dotLRN version. So OACS is not dotLRN compliant anymore? What is dotLRN anyway, in contrast to OpenACS? Why do we need a governing body for the one and cannot use it for the other?

If we install a version of dotLRN at a university, modify the code to suit their needs, can we say, they run dotLRN, the plattform developed by MIT, or shall we say the use OpenACS with a package for education, originally developed by MIT and modified to their use?

Marketing works both ways. The more people use dotLRN and brag about it, the more reknown the project will be as a whole.

Some more ideas: What if Greenpeace starts to market GreenCMS, the peaceful CMS for bridging the digital divide. Shall they get a governance body as well? How about our Communication and Knowledge Capturing Suite build on top of OpenACS (continue breathing, thats future).

Okay, now don't get me wrong. I am in favour of a Governance Body, and I see the use in particular for dotLRN. But the reasons are different. The Governance Body should not concern itself with TECHNOLOGY issues. That should be left to the OpenACS community and its mechanisms (which might include a Governance Body). But what is more important in my opinion is that anything which makes it into dotLRN and wants to get approved for using this name, should adhere to the EDUCATIONAL standards set forth.

A scenario I envision: The TAB decides that CR sucks big time and they endorse a replacement for it, making the current CR obsolete for dotLRN use. But OpenACS does not follow through. What happens then? Don't fork!!! We had this a couple of years ago, Don, Ben, Adam and myself sitting in an office in Boston Prospect Street. Don't want to see this happen again for whatever reason. But what is the alternative. If the TAB decides something, wouldn't that be like a pistol saying, eat, or fork ?

If I look at the Linux kernel, we have the standard distribution, and the AC (Cox) patches. But here the governance body is with the standard distribution.

Choosing between the two options presented (taking in account that you want to go ahead anyway and that there is actually not much of a direct implication for the rest of us), I'd go for Al's aproach as this resembles a more coordinated approach.

Last but not least, let me stress again the brand issue. dotLRN is owned by MIT as a brand, same as Linux is owned by Linus. It must be clear, that the use of the brand is allowed, as long as the dotLRN kernel is part of the product you distribute and it adheres to the EDUCATIONAL standards and quality set forth by the commitee. Reasoning: If I decide to rewrite part of the core or some applets, using C for better performance or slightly change the functionality, as AM/PM does not work in some countries, I should still be able to say it is based on dotLRN, without fear of beeing sued. Otherwise, what good is it to promote the brand when you may fear the sword will be turned against you in the future. I think Microsoft was using this tactic quite successfully, but that is just my gut impression 😊.

Al, Ben, please don't get me wrong. I'd never dream you had such things as described above in mind. But nevertheless, they were thoughts / ideas that struck my mind when reading about your proposals. And last but not least, I DO find it odd, that the organization PAYING most of the code and the one DEVELOPING most of it have a need to post DIFFERENT statements. IMHO, one statement with multiple options would have been a better way without leaving an odd fealing at least in my stomach.

What happens, if OpenACS 4.7 comes out and some packages have been improved over the dotLRN version. So OACS is not dotLRN compliant anymore? What is dotLRN anyway, in contrast to OpenACS? Why do we need a governing body for the one and cannot use it for the other?

As far as the Apache Software Foundation that Don mentions above, note that:

"Individuals who have made sustained and important contributions to one or more of the foundation's projects can be invited to become Members of the Apache Software Foundation. The members guide the foundation in much the same way that shareholders guide a traditional corporation. Most importantly, the members are responsible for the selection of the Board of Directors. The members coordinate their activities through their mailing list and through an annual meeting."

Al, this is my first suggestion w.r.t your request. This way we keep the top-down structure of governance and at the same time the consortium is decentralized enough that copyright ownership *could* never become a real issue (in the sense that I described in my previous message).

Ben wrote:

At the end of the day, innovation and greatness don't come from committees (ever seen a statue built to honor a committee?). Think of OpenACS: although there is a committee of gatekeepers, there is a single de-facto leader. At times I played that role, but these past few months it's most certainly been Don. In fact, the other gatekeepers (including myself) have effectively served as a Technical Advisory Board to Don. And although the needs and funds of users (GreenPeace, Sloan, Berklee) have certainly driven development of new functionality - without the intervention of any committee, by the way-, technical decisions and progress on OpenACS core have always been led by experienced technologists. User features are driven through needs/funds; technical architecture is driven through meritocracy and technical qualifications. Given that we're discussing a product (dotLRN) that has come out of this very OpenACS process and is considered, to date, fairly promising, it makes sense to set up a minimalist governing body to mimic this initial success. It also makes sense to build in a process for change in governance over time to enable evolution of these processes.

To my mind, this reflects a fundamental misunderstanding regarding the differences between OpenACS and dotLRN. I'm not talking about the technical issues; as I'll get to in a minute, all this talk about forking under MIT's plan is a red herring. I'm talking about who is required at the table to make dotLRN work and what it will take to get them to the table.

Let me be clear: There is no question in my mind that dotLRN will fail under OF's plan. Why? Two reasons:

First, the major institutions that are ultimately the intended buyers and users of dotLRN will never go for it. Think about it: Why are they attracted to Open Source in the first place? For the same reasons that people fire their stock brokers and open up accounts with eTrade. For the same reason that they now scan the Internet for medical information to double-check the advice that their doctors give them. In short, they want more control. They are sick of vendors selling them expensive piles of garbage for hundreds of thousands of dollars and then making them feel like it's their fault that the damned thing doesn't work. I know these people. They are my clients. They are my colleagues.

Will they feel comfortable with a governance plan that is essentially an informal technocracy run by one or two hackers? No way. They want a voice. They want a seat at the table. OF's plan gives them no such seat. The whole thing is run by hackers. You can say that it will be otherwise. You can say that you'll be consultative. But they won't buy it. And I don't blame them. I know for a fact that there are potential major investors in dotLRN who have already let it be known privately that a governance scheme of this sort is a potential dealbreaker for them. I can also tell you that my clients--both academic and private sector--would not buy this, and I'm not sure that I'd even want to try to sell it to them.

What could they do if they were unhappy under this plan? OK, they could bitch on the discussion boards. And what if that didn't do it? What then? Developers could fork, but they're not developers. There is one word even worse than "fork" that also begins with an "f" and ends with a "k." That word accurately describes the situation they'd be in.

In contrast, the MIT plan has accountability. If I, as an investing stakeholder, am not happy with the gatekeeper's performance, I have recourse. I can go to the TAB, which, by the way, is comprised of a broad committee of developers who are also recognized and respected in the community. If that doesn't work, they can escalate to the Executive Board, which would be a mix of technical folks and non-technical stakeholders. Hell, they could run for the Executive Board. So could you. Although there is no explicit migration strategy yet, the MIT plan does say that the Executive Board will become self-governing.

So that's one reason why I think OF's plan would cause dotLRN to fail. The other reason is that, even if you get stakeholders to the table to invest, you will fail to develop good educational apps. You could no longer design outstanding educational applications than I could design a database-backed web app. You have no way of even telling what's good idea and what's a not-so-good idea in education any more than a teacher has a clue about great programming.

It's easy to make disparaging remarks about committees. What is hard is bringing together people with diverse backgrounds and strengths to work toward a common goal--not a dirty, bureaucratic committee, but a governing body that is of, by, and for the whole community. We have two very hard unsolved problems on our hands. First, we're trying to create an Open Source project that scratches an itch other than the developers'. I don't have to tell you that the record on this sort of thing is spotty at best. On top of that, we have to design an outstanding educational application. You know what? I've worked with a fair number of educational applications and I have yet to work with even one that I would call outstanding. In fact, I can't think of many that I would even call adequate. This is a hard, hard problem.

The only way that you will solve that problem is by getting educators to the table for an equal, honest dialog in which you learn from each other what is possible. Now, you can say that they are welcome here. You can mean it, too. You can even set up a nice forum for them and be real nice should they show up.

They won't come. Again, these are my friends and colleagues we're talking about. I have invited, even cajoled many of them, on multiple occasions, to come and dialog. So far, none of them have. Why? Because this is not their world. It's yours. Programmers are from Mars, educators are from Venus. If you want them to really come to the table, you need to do more than invite them. You need to sell them. They need ownership. They need to feel like it's their God-given right to demand quality educational software, and dammit, they're going to be heard.

Where is their seat at the table under the OF plan? Where is their ownership? Where is the basis for their right to speak out? If you are excited (as I am) by the dialogs we're starting to have on recent threads like (https://openacs.org/forums/message-view?message_id=45096) and (https://openacs.org/forums/message-view?message_id=45257) then you need to reach out. These are the conversations that will make dotLRN great. Don't get me wrong, the developers have done a fine job creating a basis to build on. dotLRN is competitive with the best alternatives currently out there. Which is to say that it doesn't suck so bad. You need teachers here as equal partners, and you don't have them yet. You have me, and a couple of folks from the trailblazer universities. I'm not normal for people in my biz, and they are also usually technical.

Under the MIT plan, teachers have an equal voice with developers. There is a User Advisory Board to balance the Technical Advisory Board. A teacher can look at that governance plan and see that a seat at the table has been reserved for them. They are not just respected guests in a foreign land; they have been given a home. This is the only way you can get them, if you can get them at all.

And how is the MIT plan different from the OF plan in terms of the day-to-day functioning of the community? The truth is that it's not really different at all. You still have a gatekeeper who is a respected member of the OpenACS community. The code is still GPL'ed. Hackers can still contribute or not as they see fit. OpenACS can still do what they want as a community as they see fit. Heck, you can even still retain copyright on your code if you feel strongly about it. Nothing is different in the day-to-day business of Open Source development.

What is different is that the developer community under the MIT plan forms an explicit and equal partnership with non-developer stakeholders--the people who will ultimately help you design great apps and who will ultimately pay for those apps. If a formal governance structure is stifling to Open Source, then how come it's working for Apache? No, this structure is not just a series of stifling "committees," as Ben refers to them. It is nothing less than a social contract. It is what makes a community with diverse interests work. It is our Constitution. It does not increase the likelihood of a fork; the OpenACS community still has a gatekeeper chosen from their ranks, still has people on the TAB, and still has representation on the Executive Committee. dotLRN will fail without this community as surely as it will fail without educators and investing institutions, and everybody knows it.

But the bottom line is that the community needs to share power. They need to make a formal commitment, in the form of a governance agreement--a pledge to the people who you want to bring to the table. If the community is not willing to make that commitment, then I very much doubt you will be able to build vertical applications for this or any other market that anyone will buy.

The model parallels Apache governance: "the Board retains ultimate responsibility for the foundation, it delegates decision-making authority for the technical direction of projects to the Project Management Committees."

This delegation is essential if there is to be technical innovation. TAB will not be "imposed" as an alien entity by the Executive Board, but consist of recognized experts and leaders in the OpenACS community.

I don't know about you Michael, but when I hire contractors to do work that I cannot or will not do myself, they do what I tell them!  Or, I fire them and hire new ones.  I'll be damned if I'll let plumbers rule my life!

It takes nothing more than a willingness to take part to effectively join an Open Source community.  And for those who would like ultimate control of their own destiny, the price is about $100 an hour.

What you are demanding is the right to control a process without paying for it.  And if you don't get it you'll take your high powered freinds and leave us poor befuddled developers to the gutter.

Actually, you're pretty funny 😉

Being able to hire someone else is not enough of a business case for the long haul, especially I am planning to invest significant sums. For companies and institutions, the compelling business case for opensource is that they can leverage their investment dollars by receiving back the fruits of the entire community. It's an investment in a community that's important, not the access to the source code or having the freedom to hire other developers.

Here is one example.  It is everyone’s interest in the community for patches and other improvements to be put back into dotLRN.  It is also in everyone’s interest that we have materials that are useful to everyone like documentation.  Everyone benefits, either through direct use or because they help the community at large, from this set of “common goods”.  To various extents, people and institutions are willing to put some resources and effort to provided them.  However, no one is willing to do everything on their own.

The surest way to provide these resources for the community is to fund developers, documentation writers, etc. to complete the job.  Think of what it would be like if we had 2 full-time developers devoted solely to projects that are of general benefit to everyone! A consortium could organize such a campaign and raise the funds for the project through grants, educational institutions and companies. Essential to this process is funders are convinced that the consortium has the structure required to make such decisions and the authority to execute their commitments.

But this isn't about me, so I'm going to refrain from cluttering up this thread or your in box by responding to ad hominem attacks.

This has nothing to do with the issue at hand.  You claim to be one of those who are trying to make their living on the OpenACS code base yet ... you contribute NOTHING.  Other than bitching like the other day when you went ballistic over the notion that some naming conventions might change making it hard for you to make a living off of OUR work.

If it were one vote per line of code rather than one vote per submit button, you'd have zero votes.

And while I want to listen to everyone's point of view I'm not personally all that interested in the point of view of someone who's a non-contributor to the project yet acts as though his personal ox is being gored.

Seems to me you want us to keep working for you for free while you don't lift a damned finger to help.

You're a classic exploiter of the hard work of others.  Not willing to pay a cent, not willing to work up a sweat, but demanding that we do nothing that interferes with your ability to profit off of our hard labors.

Would some more people who are actually part of the project *please* read the documents and make some intellegent posts?  It's too  important for the opinions of poseurs like Stephan. who never has and never will contribute but will rather leach upon our work and bitch at us no matter what we do, to be dominant.

If a formal governance structure is stifling to Open Source, then how come it's working for Apache?

The model parallels Apache governance: "the Board retains ultimate responsibility for the foundation, it delegates decision-making authority for the technical direction of projects to the Project Management Committees."

Otherwise, what good is it to promote the brand when you may fear the sword will be turned against you in the future. I think Microsoft was using this tactic quite successfully, but that is just my gut impression 😊.

I haven't been much into dotLRN until now.  I haven't even used that code just saw one who is being used by my good friend Deds.  The site is to launch next week.  So guess the code is good.

I think its nice to have a governance for dotLRN and with users (teachers, MIT, etc.) a seat like Michael has pointed out.  It gives them assurance that what they invested in will not run away from their goals.

Also like Neophytos has stated he also wants some assurance that the consortium will not turn againts him and other developers.

So I guess both camps is just looking for assurance.  One looking for some form of control and the other looking for not that control to impact him/her in a negative way.  I think things are closer than seen, maybe we just need to add more provisions to Al's proposal on the assurance that a developer will not have to face some legal actions.

Of course I can't say what I have stated is correct and in context.  Just my 2 cents after Talli told me about this thread.

Al chose them both as technical advisors

another comment on the continued references to the apache foundation. they are apples and oranges. The members of the apache governing bodies are the soul of that community, having intimate knowledge and experience as developers of the code base. the apache foundation members arose from their skill and contributions to the community as *developers*.

i understand the desire for busineses to have a neutral institution as a means to increase their own profits. but i find it strange from a few different perspectives. is mit sloan in the business of making money? what are the goals of mit sloan in this? second the institution itself appears not to be neutral, it appears as though its going to be dominated by MIT? who are potential initial members of its executive board?

in another sense, perhaps from a naive developer pespective, i don't care. as long as the code is free (as in speech) and such institutions do not dictate the development of the code.

An essential skill enables the reader in such contexts. It is the skill of abductive logic (Peirce, 1902) (Shank, 1993). The goal in abductive logic is not ultimate truth. It is the ability to advance one's inquiry, to shed further light on the problem at hand. Abductive logic is the logic of signs: the ability to extract meaning from a given set of circumstances and then to adjust one's inquiry as new information unfolds. The skill of Eco's 'Brother William' is a critical skill in an age of information.

The fundamental characteristic of the Internet is that it cannot be controlled. While local legislation can influence pockets of control, the Internet is a world wide phenomenon, with no one in charge, (with everyone in charge). The role of education in the age of information will be the development of disciplined readers, skilled in the art of abductive logic. Since we can no longer filter and select proper materials for our students, our highest calling as educators will be to support students in developing such discipline for themselves.

This is where the modern and postmodern minds collide. To the modern mind, there is too much information. The world is exploding with ideas and perspectives that cannot possibly be consumed. To the modern mind, we must control what people read so that truth might prevail over misinformation, so that quality might prevail over mediocrity, so that correct ideas might prevail over anarchy. But to the postmodern mind, attempts to control information are futile and naive. What control exists in the postmodern world will emerge -- not from the center, but from the periphery. This paper suggests strategies for enabling such peripheral control.

What is the good news?

After a meeting with the heads of both our medical school and the computer center in Heidelberg little stands in the way of dotLRN being the next platform at Ruprecht-Karls-Universität Heidelberg. I have approval on some funding to make OpenACS (and then dotLRN) international. After long and drawn out university wide user surveys and an extensive platform selection process (which also included flying to Boston and talking with the MIT group, OpenForce, the Berklee group, and others) initial funding will be coming from the Medical School and the Computer Center to do this if everything falls into place as we predict.

What are we going to start with?

We will attempt to coordinate and focus the resources of those who would like to contribute to making the OpenACS platform and the dotLRN application international. There will be parts of the internationalization of OpenACS that our university might not need for dotLRN, yet others might be interested in funding. For this process we will offer funding infrastructure, that is typically used by multiple institutions to bundle funding for ambitious research goals.

I will be posting more on this soon...

Why in the world are you posting this HERE?

We feel an initial general plan for dotLRN governance is a keystone that needs to be put in place before we can contribute AS AN INSTITUTION to the OpenACS community. After talking with many key players (in order to make an informed decision) Michael's and Al's fears, concerns, and argumentation above pretty much harmonize with ours.

Obviously the fact that we have two conflicting proposals creates a problem for us as we walk towards the starting block in Heidelberg, yet we understand that it is part of the process (as well as an indication of the freedom given to OF by Sloan... which is not what I would call stifling). I would like to emphasize that Al's proposal by no means indicates that technical decisions will be made by the Consortium. The structure Al proposes also introduces important checks and balances... and would give the consortium the opportunity to push the gatekeepers in a direction which echos the needs and wishes of not only the dotLRN user group, developer group, but also those of the greater OpenACS community when needed.

Don's post above that first mentions the Apache Foundation also echos a lot of what I wanted to say, yet I had to talk to Ben and Al on the phone before I could put it down in black and white.

After talking to both Al and Ben I can second Don's description of the fundamental philosophical differences in the two governance documents (it is bottom up tight vs. top down broad)

After meeting both Ben and Al personally, corresponding, and talking yesterday I think that they generally both want the same thing: the best thing for the community and for dotLRN.

We in Heidelberg also want the best thing for the community and for dotLRN and think a very broad and neutral Consortium (which could be seen as a contributing member of the OpenACS community) would work very well for both. The governance model presented by Al is what we are going to push for (it would make the platform a better bet for us in the long term and as Don correctly stated it will be much easier to get funding for). In contrast to OpenACS, in its present form dotLRN has a pretty clear function it is trying to fulfill based on ACES/SloanSpace. A specific function that we as a University are very interested in: sharing and LRNing built by the needs of a teaching institution. It is not a toolkit like OpenACS is, but an EDUCATION application based on this toolkit that has been built (in a nice general fashion) for a EDUCATIONAL customer (with very similar needs to our own).

What Ben proposal might lead to is a .LRN-OF, a .LRN-MIT, a .LRN-Berklee, a .LRN-Heidelberg... or even worse a dilution of the technical leadership within the OpenACS community (Malte please consider this). This would be a disaster for dotLRN (the prospect of having to support a distribution is something that my faculty can not sell to the computer center in Heidelberg). We have been talking to major players in the industry (WebCT, Blackboard, IBM, Sun, Cisco and others) and they all offer more or less boxed applications with secure futures and guaranteed updates and support (organize funding, install, and you are done). We host WebCT at our university and this is the path of least resistance, which is very appealing to institutions. An official .LRN package that mimics this will help it compete in this realm. Having additional "dotLRN compatible" applets (what Blackboard will offer with its "open-source" Buildingsblocks program and WebCT is planning with its SDK) and is not a problem, but there must be an official dotLRN group of applets. If a group wants to create a new distribution and apply the application to a totally different sphere... great, but it will have to be named something else (e.g. dotWRK). We want to avoid an uncoordinated free-for-all... we want to prevent a dilution of efforts... please do not forget that dotLRN is entering a specific market (open-source or not) and I can tell you that there are a lot of very interesting alternatives and movements. If we want dotLRN to succeed in the long term we feel there is a need for a broad governance that Al is moving towards that freely delegates to a strong technical leadership, that provides funding for the wishes and needs of the user community. There is a huge potential here and it is clear that we must proceed carefully if we want this to work.

The most important point I would like to emphasize is that we NOW see dotLRN as an MIT initiative, which for us means the final word on branding and governance at this point in time has to come from MIT. We want to enter the playing field as a partner with MIT interested in pushing dotLRN in the right direction. This must be clear... at the same time we want to promote the existing and developing fruitful relationships between MIT, Berklee, OF, Furfly, Musea, Collaboraid, Heidelberg, idividuals, and other members of the present and future community continue.

If we take an active part in this process our interest would be in acting as a member of this consortium... consolidating funding for good ideas that push the platform in the direction the community (users and developers of OpenACS and dotLRN) wants it to go... NOT forcing a technical direction. This little grain of structure must be put into place for dotLRN if the OpenACS community wants to benefit from our contributions.

We see the main advantages of choosing dotLRN not only in its functionality and/or architecture, but the fact that design can be driven by the needs and views of both the users and developers. One of the most important reason we want to change platforms now is to allow for us to respond to our user's needs quickly and remove our dependence on a single vendor. If we see a single party (or person) taking control of what dotLRN is then the risk and energy expenditure would be too great to warrant Heidelberg taking the "road less traveled by".

At this early stage (before the existence of the Consortium) the platform needs leadership with good intentions, a high level of trust, and a good track-record. After meeting with the MIT-Sloan group (and talking to a lot of people in the OpenACS community) we are sure that governance defined by MIT-Sloan will give all parties a voice and representation. I believe it will include our concerns, developer concerns, and those of the broader OpenACS community. As I mentioned above we want this to be a shared team effort... and we are ready and willing to play our part (next to the community building around dotLRN and the existing OpenACS community).

Some things Al might consider changing in the proposal:

".LRN governance will be defined by the .LRN Executive Board, to be named initially by MIT."

Change to:

".LRN governance will be defined by the .LRN Executive Board, to be named initially by the current stakeholders of the .LRN project"

" .LRN kernel: data model, scripts, templates, and general functionality related to club and class management, portal management, applet API. "

to  ".LRN kernel: data model, scripts, templates, and general functionality related to club and class management, portal management, applet API unless maintained by the current OpenACS distribution"

And last but not least, the community of OpenACS along with all it's stakeholders should think about adopting the proposal in general for OpenACS. Which leads to my last addition:

"In case of an OpenACS Executive and Technical Advisory Board existing, the dotLRN TAB will make every (commercially/educationally/whatever 😊) reasonable effort to prevent a fork or split of the dotLRN code"

What is the purpose of the Executive Board and how can it benefit developers? Hackers want to code. Great hackers write beautiful code and want to solve interesting technical problems. Most developers don't have this luxury. I hope that the Executive Board will develop a sound businesss plan for dotLRN and generate the resources to execute it successfully. Obtaining funding to grow the dotLRN community is one of the key priorities. If we are successful, a year from now we might be able to say to some of you: "Hey, we need this problem solved. Here is some funding. Go at it." Successful product development requires an infusion of funding for research and development. Obtaining funding for R&D is just one of the goals for the EB.

I think the first thing to remember is that dotLRN did not have to be an Open Source project at all; it could have remained a work-for-hire paid for by MIT and kept for MIT's private use.

Some folks seem to be saying "thank you for paying for the code, now give it to us and get lost". That's not a sustainable model for getting similar projects funded.

So before adopting it, and before making harder for those of us who do client work to convince them that there's value in making their code available, as yourselves whether we'd be better off if Al hadn't release the code at all but rather kept it for the private use of his audience? What if they'd decided to do it as a simple custom in-house project?

I'm not suggesting the two extremes are the only two points on the continuum, of course. But it is worth asking yourself "What alternatives did Al have to setting himself up as a target by inviting the community to help determine the governance structure for dotLRN?".

Someone asked if MIT's in the business of making money. Funders talk about building organizations that attract more funding (as is happening with the University of Heidelberg) not to make money but rather to leverage their funding.

This is why so many grants to non-profits are 1:1 or 1:2 matches (in other words you get $X if you can raise $X or $1/2X from somewhere else). Match grants account for about 50% of the non-government grant funding for most small to medium non-profits in my case. It's all about leverage.

• Discussion and debate (even heated debate)
• Compromise and flexibility
• Resolution

Since this seems to inevitably be a selection of one process or the other, I would hope those that want to choose a side would consider these points, look at the body of evidence of how the parties have behaved in the community up til now and make the decision accordingly.

talli

Where would we be today without that funded code base?

1.    There has been lengthy discussions in OpenACS community about evangelism or marketing effort. I think a consortium with all the benefits mentioned on other posts, is better positioned to manage this front. Because of  MIT 's worldwide reputation , their endorsement can be most helpful.

2.    Most of dotLRN  architecture/code is not specific to educational sphere. Already there has been discussion on modifying  that code base to function as dotWRK. If  we have different verticals lke dotWRK or dotMIL ( for Military !) still most of the core architecture will remain same. Collobrative computing core can not very much between different group. From this point of view, there is little for a dotXYZ consortium to manage on technical management front, only coordination with core architecture. So the technical management issue really concerns to OpenACS.

Talk, talk, talk and little action is the result of more than 2 people discussing technology.

(they're tech driven but not in a bottom-up way, there's a core committee that tries to make decisions by consensus but which, if necessary, vote)

I've personally worked on some extremely productive committees. This doesn't necessarily mean it feels productive but ... neither do discussions like this when you're involved with them.

But ... they can be.

From a functional perspective, I personally would also vote for option (c), i.e., all non-learning-specific code should be in OpenACS, and dotLRN should be a set of education-specific add-ons to the base OpenACS code, which is governed and maintained by the OpenACS community in any way they see fit. In my mind, dotWRK is a separate application, to be governed by the stakeholders who build and use dotWRK as they see fit. The fact that there is overlap between code that is useful in dotLRN and code that would be useful in dotWRK is perhaps an indication that the code in question should be contributed to and governed the OpenACS community. There may be complicating technical issues of which I'm not aware, but from functional and political perspectives, this division makes the most sense to me.

The truth is that, as I have been saying, the dotLRN consortium has their hands full just solving the very hard problems specific to teaching online. Those in the community who have not wrestled with these problems before may find it instructive to read Joseph Konstan's thoughts on the subject:

http://www.elearnmag.org/subpage/sub_page.cfm?article_pk=1665&page_number_nb=1&title=COLUMN

Konstan is both a programmer and a teacher. He is a prominent member of the ACM and a Professor of Computer Science at University of Minissota. Yet he says he will not teach online because he doesn't believe that it works yet.

Here is my reply to Konstan:

http://www.elearnmag.org/subpage/sub_page.cfm?article_pk=2547&page_number_nb=1&title=COLUMN

You will see that my reply to him, which is consistent with what I've been saying here, is that nobody can blame programmers for developing ineffective distance learning environments if the teachers don't know what they need from those environments in order to teach effectively. The flip side of this is that, just as nobody can blame programmers for the problem not being solved, nobody can expect them to solve it by themselves, either.

And it is not a solved problem. This is harder than CRM, or ERP, or CMS, or any other big, expensive three-letter piece of software. (And remember, OpenACS has not yet licked the CMS problem.) It's harder because the real challenges are not knowing what to do with the technology but knowing what to do with the pedagogy. You can't solve that problem by writing better tcl code.

Not convinced that the problem is as hard as I'm saying it is? Read this:

http://www.elearningmag.com/elearning/article/articleDetail.jsp?id=18563

Or this:

http://www.nua.com/surveys/?f=VS&art_id=905358138&rel=true

Or this:

http://www.electricnews.net/news.html?code=8108603

Note the dates on these articles. They are all recent. I didn't have to go trolling through years of archives to find a couple of complaints; all I did was to scan back through a few months on a daily blog about e-learning. It took me all of five minutes to find these references.

dotLRN needs teachers as equal partners on the design team if it's going to be more than just another adequate educational portal.

For those who care about OpenACS but don't care about dotLRN, I agree that generic code should be pushed out to the community for their stewardship as aggressively as possible. That plus GPL plus fair representation of the community on the dotLRN governing bodies should provide ample protection. For those who care about dotLRN...well...the MIT proposal or something like it is the only way to drive real innovation and adoption.

One more thing. Anyone who thinks that the dotLRN Consortium will dictate to the OpenACS project and in some sense "steal it from us" must not know me, because if you did you'd realize that this would only happen over my dead body.

-- Don Baccus

You cannot establish sound governance or bylaws around particular personalities.

-- Al Essa

If nothing else, Al has shown that he wants to be sensitive to the needs of the community, just by virtue of having this public debate. If his governance structure turns out not to work as well as intended, I have no doubt that he will modify it accordingly.  That is probably part of the reason for MIT's controlling of the process initially - so they can make sure a working process is in place before the committees are left to run themselves.

• I do thank MIT for funding dotLRN. This thread was put on a public bboard I am responding without anger or malice.
• Lots of companies funded the openACS port (including people who are self-employeed so aren't directly getting a check from the effort) and they aren't asking for governance. So again thanks to MIT for funding dotLRN but... again I ask, why a governance? Why do they feel they need so much control (and that IS what this is about).
• I don't get paid to work on dotLRN code and therefor really have no say except, you asked.

After all, in the past we've said this is ok. At least Ben and I and a couple of others agreed that it probably would be and no one objected at the time. We're not lawyers but we shared the same gut feeling.

If they wanted to Open Source it yet retain tighter control over its direction, they wouldn't bother with a governance process at all. They'd just do what they've done in the past - control direction by virtue of being the largest (for all practical purposes) funder. Face it, they'd drive it alone just like they drove ACES in the past and dotLRN to this point. Trademark, stature and money ... yep, they'd be the driver. They wouldn't have to listen to anyone.

So, sorry, there's really no getting around the fact that setting up a neutral consortium with representation by a variety of stakeholders means that they're ceding a significant level of control.

I honestly don't care what direction the governance or lack of it takes. It is fairly obvious that MIT can do whatever they want and even Ben's proposal is meaningless if MIT decides they don't like it, rendering this all moot.

As long as it is gpl anyone can use it and I am ok with it. If I think something sucks I can add/change/not use it.

I think what scares many people in this community is the fact that dotLRN is seeming to eclipse OpenACS and when the "Technical Committee" decides to change OpenACS to make something THEY want it will be very easy to do whatever the hell they want to do.

Will this happen? I don't know, I am just throwing out ideas, and also, most of the proposed changes are needed so I am not against any changes as things are now done.

What does happen though to OpenACS when this big (in name), funded committee goes head to head with the small fragmented user/developer base over a proposed change to the core that may break all of our sites? Who has the final say? What if the OpenACS community decideds they don't want it and dotLRN says fine, the fork begins. These issues need to be addressed somewhere.

Next, it is not my usual behavior to spill private email conversations in public, but I have to at least respond to your accusations.

• the initial proposal of the TAB that I made to Al included me as gatekeeper, plus one OpenForce engineer (Yon) and one Furfly engineer (you, in fact) in addition to participants from Berklee, MIT, and Heidelberg. After further consideration, I realized that this was unfair to other OpenACS contractors and chose to put you down as OpenACS representative rather than Furfly rep. On further thought, I realized that this would be perceived as too much OF power, so I changed my mind again and took Yon out of the equation, and then tried to focus solely on corporate users of dotLRN. Given Yon's quality of code and engineering insight and obvious dotLRN expertise, I felt this would be a short-term loss for dotLRN, but a long-term win given that it would allow others to get involved more quickly.
• I had a strong technical reason for proposing that new-portal not be in the OpenACS CVS. I had a discussion with you about it, and yes it took 3 days, but you convinced me. Am I being blamed here for once disagreeing with you even though I ended up agreeing?

Don, the only reason I can imagine you making these statements is that you're calling my motivations into question. I thought we were discussing a proposal, but now you're discussing my motivations. If you have questions about my motivations, let's start a different thread where you can comment on this all you wish and I will answer questions you have.

In the meantime, I propose that we make this discussion more productive by assuming that *you*, Don will be dotLRN gatekeeper. You're perfectly qualified enough to take on that role just like you are gatekeeper for OpenACS.

Let's discuss the value of the process. As Al said, we're trying to come up with by-laws independently of personalities. If you're pushing for more oversight because you're scared of the gatekeeper, your problem is not the process, your problem is the gatekeeper.

John wrote,

I think what scares many people in this community is the fact that dotLRN is seeming to eclipse OpenACS and when the "Technical Committee" decides to change OpenACS to make something THEY want it will be very easy to do whatever the hell they want to do.

Jon, as Don has pointed out, to the extent that MIT can do wthis at all, they can do it right now. They don't need an Executive Committee to do it. If anything, such a committee would get in their way.

And as you yourself have pointed out, the code is GPL. MIT could create their own Bizarro OpenACS if they wanted to, but that wouldn't make openacs.org or the people in it go away.

MIT can't steal OpenACS(even if they wanted to), and even if they could, forming a committee would not help them do it. I just don't see what it is that people are afraid of here.

* the initial proposal of the TAB that I made to Al included me as gatekeeper, plus one OpenForce engineer (Yon) and one Furfly engineer (you, in fact)

Regardless ... even if you were to suggest I have dictatorial control over a structure based on your proposal, I'd far prefer the model Al presents. And if it took giving you dictatorial control over the technical process in order to get Al's proposal adopted, I'd at least consider it.

I'm in agreement with something Michael has said to me in private. We've got one shot to make a presence in this vertical app space. This means chasing it aggressively if we want it. Is marketing an open source vertical app some sort of unknown? I don't know for sure but I don't see it as differing all that much from marketing a proprietary vertical app. The beauty of vertical markets like this is that you can identify a large piece of the potential adoptees with a great deal of precision. Just look under "University of ..." in every phone book in the country (or world, actually).

It's simple. There's no reason to wait.

There is, however, still a sizeable difference of philosophy: in Al's proposal,
the executive board has power to replace a gatekeeper or TAB member at
any time. But the executive board answers to whom? Adding layers on top of
the TAB doesn't magically create accountability because the top of the chain
is still "topless" as Don puts it. It only alienates the technologists from any
decision-making power.

Of course, being a technologist, it's hard for me to make the point that it's bad
to alienate technologists. But I'll say it anyways: it's bad to alienate
technologists. User requirements defined the features of dotLRN. But don't
forget that technologists made it modular enough that others could develop
for it. Pure user requirements direction led to SloanSpace v1, which became
so entangled in nasty technology hacks that one could no longer install it from
scratch (the data-model didn't install). And if you can't install it, then it's not
very useful to the community anymore.

• Should there be or could there be such a thing as .WRK? Absolutely.
• Would the .LRN governance mechanisms apply to it? Absolutely Not.
• Can someone take .LRN applets and distribute it with other pieces and call it .WRK. Absolutely Not.
• Can someone take a .LRN applet or all of .LRN and distribute it as .MINE? Absolutely.
• Can someone write code, not have it reviewed, and distribute it as a .LRN applet? Absolutely Not.
• Can someone package a distribution with non-canonical .LRN code and and call the distribution .LRN? Absolutely Not.

• How would this type of question be resolved in our governance model? For the most part not any differently than it would be resolved now.
• Who would decide? The gatekeepers, members of TAB, and the OpenACS community.
• Who might these be? People like Ben, Don, Lars, etc. The Executive Board has nothing contribute, nor should it, to these types of technology decisions.
• What then would be different from the current process? Well, for one, the User Advisory Board needs to consider this also if this is a serious proposal. For example, what impact would this change have on the existing user base? Will this be a costly upgrade?

I have seen to many organizational bodies, who execute their given powers on personal taste but on hard facts and logical decisions.

So, if I would be a gatekeeper of my module (isn't that the case anyway?), I'd not want someone else to tell me to piss off. If someone thinks that I am not doing a proper job, he could take my code, modify it, ask the TAB to adopt / approve it and let the market decide (or have the TAB give a recommendation or even take my code out of the tree, but not reinstate someone else to govern my piece of art).

So much for the developer in me 😊. From a business perspektive I think having a central controlling entity (top down, with button up elections [informal as it is now, or formal]) is better, especially as they can interact easier with the EB and talk about the stakeholders NEEDS than every developer seperatly. But those needs still can only be a guideance unless someone is paid for doing this work.

Looking forward to see another 30 postings when I wake up again. Gosh,  feels like /. 😊.

These people would be the gatekeepers. They would issue regular, public progress reports, just as the Mozilla owners do. They would respond to package enhancement requests and bug fix requests in public, just as the Mozilla owners do. And if they don't do a good job, the community could request that the TAB replaces them, just as the Mozilla governing body does.

Now, on the new site, we might be able to give each package its own ETP page and let package admins scribble to their hearts delight, let others in their group scribble on it, etc.

There wasn't a real system of accountability in that effort, whatever accountability there was involved my e-mailing folks a note saying "hey, what's up with your package? You haven't told me in awhile?"

Big problem we've had is resource, i.e. getting people to own all the packages. Like every volunteer organization I've ever been involved in, we have a fairly high level of turnover. Folks get busy with other things, like jobs, family, school and can't volunteer at a sustained level forever.

But it is important that we find owners for packages if we're to move towards asynchronous releases, in other words where the calendar maintainers can issue new versions of that package to fix bugs or whatever rather than wait for the next release cycle or force folks to download from CVS.

The TAB/gatekeeper proposals here don't include a description of this sort of delegation, no. However if precedent on the OpenACS side is followed certainly CVS commit privs will be given to folks who are able to maintain and enhance packages. What's missing is the fleshing out of a plan to more formally assign responsibility for packages such as you suggest.

From my POV the only weakness in your plan is that it doesn't address the resource issue. Also any such plan needs to recognize that most of the actual package code resides in OpenACS (calendar, news, etc). But over all what you're talking about is a formalization of what I tried to do on a very informal basis during the porting effort.

With that, let me say how I am thinking about the composition of TAB. We all agree that opensource communities are meritocracies not democracies. TAB's role is to guide us toward the the best technical architecture for dotLRN. It's also a given that dotLRN's substrate is OpenACS. I think then we would all agree that TAB should be composed of those individuals who have the most expertise with dotLRN and OpenACS (as *recognized* by the community), can make the best technical judgements about platform direction and architecture, and are in a position to contribute. MIT should not have representation in TAB just for the sake of representation. If it turns out then that the criterion means that the majority of people in TAB would be from OpenForce, so be it. If the gatekeepers and members of TAB have not earned their reputation and do not have technical credibility, then we have a problem and dotLRN will not succeed.

I am leaving on holidays in 5min but I just wanted to congratulate Al and Ben for their openess.

I am really excited about the future of openacs and dotLRN!

It's SCORM compliant in the sense as stated in this thread dotLRN and standards

We have internal specs but nothing ready to post to the community. We've developed this to 'scratch our itch' and will have to figure out what/how to roll it back into dotLRN so that it serves the general community (after we've launched :)

What excites me about the idea of dotLRN is that it potentially enables me to explore and share best teaching practices using the software code as a medium for that sharing. If I learn a new, better way to teach online, and that way can be supported by the software (or, as Don Norman would put it, the software offers the proper affordances), then others will find it easier to pick up on the same technique, extend it, and give it back.

Framed that way, it becomes clear that the software is only part of the code that needs to be maintained. It is entirely consistent with current Open Source methods that the people who know the code and write the code should have stewardship over that code. Under this more expansive view of what constitutes source code, it becomes clear that technologists should be the stewards of some pieces while educators (i.e., the people from MIT, Berklee, Heidelberg, and elsewhere who will be using dotLRN to teach) should be the stewards of other pieces. Multiple gatekeepers with multiple backgrounds are required to get the job done.

The view that I just described does not capture the fact that the users are also the customers here, which Al articulates so clearly and which is an idea that is completely absent in the Open Source story in general. However, the two views are complimentary. Business processes (or, in this case, pedagogical processes) are code. They are a part of the system in equal measure with the software that supports those processes. From a production perspective, therefore, the people who know these processes are developers every bit as much as the technologists are. If you look at major software project management methods like MSF (and RUP too, I think), you'll find that embedded into their role structure is this very idea. They embed the customer in the development process itself, from beginning to end. Open Source needs to get that concept in order for it to leap the gulf between writing applications for developers and writing applications for others.

Neophytus, for example, might decides dotLRN doesn't interest me. He might think, for example: "I don't give a shit about dotLRN and would rather be a pure hacker." Or he might find the governance mechanism too constraining and oppressive. Fine. The world needs people like Neophytus. But the world also needs dotLRN or something like it based on opensource.

Isn't this contrary to the "opensource" way? There is no single way that opensource communities work. Perhaps this doesn't have a precedent. But dotLRN is also unprecedented. We want this to be the killer app in the eLearning space: a vertical application that will be used by universities, schools, non-profits, *and* corporations. I am convinced that dotLRN will not succeed unless we accept as a first principle that Users Rule.

The main issue I suppose is, that Neophytos or someone else might think "I don't like the way dotLRN mechanisms work and I'm gonna start .MINE." How would the OpenACS project view .LRN and .MINE, then? Would .LRN and .MINE be just two competing projects that are based on OpenACS? What would happen if the two projects required different changes on the OpenACS core? For the sake of this discussion you can assume that .MINE empowers the developers to control the direction of the project. Provided that I'm a non-native English speaker, I would gladly rephrase if something is not clear in my post.

If there are conflicting changes that need to made to the OpenACS core, it clearly falls within the realm of  the OpenACS gatekeepers and has little to do with dotLRN (yet I must also say that I believe technical solutions closely follow technical problems... if needed).

That's why I've been trying hard to think of an example of a project comparable to dotLRN with a proven track record (committees that don't stifle innovation) and compare their governance model.

How about the Continental Congress? That was a committee that didn't stifle innovation. Now, if I made the same claim about today's Congress, some might find the statement to be a bit more problematic. What's the difference? It's all about what the committee does. Rules make our nation(s) possible. They make cooperation between nations possible. They make free markets work. Rules are, in turn, made by committees of stakeholders. The difference between rules and committees that make innovation possible and rules and committees that stifle innovation depends largely on what the committees do and do not try to accomplish. The Continental Congress created the rules of a game where anybody could play. Their goal was not to control the game but to define it in such a way that playing that game was to everyone's benefit. The goals of today's Congress are, unfortunately, often quite different.

The critical question in our case is this: What is it that the committees are supposed to do? Are they supposed to micromanage the development of the application? If so, then we would have real cause to worry. However, that is not how the purposes of any of these committees have been defined.

Keep in mind that the dotLRN "governing" bodies in no way restrict what Open Source developers can do; the GPL ensures that. Innovation still comes from the bottom--by design. The committees are designed to create an environment that both fuels the grass roots source of innovation and provides participants with better ways to get the most out of the product of that innovation. The fuel innovation by providing a channel of information to the developers (and I use the term "developers" to mean the teams of people who are scratching their own itches, including but not limited to programmers) from the wider world about what other people might find useful. They in no way direct the efforts of the individual development teams, except perhaps by encouraging and supporting them with funding, feedback, and inspiration. Once the development has happened in the Open Source style that has proven so effective, the committees collectively help to evaluate and categorize the output of the individual efforts to make sure that output will be as useful as possible to as many constituents as possible. Again, anybody can do whatever they want with the code, as long as they don't call it dotLRN. The existence of these committees in no way stops anyone from trying anything. What the committees do, collectively, is apply a seal of approval to a subset of the code that emerges as a result of the innovation that the combination of Open Source and open markets brings. They lower the barrier for people and organizations who want to play the game but are afraid that they don't have sufficient knowledge to choose the combination of Open Source parts that meet their needs at an acceptably low risk. If you don't care about the dotLRN seal of approval, then you as a developer or consumer are in no way constrained by what they have to say. They have power only to the degree that consumers and developers choose to opt into their system. In other words, their power rests entirely in their ability to nurture and sustain a community that agrees to invest (time, money, risk, whatever) in dotLRN because the benefits they gain from doing so outweigh the rules that the community imposes as the price of entry. That's no different than OpenACS, really.

Committees are neither inherently good nor inherently bad. Rules are neither inherently good nor inherently bad. Markets are neither inherently good nor inherently bad. Open Source is neither inherently good nor inherently bad. Licenses are neither inherently good nor inherently bad. All of these are simply tools we use to tune the incentives that various stakeholders have to innovate, participate, and collaborate. All of them can be used poorly or well.

I think the design we have on-hand promises to serve our collective purposes well, if we remain vigilent and remember that they are means to a collective end.

How long will it take before the dotLRN kernel and OpenACS kernel drift apart, if they receive separate Governance?

So no forking's involved. Indeed everyone has as a goal the prevention of forking.

Maybe our terminology needs to evolve :)

Those wars were purely piratical. Pride, gold, women, slaves excitement were their only motives. In the Peloponesian war, for example, the Athenians ask the inhabitants of Melos (the island where the "Venus de Milo" was found), hitherto neutral, to own their lordship. The envoys meet, and hold a debate which Thucydides gives in full, and which, for sweet reasonableness of form, would have satisfied Matthew Arnold. "The powerful exact what they can," said the Athenians, "and the weak grant what they must." When the Meleans say that sooner than be slaves they will appeal to the gods, the Athenians reply, "Of the gods we believe and of men we know that, by a law of their nature, wherever they can rule they will. This law was not made by us, and we are not the first to have acted upon it; we did but inherit it, and we know that you and all mankind, if you were as strong as we are, would do as we do. So much for the gods; we have told you why we expect to stand as high in their good opinion as you." Well, the Meleans still refused, and their town was taken. "The Athenians," Thucydides quietly says, "thereupon put to death all who were of military age and made slaves of the women and children. They then colonized the island, sending thither five hundred settlers of their own.

-- William James, The Moral Equivalent of War.

Melians

Well, then, since you set aside justice and invite us to speak of expediency, in our judgment it is certainly expedient that you should respect a principle which you know is for the common good; that to every man in peril a reasonable claim should be accounted a claim of right, and that any plea which he is disposed to urge, even if failing of the point a little, should help his cause. Your interest in this principle is quite as great as ours, inasmuch as you, if you fall, will incur the heaviest vengeance, and will be the most terrible example to mankind.

Athenians

The fall of our empire, if it should fall, is not an event to which we look forward with dismay; for ruling states such as Lacedaemon are not cruel to their vanquished enemies. With the Lacedaemonians, however, we are not now arguing; the real danger is from our many subject states, who may of their own motion rise up and overcome us, their masters. But this is a danger which you may leave to us. And we will now endeavor to show that we have come in the interests of our empire, and that in what we are about to say we are only seeking the preservation of your city. For we want to make you ours with the least trouble to ourselves, and it is for the interests of us both that you should not be destroyed.

Melians

It may be your interest to be our masters, but how can it be ours to be your slaves?

Athenians

To you the gain will be that by submission you will avert the worst; and we shall be all the richer for your preservation.

Melians

But must we be your enemies? Will you not receive us as friends if we are neutral and remain at peace with you?

Athenians

No, your enmity is not half so mischievous to us as your friendship; for the one is in the eyes of our subjects an argument of our power, the other of our weakness.

-- Thucydides, The Melian Debate (http://www.wsu.edu:8080/~dee/GREECE/MELIAN.HTM)

As far as the chat, I would gladly publish a log of it (it's on my desktop computer right now and as I mentioned there is no power/electricity now -- but I think it can wait until Friday if this is want you want me to do and there is consensus from the other person), if it is ok with the other person or I could summarize provided again that s/he accepts me doing that.

It may be your interest to be our masters, but how can it be ours to be your slaves?

I think you owe Al a personal apology.

The OpenACS project decides and/or nominates and/or elects its representatives to the .LRN Technical Advisory Board

Eventually something more formal and more democratic should evolve, perhaps along the Apache Model. Personally I don't think today's the day, though.

Aa far as your list goes you're saying "the OpenACS gatekeepers should be the Technical Advisory Board for dotLRN". I don't expect the list to be 1:1 as you propose but I do expect people from that list to be asked to join the TAB.

As far as the OpenACS project and dotLRN project being separate, that's easy to state. They are separate so, sure, we'll tell you they're separate. No one has ever said anything to the contrary.

I still think you owe Al a personal apology for suggesting that MIT's blueprint for governance of dotLRN is a masked attempt to enslave the OpenACS project.

Regarding the issue of OpenACS nominating its own board members, well, you can ask, but you certainly have no right to demand. The GPL says MIT has the Freedom to do whatever they hell they want to with OpenACS code without consulting you, whether you like it or not, so long as they don't sell it. So any cooperation here--in both directions--is strictly voluntary. As Don says, I think you'll find that the TAB *will* reflect a serious attempt on MIT's part to actively engage the OpenACS leadership.

Regarding the allegation that multiple people were asked to be quiet, there were two people who made such claims. One of them was you, Neophytos. The other was Stephen Deasey in response to a private email that I sent him. As I noted earlier, I vehemently deny asking him to keep quiet. I did not ask him to do *anything* other than look at my user profile before casting aspersions on my motivations. If he wants to share that email with you, either publicly or privately, fine. It's a shame, though, that your level of trust is so low that it has to come to this.

And I happen to agree with Don: Regardless of how you feel regarding these various issues of substance, your overheated rhetoric is, to say the least, unhelpful and ungracious. You can attribute the words to somebody else, but you were the one who decided to post them in this context.

He's dropped out.

After convincing me to delegate 4.6 and 4.7 status and organizational tasks (as you took on with 3.2.5) he's now disappeared.  Won't follow through on his commitments.

After promising an XML-based service contract package ... now he won't play.

After committing to a tclDOM replacement for ns_xml ... we're on our own, he won't do it.

Yes, we're paying a very severe price for not allowing him to dictate terms to the dotLRN project which, after all, is *owned* by MIT.

Neophytos,

I appreciate your contributions to the discussion, yet I do have the feeling that there is a serious misunderstanding here.

I would like you to try to place yourself in our position in Heidelberg for a moment so that you understand why we are so supportive of Al's proposal and feel it is beneficial to both OpenACS and dotLRN.

I am a member of a university that is the oldest and probably one of the most well know learning institutions on German soil. Some main goals of my university is the spread of knowledge and information, the creation of an environment for learning, and the promotion and support of innovative research and projects.

This makes it easy to understand why dotLRN is a project that fits very well into the focus of our university. My belief in this is one of the main reasons I have been pushing and promoting dotLRN with such energy here in Heidelberg (idependtly of OpenACS).

This push has paid off. I have the green light on funding to implement dotLRN in Heidelberg.

Okay... what do we need to make dotLRN happen in Heidelberg?

A German version.

What are our options?

1. Start translating the UI elements of dotLRN and start using it.
2. Talk to people in the community to see if there are others with common goals. Start a discussion, collect feedback, become part of the community, find out what needs to be done in order to make it happen right. Find out who wants to do it with us. Make sure that other languages can be added quickly an easily (I would really love to see a Greek version of dotLRN). Make it happen.

It is clear to me that 2 is the way to go, but the way everything is set up at the moment it makes it hard for us to bundle financial resources of different parties in order to get this done together (in fact the way things are right now it would probably be easier to try to make this happen alone).

It is obvious to me that dotLRN is just an application built on top of OpenACS and that we need the internationalisation work to go into OpenACS. It is also obvious to me that without support of the OpenACS gatekeepers it can not go into OpenACS (this is regardless of how much money we invest in it or who is in the dotLRN Consortium).

I would like to emphasize how we would see our role in the dotLRN Consortium.

1. To help outline mutual goals
2. To help provide structures to consolidate energy and funds of diverse groups, so that we may reach common goals quickly and efficiently.
3. To insure dotLRN user representation and communication with coders
4. To support and promote dotLRN as an application and OpenACS as a platform
5. To find funds for projects that are of mutual benefit (to both dotLRN and OpenACS)
6. Push all general functionality that could be useful to more than just learning communities back into the OpenACS toolkit where it can grow and become more that it already is.

Another Example:

A consortium would make it easier to fund things that may not (at this point) be specific to our needs in Heidelberg or the needs at MIT, but are clearly beneficial and necessary in the future (for both OpenACS and dotLRN). Supporting a tclDOM replacement for ns_xml seems like a strategic move that makes sense (just as supporting a XML-based service contract model does). If you or someone else from the OpenACS project convinced the TAB of dotLRN that this is something we need, as a single university I am going to have difficulty finding money from Heidelberg to help you make this happen (even if both the gatekeepers of dotLRN and OpenACS say "WE NEED THIS"). These are "itches" that my university would have problems giving money to "scratch" (because they presently do not feel them). The Consortium would allow a pool of money for this kind of thing (it would also be more sensitive to these kind of itches).

Neophytos,

I can see a lot of reasons for you being upset. I also understand your fears (we had the liberty to fly to Boston to talk with a lot of people to clear up some of the communication problems by personally meeting people involved). Lacking transparency is a problem that all parties are aware of (everyone has been so busy they have neglected it) . I have been told that it is going to a major priority in the future.

Online communication is difficult, because a large amount of language is lost between our bodies and the keyboard. I ask you to PLEASE reconsider you decision. I really want to avoid you being referred to as cannon fodder in the future, because your commitments make you a very important person for OpenACS (and dotLRN) at this point (not to mention the fact that we we would love to have your input and help on the internationalization work).

Sincerely, Carl

Neophytos,

I think it is important that I emphasize the following:

1. The dotLRN technical advisory board (or any other dotLRN board for that matter) does not directly effect OpenACS in any other way than over the dotLRN gatekeeper (I think Lars' diagram helps make this clear).
2. Obviously we want people from the OpenACS community on the dotLRN TAB so that all the gems and diamonds coming out of dotLRN have an even better chance of getting pushed back into OpenACS (to be used by the wider community). It also makes sense to us that these jewels flow back into the base toolkit so that they get looked at from many different perspectives (not just the dotLRN view) and polished so that they become more valuable to all (it also prevents dotLRN from growing out of control).

I have noticed that Don tends to shoot his mouth off, but I can totally understand this considering the passion and energy that he and others have put into OpenACS. 😉

Please remember that dotLRN and its governance is VERY separate from what OpenACS is and OpenACS is much more than just dotLRN. Like you... I would like to see as much of the OpenACS leadership on the TAB of dotLRN to lend the project stability, but dotLRN has very different goals and I am not sure they would all be willing or have the time to deal with some of the things that need to happen for dotLRN to be a success. dotLRN is what it is now because of Ben and others from OF. OpenForce has put amazing work into dotLRN and they have done this in very beautiful ways. I argue that dotLRN beauty and potential is a result of Al choosing these leaders from the OpenACS project (like Ben) to do the job. I hope the strong technical leadership and vision that OpenForce has provided will continue to play an important part in dotLRN's future success. We need Ben and others from Openforce like Yon and Arjun, but we also need to give the users of dotLRN a voice and provide (very minimal) structure so that other large organizations can jump on board without making the ship capsize.

Neophytos, I ask you once again to please reconsider and fulfill your leadership commitments to the next version of OpenACS. OpenACS works, because of volunteers like you and like other projects based on OpenACS dotLRN depends on this. If one thing is needed right now it is leadership and people in the community seem to trust you to provide this (please consider this).

Carl

P.S. Here is a thread that you might want to follow... Community building vs. privacy in online learning I hope it is not as a much of a roller coaster ride as this thread has been.

I said this in response to your saying that you were going to fork off your own version of dotLRN and encourage others to join you and leave the main effort.

There is a new OpenACS Governance effort on its way that could settle all this... You might want to join in with ideas on how to reach such a goal:

https://openacs.org/forums/message-view?message_id=49881

If you have no objections, I would probably like to discuss the dotLRN governance with you nearer the time, to make sure I understand the implications fully, and also so both our efforts have the necessary synthesis.

Regards

Simon

Please don't get me wrong, I'm *NOT* trying to beat the horse again (hope I'm saying this right). Rather, I'm just bringing up some concerns I (and others) have with respect to the executive board and the future of dotlrn.

I can say that there is a LOT of interest in dotlrn from talking many times to people at LinuxWorld. I'm glad that MIT chose to base it on OpenACS, and has funded its initial development, and that Al Aessa has been understanding and patient with the community. The input given by many on this thread have been really interesting, and certainly would make a good reading for open source project leaders if summarized.

It's great that the executive board will focus dotlrn on the needs of the users (to paraphrase Al Aessa). I don't disagree with the existance of such board. However, my main concern is what will happen if/when the board becomes populated with people with vested interests on _THEIR_ dotlrn users?

To be more especific, I've heard rumours that Microsoft is _sponsoring_ a port of dotlrn (and apparently a good chunk of OpenACS) to .NET. In that case, if my understanding is correct, Microsoft would be a part of that board.

Given past experience of how Microsoft behaves when dealing with committees and competitors, and how much clout they have, I fear that the board would get corrupted in every sense of the word, especially technically speaking, since TAB decisions can be overruled by the EB.

Again, I don't disagree with having a board inasmuch as we have trustable people there. I also agree with it being focused on user needs. Are/will there (be) provisions to avoid such thing from happenning?

Thanks.

-Roberto