Home
The Toolkit for Online Communities
17513 Community Members, 1 member online, 2204 visitors today
Log In Register
OpenACS Home : Forums : .LRN Q&A : Request for Comment: dotLRN Technology Governance

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

Icon of envelope Request notifications

I have posted a draft of dotLRN Technology Governance on the dotLRN web site for your review and comment. Later today Ben will be posting a very different model. Both of us look forward to your comments.
Collapse
Posted by Stephen . on
In the introduction the scope of .LRN is defined to include some code which has already been commited to the OpenACS project.  Do you mean to apply this process to this now OpenACS software, or just to .LRN software?
Collapse
Posted by Alfred Essa on
Stephen, which clause are you referring to? I would like to remove it if there is any ambiguity. The governance would apply only for dotLRN, not OpenACS. --Al
Collapse
Posted by Ben Adida on
Stephen: I agree with Al, this should cover what is packaged and distributed as dotLRN, not fixes and things that are generic and rolled back into OpenACS. OpenACS governance remains independent.

Here is my proposal for dotLRN governance:

http:// dotlrn.openforce.net/project/governance.adp

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!

Collapse
Posted by Talli Somekh on
Thanks for the two documents, Al and Ben. While I've gotten a good sense of both perspectives from reading them over, would it be possible to get quick executive summaries or basic position papers?

The philosophic differences are generally there, but a more specific and fleshed out discussion of the goals of the governance docs from both perspectives would be very helpful.

Thanks.

talli

Collapse
Posted by Ben Adida on
Talli: I'm not quite sure I'm reading you correctly. Are you looking for a
summary of the philosophies, or a more fleshed out discussion of certain
issues within?
Collapse
Posted by Talli Somekh on
Sorry Ben, yeah, summaries. Sorry for being unclear. Summaries would be really great.

talli

I haven't make up my mind on all the points addressed in the two documents but I want to address copyright ownership first and the rest of my comments will follow.
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

I think this paragraph from Ben's document is very important and as far as I can say it is not adequately addressed in Al's document. My major concern by reading Al's document is the fact that the consortium would encourage transferring the copyright to the consortium or would have the ability to enforce this (Executive Board --> TAB --> Gatekeepers).

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.

Collapse
Posted by Alfred Essa on
I am open to suggestions on this. How should copyright work for dotLRN kernel and applets? There should be a two part answer. What should be done now, in the interim. What should be done once a formal dotLRN consortium materializes.
Collapse
Posted by Don Baccus on
The MIT version includes this:
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.
Open Force's includes this:
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.
The only real difference is that Al names a particular third party - the dotLRN Consortium. Al's wording implies that this is not a requirement, while Ben's explicitly states it. Ben's wording includes the word impartial, Al earlier defines the consortium as being neutral, i.e. not dominated by any particular institution or vendor.

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.
In other words there's a degree of top-down direction provided by the Board of Directors similar to Al's description of the Executive Board, and the PMC's have a certain degree of responsibility to the Board of Directors.

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

Collapse
Posted by Stephen . on
I was thinking that the new portal package had already been imported into OpenACS, but it looks like just the old one is there, my bad.  That's the direction though right? Generally useful stuff developed for .LRN was to be folded back into OpenACS?  It's just that your document, Al asserts specific rights over portal/portlet scripts, datamodels and APIs.

Would .LRN be kept as a seperate download, and any code integrated into OpenACS would not be considered under the control of any .LRN organization?

Could there be some sort of contingency that bequeaths copyright ownership to OpenACS, GNU/FSF, opensource etc. upon the selling or dismantling of the formal organization?
Collapse
Posted by Don Baccus on
Well, the docs are supposed to be about governance ...

you'll notice an amazing similarity between Ben's description of the kernel and Al's.  That's due to cut and paste writing on Al's part.

Technically dotLRN does some portal management of its own through the applet mechanism (adding portlets to pages) so saying "portals management" is part of the kernel doesn't say that the new portals package won't go into OpenACS.  Nor does it say it will.  In fact it doesn't particularly say anything about the new portals package, only that dotLRN does portals management.

How's that for beating around the bush :)

As to where the new portals package lands that's really a technical decision, I think all are agreed that at this level we're looking to do the right thing.  IMO the new portals package should replace the old portals package in the standard OpenACS release but such a discussion should take place in another thread.

Collapse
Posted by Stephen . on
Absolutely Don, but would the continuing development of portals be then down to OpenACS or under the .LRN commitee?
Collapse
Posted by Ben Adida on

Talli makes a good point that the philosophy of each proposal may not be clear. I'll try to help on the philosophy of the OF proposal:

An open-source project is generally successful because it has strong technical leadership and a modular design to allow for distributed innovation. The OF proposal seeks to provide direction with an empowered, technically-oriented gatekeeper (whose term should be limited in time to prevent abuse of power) and to allow innovation by minimizing the extent of control.

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.

Hmm, and I was always under the impression that dotLRN is "only" a large package / application running on top of OpenACS, specificly useful for education. But reading both papers I think it is something completely seperate, an entity of its own, with some ties to OpenACS.

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.

Collapse
Posted by Ben Adida on
Malte,

One important thing that I believe everyone strongly believes: dotLRN is an
OpenACS application. It remains entirely dependent on OpenACS. There is
no dotLRN without OpenACS, and components of dotLRN that are sensical to
roll back into OpenACS get rolled back into OpenACS.

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?
Thanks Malte. You saved me from writing a lengthy message -- given the fact that I'm not a native English speaker that would take a lot of my time. Well, I share some of the same questions/concerns that Malte posted in his message. No need for me to elaborate on that.I would appreciate some answers as well, though.

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."
In what way, could something similar work for the .LRN and/or OpenACS consortium? I'm not delusinating here -- I know and comprehend the fact that Sloan funded dotLRN. OTOH, though, "There is no dotLRN without OpenACS" and I'm quoting Ben here. OpenACS is powered by the blood, sweat, and tears of the OpenACS community ("the people who fund it") and I'm quoting the footer on our front page here (probably written by Don). In what way the consortium will recognize/empower the contributions of the OpenACS community and the "Foundation Members" in the sense that they are recognized/empowered in the Apache Software Foundation?

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).

Collapse
Posted by Alfred Essa on
One important practical difference between the OF and MIT proposals concerns this question: Who decides platform direction?

In the OF proposal, all power emanates from and is concentrated in an uber-technical-gatekeeper. In Ben's words: "The OF proposal seeks to provide direction with an empowered, technically-oriented gatekeeper." The MIT proposal tries to establish a checks and balances among multiple and possibly competing stakeholders. Above all, it recognizes that users as well as those who fund dotLRN development need a seat at the table. In my opinion, dotLRN will never get off the ground unless this is explicitly recognized from the start in the governance model.

Now, what happens if the uber-technical gatekeeper also happens to work for a vendor? It's no secret that Ben is the obvious choice for dotLRN kernel gatekeeper. I would be the first to support that choice. But Ben is also the CEO and CTO of OpenForce. What are the checks and balances to ensure that the uber-gatekeeper will not skew platform direction in the interests of his/her company? What is to ensure that the uber-gatekeeper will be responsive to the needs of the users and funders? What recourse do the users and funders have?

Whether I trust a particular gatekeeper or not is irrelevant. You cannot establish sound governance or bylaws around particular personalities. Ben would mitigate the risk ("abuse of power") by limiting the term. Well, that's marvelous. If it's a one year term as is being proposed, that's more than enough time to sink the project into oblivion based on a few mistakes, unresponsiveness, or poor strategy.

We decided to go the opensource route for business not ideological reasons. We didn't want to be locked into one vendor. The OF model is worse. We could end up banking our entire strategic technology on one individual working for one company. No organization with any business sense will buy into that model. In short, the fundamental flaw in the OF model is that it lacks systematic provisions for allowing users and funders, two critical stakeholders, to influence platform direction.

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 Baord. 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 (http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0005YN&topic_id=15&topic=dotLRN%20Development) and (http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0005ax&topic_id=15&topic=dotLRN%20Development) 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 unsually 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 represntation 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 committment, 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.

Collapse
Posted by Stephen . on
Hardly.  If you don't like the direction things are going then stop paying Ben's wages and take the Open source code to some one else.  How is this anything like being locked into one vendor, never mind worse?
Collapse
Posted by Alfred Essa on
Ben's implication that the MIT plan would subordinate developers to "committees" is based on a misinterpretation and misreading. We state that the "Executive Board delegates decision-making authority for the technical direction of the kernel and applet development to the gatekeepers, developers, and the Technical Advisory Board."

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.

Stephen, I can take my app and go home, but then I'm alone. Institutions do *not*, by and large, want to be supporting their own custom apps when they can possibly avoid it. Given a choice between that and buying a mediocre closed source app, they'll buy the closed source app.

The whole point is being in a community. If I'm a developer, I can lead a team of developers and hopefully form a new committee. Have you ever heard of a sponsoring organization creating a new Open Source community with money? It doesn't happen. The non-developer stakeholders can't go it alone and they can't start their own community either. They're locked in.

Collapse
Posted by Stephen . on
That's the most wrong-headed nonsense about Open Source projects that I've ever read Michael Feldstein.  You're so completely off the mark it's difficult to know where to begin, or if it's worth the bother.

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 ;-)

Stephen, I am making no threats at all. I've been in this community at least as long as you have, and while I can't contribute code, I have contributed everything that I can, including my perspective.

What I'm saying, as a long-standing, committed member of this community who knows the audience you are now trying to sell to for the first time intimately well, is that you'll never succeed this way. *We'll* never succeed this way. I'm not saying I won't sell this to my clients. I'm saying I can't because they won't buy it.

This is not just about Open Source. It's about developing an application for an audience to which the developers do not belong. I'm saying that if you go this route you will waste considerable precious volunteer effort, not to mention the money of the investing stakeholders, and not attract the other buyers that will make this worthwhile.

This is not a hobby. It is not a club. People are building this app so that other people will use it. So that other people will pay for their services and expertise. If you want that to happen, then you'd better look again at your governance structure, because the OF plan will turn them away. Not me. Them.

Collapse
Posted by Alfred Essa on
Stephen, as a business proposition if I fork, I lose. As Michael notes, at the end of the day that's no different than undertaking in house development or paying for custom development. Yes, having access to the source code can be advantageous. But it's a form of insurance, and only that. I would rather not have to collect.

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.

Collapse
Posted by Stephen . on
The sweet deal on offer here is free code, free updates, proven success at high profile institutions, and a pool of skilled development firms to choose from to implement your customisations (should you need them).

If you can't sell that, well then I guess that must be a bit dissapointing as far as your own personal business interests go.

Luckily, there are many enlightened institutions who have already decided that it is indeed a pretty sweet deal, and will be rolling out .LRN to their users.  They'll succeed because they have an honest, obvious stake in seeing it do so, and they have every oppertunity.

