I have comments in-line.
Also, let us speak of chicken and egg.
I observe that the Board and the Offices of ASF do not wish to deal with hypothetical
cases. Exceptions must be specific and actionable. Also, exceptions do not create
precedents. If one project sees something they want as exception for them, they must
create specific exception of their own. (AOO has exception for bundling some writing
tools in binaries only, not in source code, because licenses are incompatible. It is
very specific and not a precedent for other projects. When details of another exception
are worked out, it is often revealed that the cases are not the same. The ASF avoids
common risk of others seeing more "precedent" for their case than there
actually is.)
It seems to me that if there is a request for some sort of external
relationship(s), the external parties must already exist and be prepared to
provide detailed agreement on how it will partner with AOO project in a way
that preserves the principles and purpose of the ASF in how AOO participates in
the arrangement. This is not hard.
I do not think making exceptions about hypothetical arrangements and then
seeking external parties will work.
That is why it may be better for external party to be created first, operating
as good downstream citizen, before requiring anything of the AOO PMC and ASF
Board. Ideally, no significant attention will be required. The only thing
external entity cannot do, and PMC would have to intervene, is make use of
Apache trademarks in other than allowed ways. Since it is not proposed that
the external entity release any software product, this should be agreeable.
Also, the external party should not promise others that requested features will
be incorporated in AOO in the manner they desire. They will never have the
authority to control AOO project actions, even though by mutual work, there may
often be good alignment.
Only my thoughts, not thoughts from any PMC or Board discussion.
- Dennis
-----Original Message-----
From: Peter Kovacs [mailto:legi...@gmail.com]
Sent: Wednesday, January 18, 2017 23:08
To: dev@openoffice.apache.org; orc...@apache.org
Subject: Re: Community building: give our User a chance to contribute!
Star Citizen proofed that a community can follow developers intend and
raise the money needed.
Even if we can not use the business model, we can learn something from
their communication model they have developed.
Also what becomes clear to me is that we can not operate with a single
entity. If I consider that we need to position us global right from the
start, this is not so bad.
Maybe it would be better if we lay out a white paper on some model. Then
we talk about this. We can then check for concerns. Note them down and
find a solution for it.
@Raphael do you like to write your idea in a document? I think we have a
similar idea. Maybe I can put my idea as variation suggestion next to it
afterwards.
[orcmid]
Raphael raised his questions on d...@community.apache.org. The responses are
informative.
Then we can see if we can refine the document.
I think we need to focus on reaching a goal somehow, this discussion
dissolves somewhat because we focus to much on the ASF and bugs. Then on
goals concepts and stuff.
When we have a clear view, we can reach out to the ASF and hear their
concerns, update the concept based on their feedback. I assume this way
we will find a solution that works for everybody.
[orcmid]
If you do not understand the concerns of the ASF and that AOO is ASF project,
you may waste your time. It works best to operate in models of external
support that have worked well.
Please consider this document now in draft, meant to be aligned with detailed
documents it refers to:
<http://www.apache.org/dev/project-requirements>.
I recommend that all developers interested in this discussion also subscribe to
d...@communit.apache.org where good discussion can be held.
Also, it is the PMC that must communicate with ASF Board. The PMC is
responsible for the care of the project in terms of satisfying and preserving
ASF spirit for projects.
Discussion and creation on dev@ is fine. But PMC must as a body agree to some
proposal if it is so exceptional that Board approval is required.
In Germany it is said that to lay out a business model takes 8 -16
month. So IMHO we have time, does not need to be perfect.
All the best
Peter
Dennis E. Hamilton <orc...@apache.org <mailto:orc...@apache.org> >
schrieb am Mi., 18. Jan. 2017, 17:36:
> -----Original Message-----
> From: Raphael Bircher [mailto:rbircherapa...@gmail.com
<mailto:rbircherapa...@gmail.com> ]
> Sent: Tuesday, January 17, 2017 21:36
> To: dev@openoffice.apache.org <mailto:dev@openoffice.apache.org>
> Subject: Re: Community building: give our User a chance to
contribute!
>
> Am .01.2017, 05:31 Uhr, schrieb Dennis E. Hamilton
<orc...@apache.org <mailto:orc...@apache.org> >:
>
[ ... ]
>
> I personaly don't believe in that model for Apache OpenOffice.
There is
> no
> need for a customized version of Apache OpenOffice. And the
people who
> fork, do it normaly to have there own product. They don't want to
> upstream. But Yes, it is one model, who exist within ASF. Not
that I'm
> completely against this way... If someone finds a way, to
generate money
> to contribute back, it would be nice. But I don't think it's the
right
> way.
>
> I'm more with the payed feature model
[orcmid]
That was also discussed - creation of an external organization that
would arrange paid features and contribute to Apache OpenOffice. That
must be external to ASF. And either (1) there are AOO committers who
participate in both or (2) AOO committer and PMC must accept the changes
and the AOO project incorporates features in AOO releases.
So the feature organization would need to be able to do everything
but make distributions to provide tested, quality features. Or have AOO
committers in the feature organization to work on feature branches of
AOO SVN.
In all cases, there must be *no* payment process or fund-raising
process that involves the ASF. That is key requirement #1. I see that
Bertrand Delacretaz has provided a good answer about this on
d...@community.apache.org <mailto:d...@community.apache.org> .
AND
The greatest barrier of all is key requirement #2: finding already-
capable OpenOffice developers who have the capacity and willingness to
do such work. The fees that an OpenOffice features organization would
pay must be enough. Someone with the required at-hand skills can already
earn $100,000 per year and more (in US), with all benefits available
where they work. I do not know comparable salaries in EU. I believe it
is still expensive in terms of how much money feature-organization must
raise. Also, providing contract agreements for performance of feature
delivery is also complicated.
There is a great misunderstanding in the user community of how much
feature development costs using developers with professional, at-hand
skills.
- Dennis
>
> >
> > We can dig up that conversation if you like.
> I would be interested, where the discussion ends ;-)
>
> Regards Raphael
> --
> Mein Blog: https://raphaelbircher.blogspot.ch
>
> -----------------------------------------------------------------
----
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
<mailto:dev-unsubscr...@openoffice.apache.org>
> For additional commands, e-mail: dev-h...@openoffice.apache.org
<mailto:dev-h...@openoffice.apache.org>
-------------------------------------------------------------------
--
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
<mailto:dev-unsubscr...@openoffice.apache.org>
For additional commands, e-mail: dev-h...@openoffice.apache.org
<mailto:dev-h...@openoffice.apache.org>
--
Disclaimer: Diese Nachricht stammt aus einem Google Account. Ihre
Antwort wird in der Google Cloud Gespeichert und durch Google
Algorythmen zwecks werbeanaöysen gescannt. Es ist derzeit nicht
auszuschließen das ihre Nachricht auch durch einen NSA Mitarbeiter
geprüft wird. Durch kommunikation mit diesen Account stimmen Sie zu das
ihre Mail, ihre Kontaktdaten und die Termine die Sie mit mir vereinbaren
online zu Google konditionen in der Googlecloud gespeichert wird.
Sollten sie dies nicht wünschen kontaktieren sie mich bitte Umgehend um
z.B. alternativen zu verhandeln.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
