Forum OpenACS Q&A: OpenForce's commitment to the OpenACS free software community

The last few weeks, however, have seen these rumors spread and grow beyond anything I expected. I'd like to take this opportunity to strongly reiterate our beliefs, our commitments, and point out the efforts we've made to always be top-notch contributors to the community.

OpenForce is entirely dedicated to free software. Our name says it. Our work says it. We will never waver from this. Our code, whenever possible, will be released under the GPL. Always.

A few important points to support our words with actions:

• OpenForce was the first company to commit to OpenACS - not ACS. We committed to OpenACS back when it wasn't such a safe bet, back when everyone said "we work with ACS.... oh and with OpenACS too." OpenForce was one of the first companies to develop and host a commercial OpenACS site (GreenOrder.com).
• OpenForce actively lobbied ArsDigita to provide OpenACS hooks into ACS 4.x, and to maintain code under the GPL license. At every conference where we gave speeches (ArsDigita meetings, the European Free Software Meeting, the O'Reilly Open-Source Conference), we pitched OpenACS as a platform and *every* current OpenACS company equally.
• OpenForce has contributed *many* critical packages to OpenACS 4.x, including total rewrites of forums, calendar, notifications. Important rewrites, cleanups of file-storage, faq, news. Important rewrites and optimizations of the core APIs. Entirely new packages from the dotLRN work.
• OpenForce was the first company to *manage*, not just release, a client development effort in an open-source manner - dotLRN. Until Lars's announcement yesterday, we were the only ones. We applaud Collaboraid for taking this even further with their latest Internationalization effort. Open-source development is not always easy. Open-source development of a client project is quite difficult.
• Although not specified in our contract with Sloan, OpenForce designed dotLRN to be as modular as possible from the start. There are currently four companies doing parallel yet compatible dotLRN-based development thanks to this architecture. OpenForce chose an architecture that created a new market: we effectively created our own competition because we believe in true open-source development.
• OpenForce designed an architecture for dotLRN that allowed dotLRN to benefit from OpenACS *and* OpenACS to benefit from dotLRN without forcing an install of dotLRN. This is far from trivial. It's the reason for the 3-package approach to building a dotLRN applet. It's the only such client development that has been completed successfully to date: true symbiosis of the platform and client application.
• OpenForce lobbied for assigning dotLRN copyright to the Free Software Foundation as a means of ensuring that future, diverse interest in the dotLRN platform would never compromise the GPL status of the code.
• OpenForce managed, wrote most of, and released the PostgreSQL port of dotLRN under the GPL (with the help of some community members like Neophytos and a number of others). This was not part of the Sloan contract.
• To this date, OpenForce spends thousands of dollars in legal negotiations with every client to make as much of the resulting code as possible available under the GPL. That is our continued dedication to free software and to the community.

So why this list? Because somewhere along the road, some people got the idea that we were no longer contributing. That we were fighting against them. We *are* contributing. We are *not* fighting against anyone. We're working with the community. We're trying to make OpenACS bigger and better.

I'm asking that you judge us by the results we've accomplished, by the actions we've taken. Look at the code, look at the opportunities created by this code.

If you have questions, I am making myself available by email, IRC, and physical presence. I'll be at tomorrow's social that Talli is organizing in NYC. Feel free to ask me about doubts you have. Feel free to question anything we've done, as long as you place your faith in the code produced and actions taken. If you have specific requests about things you think we're doing incorrectly, please tell us!

OpenForce is committed to free software and to the free software community. We always have been, and we always will be.

I am at the same state as Vinod.  Don't know why Ben posted this.  And why DonB replied that way.  Can someone fill in the details and points?

So no comment on the above posts except... what the heck is going on?

I can't really comment much.  But for whatever happens I hope things are possitively resolved.  I don't know who else are involved but even if its just OF and DonB there is already a substiantial part of OpenACS contributors involved.  At any rate I hope things turn out for the better, a negative turn out may severly have a negative impact on the project.

Anyway I am sure community members like me who have little knowledge about this and is concerned about the matter awaits further postings by any other community member involved in this issue.  Thanks.

As far as I am concerned anyone who is spreading this rumor should be taken to the woodshed and given a sound beating. I will be the first to get in line with the paddle.

Before Ben left for vacation, I asked him to serve as dotLRN kernel gatekeeper. Don Baccus, as chair of the dotLRN Technical Board, asked if someone from OpenForce could also serve on the Technical Board. Make no mistake about it, this would have given Ben and OpenForce *THE* dominant voice in setting technical direction for dotLRN. This was in recognition of Ben and OpenForce's contribution in developing dotLRN. Ben said that he would give his answer after returning from vacation. Note: *THE* dominant voice does not mean the *ONLY* voice.

As many of you know, dotLRN is generating tremendous interest and momentum because of the work of everyone concerned. However, every day that goes without achieving clarity and transparency we lose potential adopters and potential funding. We need to move on with the governance for dotLRN. We need to know *how* OpenForce wishes to particpate in dotLRN. The issue is not whether OpenForce contributed to dotLRN or is committed to open source. Who the hell questions that? However, we need to be clear as soon as possible on how OpenForce wishes to participate in dotLRN. No one expects OpenForce to do all the work. But we need to know who is going to write the developer documentation. When will the code be released officially? How will bugs be tracked? On and On and On.

Do I expect OpenForce to do it all? No. It's precisely because OpenForce can't do it all that we need to know what OpenForce is willing to do and can realistically be expected to do. Whatever it can contribute, the community will be grateful as in the past.

When Ben returned from vacation, we received an email from him declining to serve as gatekeeper or have OpenForce representation. That's a business decision that Ben needs to make, one which he has every right to make, and for which he will be respected. Ben does not believe that the governance plan for dotLRN will work. Carl and I asked him to reconsider. I will post my email message below. I won't post Ben's original message rejecting participation in dotLRN governance unless he wishes to do so himself. We did not receive a reply from Ben. Instead, I saw this posting.

Aside from posting my email to Ben, this will be the one and only posting from me on this topic. I need to spend my energies on dotLRN and all the work that remains to be done, not chasing rumors and innuendoes.

Ben,

I am extremely disappointed in your decision and hope that you will re-consider. dotLRN owes its success to your leadership and that of OpenForce. I know others would also agree with me that OpenForce participation is critical to dotLRN's future. By your serving as kernel Gatekeeper and also OpenForce having representation on TAB, you and OpenForce will have the most influence and power to shape dotLRN's future.

What problems are we trying to solve with the organizational structure? If dotLRN were entirely a technical platform, then dotLRN governance should be of developers, for developers, and by developers. But dotLRN is a vertical application and for that reason it's success will not simply depend upon developers. dotLRN did not get built nor will it evolve because of developer "itchiness". Developers didn't come along and say...."gee wouldn't it be nice if we had an e-learning platform." dotLRN got developed because people put money on the table.

The problem we are trying to solve is simply this. If dotLRN is to succeed we need the widest possible adoption and as quickly as possible. In my estimation, we have a small window for success, twelve to eighteen months at most. In order for dotLRN to succeed, we need wide adoption. In order to have wide adoption, we need:

• transparency. this point has been made eloquently by Carl and I won't make it again. this comes up over and over again with everyone I talk to. as soon as one starts to talk about "organic" processes, the decision makers head for the door. it's as simple as that.
• legitimacy. having the MIT and Univ. of Heidelberg brand helps.
• sustainability/funding. dotLRN will not succeed if we expect developers to code and thereby scratch an "itch"; most developers could care less about an elearning platform; they do care about having bread on the table. for me the primary goal of the EB will be develop a business plan so that dotLRN development can be sustained and that there is adequate funding to do the things we all want to do.

Best,

Al

I am still hoping that Ben will change his mind about being gatekeeper (it is still very early for dotLRN and I feel his experience would also be valuable in building the dotLRN Consortium)... yet time is of essence and we need to move on (we have been waiting for Ben's response for more than two weeks).

I would like to emphasize that one of the major selling points of dotLRN will be vendor independence. dotLRN is going to succeed with or without OF (partially due to their commitment to open source software)... I hope with. If Ben ultimately decides against it, it will set dotLRN back... but dotLRN will survive. If Ben does not want OF to take part in the governance I hope that they take part in other ways.

Carl

P.S. To prevent problems related to transparency in the future the i18n agreement between Collaboraid and Heidelberg has specifically made transparency a requirement. I hope that this can serve as a model for future dotLRN/OpenACS development. Please follow and contribute to decisions here: http://www.collaboraid.biz/extranet/i18n/

But I disagreed with him on the issue of dotLRN governance, and spent a fair amount of time trying to convince him that Al's plan was the better one. And though I disagreed with him, I strongly believe that Ben's rejection of Al's plan was entirely principled, and that he had no ulterior motive for that rejection or for refusing the dotLRN gatekeeper position.

As for the rest, as I said above I'm going to keep my mouth shut. If that makes me "incredibly sleazy" in your eyes, then so be it. The community's more important than my reputation and a public slugfest will do no good whatsover.

• my original posting has nothing to do with my opinion of the dotLRN governance issue, which I was waiting to resolve with Al before publicy discussing.

• Don, if you have no issues to point out, then I have no answer to provide. If you have some "rationalizations" in mind, then I'm sure you know what issues these were supposedly refering to (I sure don't). The only reason I brought this up publicly is because you've been bringing it up privately, causing divisiveness privately, and refusing to hear my technical opinion privately.

• new-portal. OpenForce has always developed this to be OpenACS- dependent and not dotLRN-dependent. I never advocated that new- portal should be dotLRN-dependent. One of my private emails was grossly misquoted on the issue, which understandably led to this misunderstanding. What I advocated was the idea that new-portal shouldn't be distributed with the base OpenACS tarball and stuffed down every developer's throat, because I believe that is serious bloat. I suggested distributing it separately, as an independent package. I went back on this decision after I realized that, given current OpenACS architecture, this would make people's life more complicated, not less. That said, I'm still very worried about OpenACS bloat.

• new Tcl procs: we cleaned up a lot of the Tcl API but we never deprecated old procs, we made sure they were always functional. We tried to give as much help as possible to point this out, but we probably didn't do enough. We'll work more towards that, this makes a lot of sense.

• documentation: yes, we have not documented as much as we should have. It's very difficult under client deadlines to do so. That said, we've provided as much person-to-person help as possible. We've offered our help to MuseaTech, Furfly, and Collaboraid in case they hit any snags. We'll work harder on this, this point also makes sense.

• generally increased communication: we'll work harder on that, too. I think this is a general problem that we all have, apart from the few courageous documentation gurus like Roberto and Vinod, without whom we would have code and no docs.

Or I can sit back and let Ben cheerfully paint himself as being, as always, the innocent victim of a misunderstanding that he himself bears no responsibility for.  Making me look like an ass in the process.

Hmmm...I'm in an enviable position, don't you agree?  Fucked if I do, fucked if I don't.  Wonderful.

OK, Ben, I guess you win.

I wasn't aware of these OpenForce rumours, and I really don't know what are the issues and events involved in Don's disagreement with Ben.

I will now go ask the Jedi council for guidance from the force, because it seems the only way to find out what's going on.