I can't imagine the kind of scenario you seem to fear in which a lone developer can hold an entire community of his wage payers to ransom. At this point, HE has effectively forked, you can replace him and carry on as if nothing had happened.

For such a vicious attack on Ben and developers in general, I'm suprised no one has anything to say.  Perhaps I'm not the only one being asked by email to please keep quiet because Michael has some business deals cooking.

Collapse
Posted by Tracy Adams on
The idea of a consortium is particular inspiring to me because I think it can open up a whole range of possibilities for the future.

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.

Collapse
Posted by Alfred Essa on
There are some mythologies that we need to get past. I am quickly learning that in discussions of opensource there are many.
<p>
Ben writes: "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."
<p>
Given the premise, the conclusion is plausible. The myth is that dotLRN originated fully formed, much like Aphrodite, from the brilliance and technical foam of OpenACS developers. Let me remind everyone of the facts. OpenACS version1 is SloanSpace version2. SloanSpace v1 was developed and evolved as a collaboration between users, developers, and people like Caroline Meeks and Michael Feldstein who know how to interpret and articulate user needs. I remember one innovation that Michael suggested and we ultimately implemented that made a huge difference in an Executive Education course offering for Merrill Lynch. SloanSpace and, therefore, dotLRN would not be possible without users and user experts such as Caroline and Michael. Our ability to add new features incrementally based on input from students, faculty, staff, and alumni was the decisive reason for SloanSpace's success.
<p>
I want to give recognition to developers and the technical community that has built OpenACS and dotLRN. But let's not perpetuate this mythology that a vertical application can be successfully built and made to evolve entirely by developers.
Stephen, I believe I pointed you to my user profile here on OpenACS.org and asked you to reserve judgment on my motives until you've had a chance to review it. I don't believe I asked you to keep quiet, or to do or not do anything, for my business reasons or any other reason. I was simply trying to show you that I have a track record here, that I am not attacking hackers, that it is rare for me to come on strongly as I have in this thread, and that when I do so it's because I care about what happens to this community. Clearly, I failed. If you or anybody else who doesn't know me wants to find out more about who I am to presume to speak so strongly here, I encourage you (again) to look at my history: http://openacs.org/shared/community-member.tcl?user_id=50.

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.

Collapse
Posted by Talli Somekh on
Many of the people posting here today are familiar with the background of the governance issue. That is to say, what has been going on off the boards. I am not one of those people, so this is the first I've seen of this discussion.

As the representative of an OpenACS company, as a committed member of the community, as a vendor to Sloan and having at least one client that is interested in using dotLRN, I certainly have a lot of interest in how this issue is settled. Since today is the first time that I've been exposed to all of this, I am trying to withhold judgement until all of the parties have an opportunity to express themselves. And I also am trying to think of the best solution for the project, rather than the opportunities that could present themselves if either proposal is selected. I would like to stress that last point.

In the past, I have been relatively outspoken, on and off the boards, that the dotLRN project and all of the OpenACS project, needs to have more transparency in the way that decisions are made. I think that both of these proposals present ways that this can be achieved.

IMHO, it's very hard to tell the people who have put the money up for the project that they can't decide on its direction, right or wrong. I understand Ben's intentions, though, that it's important for a free software project to be relatively free of influences other than what is best from a software perspetive.

I have been assured by people I respect that Sloan's intentions in having a neutral body oversee the dotLRN code are true. That's generally more than enough for me, but I do still worry about who Sloan might want on the consortium. Al, could you speak to that?

On another note, Stephen, I think you're being unfair to Michael, who has put a lot of energy into this community and this project in terms of vision and input. While he's not a hacker, he deserves as much respect as any tcl developer out there.

You are generally a contrarian when posting on the bboards, but you usually back up your claims with solid technical ideas. And I'm not one to talk about making strong statements here. But IMO Michael has contributed a great deal for a long time, probably more than you have, and he's done it more politely and reasonably.

I think I understand your frustrations with regards to the way development is sometimes done in the community, but I think here they are very misplaced. And I don't think Michael's integrity deserves to be questioned. You're more than welcome to question mine, but Michael, and Al for that matter, has always been forthright and honest, on the boards and in private.

They certainly don't need my defense, but I think they deserve more respect than that. Especially since there's been a lot of non-OpenACS discussion going on in private that could have, and maybe should have, remained that way.

talli

Collapse
Posted by Don Baccus on
Stephan ... I'll listen the day you actually contribute to the OpenACS project with commitment, leadership, code, documentation, or anything other than unrepentanent bitching.

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.

Thoughts of an heretofore noncontributing, bumbling OpenACS fanatic..

Talli's right. To the extend that dotLRN is not opensource, its management is directed by immediate organizational (operational) needs and therefore this discussion (in an opensource forum) could be deemed irrelevant in the context of the opensource community. The project could have it's own directives, funding etc. and exist harmoniously with the openacs community whether's its run by a benevolent dictator, Roman style congress etc.

Is there wisdom in trying to create a religious, formal organization around an event or manifestation of opensource resources?  Religious wars come to mind... We might be evangelists... hopefully not blind separatists with OpenACS and dotLRN vying to go different ways.

Is this thread related to an identity boundary problem?

My first impression of the documents suggests there is an underlying attempt to govern the opensource development. The spirit of the cooperative opensource culture becomes limited when governed or directed by organizational directives (based on thought and needs alone). Organizations tend to quash creative inspiration for example.

For the spirit of cooperation to prevail, any organizational involvement needs to be supportive to the community --not the other way around. An organizational structure needs to consider the social, economic and functional impact in the existing and evolving environment. I believe the authors of the documents are trying to create a supportive organization --but there are many traps in that paradigm.

Does one organization need to be *the* representative for grants, financing etc developing this learning system?  Should cooperation be constrained to international ventures (with organizations formed in other countries) only? Legally, an organization could be formed with the same purpose in any other country...  This community is more dynamic than what can be supported by any single organization. Still we know that an organization can play a supportive role in this community --they have. The Sloan/MIT/dotLRN project has many internal objectives that are shared with the community, and DotLRN has a leading role in OpenACS development.

However the organization is formed, I'm certain the experience will be positive as long as the underlying principles that foster an opensource community remain.

So why ask the community for comments? Is it to gain a consensus on what would be most accepted by the community? or is it that the community has a diverse perspective --creativity is one of its resources-- thereby helping organizers to think outside of the organizational box?

I would like to know more of the requirements (and motives) behind the strategy on these structural/operational outlines before commenting further.

Isn't Aduni.org's objectives similar? Why not use Aduni as a launching platform?

It may be days before I get another chance to reply. This message is written with goodwill to all, and a sincere interest in positive outcomes for everyone... best wishes, Torben

Just in case I have to mention that I *DID* contribute and I got no answers, yet, on the questions that are still puzzling my mind. Everybody, tells me how good this consortium is supposed to be. I'm not convinced yet, sorry.
If a formal governance structure is stifling to Open Source, then how come it's working for Apache?
The proposals in this thread don't even come close to 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."
Al, I'm sorry, I don't agree that the consortium proposals/opinions expressed in this thread much the Apache model. In fact, the board of directors of the Apache Software Foundation is selected by the foundation members, not the other way around.
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 :-).
Right. Rules only help avoid turning a situation into a living hell but cannot make the situation a paradise. What we all ask for is that there are provisions in the consortium's governing rules that "the sword will not be turned against the OpenACS community in the future." My gut feeling tells me that there's more than what have been said in this thread. I think that Sloan should come clean with their plans and the role of the consortium in those plans.
Torben and I posted the same time. I just wanted to say that I agree with Torben as well.
Collapse
Posted by Jun Yamog on
Hi,

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.

Collapse
37: Let's wise up, folks (response to 1)
Posted by Staffan Hansson on
I'm reading this thread with increasing dread. I have never seen so many logical fallacies in one chain of argumentation before, at least not in this community's forums.

Confusing the validity of a statement with the personal qualities (such as social status, professional history, personal type, etc.) of the deliverer of the statement (that is, committing social fallacies) is perhaps the most basic way of sabotaging a process of truth seeking. If it's done deliberately, it's a serious crime.

Far from everyone in this world has had the opportunity to get informed about the basic rules of argumentation but I'm very surprised that the argumentation veterans of this community display such ignorance. This is serious. We got to help each other wise up.

Staffan, as someone who's paying job is to do research for argumentation with incomplete knowledge, and at the same time create software that does exactly that, I have to note that the linked document mentions nothing about abduction and the role of incomplete knowledge in an argument.
Hello Al, maybe I read your comment wrong {OpenACS version1 is SloanSpace version2}, but until very recently OpenACS has evolved quite nicely without SloanSpace contributing to the effort. And I don't think it should be viewed like OpenACS is a by product of Sloanspace in the future.

As for the business implications, yes, definitly go with a consortium to adhere standards (though not necessarily technical ones, see above statement). We might even thing about this body releasing certification tests to accredit companies of beeing capable of installing dotLRN. But again the question: Why only dotLRN, why not OpenACS?

If MIT wants to control the brand and the way the community deals with it, that is fine. If some stakeholders want to use this stronghold along with a governance body to influence the communities direction, that's a different issue.

My suggestion: Restrict the dotLRN governance body to the level demanded by potential clients. That is limit it to quality assurance and adherence to standards in the educational area (after all, dotLRN is focusing on education and as long as MIT does not want to launch dotWRK...) and using of the brand. And make sure we have something like it for OpenACS as a whole along with a technical board (which can be the gatekeeper structure we have at the moment). I mean, potential clients of OpenACS have the same concerns.

Last but not least, it is a misconception that OpenACS is build only by developers. It was taken from the code developed by AD which was taken from the code developed for their clients. Most of the things we see within OpenACS are client driven, they have given us specs, things they need, modules they want to USE. The clients have been deciding about the functionality and how modules should behave. The developers decide how to make this happen. Keep it this way.

P.S.: I think everyone has a right to comment on this after it has been brought out into the open by Al and Ben in his/her own way. But you should keep personal attacks out of it. And see this as a chance to have something evolve that is not already there and be greateful for Al and Ben to give us the possibility to participate in the process and submit our ideas. That is taking for granted, that both Al and Ben are willing to make amendments to their proposal :-).

Just to make it more clear, real world argumentation requires that you argue with incomplete knowledge and at the same time context information (priorities) can be used to support contradictory conclusions. In some way the underlying theory is not static but dynamic.
Collapse
Posted by John Norman on
At the University of Cambridge (in England). We are planning to deploy dotLRN/SloanSpace v2. We are also closely involved in the Open Knowledge Initiative and are hosting alternative commercial platforms (Blackboard and FirstClass). We are trying to avoid placing our bets yet.

I don't want to tell anyone what they _should_ do, but the more 'open' dotLRN is the more attractive it is to us. In my view, good open source software is about a process that creates robust, useful, useable and used applications.

