Frank, I think it would be a huge mistake to not use the object system of OpenACS. It is what allows components of OpenACS to interact with each other.

On one hand your website says you jumpstarted P/O using the ACS 3x Intranet, on the other you pose 'certain restrictions' on the re-distribution of 'your' software by third parties for commercial purposes, for a number of reasons explained in your partner agreement. Can you clarify this part? ( I got a weird message in German when I clicked on it *404: Datei nicht gefunden!*).

Also can you illustrate what is it that P/O has that ACS intranet didn't. I mean a little more detail than saying 'complete redesign of the ACS Intranet.'?

Why don't you pool in your efforts and ideas to complement the dotWRK initiative? There are quite some folks out there trying to work on this here right. (http://openacs.org/projects/dotwrk/people). There were members in the community encouraging you in this direction back in September right?(http://openacs.org/forums/message-view?message_id=124433)

OpenACS 5 has come a long way since ACS3x, and you also say, your work is a modified 3x in effect! Isn't that fork like...stuff from 'way-back-in-those-days'?

What about dotLRN?

Suppose forums, forums-portlet and dotlrn-forums were not written and someone wrote those. Would they be able to claim a licence on those three packages based on the code that is currently in those packages?

Hi,

yes, I know, I'm getting into deep trouble here. So be prepared!!!!

First of all, it's important to emphasize that Project/Open is a _commercial_ project. This is a necessity for me, because the tech sector here in Spain doesn't do very well, and there are no Content & Communtiy clients around here that would pay for my salary. I really envy some of you guys in Boston/Hamburg...

So the development of Project/Open has to follow basicly the rules of commercial software development, which is return of investment. And there are very limited resource to invest as you can imagine. So this criterium tells us to minimize work on the code except it makes a tangible difference for a customer. So introducing objects for example can only be a third priority. First we need to satisfy a few customers here and second we need to get rid of Oracle.

And then I've (personally) a huge doubt whether ERP software (and that's what Project/Open is aiming at) and the "classical" open source development process go together very well. ERP stuff is extremely boring, and no reasonable open source developer would work on it without an urgent necessity. Some sociologists even describe us as hedonistic. On the other hand, companies don't mind to share a part of their benefit if they employ a software that helps them to reduce costs or to earn more money. So I hope I have made a reasonable case why we are employing different priorities with Project/Open.

So Don, does Project/Open really need to become part of "The Community"? I seriously don't know, and it really doesn't matter very much from the ROI point of view. We all owe a lot to Philip and ArsDigita, so I definitely want to give back to the community. But I am actually not that impressed by OpenACS. The software usability is quite poor and it has completely lost the race against PHP.

This is the reason why I am (personally) following the OpenACS from a distance (there are other people somehow involved with Project/Open that have a different opinion). Don, I understand your intention to maintain coherence, but it may not always be helpful for the community. I hope that was a polite reply, wasn't it? Or is there now a "community police" after Patriot Act II has passed?

Lars Pind wrote:
> > My understanding is that P/O focuses mostly on "boring"
> > functionality such as costs, invoices and other financial
> > transactions that are more typical for ERPs then for
> > communicaty or collaboration systems, so I don't see any
> > duplicated code here.
>
> This is interesting. I was planning on writing some of the
> cost/invoicing stuff for our own needs. We won't, obviously,
> if you already have this, and are porting it to 5.0.
>
> Are you planning on using/extending logger for the timesheet
> features?

Sorry Lars, I haven't checked the logger yet. Timesheet management is based on Intranet 3.4 code with extensions from Competitiveness for managing budgets.

Actually, we plan to move all cost/timesheet/... stuff into a separate module, because accounting processes are handled quite differently by companies of different business sectors (notably service and production) and between the EU and US. The idea is to saw the seeds for a whole variety of "Cost" modules adapted to each specific purpose (=> vertical solutions). Check http://www.project-open.com/whitepapers/ for more details on the module concept.

Lars Pind wrote:
> > I feel that this [commercial] focus conflicts in some areas with
> > the general OpenACS philosophy, for example in terms of
> > producing pure open-source (we consider proprietary
> > "added value modules" for the future) or in terms of being
> > more conservative in terms of the architecture used (see
> > next paragraph).
>
> Interesting read. Speaking for Collaboraid, we have a pure commercial
> focus, looking for the real customer needs as a first priority. However,
> we believe that the commercial ends are best achieved through an open
> source development model that builds and builds on the network between
> developers, users, vendors, and clients. But so long as the legal stuff
> is in order, everybody's free to pursue their business objectives the
> way they best see fit. I don't think you'll find people opposed to you
> writing proprietary software on top, but don't expect unpaid help from
> the community to do it. :)

I truely believe in giving back to the community, and I'm actually checking for new forms on how to do it. Venkatesh has cited me with:

> on the other you pose 'certain restrictions' on the re-distribution of
> 'your' software by third parties for commercial purposes

