Forum OpenACS Development: Porting Project/Open (Intranet Module) to OpenACS 5.0

Hi,

I would like to announce that the Project/Open (http://www.project-open.com/) team has started the preparations to port the P/O "core" functionality to OpenACS (probably 5.0). We are looking for support from the community.

A Short Update on Project/Open

The Project/Open "Core" functionality is based on the ACS 3.4 "Intranet" module, dealing with projects, project collaboration, customers and users. It has been extended to handle financial data and employs role-based permissions.

Project/Open is an umbrella organization with the objective to develope and promote sector-specific applications:
- Project/Open "Core": Generic functionality around Projects, Customers and Users
- Project/Translation: An ERP system for Translation Agencies (most advanced project today)
- Project/Knowledge: A project management solution with Artificial Intelligence search functionality (Bayesian Networks based content classifiers)
- Project/Agency: A solution for advertizing agencies (a preconfigured "Core")

The current project team currently consists of:
- 1 Final thesis student from "La Salle" Tecnical University working on Project/Translation
- 4 Final thesis students working on Project/Knowledge
- A marketing team with two persons
- A two person management team for Project/Knowledge
- A two person general management team

Project/Translation is currently in productive use as a ERP system in 2 translation agencies and in one consulting company. Active negotiations are going on with some 6 potential customers.

Porting Project/Open to OpenACS 5.0

To understand the challeges of porting the P/O core to OpenACS you have to understand that P/O follows a quite different philosophy compared to community systems, because it has to deal with critical business data such as customer lists, payroll and financial data. Also, the GUI needs to be quite different...

So I am not 100% sure if we are going to adapt all of the OpenACS 5.0 features. In particular I have to admit that I'm (personally) not a fan of object orientation in Web applications, even though I have to admit that it may be useful in areas such as content management. I prefer to go more with components, which actually seem to fit quite well with a "relational object model".

So there are still a lot of decisions that need intensive discussion. So we have decided to go ahead with a phased development, starting with "legacy" code, so we can reasonably postpone part of these decisions until mid-January.

So we are going to start porting in several phases, working with a particular customer (Competitiveness) who already has a customized version of the 3.4 Intranet running:

1. We are going to unify the customized Competitiveness 3.4 Intranet with the Project/Open 3.4 Intranet. The goal of this task is to creates a unified "Intranet" module with an elegant GUI and the joint functionality (Samba-Filestorage, presales & CRM, timesheet, costs, invoices and payments, ...)

2. Update of the unified Competitiveness-Project/Open Intranet to OpenACS 5.0. with "minimum changes". Actually, the idea is to use "adaptors" (=> adaptor pattern) such as SQL-views or TCL procedures to minimize changes in the Intranet code.

3. "Cleanup" the unified Intranet to use OpenACS 5.0 features such as templates, i18n etc.

4. Integrate the resulting code with other Competitiveness specific functionality outside the Intranet module

I expect to finish the work on steps 1 and 2 in February using our "internal" team, because it involves touching customers code and data, protected by an NDA. However, we plan to publish the code at the end of phase 2, so that phase 3 could include participation from the community.

Phase 3 would also be the phase to decide for interfaces/integration with other packages, in particular dotWrk.

Collaboration

So we would like to invite everybody to participate in the project. Please send me an email (mailto:fraber@project-open.com) if you are interested and/or if you want to stay informed.

Bests,
Frank

Collapse
Posted by Jade Rubick on
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.
Collapse
Posted by Don Baccus on
If you don't use the object system then, to be blunt, you won't be porting your work to OpenACS 5.0.  Just for starters you won't be able to use the permissioning system, which is a fundamental component of the system.

Rather you'll have an independent piece of work that borrows some OpenACS 5.0 components.

Which will make it of much less direct interest to the community.  I'm doubtful we'd even include it as a contrib piece.  Of course the code you release may well form the basis for the building of a true OpenACS 5.0 application.

I'd urge you to engage the community in the design process if your goal is indeed to build an OpenACS 5.0 application.

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. (https://openacs.org/projects/dotwrk/people). There were members in the community encouraging you in this direction back in September right?(https://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'?

Collapse
Posted by Don Baccus on
The 404 is "page not found", so we can't read the restrictions.

However ... the only restriction on the redistribution of GPL'd software that's possible is that it be GPL'd as well.  That may be all that's implied by the comment.

Frank, can you clear that up?  ACS 3x was GPL'd, as is OpenACS  5.0.  We allow packages built on top of OpenACS 5.0 that doesn't contain our code to be licensed however one wants (much like a program running on top of Linux) but of course if your code contains any of our or ArsDigita's GPL'd code then it needs to be GPL'd as well.

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?

Collapse
Posted by Dirk Gomez on
I don't really understand your question. Anyway: you use GPLed code somewhere => In case of distributing the code you need to give it away under the GPL.
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:
<blockquote> > 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?
</blockquote>

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

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:

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

I have already mentioned here on OpenACS (last message at https://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:
<blockquote> > 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.
</blockquote>

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

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.

<blockquote> > 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.
</blockquote>

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

Dirk wrote:
<blockquote> I don't really understand your question. Anyway:
you use GPLed code somewhere => In case of
distributing the code you need to give it away
under the GPL
</blockquote>

Hi,

all the modules that contain a single line of GPLed code need to be GPLed, no doubts about that.

However, if somebody writes a new module from scratch, only using calls to the TCL libraries ("Clean Room Development"), then this module is not bound to the GPL and can be released under any other license and/or contract terms. Atleast this is what my lawyers say. (I would be really happy to received qualified feedback from you, because it would save me a lot of trouble in the future...)

And this is where the new Partner License would be employed to make sure that a fair share from "Implanters" revenues would be redistributed to the "Coders".

I know that's going to be a long discussions, and I'm really looking forward to it. Actually, the previous discussions I had here on OpenACS have really helped to get to this point.

I really believe that such a Partner License is more suitable for the "beforementioned boring ERP stuff" than the GPL. We'll see. The market and the communities are going to decide.

I think it's a natural reaction to reject new (unpleasently commercial) thoughts, but don't crucify me before the legal text is out, ok?

Frank

Collapse
Posted by Don Baccus on
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.

Collapse
Posted by Don Baccus on
As far as commercial thoughts being unpleasant ... a large percentage of the people here are making their living out of the project.  We're not at all allergic to commercial thought.

On the other hand there's a great deal of loyalty to the open source model and the GPL here.  Not all the work we do is GPL'd of course ... but thus far community members writing code for distribution have GPL'd that code.  Strictly custom code tends to not get distributed, while distributed code is released under the GPL.  Thus far this model has worked well enough for the community.

I'm not suggesting that another model will be rejected out of hand, but will say I think you may find convincing the community of the need might be an uphill battle.

As far as there being "thought police" ... the project does have coding and design standards for work we bless.  We have a formal process for making community decisions as to how we expect code to be written if it is to be included as part of our project - the TIP process.

This is not some sort of radical concept - most engineering projects and software companies have such standards, and the development and use of such standards is considered a mark of professionalism by many.

So, no, you don't have to conform to our recommended practices - we have no way of forcing you to do so.

But if you don't, your work won't be accepted as part of the community software.

I don't mean that as a threat, just a statement of reality.  Indeed with some of the stuff you're talking about it may not matter - since we only accept GPL'd code into the project and you're talking about not GPL'ing at least part of your work, for that code it's moot.

But this cuts both ways - if you don't integrate your code with the toolkit, then you'll find it very difficult to integrate new work we do with your stuff.  Which again may not matter to you.

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

Hi Frank,

If you have a choice about it, I would recommend OpenACS 5.0 as your target platform instead of 4.6. It's a huge leap forward, and better to target that than 4.6 and upgrade later IMO.

I think as you hang around here you'll find that all of us are busy satisfying our customers as well, and our focus is similar. Most of our development is client driven.

There are some issues to hash out here, but don't disappear until February! If you're planning on porting to OpenACS, you'll probably want some advice along the way while you're getting up to speed on OpenACS.

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. And GPL is the default here, so if you're wanting to release it under something else, that's fine, but it'll be up to you to convince developers to jump aboard. If it's in our self-interest, we will, and we'll be happy that you're contributing your code for all of our self-interests (including your own!). It's a win-win situation in my opinion.

Glad to have you here, and I'm looking forward to seeing P/O on OpenACS if you choose that route.

Collapse
Posted by Don Baccus on
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 think we're starting to touch the intersting point: In the whole P/O there is (currently):
- No object that you need to comment on and
- No object that needs uploads
Categorization may be an interesting feature however.

In contrast, permissions for many objects are extremely complicated. Here is the example of a "Customer":

Rules to access a CustomerViewPage: Allowed are:
- Administrators
- General Management
- The customer himself, but no other customer
- Employees can only see the name of the customer, but nothing more, except they are assigned to the customer as a key account manager
- The project managers of projects for this customer while the project is "open".
- No freelancers at all
- Accountants have access the financial information, but have no access to CRM and presales information

When accessing the _Project_ListPage:
- Admins and GMs see everything
- Freelancers can see the project, but don't see who is the customer

Whe accessing the Incident Tracker:
- Messages posted by a customer are only visible for the project manager
- Messages posted by freelancers are visible for employees and the PM, but not to customers.

... and so on. Don't tell me that's fashist rules, that's from a very cometitive environment where employees walk out of a company and take their customers with them... So how would you implement that?

Actually, I used to have permission controlling code on every page, but recently I've started to write "access_matrix" routines that return something like "can_see_customer_p" and "can_edit_customer_p".

I hope that helps to understand the situation. I would definitely be greatful for silver bullet type of solutions...

Frank

<blockquote> 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.
</blockquote>

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

Collapse
Posted by Don Baccus on
One of the very nice things about the OpenACS 4.x/5.x permissioning system (designed by aD, made scalable by us) is that the question being asked is "can party P do action A on object O".

A "party" can be a user or a set of users (a group or relational segment, with the latter being much like a subgroup  of users in a particular role) ... or anything else derived from the "party" type.  For our purposes, though, the three I mention (user, group member, group member with particular role) are the useful ones ...

Now I'm just talking off the top of my head but in order to attack this part of the problem:

"Rules to access a CustomerViewPage: Allowed are:
- Administrators
- General Management
- The customer himself, but no other customer
- Employees can only see the name of the customer, but nothing more, except they are assigned to the customer as a key account manager
- The project managers of projects for this customer while the project is "open".
- No freelancers at all
- Accountants have access the financial information, but have no access to CRM and presales information"

I would probably define subgroup/role (relational segment) parties of the intranet members for "administrators", "general managers" etc.  The employee subgroups would have "read" privileges on customer objects.  The easiest way to do this would probably be to define a "employees" group and then define the subgroup/role relational segments within the "employees" group.  Then everytime a new customer object is created you'd just grant "read" for the "employees" group (party) on that customer object.

Your freelancers and customers would be handled individually  for permissions purposes - freelancers would have no "read" privilege, while a customer would have the "read" privilege on their own object.  You might make a group for each customer (assuming a "customer" is actually a set of "customer employees") and assign the "read" privilege to the customer employees group rather than each one individually.

Or you might have a "customers" group with a separate "customer FOO" subgroup for employees of each customer if you need to treat the union of all customer employees as a single set for some reason (say, to send them each a Christmas card :)

I'd define some custom privileges (easy to do) for things like "can_read_financial_data" or "can_read_customer_details" etc ... these could be assigned, then, to the subgroups of employees or individual employees (i.e. one assigned to a customer project).

This is just a sketch but I think it illustrates something interesting and nice about the permissions model/design:

1. In the page itself, I only need to check "can the current user read the customer object this page wants to display?" or "can the current user read the customer's financial data"? etc. This makes page implementation very, very easy. The individual pages do not need to have *any* knowledge about the various roles and groups ... making it easy, among other things, to customize the system for organizations with novel employee structures you've not thought of ahead of time.

2. In your overall design, it allows you to concentrate on how to partition your intranet members into meaningful sets of people, and then on what actions you'll allow people in the various sets to take.  In a system like you're talking about, I think the *hard* part is defining roles and relationships to be held by various users of the intranet so  it seems appropriate that the design effort should center around the groups and [sub]group/role definitions.  This not only drives the permission system but is how you'll generate lists like "show me all employees of customer Foo" and "show me all of my employees assigned to Project FUBAR'd" etc etc.

4. The "customer object" would probably just be your package - mount a new instance of your package for each customer.  The request processor ensures that a vistor has the "read" priv on a package before letting them visit it - much less prone to programmer error than having each page do the read check itself (it's easy to forget to do so).  Then the page programmer only has to worry about checking for the special stuff like "can_read_financial_data", which they presumably are less likely to forget since they'll remember that it's sensitive information.  This would make it easy to provide each customer intranet subsite a different look and feel, say to include their logo on the page.  Or you might center the design around the subsite and portal packages...

Anyway ... the above is how I'd attack the design problem: keep the permissions checks simple.  Define a "employee" group for the main subsite with roles matching your criteria for partitioning them.  Each customer package instance/subsite+portal instance or whatever could define groups like "customer employees", "assigned vendor employees" etc and you'd then add people as appropriate and those groups would have the proper permissions assigned them to give members the rights they need.

This would mean that by default registered users could do nothing, all vendor employees would have the basic "read" right (not able to view sensitive data), and ANY OTHER permission would require explicit action on the part of the site administer - add them to the group of vendor employees assigned to a customer, for instance.  This is the kind of safety you need for such an application.

Anyway ... I hope this entirely top-of-the-head sketch helps a bit.  Any other community members have comments to add?

Collapse
Posted by Don Baccus on
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.

Collapse
Posted by Don Baccus on
I meant my little threefold hierarchy holds regarding the usefulness of such code to the community (I was a little terse in my statement above)
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!

Collapse
Posted by Dirk Gomez on
Another question: What are the obligations of the party receiving money for "PLed" software? Is it strictly no-warranty software? (Is that possible?)