Collapse
42: Let's wise up, folks (response to 1)
Posted by kapil thangavelu on
just a quick note, to lend my support to malte's opinion. which is
the only one that resonates with me.

Malte wrote:

My suggestion: Restrict the dotLRN governance body to the level demanded by potential clients. That is limit it to quality assurance and adherence to standards in the educational area (after all, dotLRN is focusing on education and as long as MIT does not want to launch dotWRK...) and using of the brand. And make sure we have something like it for OpenACS as a whole along with a technical board (which can be the gatekeeper structure we have at the moment). I mean, potential clients of OpenACS have the same concerns.

My impression is that the first part of your statement (i.e., that the governing body should focus on QA and standards in the educational area) is not far from the plan. If you add in leadership in the educational area and high technical standards for the dotLRN-specific code, I think you have the picture.

As to the second part of your statement, I do not think that MIT would ever presume to set up a governing body for OpenACS. That would have to come from the community itself.

Now, there's a related question that has been raised here at several points about where OpenACS ends and dotLRN begins. My understanding is that both the dotLRN leadership and the OpenACS leadership have agreed to push down all non-dotLRN-specific pieces of code into OpenACS and to let the OpenACS leadership own that code once it leaves the dotLRN codebase. There is an issue about which code counts as dotLRN-specific and which is general enough to belong in OpenACS. It is a technical issue, and I don't presume to know enough about it to even begin to discuss it. Who has been discussing it? And who is likely to make the recommendation that MIT will take regarding what the right choice is? AFAIK it's been Ben and Don, the two co-founders of the OpenACS community. Al chose them both as technical advisors and from what I can see he takes their advice very, very seriously. I'll let Al speak for himself on this, but I can't imagine that Ben and Don would not continue to play central roles in the governance. MIT has made every effort possible to make this work with the community.

As several people have pointed out, it didn't have to be that way. As the major sponsoring organization, MIT can basically call the shots on dotLRN governance. Al chose to invite public comment. And his willingness to let Ben and OF put a rival proposal out for comment is a clear sign of his respect for them.

For somebody who is in a position to call the shots, having a bake-off in the community like the one we're having now comes with huge risk. Why would he take that risk? There is only one logical answer to that question: Al wants all of you on-board. He doesn't need your buy-in to proceed, but he's smart enough to know that he needs your buy-in to succeed. He wants you at the table. I hope the community will recognize his tangible tokens of good faith and respond in-kind.

Al chose them both as technical advisors Michael if you know something we don't, please go ahead and post. If the consortium's members have been selected, already, please let us know so that we can comment given that fact.
Collapse
45: Abductive logic (response to 1)
Posted by Staffan Hansson on
Neophytos,

I'm personally very excited about the subject you brought up, even though it's off topic in this thread. My homepage was more or less created for discussions on the subject of abductive logic, it seems. You're welcome to continue your line of thought there.

Just so that the not so initiated know what we're talking about, here's a short introduction to abductive logic that I myself found useful.

For, even though I've written quite extensively about the subject of postmodernist logic, I have to admit I had never heard the term "abductive knowledge". This is probably because my path to postmodernism has gone through premodern and not modern sources. I didn't know the hype words, so I refer to "historic logic" when you would rather say "abductive logic" - if I'm not very much mistaken.

To answer your remarks about the logic fallacy glossary, I vaguely refer to the "hen-and-egg" problem, and that's all in connection with abductive logic. This is because, I argue, the historical logic method is not as closely related to scientific logic method as one might think. Maybe I should add something about that to the glossary, though. But not now.

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.

Neophytos, my comments about Ben and Don being included are based on the fact that they are both highly influential on the dotLRN project right now. OF has been providing obvious, visible leadership on dotLRN to-date and Don has clearly been involved in the conversation too. That's more-or-less public knowledge. I don't know MIT's plans for exactly who is going to be on those boards, and I wouldn't presume to speak on that even if I did know. It wouldn't be my place. I'm simply pointing out that, given MIT's behavior to-date, the simplest explanation is that they are acting out of good faith to build relationships with the community, and that there is no evidence that they will not continue to listen to trusted community members in the future as they have in the past. Occam's razor.

That said, I do know Al well enough to vouch for his integrity and serious commitment about Open Source. I do not think there is any nefarious intent--on *either* side of this argument. But there is serious disagreement about how to make sure this project succeeds.

Staffan, that's an excellent reference [I've contacted Staffan by email and we're going to continue this discussion in his site soon]. I'm quoting:
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.

Just a quick clarification. I did not want to imply that MIT should provide the governance for OpenACS. That was a suggestion for the community to take and make, not MIT :-).

Concerning the shots: By releasing dotLRN in the open under GPL MIT has already lost most of the bullets. Their only bullet left is labeled dotLRN (TM). Noone could stop Ben, Don, Michael and Caroline to setup a body governing the future development of the product formerly known as dotLRN without involvement from MIT {though I doubt it is wise...}. So yes, I am thankful for Al to have opened up the discussion. And I add this is a very clever and strategically necessary move. But it is not necessary to thank MIT more than e.g. AD or Greenpeace or any other organization who bought an OpenACS site. And neither of these came up with the idea of a governance body just for their own product (aka special version of website).

Collapse
Posted by Carl Robert Blesius on

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 your 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).

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*.

Kapil, the key parallels between Apache and the MIT proposal are that both have formal governance structures, both are ultimately self-governed (remember that MIT does not propose to run the Executive Committee for the long-term), and both are made up of not just developers, but users of the platform. With Apache, the developers and users happen to be largely one and the same. That's not the case with dotLRN, so MIT is making an effort to broaden the mix.

Why? Again, I'll let Al speak for himself on this, but again, there is a simple, logical explanation based on his comments so far in this thread. Al has said that when an institution invests in Open Source, it's real investment is in the community. If MIT fails to get other institutions to adopt dotLRN, then it effectively becomes a custom development project. Al has already said in this thread that custom development is a bad investment for him. So MIT has a reason to "sell" dotLRN, meaning convince other organizations to adopt it.

And really, if dotLRN doesn't take off and get used by others, what's the point of doing it in the first place? What's the point of making it Open Source? The best reason possible to "sell" dotLRN is that it has the potential to offer the real quality online educational software (a rare commodity at best) to all educational organizations, regardless of their ability to pay.

The point is, none of that will happen if nobody is interested in adopting the software. If you build it, they won't necessarily come. Now, if *they* build it *with* you, that's another story. And that's the whole rationale behind a formal governance structure with a broad range of stakeholders.

Collapse
Posted by Malte Sussdorff on
Thanks Carl for the good news and I completely agree with your way of thinking. Maybe I voiced too much the devil's advocate for you to assume I'd like Ben's solution or none at all :-).

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"

Collapse
Posted by Alfred Essa on
Opensource thrives because code is subject to examination, review, comment, criticism and debate. The same is true for ideas. If you disagree with my positions, go at it. You won't offend me. That's why the proposal was put forward as a Request for Comment.
Collapse
Posted by Alfred Essa on
One of the fears seems to be that non-techies will be telling what developers what to do. Anyone who thinks that opensource developers can be *made* to do something is out of their minds. Opensource communities are not unlike academia in this respect: you also can't tell faculty what to do. If you try, especially at a place like MIT, you will be lucky if you last more than a week.

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.

Collapse
Posted by Janine Ohmer on
Wow, this is quite a thread!

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.  The fact that Al has chosen to make it Open Source, and that we are having this discussion at all, ought to make it reasonably clear that his motives are good.

(obviously Ben's motives are good too, but they don't seem to be under question here so I don't need to defend them)

As to why Al is doing this, it has been my impression that he wants to see dotLRN be adopted as widely as possible by other educational institutions.  This is one way of getting value out of a piece of distributed software.  Selling it is the other - let's be thankful that Al chose the Open Source route, eh?  And if wide adoption is the goal, Al *has* to set up a structure that the potential adoptees will be comfortable with.  I think Michael and Carl have done an excellent job of explaining why the model Al has proposed is the right fit for the educational software space.

As for the comparison with Apache goes, although there are many similarities, as others have pointed out, there are differences as well.  The main difference being that dotLRN was commissioned and paid for, and has therefore sprung forth fully formed. It has not, up to now, been the product of volunteer developers.  That gives it a certain appeal in places that are slightly suspicious of the percieved anarchy of Open Source, and I think MIT should do all they can to preserve that.  I believe that the proposed Governance structure will help in that regard.

I think Tracy had a good point about the ability of the proposed Consortium to hire folks to do things like QA testing, writing documentation - tasks which benefit the entire community.  It's a great way for institutions to pool their resources and end up with enough funding to really get things done.

I can understand why people are concerned about future changes to dotLRN forcing changes to OpenACS.  However, I think one can see how dotLRN was built and see that this is not necessary.  For example, the existing Portals package was considered to be inadequate.  Instead of rewriting the OpenACS package and forcing the project to adopt the new one, OF wrote New Portal.  Now, it happens that New Portal will probably make it back into OpenACS proper, because there seems to be general agreement that it's better.  But that doesn't have to happen;  changes made for dotLRN that the OpenACS gatekeepers really don't like can remain in dotLRN.

Having said that, I think it would make people feel better if Al added something to his document to the effect that the dotLRN project can never *require* the OpenACS project to implement a change.  They can ask, but they can't require it.  And maybe also that dotLRN should be kept compatible with the latest (from CVS) version of OpenACS.

And lastly, I agree with Malte that a similar governance structure might work for OpenACS, but I think that's premature at this point.  IMHO that idea should be set aside until the dotLRN governance issues have been worked out and a structure that works well for all stakeholders has been achieved.  Then we as a community can take the lessons learned from that and decide if the process is appropriate to OpenACS or not.

Collapse
Posted by Don Baccus on
Hello Al, maybe I read your comment wrong {OpenACS version1 is SloanSpace version2}, but until very recently OpenACS has evolved quite nicely without SloanSpace
A gentle reminder. OpenACS wouldn't exist without a substantial code base that was funded. As the current project manager I'm perhaps most keenly aware that while Greylock's $38M didn't buy software perfection, and while we were left with a great deal of clean-up to do (most of which has yet to be done), and while we did port to PostgreSQL, the bald fact of the matter is that 90% of the code base is ACS 4.

Where would we be today without that funded code base?

How have people come to this fantasy conclusion that OpenACS 4 is due solely to volunteer effort? We had the code base, bought and paid for by Your DotCom Dollars. Some folks (including myself) are volunteers. Others have been funded to work on OpenACS at least part time. So the 10% of the code base that's ours is partially, but not purely a volunteer effort and the other 90% not remotely a volunteer effort.

As to success ... have you all forgotten how much bitching there's been at how long it's taken us to get the first release rolled out, and how buggy it still is, and how much improvement it still needed? Are you aware of how little work is being done on the toolkit that's not being directly funded by someone?

"Hey, Musea, where's ETP2?"

Sorry, we haven't found anyone to pay for it, can't get it done.

"Is the bugtracker going to evolve into a new SDM and support Oracle?"

Well, it would be nice if there were some funding ...

I'm not trying to pick on anyone (despite naming Musea, that's just an example that came to mind). My point is that as a project at large we don't really accomplish all that much without funding.