I have already mentioned here on OpenACS (last message at http://openacs.org/forums/message-view?message_id=124433) that I'm thinking about a new model to license "added-value" modules using a new Partner License. This license is based on the idea to redirect part of the money that "Implanters" (like Collaboraid) make from services around OSS to the developers of the modules. It's not finished yet, but I've advanced a lot on the legal side. It's going to be similar to the way how artists receive money when radio stations play their songs...


Lars Pind wrote:
> > I have the perception that the OpenACS architecture is
> > based on the idea that everybody should have access to
> > all information, unless it is explicitely forbidden,
> > while P/O takes the oposite view, resulting in a
> > relatively complex management of user permissions.
>
> OpenACS has a fairly flexible permissions model, which we're still
> learning to use properly. To me, this isn't a question of philosophy, as
> much as it's a question of meeting customer needs. If we understand how
> customers need permissions to work, we can do it.

There is a difference between a permission model and a concrete implementation/configuration, as there is a difference between the OpenACS toolkit and www.greenpeace.org. It's just a question of time and resource investment. Perhaps "the community" could pitch in and help with adapting all of these f.... 255 pages to the OpenACS permission model... However, I'm a big fan for XP-type "phases", and I think the objective of phase 1 is to get the system running on OpenACS and Postgres, right? We'll see how many voluntaries are going to pop up to do this _extremely_ boring stuff ...

Lars Pind wrote:
> > The management of complex user permissions has lead the
> > development of P/O towards "components", instead of
> > templates. Juanjo and I had some very interesting
> > discussions on this subject, and we haven't come up with
> > a final solution yet.
>
> I don't know what components are in this context.

Well, I've written some PPS about that in the Whitepapers section of the P/O site. I think you'd call it a Portlet or similar. It's basicly just a TCL procedure that generates a piece of HTML.


> > I think I can speak in the name of the whole P/O team to
> > say that we would be very pleased if we could engage in
> > some kind of cooperation. We'll publish the code as soon
> > as we have a basic OpenACS version running.
>
> Likeways. I'm certain we share many objectives, including making a
> profit. The trick, of course, in distributed development between parties
> with fluctuating interests and companies like my own with different
> client obligations at different times, is to get to focus on the same
> problems at the same time. That's a real challenge.

I completely agree. I'm really curious how this is going to evolve. Fortunately there is much to win but nothing much to lose. Strange really, normally it's the other way round...


Bests,
Frank

I don't see anyone rejecting, what I see is folks asking for clarification.

In the past (as I said above) with the modular structure of OpenACS 4.x (which includes 5.0) we've taken the position that packages that are written standalone, not containing GPL'd code, don't need to be GPL'd. Much like the position that the Linux folks take with the kernel - if you make kernel API calls that does not require you GPL your code. GNU developed the LGPL to make this more clear in regard to libraries but AFAIK GNU's never taken an extreme position in regard to libraries anyway - the LGPL was created to clarify things (folks who know the history better, feel free to correct me).

So I think we're on the same wavelength in regard to licensing.

But I am actually not that impressed by OpenACS. The software usability is quite poor and it has completely lost the race against PHP.

Hint: insulting the community isn't likely to win you friends and isn't likely to foster an atmosphere where community volunteers chip in with hints on design or implementation.

We're not in a race against PHP - which is a language, not a community-based system. While we are working to improve the out-of-the-box usability of OpenACS, that's not our only or even primary goal. "Why not?" That's an exercise I'll leave to you to figure out. Because your tone does nothing to encourage me to spend time educating you.

I will say that porting from OpenACS 3.x to the OpenACS 5.0 platform is a very sizable task if you're going to do a proper job, and if you're not going to do a proper job, why bother? You can import the templating system into the ACS 3.x environment, for instance.

And if you really feel PHP has torched our ass and that we've lost the race (an odd observation since we're not "racing" PHP), why not port your system to PHP? It might even be easier for you since it appears you're not likely to do a proper integration with OpenACS 5.x anyway.

And by choosing PHP, why ... you'll be on the winning team, surely preferable to hanging out with a bunch of losers like us.

Hi Don,

I think it's important to understand the different priorities of OpenACS and P/O to avoid unnecessary negative emotions in the future. Because at the end the community lives from the contributions of its member and members from the support of the community:

I supose the priorities for the OpenACS leadership team are to guarantee the interoperability of the code and to maintain coherence in the community. Is that more or less correct?

The current priorities of the P/O team are:
1. Satisfy some customers
2. Get P/O running on 4.6 and
3. Get rid of Oracle in order to involve more community members and to extend the potential customer base.
4. Adapt P/O to 4.6/5.0 object, permissions, templates etc.

That's because without some quick results from 1 there are not 2 and 3 and 4. And 2 is a necessary step before 3 and 4. I hope that sounds reasonable.

Concerning the adaptation to objects, permissions and templates:

- I'm not 100% happy with the permission management as it exists with P/O today, because it is currently a function of the user profile and it doesn't take into account object characteristics, which is necessary in many cases. Also, there is quite some code redundancy. So a reorganization of permissions could lead to a permission system integrated with the rest of OpenACS.
- P/O employs hardly any content management functionality so all the related OpenACS functionality doesn't apply.
- The application of templates to "components" (~portlets?) is an open question that we need to discuss more in detail.

So the area of potential "conflict" is actually quite limited. I propose that we continue the discussion in February when priority 2 is finished and eveybody can analyze the P/O code on their own systems. I'm curious to see how much interest is going to be exhibited by the community to advance with priorities 3 and 4. I still wonder why the old Intranet module hasn't been ported and published yet...

Cheers,
Frank

Frank ... a bit of history ... the e-commerce package, originally an ACS 3.x package, underwent a staged migration to OpenACS 5.0.  The first port was not very "OpenACS 4-ish" at all - it's become better integrated over time as people have had time (and client dollars!) to spend on it.

So my criticism is not of taking a staged approach, because we ourselves have done that, but rather to rejecting (say) the object system or other key elements out of hand.  Not just as something to skip over in the short term but to permanently avoid.

Also in regard to the object system ... no one will suggest you turn every table in your datamodel into an object.  The things that would want to become objects are items that you want to control via permissions, to categorize, to allow comments on, to allow attachments on, etc.  If you want revisioning/auditing (as you might with CRM data, for instance) you may want to go a step further and use the content repository.

*eventually* - I think everyone here would agree that a total integration as a first step is unrealistic.

As to why the intranet module's not been ported over, there's not been sufficient interest in that package as it existed originally within our community.  This probably has more to do with the kind of client most of us work with than anything.

Community people - led by Jade, who posted above - have started .WRK which will include some of the intranet functionality but also other things which they've deemed more important that was NOT implemented in the old intranet.  Real project management tools, in particular.  Jade's work is driven in large part by his employer's needs.

That's kind of how things are driven around here.  In part "scratching an itch" - personal interest - but also to a large degree by our client's or employer's needs.

> I don't think we have any problem with proprietary
> code on top of OpenACS, but generally you're not going
> to interest very many other people in working with
> your code unless you release your code under some sort
> of open source license.

Let's asume the "Translation Workflow" module: Do you think anybody in this community cares whether this module is GPL or a "Partner License"? Do you think they would help if it were GPL? Or what about the "Translation Freelance & Quality" module implementing provider management and statistical process control?...

This is the type of modules nobody in the community cares about, but that provide a complete solution to a translation company, so that they are willing to pay for the system.

A more critical example is the timesheet/cost module, but this is GPL because it's based on the original ACS 3.4 Intranet code.

I hope it's getting a bit clearer where a PL makes sense and where not, right?

Frank

I think one issue you're missing is that modules aren't necessarily adopted wholesale, i.e. it is common to cobble together a custom site by taking bits from here, bits from there.

So let's say someone signs your partner license for one of your specialized packages, needs to do some heavy customization, and could do so by taking a bunch of bits and pieces from some of our GPL'd OpenACS work.

Or conversely build a custom site based on one of our GPL'd packages that could benefit by cobbling in some of the work you've done in one of your commercial packages.

The licenses clash and neither is an option ...

So, yes, it DOES matter, and there's no sense in saying it doesn't.

The question, then, is HOW MUCH does it matter?  I think you've seen from this thread that certainly it doesn't matter so much that people will complain, or dislike you, or refuse to talk to you, or not answer your questions, etc etc.  That's not the point.  It is just that code not GPL'd will always be of less use to the community than code that's not.  This is not necessarily a big deal, but it may be a big enough deal that some community members won't be particularly motivated to jump in and help with such code.

Still such code is more useful than custom code done for the client that never sees the light of day, is never distributed, etc.  I think the following hierarchy certainly holds:

1. GPL'd code
2. Non-GPL'd code released under another license
3. Custom code never released at all but kept strictly confidential by a client

Most of us here have done plenty of code in #1 and at least some code in #3.  Thus far our community's avoided #2 but then again no one else has raised the issue with the kind of detail you're providing.

Hi Frank,

One question on the partner license: If I use your code and modify it heavily to make it more useful, can I release my modifications under the GPL? How can we make sure that it will stay in sync with modifications you are doing in the future and that someone can *patch* your version with my GPLed modifications.

For obvious reasons you are not able to include my modifications in your partner licensed product.

Alternatively, I made modifications that you like. How would you pay for the modifications made by myself to be included in the main trunk. How do we prevent forking? Am I stuck with a commercial product where I can only *hope* the vendor will make changes that are useful for my client. After all this would turn the whole notion of using OpenACS upside down.

Maybe you can clarify your ideas there as well. Other than that, it is great to know that you are planing to go for OpenACS 5, and as Don and others mentioned, make as much use of it as possible. This might make it harder to port at the beginning but will give you huge advantages at a later stage (as you will benefit from extensions done to the core in the future).

Looking forward to see more of it!