incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lawrence Rosen" <>
Subject RE: Call for comments: Webpage for Listing OpenOffice Consultants
Date Wed, 26 Sep 2012 22:40:46 GMT
The policy implications may be broader than you've summarized below. 

I read the draft disclaimer and I like it. But I'm not convinced that a
disclaimer is sufficient when Apache identifies people or companies who can
help with AOO unless there is also a statement of our right, in our sole
discretion, to remove any listing that does not conform to AOO community
standards (whatever those are?). 

Is there a standard by which you can remove someone from the list?

Is this an opportunity for a job listing board rather than for Apache itself
to manage?


Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (
3001 King Ranch Rd., Ukiah, CA 95482
Office: 707-485-1242

-----Original Message-----
From: Donald Whytock [] 
Sent: Wednesday, September 26, 2012 2:04 PM
Subject: Re: Call for comments: Webpage for Listing OpenOffice Consultants

Still suggesting some sort of expiration mechanism (perhaps a timestamp in
the entry, with a scheduled job to prune), so this doesn't become a barnacle


On Wed, Sep 26, 2012 at 4:58 PM, Rob Weir <> wrote:
> Another one of those "larger ecosystem" things I'll be pushing on.
> If you recall the legacy project had a webpage that 
> listed various consultants who provided services for OpenOffice.  We 
> took it down because it was very out of date and we didn't have time 
> (at that time) to figure out the policy implications and update the 
> content.  Well guess what?  I have time now.
> ====> A draft of a proposed approach is on the wiki here:
> penOffice+Consultants+Directory
> <====
> I'm working on the XSLT script now.  Looking good so far.
> If you read the wiki you'll see the policy implications are minimal:
> We'll be fair and accept all relevant submitted listings, provided
> they don't abuse ASF trademarks,   I don't think we need more than
> that, but adding more is certainly easy enough.
> Note also the disclaimer on the wiki, which I'll repeat here.  As a 
> non-profit we need to be careful about how we intersect with 
> commercial activities.  I think this is sufficient, but changes are 
> easy to make.
> "Disclaimer:   Although most individual users are able to download and
> use Apache OpenOffice without any help, or with the assistance of 
> volunteers on our Forums and mailing lists, some users, especially 
> corporate users, may have more complex requirements that require 
> commercial services in order to optimize their deployments.  The 
> following individuals and firms offer services that may be of
> interest.   The information provided here was provided by the entities
> named here, and is not verified or endorsed by the Apache OpenOffice 
> project.  We offer these listings as a service to the ecosystem."
> If there are no objections to this general approach, I'll proceed as
> 1) Write up a definition of the requirements for the input XML file.
> XML Schema and plain English definition, for use by consultants 
> submitting us listings
> 2) Draft a webpage giving info on how consultants can submit a 
> listing.  Would list technical and policy requirements.
> 3) Complete XSLT scripts and get them checked in.
> 4) Get this all onto the website into a test directory for review.
> Perhaps we seed it with initial data from project members who provide 
> services, so we have something at launch time other than fake data.
> 5) Once approved, we go live.  The legacy project buried this under 
> the "support" page, but I think we should offer a more prominent 
> location, perhaps a link on the home page.
> 6) Promote via blog, social networking, etc.
> 7) PMC reviews incoming submissions, etc.  Routine maintenance.
> Note: this same approach (Submission instructions page + XML/XSLT to 
> generate user-facing XHTML page) would also work very nicely for a CD 
> Distributor listing page.  It should be possible to copy this 
> approach, including the XSLT script, even including this note, and 
> with some modifications reuse it for that purpose.
> Regards,
> -Rob

View raw message