Open Force has done a great job on dotLRN. Does anyone here believe they would've created this application if they weren't being paid?

Funding for Open Source work can only help, not hurt. While MIT (and most likely the consortium) have relatively narrow needs and will therefore fund quite narrowly, the fact is that it can only help us.

Assuming success is the goal

If success isn't the goal, would somebody please tell me what it is?

Collapse
Posted by Alfred Essa on
One of my comments is a misprint. I did not mean to say OpenACS v1 is SloanSpace v2. I meant to say dotLRN v1.0 is SloanSpace v2.
Collapse
Posted by Don Baccus on
Does one organization need to be *the* representative for grants, financing etc developing this learning system?
This is a somewhat interesting question. The obvious answer is no, of course, there needn't be one representative for grant. And setting up a consortium doesn't imply there will only be one.

However ... I have decades of experience in the non-profit world, including stints when young at one of the largest science musuems in the West, and fifteen years on the board of the second largest Audubon chapter in the country ($2M/yr budget).

While there doesn't *need* to be a single representative for funding, there's no doubt in my mind that it helps. Take the issue of old growth forest protection in the western Pacific Northwest. A large foundation supported the campaign to the tune of a $300K-$400K a year. While there was no formal consortia of regional conservation groups, there's a lightweight governance body that's been around for about 25 years now, and there was a cohesive plan among the eight or so non-profits who worked together to get the grants. Without that cohesiveness and without the Oregon Environmental Council's ability to set priorities and the outline of the conservation agenda for all major conservation organizations in Oregon chasing funding for this cooperative campaign would've been much harder.

A more formal example relates to how I learned to program in the first place. Early computers were expensive and few districts could afford them. Several Oregon districts formed a formal organization called the Computer Instruction Network. The organization applied for and got grants, and was able to buy an IBM 1130, a van to put it in, a PDP-8, and support staff to ship them around the schools and educate teachers and students.

Could the individual schools apply for grants? Did there need to be an organization of schools? Um ... care to guess what they did before forming CINET? I know that afterwards I tried hard to get my school funding for additional equipment and it was impossible.

The point is that something like the consortium being discussed isn't necessary for funding. However ... it opens the door to funding that would otherwise be unavailable.

Of course funding is just one issue to consider but I do believe it's an important one if our goal, as mentioned in my previous post, is success.

Collapse
Posted by Don Baccus on
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.
A good point. We don't have these discussions about Siemens ShareNet because we can't get the code.

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.

Collapse
Posted by Jon Griffin on
This thread was so long I had to open a window and write this while reading. I still haven't finished so I hope this isn't a rehash or a misunderstanding of some fundemental ascpect.

Comittees - I understand the desire for a committee, that said I think for dotLRN to grow no committee should be formed. Of course I don&#39;t have any say in this as MIT is funding this, but committees are great for killing projects. Talk, talk, talk and little action is the result of more than 2 people discussing technology.

People mention apache as a successful governance model, I disagree. Apache 2.0? Apache has a momentum that even a committee can&#39;t kill, it also has money. I understand academics desires for committees and meetings, but these are slow, bungling, politicized places where the best seldom wins.

I also know of two extremely large (top 6) school districts planning on implementing dotLRN, with or without a committee. Therefore I completely disagree with those saying that without a committee dotLRN will die. On the contrary I think control by the principals is the main point of any committee, despite best intentions at the outset.

Collapse
Posted by Talli Somekh on
One issue I would like to address is Ben's assertion that open source software communities need strong leadership. I couldn't agree more. However, the leadership that *any* community needs, whether it be software, family or local, is one that embraces a democratic process. This includes:
  • Discussion and debate (even heated debate)
  • Compromise and flexibility
  • Resolution
  • Regardless of which proposal is selected, and Musea will make an official selection for the record, these principles will be critical in having a successful project.

    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

Regardless of which proposal is selected, and Musea will make an official selection for the record, these principles will be critical in having a successful project.

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, as far as I'm concerned, if this is inevitably a selection of one process or the other (as they have been posted today) I would choose NONE. And this is an official statement for the record as well.
Collapse
Posted by Dave Bauer on
I would hope that using the feedback here, a modified proposal could be offered addressing the concerns expressed by the community.
Collapse
Posted by Lars Pind on
Thanks for both software and proposals to both parties.

Governance

If you draw them up, it's very clear that the main difference between these two proposals is that Al's has an Executive Board (EB) and a User Advisory Board (UAB), while Ben's does not. The Technical Advisory Board (TAB) and Gatekeeper (GK) structure is identical in both proposals.

What this means is that Al's structure has a clear accountability built-in: The TAB is accountable to the EB, which is accountable to MIT and the community. The UAB formalizes the input of the user organizations. In comparison, I don't see anything about accountability in Ben's plan, except his reference to the right to fork. Who's Ben's TAB accountable to?

Is that good or bad? I don't know. There are two parts to it. (1) Is this extra structure and overhead going to contribute positively, and (2) do you trust MIT with this power. I honestly don't know the answer to these questions.

I think there's truth in the fact that most of the customers that we can't sell to today don't care so much about software, they'd like a brand, a name that they can trust. MIT and .LRN and this body could give us that.

On the other hand, there are a couple things on my mind that I haven't seen addressed yet. One such very serious thing is .WRK. There's wide-spread interest in the community about building an intranet-suite called .WRK, based on much of the .LRN infrastructure. I, for one, have a strong interest in this.

How would this .LRN governance structure fit with that? Would it (a) say that .WRK belongs to .LRN -- i.e. .WRK users may get a seat on the UAB, trying to convince the EB and the TAB and the GK to include .WRK-specific features into the .LRN distribution. Or (b) say that we don't care, you can fork if you want, just don't call it .LRN. Or (c) say that we should move as many features common to .LRN and .WRK into the OpenACS distribution, and encourage the .WRK community to set up a structure similar to the one for .LRN to govern the development of .WRK.

My hope would be option (c), but I'm not sure what Al, Ben, and others are thinking. Comments?

This touches on an issue of what exactly people think that .LRN should mean. How big is the .LRN part of .LRN, and how big is OpenACS. Right now, there's a lot of code in the .LRN repository that I hope belongs to OpenACS, such as the portals, the portal wrappers around all the applications (forums, file-storage, etc.), the whole group/community framework, etc. All of that is, from my perspective, so fundamental to a collaboration software toolkit, which is what I view OpenACS as being, that it belongs there. That leaves a relatively minor list of things, such as a homework drop-box, administrative pages for setting up departments, subjects, classes, etc. for .LRN. Plus, and that's what I find the important part, whatever variations are needed in how functionality is presented is needed in the educational environment.

I'd like to know where Al, Ben, Don, and others stand on this.

Also, I'd really like to hear something more concrete about who would be on which ones of those boards.

Finally, there's something obviously notable in the tone of those proposals. Ben is clearly coming from a hacker culture, the bazaar, and Al is clearly coming from a bureaucracy. Don't know what to read out of that, except for the obvious, but it's making it harder to compare apples to apples. Or perhaps it's making it easier, don't know.

/Lars

Where would we be today without that funded code base?
I will ask back. Do you think Sloan would have been funding the development of dotLRN if it has not been for the efforts of volunteers like myself and the rest of the OpenACS community? The code base we received from aD would have probably stagnate if it was not adopted by this community. So, *if* MIT Sloan wants to proceed on their own without any consideration of the people who brought OpenACS where it is today, that's fine by me, just don't expect me to "approve" the .LRN consortium -- in that case, I'm sorry, I'll pass.
The TAB is accountable to the EB, which is accountable to MIT and the community.
How is TAB accountable to the community? The governing rules that were posted are clear -- MIT would call the shots.
Collapse
Posted by Samir Joshi on
I am relative newcomer to the community and geographically on the other side of planet ( looking from New England  that is :) ) - Here is a perspective from distance -

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.

Collapse
Posted by Samir Joshi on
Lars, I saw your post after posting mine - because of length of the thread.
Collapse
Posted by Don Baccus on
Talk, talk, talk and little action is the result of more than 2 people discussing technology.
Could some one point me to the date on which the PostgreSQL project died?

(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.

(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)
Some quotes from postgresql.org:

"A PostgreSQL database developer is someone who is actually working on the project, not someone using it to develop an application or a website."

"Membership on the steering committee is by invitation only, by the other steering committee members, ..."

See who actually controls the direction of the project: http://www.ca.postgresql.org/devel-contrib.html

Lars, as always, your post is thought-provoking.

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.

Collapse
Posted by Don Baccus on
Right now, there's a lot of code in the .LRN repository that I hope belongs to OpenACS, such as the portals, the portal wrappers around all the applications (forums, file-storage, etc.), the whole group/community framework, etc. All of that is, from my perspective, so fundamental to a collaboration software toolkit, which is what I view OpenACS as being, that it belongs there.
For the record, Ben and I argued strenously about new-portals. For three solid days. Where we've left it is that Ben has agreed it's OK for new-portals to go into the standard OpenACS distribution. That was not his first choice.

Frankly after our last discussion I've been avoiding the issue of the portlet wrappers - those that aren't intimately tied into dotLRN of course (standard package portlet wrappers).

However I did write up a short note on the subject last Sunday. I'm going to post it in a new thread. I wrote this before Ben and I reached agreement on moving new-portal into the standard OpenACS release. This discussion will be public, not private.

I'll post that in a minute in another thread, in this forum. Feel free to comment there.

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.

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

Collapse
Posted by Don Baccus on
I will ask back. Do you think Sloan would have been funding the development of dotLRN if it has not been for the efforts of volunteers like myself and the rest of the OpenACS community?
No, they'd probably still be contracting with me and others to continue to extend SloanSpace V1, aka ACES, aka ACS 3.5 (Oracle only) as distributed under the GPL by Sussedorf and Roy.

At least that's what they were doing last summer, and even this spring, though to a much lesser extent than before due to the imminent deployment of SloanSpace V2 (dotLRN).

Think of the pain they would've saved themselves if they hadn't chosen to base a new platform on our project, and fund a path that would lead to availability on Postgres as well as Oracle, and chart a course that will help extend funding for OpenACS developers in the future?

And you talk as though it is a one-way street, with MIT benefiting from our work and giving nothing back.

Au contraire, both SloanSpace V1 (ACES) and SloanSpace V2 (dotLRN) have been GPL'd and available to the community. It's a two-way street. MIT has given back to the community and I hope will continue to give back to the community. Again, someone in this thread might consider saying "thank you" to Al for releasing both ACES and dotLRN because MIT has been under no obligation to do so. Both could've been pursued as typical one-shot client jobs with the result, like Siemens ShareNet, being code the community would like to have but can't get their hands on.

Well, Talli seems to have a problem with the fact that I'm posting my concerns about the consortium. I'm sorry that he feels this way but I have my own opinion. If someone doesn't like it, that's fine by me but I'll still say what I believe no matter what.
Collapse
Posted by Don Baccus on
You cannot establish sound governance or bylaws around particular personalities.
Where was I talking about governance? (Al's right, BTW) I was talking about my own ability to behave somewhat like a brick wall at times.

If necessary we could just pick up our community, walk away, and start over. No problem. No one can stop that.

After all, that's pretty much the story with aD. The community was neglected and to some degree disrespected (I'm talking about corporate behavior, many individual aDers were heavily supportive of the community and later our OpenACS project, and of course we have many of them in our community today). So the community got up and walked away.

Same with dotLRN users. If they don't like what the consortium does, they can walk. Governance be damned.

Credit Al with some brains. He has no reason in the world to want to trigger that sort of split.

As far as dotLRN being used regardless of what MIT does, sure it will be. Just like Linux is used on the desktop. Some of us are shooting higher, we'd like dotLRN to be prevelant like Linux in the server space.

And that takes more than just a few random public school districts adopting it, a few independent efforts to extend it, and a handful of technical people controlling its direction to achieve.

Maybe others don't care about the extent of adoption. If so, that's fine. But a governance that helps those that do shoot high isn't going to hurt those comfortable being bottom-dwellers.

Collapse
Posted by Janine Ohmer on
There seems to be some serious anger in some of the posts here.  Why does this proposal upset some folks so much?  Or, to put it differently, if Al's proposal is put into place, what do you think is going to happen?  What terrible, nefarious plans could he have up his sleeve?  It is not in MIT's best interests to piss off the OpenACS community when their package depends on it.  If they wanted to do something for personal gain, MIT could take the package and sell it, which would be far more profitable than going through all this show of building a community.  I just can't see what all the fuss is about... it's clear that some folks don't trust MIT, but even looking at it from that perspective I don't see what harm they can really do with all this.

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.

Trust Lars to provide a good graphical representation.

As someone that has been around the community for awhile struggling to figure out how a non-coder can make a contribution, and not nearly as eloquent as Michael Feldtein, I have clearly FELT the absolute lack of a structure for user views to make it into the community. When they do make it into the community, they have been filtered by a vendor. It is true that customers will seldom want to participate in the community, but, if like MIT, they do want to participate, they can be extreemly valuable to the long term sucess of the community.

.LRN is an opportunity for user-side interests to have a channel into the OACS community and provide a future model for dotWRK, etc. Perhaps Al's proposal is not the best one, but the key question for me, looking at Lars' diagram, is "Through what box/ structure do user needs flow?"

In Ben's proposal I do not see a channel. In Al's proposal I do see a channel for user interests.

For all the folks that do not feel comfortable with Al's proposal, I ask "How, precisely, does someone commissioning a significant OACS application participate in the OACS community?"

There is another layer on top of users and that is the BRAND layer. .LRN is an MIT e-learning brand. Any OACS developer can adopt the GPL code and peddle it under their brand--most are too small to realize any benefits from this approach.

In my opinion this is the place that forks happen. I think that personalities prevent the forks, so there may not be any structure that addresses the brand/fork problem. Though Don's point of the community getting up and walking away if they disagree with governance, as they did with aD, suggests there is more than enough incentive to prevent forking.

Collapse
Posted by Jon Griffin on
I want to clarify my previous post since I am back home and finished reading the thread.

  • 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.

Collapse
81: A clarification (response to 1)
Posted by Ben Adida on
I think there is some confusion as to what problem I was trying to solve when Al asked me to put together a governance document, and therefore some belief that I'm trying to exclude users of dotLRN who are not programmers. This is not the case by any means. First, I want to clarify that it is MIT's role to determine future direction and Al has the final call on this. I will clarify where I'm coming from so that omissions in my proposal are not misinterpreted.

The question I was trying to answer is "how do we get non-OF people involved in dotLRN as soon as possible while maintaining a coherent direction?" - you'll note that the proposal is called "dotLRN *Technical* Governance." This is why my proposal is minimalist - to get things off the ground ASAP. However, I'm *not* excluding the later formation of other groups. I'm only saying that the formation of such groups should probably be organic, led by early adopters (users!) of dotLRN once they have some experience working together with dotLRN.

Some in this thread have compared this to the Apache project. Putting aside the fact that the Apache Board is generally not credited for Apache's success, dotLRN is very different from Apache because dotLRN serves non-technical end-users directly. This is Michael's point and I agree with him on this. In fact, I agree with this point so much that I'm loathe to dictate too much process in an area where *no one* has any real experience: open-source vertical apps. This is why I'm sticking to a minimalist, well-known structure, fully hoping that MIT, as the owner of the dotLRN brand, will coordinate user discussions and conferences to truly tap the educational community.

I simply don't think that it is beneficial to predicate additional developer participation on these ambitious goals. I fear that it would stifle the enthusiasm that many developers have clearly shown about dotLRN.

Lars raises some interesting questions, which I'll try to answer:

  • dotWRK is totally separate from dotLRN. Common code should be modularized out so as to form as strong a common base as possible.
  • yes, new-portal and the portal wrappers belong in OpenACS (and in fact, we're in the process of rolling them back in the next few days).
  • in my proposal, the TAB is accountable to the community and to the organizations they represent. The gatekeeper is accountable to the TAB.
  • the dotLRN kernel is not very big, but it is fairly crucial to keeping a solid architecture. It includes the applet API contract and implementation, the group management tie-ins to portal management, the specific role definitions and management, and a handful of other small details. In the proposal I put up, I mentioned the "portal architecture." I will revise this right now as per my discussion with Don.
  • one formation of the TAB that I envisioned (although, again, Al has final say over this): lead engineer from each of the big initial users of dotLRN (Sloan, Berklee, Heidelberg). As for gatekeeper, I proposed playing that role for the first 6-9 months, depending on speed at which the TAB can define a new process.

Collapse
Posted by Don Baccus on
If they wanted to control it, they could just sell it as a proprietary package of education-specific packages to install on top of a vanilla OpenACS install, while of course redistributing changes to core packages like calendar to the OpenACS project under the GPL.

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.

Collapse
Posted by Don Baccus on
# yes, new-portal and the portal wrappers belong in OpenACS (and in fact, we're in the process of rolling them back in the next few days).
Reading this you'd never guess that Ben fought me on this issue for three solid days, as I mentioned above. In fact he argued strenously that the portals package doesn't belong, that indeed it was a horrible idea. That the best decision was to keep new developer-oriented pieces like this in dotLRN rather than OpenACS.

The argument was so distasteful that I couldn't bring myself to raise the issue of package portlets.

Just for the goddamned record.

Why is this relevant? Because I know that Al;s vision is that there would be some OpenACS representation on the TAB. Explicitly because the two projects need to coordinate.

Ben mentions having three engineers from Sloan, Berklee, and University of Heidelberg on the TAB. An earlier version supplemented that with two Open Force engineers. Neither includes neutral OpenACS representation. Whatever else shakes there's got to be such representation on the TAB.

Collapse
Posted by Jon Griffin on
Don,

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.

Ben wrote:

The question I was trying to answer is "how do we get non-OF people involved in dotLRN as soon as possible while maintaining a coherent direction?" - you'll note that the proposal is called "dotLRN *Technical* Governance." This is why my proposal is minimalist - to get things off the ground ASAP. However, I'm *not* excluding the later formation of other groups. I'm only saying that the formation of such groups should probably be organic, led by early adopters (users!) of dotLRN once they have some experience working together with dotLRN.

I agree with this completely. In fact, that is precisely what is happening. If you look at the posts of the few non-programming users and stakeholders in this discussion, they have all come out in varying degrees in favor of the MIT proposal. Al didn't make this up out of thin air; he wrote it after consulting with both programming and non-programming stakeholders. This is what we want--or at least the end users from whom I've heard up until now--after having had a little experience working together with dotLRN. I'd call that process fairly organic Maybe the product--two committees--doesn't feel very organic, but that product was requested from the grass roots.

So it seems to me that if the only major difference of opinion between OF and MIT is that OF wants to get a signal from non-programming stakeholders about what they want, then we may have one giant non-issue on our hands. Now, if the issue is waiting for more stakeholders to come to the table...well...you know my opinion on that issue. If you want to reach those who aren't here yet, then the best way to convince them to join is to create a governance structure that satisfies the stated needs of those who already are here.

Collapse
Posted by Ben Adida on
Don: you're absolutely right about one thing: OpenACS representation. I thought I brought some of that along, but if that's not enough, I'm all for having you on the TAB to bring that influence.

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.

Collapse
Posted by Don Baccus on
I think what scares many people in this community is the fact that dotLRN is seeming to eclipse OpenACS
Well ... I worried about that when I met with resistance to putting the new portals stuff into our standard OpenACS. Not doing so would strongly position dotLRN as being the development platform of choice, rather than position it as being a vertical e-learning application which happens to feed back development tools into OpenACS proper.

That's why I think it's important that the TAB include OpenACS representation and that even more importantly that they be tasked to do their best to see that decisions as to what goes into dotLRN vs. what should be pushed into an OpenACS release be made solely on a technical basis.

Who can hold them accountable to this task in Ben's topless model? If there's no OpenACS representation on the TAB, as Ben suggests, will they take our needs into account?

On the other hand in Al's model it is clear who will assign them that task and who can hold them accountable.

Now ... the obvious question is whether or not Al's model leads to the TAB being tasked in this way. Al's plans, as stated to me, are to do this but they're not explicit in his loose outline. Maybe there needs to be some formalization of the fact that a key part of the plan is to see that there's technical representation of the OpenACS community on the TAB, and that not forking is a mandate.

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.

Collapse
Posted by Janine Ohmer on
Since we run Linux, we deal with a lot of Open Source code.  Doesn't seem to matter where it comes from, there is a common thread:  the documentation sucks.  The UI often sucks as well, though that's a bit less of a given than the documentation.

We attribute this to the fact that Open Source projects tend to attract more programmers than anything else, and programmers are very often not good at thinking in the way newbies think.  So they write documentation and UI that are only useful to someone who already knows how to use the program.  They don't do it intentionally;  in fact they quite often try very hard to write good docs, but it usually doesn't work out.

This has been the case for OpenACS too;  although we have a decent install doc, there is very little else.  And we see complaints all the time from new users about the lack of docs and the impenetrable UI.

My point?  This is what happens when programmers design for programmers.  It hasn't been fatal for OpenACS because our users are mostly programmers too, just as the users of qmail and the other tools Mike complains about being poorly documented are other sys admins who are ultimately able to figure it out.  But it *would* be fatal for dotLRN, which is an *application* rather than a toolkit.

IMHO that's why user representation, participating and funding are so important.  We need to make sure that the proper importance is placed on the things users need, not just on the things programmers need.

Collapse
Posted by Don Baccus on
* 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)
I must've seen an earlier draft, then ... unless Al argued that I not be on the TAB, and got you to remove my name, which doesn't sound quite right to me.

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.

Collapse
Posted by Don Baccus on
Don, the only reason I can imagine you making these statements is that you're calling my motivations into question.
We can leave motive out of it.

If we were on the TAB and if the TAB had been tasked with making sure that general development tools funded by the consortium should be migrated back to a standard OpenACS release, then we wouldn't've spent three days arguing the issue.

The answer would've been obvious and you would've started migrating the code over three days earlier.

Sometimes having structure helps.

Collapse
Posted by Ben Adida on
Michael: I appreciate your trying to be conciliatory here, that's definitely a
productive direction for discussion.

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.

Collapse
Posted by Don Baccus on
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).
Untrue. The user requirements for ACES and dotLRN are very similar. Technical management of SloanSpace V1 was lax, leading to a situation where the datamodel was being patched in SQL*Plus with the changes not being reflected in the SQL files. Or so I understand, it was already uninstallable when I was asked to help out.

This might've been in part because so much of it was being done by inexperienced undergraduate students of technology, without proper guidance or direction.

But it sure doesn't have anything to do with user requirements driving specs. It was a failure of the technical people involved in the project (inclusive of technical management).

But don't forget that technologists made it modular enough that others could develop for it.
That's your job. No one is suggesting that the EAB will do your job for you. No one is suggesting they'll do the TAB's job for them.

Both of these are red herring arguments. Substance, please.

Collapse
Posted by Alfred Essa on
Let me say something about .WRK:
  • 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.
  • To me what's important is that we build the brand .LRN and that the brand should come to mean something.
Collapse
Posted by Alfred Essa on
MISTAKE IN MY LAST POST.  HERE'S CORRECTED VERSION:

Can someone take .LRN applets and distribute it with other pieces and call it WRK. Absolutely.

Collapse
Posted by Alfred Essa on
Lars asks: "This touches on an issue of what exactly people think that .LRN should mean. How big is the .LRN part of .LRN, and how big is OpenACS. Right now, there's a lot of code in the .LRN repository that I hope belongs to OpenACS, such as the portals, the portal wrappers around all the applications (forums, file-storage, etc.), the whole group/community framework, etc. All of that is, from my perspective, so fundamental to a collaboration software toolkit, which is what I view OpenACS as being, that it belongs there. That leaves a relatively minor list of things, such as a homework drop-box, administrative pages for setting up departments, subjects, classes, etc. for .LRN. Plus, and that's what I find the important part, whatever variations are needed in how functionality is presented is needed in the educational environment."

  • 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?

Ben wrote:

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.

I don't see how technologists are alienated. You have a technologist who is the gatekeeper. You have an entire board of technologists who oversee the gatekeeper. OK, so the people at the very top are not all technologists (although you neglect to consider the overwhelming likelihood that there will be technologists on the executive board as well). So, because technologists don't absolutely run the show, they are alienated? And non-technologists are not alienated under your plan, in which they have no place at all?

Ben, I wasn't just trying to be conciliatory; I was trying to test to see whether we, in fact, have common ground. I see now that we don't. You say that you want users to be full participants, but you reject any plan that doesn't put technologists--and just a few technologists at that--at the top of the power pyramid all by themselves. It's all or nothing. As I said in my initial post, this narrow technocracy will kill dotLRN.

Now, there is a piece of the governance proposal that is missing from both plans, by the way. It is the bottom-up accountability. I had privately suggested a Mozilla-style system where dotLRN packages are owned by individual programmers in the community--not companies, not company CEO's, but the individuals who actually maintain the code. 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.

I argued, and still argue, that such an accountability structure is actually more urgent than a governance structure and would lay a foundation of communication and trust that would enable a true governance structure to grow. Al responded very positively the idea when I presented it to him, but the idea apparently met with resistance elsewhere. Since I wasn't party to those conversations, I hesitate to characterise them. Suffice it to say that this proposal wasn't quashed out of any action on MIT's part. So I ask now: How does the community feel about such an accountability plan? How would it affect your feelings about governance?

Hi Michael, though I like the idea, I'm not sure I would like to see my baby taken away from me by some governing community for whatever reasons they might have.

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 /. :-).

Collapse
Posted by Ben Adida on
A quick summary of my plan, as it seems to have been forgotten or ignored: I
was trying to solve *only* the *technology* governance problem, as
specifically instructed by Al. The immediate goal which was communicated to
me by Al and Carl was "we need to know that Lars can build
internationalization, that MuseaTech can submit bug reports and patches,
without having to go through OpenForce approval or engineers." That is the
problem I was trying to solve, and I believe I presented a fairly simple plan for
this that tried to impose the smallest necessary amount of process.

It is my belief that 3 committees of people with wildly varying goals trying to
manage a small kernel of code is a recipe for disaster.

That said, I don't own the dotLRN trademark and I have no say in this. I'm
thankful to Al for allowing me to express my opinion and for releasing dotLRN
to the public under the GPL. These are important moves and they indeed
show a desire to involve the community - and that's a good thing.

I believe it is clear that my proposal has been rejected by the community, and
there is little need to let this degenerate any more than it already has. I look
forward to seeing the composition of these various boards.

Collapse
Posted by Don Baccus on
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.
I tried to manage the originally OpenACS 4 porting effort somewhat like this. Package owners who reported to me who then tried to maintain a status list (a job I did fairly lamely, miserably, poorly, incompetently - pick your adjective, Neophytos has offered to do it for 4.6 and I'm glad). By "reported to me" I don't mean in the managerial sense, I mean in the "if we weren't so lame we'd have set up some way for them to edit their own status but we didn't so Don tried to do it" sense. In general package porters were very good at reporting progress, I was the communications bottleneck.

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.

Collapse
Posted by Don Baccus on
Ben ... I appreciate your seeking closure on the issue. I'm not trying to flog a dead horse here but would like to add a clarification.
It is my belief that 3 committees of people with wildly varying goals trying to manage a small kernel of code is a recipe for disaster.
If it were just a matter of managing the code, yes, I'd agree.

But clearly we're talking about more than that. We explicitly are tackling the issue of marketing as well - marketing in the broadest sense (in the sense that has led us to decide on having an "evangelism" rather than "marketing" forum for the new openacs.org site). And fund-raising. And the issue of giving funders a voice in how the software they fund gets presented to the world.

Anyway ... I'd like to congratulate you and Al for having spawned a thread that eclipsed our recent thread on the graphic design of the new openacs.org both in intensity and length. Though that thread included more posts with inline graphics. If it weren't for Lars we would've been skunked in that category here.

I didn't think it was possible.

Though that thread included more posts with inline graphics. If it weren't for Lars we would've been skunked in that category here.

Collapse
Posted by Alfred Essa on
In any "philosophical discussion" it's always good to return to first principles. What shouldn't get lost in this entire discussion is the fact that dotLRN would not be possible without Ben's leadership and Yon and Arjun's brilliant contributions. Their code base is a gem. That's common ground.

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.

Wow, this thread is so enormous and full of interesting ideas that I don't know where to start! I think this discussion has greatly helped me understand Als governance proposal. Eventhough the proposal is very well written it is still, by necessity, abstract and it is difficult to see the practical implications.

I personally have no fear or reluctance about MIT governing dotLRN, on the contrary, I feel that it is MITs continued involvement and backing of the project that gives it credibility and weight and ultimately what makes world-wide adoption viable. If MIT would pull out of the governance of dotLRN at this stage I feel that this would severel hurt my chances of selling the platform in Europe.

The idea of the executive board and the user advisory board makes perfect sense to me. There needs to be a forum where the needs of various user organizations (i.e. learning institutions) can be expressed and synergies can be found. The Technical Advisory Board helps monitoring the work of the gatekeepers. If it turns out that the gatekeepers are unresponsive or their direction is not inline with the strategy of the Executive Board then the board needs to have the power to take corrective action. Of course, in practice, the gatekeepers will not be reduced to mere implementors, but will surely have a dialog with the board about strategy.

Don's point about allowing room for non-technical people is excellent. I think that people like Michael Feldstein who are passionate and knowledgable about e-learning are a great value-add for the dotLRN project and we need more people like that. Ultimately the challenge will be to collect the feedback of the user community to find a good direction for the platform.

Carl touches on a key issue here which is to avoid diluted efforts, or a fork of dotLRN. It must be the mission of the Executive Board to avoid such a fork by finding the compromises that best express the needs of the various clients. Once again, this helps us understand why the board is important.

It is somewhat worrying that Don has to point out to the community that funding is a good thing and that OpenACS wouldn't even exist without the VC money that ArsDigita poured into creating it. dotLRN is a school book example of how a funded OpenACS project gives the whole platform a tremendous boost and benefits us all. I would go as far as saying that dotLRN is the most exciting and promising project to have entered the scene in the whole history of the ACS movement. I am utterly grateful and excited about it!

Al, thanks for realizing the importance of governance and for being so receptive to ideas in the community! I am very excited to see the new governance structure take shape and watch dotLRN evolve and be adopted world-wide with a firm guidance from you and MIT and the others in this community!

This thread is great, seriously, I hope someone picks it up to write about open source management and development.

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!

First, thanks Ben and Al for your willingness to hash this out in an honest debate. And thanks to the community for all of the thought-provoking replies. Special thanks to Lars, the picture is worth thousands of words.

I've been trying hard to think of another project that we might be able to compare the governance models against. The closest thing that comes to mind is Prometheus (which no longer is available). Does anyone know how the Prometheus project was governed? It certainly was successful in getting adoption from other institutions http://www.prometheus.com/partners/academic_partners.html (Prometheus.com redirects to Blackboard but there's a site underneath it..) http://www.prometheus.com/product

dotLRN team congrats on the launch! U Heidelberg (Carl) welcome!

As for Berklee's status, we've built an excellent LMS ontop of the course admin pieces of dotLRN and are working non-stop towards a launch in September.

Michael, is that LMS SCORM-compliant, by any chance? Are there any specs you can post?
Collapse
Posted by Alfred Essa on
I want to thank everyone for their contributions. This weekend, I will try to summarize my "takeaways". I have learned a lot from this process.

Throughout the discussion I kept thinking of Talli's question: What is be the goal of the .LRN consortium and how will membership be defined? A related question, as raised by Ben and Neophytus, is: To whom will the Executive Board be accountable? As I interpret it, their concern is that in opensource communities technologists rule. My governance model turns things on its head by letting non-technologists call the shots. And that's definitely not the opensource way no matter which governance model one looks at: Apache, Mozilla, X.

I think that's fundamentally Ben's concern. His interest is to drive innovation and he is right to raise the objection that this type of model seems to be without precedent.

The short answer is that the .LRN consortium will be established primarily to serve the interests of .LRN users. Technology and Ideology will always be subordinate to that aim. We are not terribly interested in developing an eLearning platform for its own sake. If developers and hackers want to be left alone to hack whatever, then fine. We are not going to and cannot get in their way. I am not afraid of saying it plainly. The consortium will *not* exist to serve the needs of hackers. Nor will it exist to serve companies that decide to sell products and services around .LRN. It's in the interest of the consortium to make sure that .LRN developers and vendors flourish. But that's not its primary mission or charge. From the perspective of actual and potential users (e.g. Heidelberg, Berklee, MIT) .LRN is now a product. By having adopted the platform, it's in our interests to ensure that the product continues to evolve in a way that meets our needs.

Similarly, potential adopters of the platform need to know that the governance mechanisms will allow them to influence platform support and platform direction. We will never be at the mercy of vendors.

To whom will the Executive Board be accountable? Organizations that use .LRN. Think of MIT as a placeholder until we can formally organize the user community.

Why should the developer community play? Why should developers contribute code, participate as gatekeepers, serve as members of TAB? It could be for a variety of reasons. You might find particular projects intrinsically interesting or challenging. Or if you work for a vendor, it might be in the interest of your company to advance the platform. I know Sloan will give preference to vendors that contribute back code and resources to the community. That will be a very important criterion in our bid awards.

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.

Michael,

It's SCORM compliant in the sense as stated in this thread http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0004oW

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 :)

Al,

I think I can speak for our team in Heidelberg and saying that we are looking forward to productive partnership!

Here is a quote that came to mind when reading your last post:

"The concern for man and his destiny must always be the chief interest of all technical effort.
Never forget it between your diagrams and equations."
-- Albert Einstein

I am thankful to all the OpenACS community for what you all have made possible and I look forward to playing my part.

One possible way to reframe some of the ideas in Al's most recent post in the context of Open Source philosophy is to consider the possibility that the "source" which is intended to be Open in dotLRN is more than just software code. There are methods in teaching--pedagogical API's. Those API's are still largely undocumented, particularly in the context of online learning.

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.

Next week, I will be sitting in a booth at Linux World pitching OpenACS to a massive collection of people wearing shirts like "chown users  /world." There will also be many people who have been growing beards since before I was born. Many will be fluent in Klingon. *AND* Roberto will be there.

The only reason that we can have an OpenACS booth at Linux World, though, is because IDG is kind enough to offer free booths for Open Source projects. Otherwise, this would be a very expensive proposition. Even still, it's expensive for those who are attending as we have to pay for plane flights, the materials for the booth, time in SF, etc.

Regardless of the expense, I am happy to do this and have been delighted to host the socials. I think that all the other individuals, companies and organizations who have worked to bring attention to the OpenACS community feel the same way.

What excites me about the consortium, though, is that it will provide an opportunity for exposure orders of magnitude above what any member of the community can afford at this time. This will provide access to markets and customers that are simply impossible for the small companies and individual developers to access now. I am very grateful to Sloan for providing this opportunity.

In addition, I, as is David Geilhufe who posted earlier, am part of an effort to build a community of nonprofits to build OSS for the nonprofit community. People within that community have named the project dotNGO. I expect that the solidification of the governance process and the prestige that will be brought will give a major boost to the success of dotNGO.

As an OpenACS member and a OSS advocate, I do fear the possibility of a "corporatist" takeover of the community. But I have faith that Sloan recognizes the importance of the volunteer developers who are the lifeblood of the community. If they don't, I have even more faith that Don "Long-haired, owl-loving hippy" Baccus will remind them. Gently, of course.

What has excited me a great deal about dotLRN is the potential application of its work in places that I believe can most gain from OSS educational software - public schools and other resource-starved educational ventures. I am extremely excited to hear from Jon Griffin's post that some of the largest school districts in the country are aware of and eager to use dotLRN.

I really hope that Sloan and the consortium will include the voice of these organizations side-by-side with those of higher and corporate education. The ethic and practice of community participation and sharing of resources can exponentially help these orgs. Their needs and approaches are very different (I expect them to have vastly lower budgets and many more volunteer developers) but I hope they will have space on both the UAB and the TAB.

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.

Al, thank you very much for your response. First of all, it's Neophyt*o*s but don't worry about it -- Roberto did the same mistake in a private email last night.

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.

Collapse
Posted by Don Baccus on
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?
Good question, Neophytos.

I think the answer is fairly simple though. Both projects are in the same boat. They can request changes to OpenACS but can't require changes.

This could lead to a chaotic situation if we're not careful, and I think we're all aware of it. This is why the need for OpenACS experts to be involved in the technical side of dotLRN governance (under either proposal) has been emphasized. If you start a .MINE project and want smooth coordination then you'd be well-advised to include OpenACS expertise in whatever management system you set up for your project (of course you're an OpenACS expert yourself, making this a not terribly good example, but I imagine you get the point)>

What is the underlying motive for projects to play well with OpenACS and for OpenACS folks to work hard to play well with projects based on our code base?

The fact that everyone recognizes that a fork would be very expense, not only technical but in our efforts to evangelise OpenACS, dotLRN, .MINE. .YOURS etc.

It's true that at some point some folks may decide the cost of forking is less than the cost of not forking, or just fork for the hell of it. That's part of the beauty of Open Source, since we can't stop it irrational forking there's not much sense in worrying about it :) What we can do though is work very hard to make sure that sticking together is in everyone's best interest.

Neophytos: I do not see the danger in there being .MINE (and I do not think there is a way of avoiding it if someone wants to branch), yet it must be absolutely clear that it is no longer .LRN and if necessary the projects would be competitors (although that would be a dilution of effort that I would hate to see). On the other hand I would not mind seeing a .WRK but I would push very strongly for cross pollination, collaboration, and NOT competition in this area (in fact a better solution might be a group of .WRK applets).

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).

Sorry for being repetitive (Don)... should have hit the reload button on the thread to see what anyone else had to say before submitting.
Collapse
Posted by Alfred Essa on
Mike: We evaluated Prometheus and decided against. It had some attractive features, but was not *opensource*. It originated at George Washington University and was based on Cold Fusion. Prometheus began to emerge as a strong alternative to Blackboard and WebCT once they began to offer access to the source code and were establishing mechanisms for "code sharing" (similar to Allaire's Developer Exchange for Cold Fusion). These mechanisms have some value, but it's like taking your mom to the prom because you can't get a date. (No knock on moms). You still needed a license from Prometheus. As soon as they began to capture some market share, Prometheus was swiftly acquired by Blackboard. As far as I know, Blackboard has killed the project and existing customers have to move over to Blackboard. If you try, http://www.prometheus.com, it now does a redirect to Blackboard. So much for Prometheus.
but it's like taking your mom to the prom because you can't get a date
Thanks Al. Yes, I too had looked a Prometheus and it's not a platform I would have chosen but was surprised at the level of adoption they had achieved. We certainly don't want to adopt their (conventional) model but will have an uphill battle trying to explain our unconventional one (as evidenced in our struggle to define the governance model.)

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. Perhaps we're in virgin territory.

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.

Collapse
Posted by xx xx on
Well, this thread has really prompted a lot of reactions. I hope I can take a seat at the table too, although I'm aware that I don't have a seat if this is a pure meritocracy.

Anyway, my suggestions to adjust Al's proposal are (bluntly):
1. Drop the .LRN kernel (as a name) and seek governance for one permanent OpenACS-.LRN-.XYZ kernel (don't fork from the start)
2. Use the .LRN trademark for the .LRN package of applets only (if possible)
3. Be sure there's no conflict with a dotLearn trademark

Why?
1. How long will it take before the dotLRN kernel and OpenACS kernel drift apart, if they receive separate Governance? How long will it take before a third strong project will appear to disperse developers even more? Shouldn't there be an agreement on the future of the kernel first (or is there?), when discussing governance? When I searched this thread for kernel/core I found conflicting point of views.
So again, is one kernel/core feasible and is the current kernel forking (as I perceive it) unique for this occasion?

2. Is it possible to redefine the OpenACS kernel as Open-Application's CommunityCore-System (OpenACS/OpenACCS),
with .LRN being the 'office-like' Package of Applets(Open-Applications) that serves the educational community.
This way a .LRN UAB could fit in as easy as a .XYZ application package. Could there be a required OpenACS tarball and some optional application tarballs (.LRN, .XYZ, etcetera).

It really feels dangerous to ask all these questions, so I really hope I'm not stepping on toes here.
But, would 1. and 2. support/disturb .LRN development in the future? How much would it support/disturb OpenACS development?
From my user's point of view -with no balanced opinion on governance- I would like to see a governance that prevents forking or primary features (groups-admin) from being ignored.

3. Lars mentioned: "...customers that we can't sell to today don't care so much about software, they'd like a brand, a name that they can trust. MIT and .LRN and this body could give us that. "
Just to be sure, is IntelliPro.com in on the .LRN-project? If not, isn't there a (brand-name)problem, since they registered dotLearn.com/net/org in 1999?
Collapse
Posted by Don Baccus on
How long will it take before the dotLRN kernel and OpenACS kernel drift apart, if they receive separate Governance?
This is a misunderstanding, there will be no redundant code in the two. The dotlrn "kernel" runs as a set of packages on top of the standard OpenACS kernel.

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

Maybe our terminology needs to evolve :)

Collapse
Posted by Alfred Essa on
Aldert: You are correct. There is potential for confusion of dotlrn (.LRN) with dotLearn (.LEARN). I don't know very much about dotLearn except that they are a content company which publishes "e-learning" titles. They are not well known and I have serious doubts about their business model.
Collapse
Posted by Alfred Essa on
Aldert: You raise an interesting question about the status of the dotLRN kernel. OpenACS core is integral to dotLRN and we have no intention of forking. TAB will consist primarily of OpenACS developers and one of their tasks will to ensure that the two projects remain strongly coupled. As dotWRK and dotNGO emerge, perhaps we will all share a common kernel. At that point, it might make sense to revise our nomenclature. These types of questions will be delegated to TAB.
Collapse
Posted by Alfred Essa on
I find the prospects of dotWRK and dotNGO very exciting. I would like to see, for example, a collaborative package for project management. It's unlike though that that will get developed in dotLRN. It would be wonderful if dotWRK were to develop that package. A consistent architecture would then allow dotLRN sites to use dotWRK/dotNGO applets and vice versa. Everyone would benefit from the modularity and cross-sharing.
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.

Al, could you please let us know if you're planning of posting a revised proposal? After a private chat last night, it seems to me that it is not enough to .LRN for OpenACS to remain neutral. Is this the case?

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)

Collapse
Posted by Alfred Essa on
Neophytos: I do plan to submit a revised proposal in the next few days but it will not be substantively different from the existing one.

I am a great admirer of Classical Greek Civiliation and a student of Plato, Aristotle, and Thucydides. I, therefore, find your comparison of this debate to the exchange between the Athenians and Melians interesting but absurd. Please provide arguments instead of using indirection as a rhetorical tool. State *clearly* what you want, what you fear, and what you think the governance model should be. Lay it out on the table and let everyone examine your views. Do you have any substantive proposal to bring forward?

The implication that we are trying to strong arm openACS developers is ludicrous and you know it. Don't forget that we are making available code under GPL with the goal of *growing* the OpenACS community. We are not taking anything away. As everyone knows, we have no control over OpenACS and this governance model is not about OpenACS development. Similarly, we have not the intention, desire, or ability to compel anyone to do anything with the dotLRN code. But you don't have to believe our intentions. Even if we harbored imperial designs, GPL does not permit anyone to seize control of the code. To claim otherwise is sheer sophistry on your part.

As Lawrence Lessig has observed, opensource code is by definition "non-rivalrous". This means that my using it does not take away or hinder your ability to enjoy it in anyway. Isn't it absurd to call us "imperialists" when we our sharing our code and designing mechanisms to have *more* code available as opensource? The Technical Advisory Board will consist mostly, if not entirely, of opensource developers. Moreover, our proposal is intended to give *more* representation to more constituents.

Maybe you can enlighten us all about your "private chat". I still don't know what you want or what you are arguing for. What do you want?

Al, nothing that I posted in this thread is absurd. Everything is there for a reason. Unfortunately, we had a power failure in my area and I'm leaving for Paphos now (My laptop's battery is almost empty). I'll reply to your message as soon as I arrive to Paphos.

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.

Collapse
Posted by Don Baccus on
If you're talking about your conversation with me, Neophytos, no, I'm not interested in having it published in public.  When you ask me private questions I answer in private, if you want public discussion, ask in public.

However, as you know, I agree with everything Al says above and disagree with your rather paranoid fears.  We have a great opportunity in front of us.  How about giving this opportunity a chance rather than work to sabatoge it before it gets off the ground?

Collapse
Posted by Don Baccus on
It may be your interest to be our masters, but how can it be ours to be your slaves?
To be honest, Neophytos, I find statements like this to be offensive. MIT is not working to become our "master" nor to make you or anyone else their "slave". I find absolutely no justification whatsoever for insinuating that this is the case.

I think you owe Al a personal apology.

First, of all you realize that this is a forum maintained at the OpenACS project. Thus, my messages in this thread are not only addressed to .LRN but also and especially to the OpenACS community, its developers and its leaders. More than once in this thread it has been mentioned that there were efforts to keep people quiet so that they wouldn't share their view in public, so I consider it at least a paradox to claim that my posts have been absurd.

Don, I spoke with other people as well last night. Anyway, the person emailed me and said s/he would appreciate if I don't publish the chatlog and I won't -- end of story. You see some people have to make a living and they don't want to crash their heads against the *wall*.

State *clearly* what you want, what you fear, and what you think the governance model should be.
Here's what I want (both in spirit and in letter):
  • The OpenACS project decides and/or nominates and/or elects its representatives to the .LRN Technical Advisory Board (and *no* I'm not interested to take a seat on the board). Here are the people I nominate (the OpenACS gatekeepers -- in alphabetical order):
    • Ben Adida
    • Don Baccus
    • Roberto Mello
    • Dan Wickstrom
    • If there are more seats on the board, I would also like to nominate Jon Griffin. I have taken into consideration the companies and/or related stuff before I submit my nominations.
    • Second request is that both the .LRN camp and the OpenACS project state clearly that they are separate (in the sense of their governance rules and processes) and that OpenACS would remain neutral in case more projects are founded. (more info: check the discussion about OpenACS packages in the "Open 4.6 Items & Project Status" thread in the OpenACS Design forum)
    • Thank you very much for your attention.

      Best wishes, Neophytos

Collapse
Posted by Don Baccus on
The OpenACS project decides and/or nominates and/or elects its representatives to the .LRN Technical Advisory Board
The OpenACS project itself isn't democratic (who elected you to be the driver for the 4.6 and 4.7 releases?), it's more a meritocracy.

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.

I still think you owe...
I'm a non-native English speaker, as you know. What do you mean by "owe"? BTW, my message is what I posted -- a passage by Thucydides. I didn't want to suggest anything. Each one interprets that passage in whatever way he wants to.
Neophytos, regarding the separation of dotLRN and OpenACS, I don't see anything than anyone has said that implies otherwise. Now, the mechanism of cooperation between the two probably does need to be fleshed out over time, but really, the only concrete issue I've heard voiced was about pushing generalized code that was developed by and paid for by dotLRN consortium members down into the OpenACS core. Most of the disagreement on this issue took place between two of the people you have nominated in your post, and the precident-setting resolution was to push code down into the OpenACS core  whenever (a) it makes technical sense to do so and (b) the OpenACS leadership decides they think it's right for OpenACS.

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.

I haven't follwed this thread at all yet, but I'd just like to suggest that everyone take a deep breath, calm down, and think before posting.

Let's all try to be nice to each other and talk this through. All of us are trying to get things done in a good way, so let's keep that in mind.

Collapse
Posted by Don Baccus on
Well, nice thought, Roberto, but Neophytos just did what he always did.

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 has dropped out, again, without warning for the second time after making personal commitments to the project.
Don, I suggest you watch the language you use when you refer to my name, especially when one of the primary reasons I "dropped out" as you say is the way *you* handle the .LRN issue.

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). Laking 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 majore 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 internationalizatoin work).

Sincerely, Carl

Carl, thank you very much for your message -- I really appreciate it. In fact I agree with everything that you have posted. You may or may not know that I'm participating in the OpenACS project as a volunteer -- my paying job has nothing to do with OpenACS.

Yes, I'm upset about the things that have been going on both in public and backstage. In a private chat, someone claimed that I was a community resource and if I decided to dedicate my time elsewhere then I would be forking community resources. How can one claim that my posts have been absurd when such statements were made? How can one tell me what to do with my time?

As you have noticed my requests (not demands) were that the proposals be revised in a way that the OpenACS project choose its representatives (not *asked* to join) in the TAB and that OpenACS is neutral. Are these requests absurd?

Maybe my post about leaving the project was not clear enough. What I really wanted to say is that I was leaving the management team in the sense that I have been the release manager -- now, I'm only a community member and I would gladly share my work with anyone in this community for free (as in freedom). But, as long as I don't agree with the things that are going on in the project, people will have to download my work from the file-storage area and if someone wants to commit it in the CVS tree, he has the freedom to do so.

I don't know if I have addressed all your points, so please let me know if I missed any and I would gladly post again. Please know that I'm writing this message with all the good faith and not scepticism.

Collapse
Posted by Alfred Essa on
Neophytos: I want to second Carl's posting. We share the same goals. You are focused on OpenACS, which needs to serve wider goals and must maintain "neutrality" as you call it. I think you want to make sure that dotLRN does not dominate and eclipse OpenACS. This is a legitimate concern. Since dotLRN rests on OpenACS, it's in our interest not to alienate or try to dominate OpenACS developers. Suspicion and mistrust breeds in the absence of knowledge. We will do everything possible to share our intentions and goals with the community. I do want to *thank* you for having the *courage* to speak your mind.
Al, thank you very much for your message. I really appreciate it. My apologies about the Thucydides passage even if I did not mean to say that MIT would enslave the community.

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... http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0005lA I hope it is not as a much of a roller coaster ride as this thread has been.

Collapse
Posted by Don Baccus on
In a private chat, someone claimed that I was a community resource and if I decided to dedicate my time elsewhere then I would be forking community resources.
I said that, and it's a true statement. "diluting" is a better word. 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.

I made the obvious point that I would do my utmost to discourage a move like this, because it would dilute our resources and our resources are already inadeguate.

And you're one of those resources. If the meaning of this isn't clear, maybe someone else can help with a definition in terms you'll understand.

If you misinterpreted my words to mean that I think the community has a *right* to your time, I did not mean that at all.

Of course if you chose to spend your time off on your own on a forked-off dotLRN, that's your right, just as it's my right to try to convince everyone else to continue to play with the home team.

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.
Well, as I said earlier in this thread, I would gladly publish a chatlog of our discussion if you agree. You are only taking part of the discussion and making your argument on things I've never said. When did I say that "I would encourage others to join me to leave the main effort"? And yes, what you said in that chat was interpreted as if I was forking community resources if I decided to allocate my time in a different way? So, if you agree, I'll gladly post a chatlog as soon as I'm back to Nicosia and let the community judge of what has really been said in that chat.
Neophytus,

It seems this is going nowhere, and both yourself and everyone else appears to have had their say.

I'm sure we can all accept there's been some confusion and misunderstanding. But there doesn't seem any value in continuing this war of words much further.

Could you not now let this go, and get back on track with the release management? We're waiting to start up the testing, so if you can get going again that would be much appreciated. I'm sure primarily we're all looking forward to a timely, and quality 4.6 release.

Regards

Simon

Neophytos,

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:

http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0005lA&topic_id=11

Collapse
Posted by Alfred Essa on
Simon: - I applaud your effort to also achieve similar transparency in governance for OpenACS. It will help all our efforts.
As I mentioned in the other thread, I'll hold off until 4.6 is pretty much complete, but that should give everyone chance to mull it over prior to a debate...

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

Like you... I would like to see as much of the OpenACS leadership on the TAB of dotLRN to lend the project stability,

[...] 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, once more, thank you for your kind words but I want to assure you that I do not consider myself a leader in this community. Others are more entitled to claim that for their selves. Myself, I've just contributed my work and spoken to my worries -- nothing more, nothing less. I've no doubt that dotLRN would be a big success and I said that already both in public and in private.

So, thank you again for your kind words but I really don't want to be involved in this anymore other than being just a plain community member. Be sure though, that I'll gladly dedicate as much of my time to work on something that I can contribute both to OpenACS and dotLRN provided that I'm not alienated by their governance and decisions.

Collapse
Posted by Alfred Essa on
Neophytos: Leadership is manifested in many guises. Your passion speaks to your commitment to OpenACS. That's leadership. In an "open community" it's also necessary to have people who are willing to "rattle the cage". It makes us all question our assumptions and motivations. That's also leadership.
Neophytos: Leadership is manifested in many guises. Your passion speaks to your commitment to OpenACS. That's leadership. In an "open community" it's also necessary to have people who are willing to "rattle the cage". It makes us all question our assumptions and motivations. That's also leadership.
Al, once again, thanks but you see, I've lost too many friends by taking such an active role in this thread and that was not my intention. By being a "leader" in this community, I'm not going to win them back and I want to have a chance to win them back in the future. So, again, thank you for your kind words and I wish you all the best in your efforts for dotLRN and I hope you'll do your best to balance everything. We have *all* become wiser in this thread, I'm sure.
So I spent a good deal of time reading and re-reading this thread. We also talked a lot about this issue while at LinuxWorld.

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