Re: Donating to Apache Flex

[Christofer Dutz]

Hi,

I would not like to see non-committers with root access to our infrastructure 
(if we had any). 
These people would have access to credentials for technical users that again 
have privileged access to other ASF services.
If you asked me, I would opt for people having to be at least PMC to get that 
level of access.

And yes … everyone can contribute to Infra via puppet scripts and pull 
requests. 

Chris


Am 13.02.17, 23:13 schrieb "Justin Mclean" :

Hi,

> I forgot to mention that, besides the community tax, there might be
> another bill from the ASF for services we use such as email, release
> distribution storage, and assistance from the financial folks for handling
> the accounting of the money.  The ASF receives bills for the same already,
> we would just be a micro-version of the same.

I’m not sure that would scale well (across the entire ASF) without the ASF 
adding other paid stuff to manage this.

> 1) If we self-host, would we require someone be a committer first via the
> usual ways, or would contributing to keeping the VM safe and running be a
> valid way to earn committer rights?

All contributions are considered equal so I don't see why not.

>  That would require trusting someone to work on the VM before being 
trusted enough to be a committer.


Believe infra do this via PR to their puppet scripts? ie all the config for 
the server is in the open but you don't need access to be able to suggest 
changes.

However I don't see how we could give non committer or perhaps even non PMC 
members full access to VMs that run our critical infrastructure, given the risk 
and possibly sensitive into on them. 

Thanks,
Justin

Re: Login Security (was Re: Donating to Apache Flex)

[Christofer Dutz]

Hi Alex,

Well I think we shouldn’t go down the path of yet another login. I really like 
the ASF LDAP system. This must be managed and taken care of.

Chris


Am 13.02.17, 17:25 schrieb "Alex Harui" :

Another technical thread

On 2/13/17, 12:28 AM, "Christofer Dutz"  wrote:
>
>There is a HUGE difference between setting up a Jenkins on the Intranet
>and running a Jenkins on the Internet. From the end-user’s perspective,
>this isn’t noticeable, but when administrating these system, it is huge.
>I had been working on a solution for assisting companies to detect and
>fix security vulnerabilities for 4-5 years and have learnt quite a lot on
>this. Just some things that would pop my mind:
>- You must integrate the authentication into the ASF LDAP (Setting up a
>separate one is out of the question)

Why is this a requirement?  ASF Wiki and ASF Jenkins have separate account
systems?  Don't many folks have logins and multiple users for VMs running
in Azure and AWS?

Thanks,
-Alex

Re: Credentials and Maven (Was Re: Donating to Apache Flex)

[Christofer Dutz]

Hi Alex,

Maven has a hierarchy of settings. Above the pom.xml is the settings.xml in the 
user’s profile and above that the settings.xml in maven.
Usually you don’t provide credentials in the pom, but define id’s.  In the 
settings.xml you usually provide the credentials for the ids to inject them to 
the build (I am handling this in my training video quite extensively).

Infra have a settings.xml in which they provide the credentials for a technical 
user on each agent. But anyone with access to the VM would be able to read and 
copy these credentials.

Hope that explains this aspect a little more.

Chris



Am 13.02.17, 17:23 schrieb "Alex Harui" :

Forking a few technical threads...

On 2/13/17, 12:28 AM, "Christofer Dutz"  wrote:

>
>Right now, I don’t know how we could make sure we are able to commit to
>GIT or upload to maven without having the credentials on the VM we
>control … 

I guess I don't understand enough about Maven and credentials, so can we
use this thread to get more details?

Is it true that on builds.a.o, your credentials are stored there or the
ASF has a special credential stored there for use when publishing to Maven?

Must credentials be stored on a server or can they be prompted?

Thanks,
-Alex

Re: Donating to Apache Flex

[Justin Mclean]

Hi,

> I forgot to mention that, besides the community tax, there might be
> another bill from the ASF for services we use such as email, release
> distribution storage, and assistance from the financial folks for handling
> the accounting of the money.  The ASF receives bills for the same already,
> we would just be a micro-version of the same.

I’m not sure that would scale well (across the entire ASF) without the ASF 
adding other paid stuff to manage this.

> 1) If we self-host, would we require someone be a committer first via the
> usual ways, or would contributing to keeping the VM safe and running be a
> valid way to earn committer rights?

All contributions are considered equal so I don't see why not.

>  That would require trusting someone to work on the VM before being trusted 
> enough to be a committer.


Believe infra do this via PR to their puppet scripts? ie all the config for the 
server is in the open but you don't need access to be able to suggest changes.

However I don't see how we could give non committer or perhaps even non PMC 
members full access to VMs that run our critical infrastructure, given the risk 
and possibly sensitive into on them. 

Thanks,
Justin

Login Security (was Re: Donating to Apache Flex)

[Alex Harui]

Another technical thread

On 2/13/17, 12:28 AM, "Christofer Dutz"  wrote:
>
>There is a HUGE difference between setting up a Jenkins on the Intranet
>and running a Jenkins on the Internet. From the end-user’s perspective,
>this isn’t noticeable, but when administrating these system, it is huge.
>I had been working on a solution for assisting companies to detect and
>fix security vulnerabilities for 4-5 years and have learnt quite a lot on
>this. Just some things that would pop my mind:
>- You must integrate the authentication into the ASF LDAP (Setting up a
>separate one is out of the question)

Why is this a requirement?  ASF Wiki and ASF Jenkins have separate account
systems?  Don't many folks have logins and multiple users for VMs running
in Azure and AWS?

Thanks,
-Alex

Credentials and Maven (Was Re: Donating to Apache Flex)

[Alex Harui]

Forking a few technical threads...

On 2/13/17, 12:28 AM, "Christofer Dutz"  wrote:

>
>Right now, I don’t know how we could make sure we are able to commit to
>GIT or upload to maven without having the credentials on the VM we
>control … 

I guess I don't understand enough about Maven and credentials, so can we
use this thread to get more details?

Is it true that on builds.a.o, your credentials are stored there or the
ASF has a special credential stored there for use when publishing to Maven?

Must credentials be stored on a server or can they be prompted?

Thanks,
-Alex

Re: Donating to Apache Flex

[Alex Harui]

On 2/13/17, 12:28 AM, "Christofer Dutz"  wrote:

>Well a lot of what you write sounds sensible … especially with an assumed
>Community-Tax (or whatever you call it in the end).
>
>Eventually it would be an option to have a global “donation service” form
>the ASF together with the option to - let’s say add a “Donate to Flex”
>button on the projects website in which donations are done to the ASF
>with a marker of it being directed to the Flex Project. I wouldn’t want
>to have to manage a dedicated bank account and handle all the beurocratic
>stuff.

I forgot to mention that, besides the community tax, there might be
another bill from the ASF for services we use such as email, release
distribution storage, and assistance from the financial folks for handling
the accounting of the money.  The ASF receives bills for the same already,
we would just be a micro-version of the same.

>
>There is a HUGE difference between setting up a Jenkins on the Intranet
>and running a Jenkins on the Internet. From the end-user’s perspective,
>this isn’t noticeable, but when administrating these system, it is huge.
>I had been working on a solution for assisting companies to detect and
>fix security vulnerabilities for 4-5 years and have learnt quite a lot on
>this. Just some things that would pop my mind:
>- You must integrate the authentication into the ASF LDAP (Setting up a
>separate one is out of the question)
>- You must install the good patches as soon as possible and skip the bad
>ones (Usually you have a test-environment to test updates)
>- The credentials for accessing the ASF LDAP must be available on the
>system (Don’t think Infra would like that)
>- To publish artifacts to the ASF Maven repo, credentials of someone must
>be provided (alternatively Infra could create technical users, but this
>will not happen and I think that’s good that they won’t do that)
>- To commit and push to the GIT repos the same applies as for the Maven
>repos
>- Unfortunately, there is no “setup.exe” to install Security. It’s why a
>good system Admin is worth its weight in gold (At least this was one
>thing I learnt from my Professor). Every “shortcut” opens dozens of
>possible security holes, you have to think about all of them.
>- I bet if we were to switch to the “self hosted mode”, I would start
>voting -1 setups and decisions to block unsecure shortcuts, we would have
>a whole new dimension on discussions here … not looking forward to that.
>- If we run our own JIRA/Wiki/Website … we need backups and people
>skilled enough to restore them after a catastrophic failure.

There are some interesting questions in this regard:

1) If we self-host, would we require someone be a committer first via the
usual ways, or would contributing to keeping the VM safe and running be a
valid way to earn committer rights?  That would require trusting someone
to work on the VM before being trusted enough to be a committer.
2) I think any "decentralized" solution would result in Infra wanting to
store the backups and maybe dictate how often they take them.

>
>I guess most things that people are complaining to Infra about are
>probably sort of the same type of problems we were having in the past.
>The thing is that we wanted them to provide a build that fits the build
>we created. What I did, was to simplify the build and create a common
>ground with Infra towards what’s possible and what’s not and to adjust
>the build accordingly. If all projects would use this type of dialog I
>guess, we wouldn’t have this type of problems.

Well, having a "what's not possible" list is bad for the project if we
need to do some of those things on that list.  This is why a decentralized
solution is better for the project.  But there was a recent thread where a
Mac CI Server was taken down because there weren't customers for it for a
period of time but someone did need it.  Again, I don't like these
decisions taken out of our hands.  If we need to test on some stinky old
version of Java, we should be able to acquire the resources and do it and
not have Infra say they are too busy or don't have the resources.

-Alex

Re: Donating to Apache Flex

[Christofer Dutz]

Well a lot of what you write sounds sensible … especially with an assumed 
Community-Tax (or whatever you call it in the end).

Eventually it would be an option to have a global “donation service” form the 
ASF together with the option to - let’s say add a “Donate to Flex” button on 
the projects website in which donations are done to the ASF with a marker of it 
being directed to the Flex Project. I wouldn’t want to have to manage a 
dedicated bank account and handle all the beurocratic stuff. 

I guess there are enough new-banking solutions where we could split up a 
classic bank account into virtual sub-accounts and each PMC has limited access 
to pay using that (Just an assumption that something like this exists … if not 
we should create a new TLP for that ;-) ) 

One thing I never want to see or discuss is: Should X be paid to do Y because I 
know this will cause a lot of problems. Especially if Z could also do the same 
job and might be also willing to be paid for doing it. Who decides if X or Z is 
chosen? It could also lead into a direction that people could stop doing things 
for free. Sort of like “If I wait for a problem to become more and more a pain, 
I could get paid to fix it”.

There is a HUGE difference between setting up a Jenkins on the Intranet and 
running a Jenkins on the Internet. From the end-user’s perspective, this isn’t 
noticeable, but when administrating these system, it is huge. I had been 
working on a solution for assisting companies to detect and fix security 
vulnerabilities for 4-5 years and have learnt quite a lot on this. Just some 
things that would pop my mind:
- You must integrate the authentication into the ASF LDAP (Setting up a 
separate one is out of the question)
- You must install the good patches as soon as possible and skip the bad ones 
(Usually you have a test-environment to test updates)
- The credentials for accessing the ASF LDAP must be available on the system 
(Don’t think Infra would like that)
- To publish artifacts to the ASF Maven repo, credentials of someone must be 
provided (alternatively Infra could create technical users, but this will not 
happen and I think that’s good that they won’t do that)
- To commit and push to the GIT repos the same applies as for the Maven repos
- Unfortunately, there is no “setup.exe” to install Security. It’s why a good 
system Admin is worth its weight in gold (At least this was one thing I learnt 
from my Professor). Every “shortcut” opens dozens of possible security holes, 
you have to think about all of them. 
- I bet if we were to switch to the “self hosted mode”, I would start voting -1 
setups and decisions to block unsecure shortcuts, we would have a whole new 
dimension on discussions here … not looking forward to that.
- If we run our own JIRA/Wiki/Website … we need backups and people skilled 
enough to restore them after a catastrophic failure.

I guess most things that people are complaining to Infra about are probably 
sort of the same type of problems we were having in the past. The thing is that 
we wanted them to provide a build that fits the build we created. What I did, 
was to simplify the build and create a common ground with Infra towards what’s 
possible and what’s not and to adjust the build accordingly. If all projects 
would use this type of dialog I guess, we wouldn’t have this type of problems.

What I would be willing to support is something down this path:
- Have the option to do (micro-) donations directed at the ASF that go into an 
ASF managed account that we can distribute funds from
- A ASF Community-Tax has to apply that will make sure that the other ASF 
projects don’t dry out financially
- We continue to use the ASF systems (Jenkins etc.) 
- We use our funds to pay for one or multiple Jenkins agents that only the Flex 
project can use
- Funds should never be used to pay for development/documentation/testing work 
done on the project

Right now, I don’t know how we could make sure we are able to commit to GIT or 
upload to maven without having the credentials on the VM we control … 

Chris


Am 13.02.17, 07:05 schrieb "Alex Harui" :



On 2/12/17, 4:25 PM, "Justin Mclean"  wrote:

>Hi,
>
>> Don't worry about finances, that's an ASF corporate question - to start
>> with, look at the directed funding proposal from the past President's
>> report in a board report.
>
>Alex’s suggestion as I understand it  doesn’t seem to fit with the above
>experiment. Alex (please correct me if I’m mistaken here) but you’re
>looking for lots of small donations from many (possibly unknown) people
>rather than a single largish donor up front right?

Yes.  I explicitly asked on board@ if I should continue to pursue this
idea even though it doesn't close to the 50K threshold mentioned in the
minutes and they said to go ahead.  My takeaway is that the Prez report
was an opinion and 

Re: Donating to Apache Flex

[Alex Harui]

On 2/12/17, 4:25 PM, "Justin Mclean"  wrote:

>Hi,
>
>> Don't worry about finances, that's an ASF corporate question - to start
>> with, look at the directed funding proposal from the past President's
>> report in a board report.
>
>Alex’s suggestion as I understand it  doesn’t seem to fit with the above
>experiment. Alex (please correct me if I’m mistaken here) but you’re
>looking for lots of small donations from many (possibly unknown) people
>rather than a single largish donor up front right?

Yes.  I explicitly asked on board@ if I should continue to pursue this
idea even though it doesn't close to the 50K threshold mentioned in the
minutes and they said to go ahead.  My takeaway is that the Prez report
was an opinion and not a policy.  We need to solidify a proposal.  They
might still say no, but right now I am an additional person investigating
directed funding options so they don't have to spend time on it.  Maybe we
will come up with a good new idea.  Or not.

Thoughts on other responses:

Fundamentally, regardless of Apache "direction", it occurs to me that it
is just plain wrong for Flex to be a net consumer of resources at Apache.
Really, all projects should be striving to be providers, by bringing in
enough donations to not only pay for ourselves, but also have some extra
for the other projects that need help.  So I don't know how many of you
contribute money to the ASF and are willing to go public about it, but
before I go asking for a new VM from Apache I'd want to know we are
putting enough money in to effectively pay for it.  And that's the problem
for me:  if I write a check to the ASF, I can't currently earmark it for a
VM for Flex.

To me, the "Donate to the ASF" goal is different enough from the "Donate
to Flex" goal that it seems worth trying the latter.  The "Donate to the
ASF" goal is about altruism for open source software in general.  I'm
willing to give a certain percentage of my salary to good causes.  But I'm
willing to give more to help my community, because I hope to get payback
in other ways.

So sure, there may not appear to be a need to do something like this now
since things are working.  But just like you re-do the roof on your house
before it starts to leak, I want to find out what it would take to track
if we are paying for ourselves.  Would it require an actual separate bank
account?  Don't know.  Would we get a "cost center" like in my $dayjob?
Don't know.  We'll find out if we get that far.

I guess I didn't understand what Justin meant by "Professional Services".
The ASF doesn't want to pay for folks to write code, and I think that
include documentation as well.  But could the collection of lots of little
donations require that we pay for professional accountants?  It could.
The ASF already pays for professional financial management.

If some people want to collect money to pay folks to write documentation,
I think that needs to be done in a separate effort.

CI on builds.a.o is working nicely.  But what changes would be required to
move it to apacheflexbuilds?  Isn't there something special about
builds.a.o and its capability to publish Maven artifacts?

Other folks on past directed donation threads on other ASF lists have
expressed concerns about rich projects and poor projects.  IMO, the ASF
could implement a graduated tax.  Right now they are just saying 15%, but
they could raise it in general or tax higher incomes more.  In the US,
income is taxed on a graduated basis topping out at 35% or so.  I think it
is much higher outside the US isn't it?  15% may be too low.  It just has
be the right number to fund what needs to be funded without discouraging
donations.  I'd bet the higher income projects are also big consumers of
resources so there'd be enough money from the taxes to pay for the "poor"
projects.

We would have to have language that says that your donation is not
guaranteed to be used for what you want it to be.  I think many
fundraising manage to get this wording right enough to be successful.
We'd probably have to have language that if money doesn't get used or the
project goes to that attic someday that all funds will go to the ASF
general fund.

We would use the same decision making process to decide what to spend
money on as we do for deciding what code donations to take and other
project-level decisions.

I'm hoping that we don't have to do the same things that Infra currently
does.  I believe my Azure account pays for a lot of what Infra does.
Azure folks keep the servers up and running.  "All" we have to do is
install and maintain apps like Jenkins which several of us have already
figured out how to do, and maybe some day JIRA, maybe a web server, who
knows.  I already learned how to set up JIRA when migrating the Flex bugs
from Adobe.  These things feel more like application usage than "Infra"
stuff.

We will have to have security on everything whether it is server-side or
client-side.  We will be writing a ton of 

Re: Donating to Apache Flex

[Justin Mclean]

Hi,

> Don't worry about finances, that's an ASF corporate question - to start
> with, look at the directed funding proposal from the past President's
> report in a board report.

Alex’s suggestion as I understand it  doesn’t seem to fit with the above 
experiment. Alex (please correct me if I’m mistaken here) but you’re looking 
for lots of small donations from many (possibly unknown) people rather than a 
single largish donor up front right?

> That's a question for fundraising@ which we'll work on when a project
> comes forward with a likely donor.

If I am mistaken re above do we have any likely donor(s) in mind?

Thanks,
Justin

Re: Donating to Apache Flex

[Shane Curcuru]

A few clarifications on this excellent conversation from a long-time
Apache Member perspective:

Harbs  wrote earlier:
> My thoughts:
> 
> Conceptually, I like the idea of donating to projects (and in our
> case Flex). The direction of Apache seems to be moving to a more
> project-centric approach like we’re seeing with ApacheCon. That makes
> sense to me in general as Apache has grown quite a bit and
> diversified a lot in recent years. Large companies have business
> units with funds earmarked for them, and it seems logical for
> projects to have a certain level of autonomy in terms of justifying
> their own existence. (I’m not saying that every project needs to be
> “profitable”, but it also should not be shackled because it’s owned
> by the foundation.)

The ASF's mission is to provide software for the public good.  We do
that by hosting like-minded project communities.  As long as there's a
community to provide oversight for a project, we'll host them.  There's
really no thought of "profitability" ever in ASF thought.  (I think
everyone here knows that, but for the archives I wanted to provide that
reminder.)

Separately, the "Apache direction" is... not a thing.  The ASF is here
for our projects.  It's great to see a number of projects wanting to do
more - like for ApacheCon - and in particular, being *serious* and
following through on that kind of organization.

> Having earmarked money which has a foundation tax seems like a
> win-win to me. In all likelihood, project-specific donations will
> increase over-all donations to the foundation which could be very
> good to projects in particular and the foundation as a whole. Either
> way, it seems to me like a worthy experiment.

We're at a point where we're looking for new fundraising ideas that
still fit with the Apache Way and that will actually work with the all
volunteer-led governance the ASF and our projects use.  If I had to give
general advice, it would be 1) focus on getting interest for your
project, then worry about the rest, and 2) work on getting organized and
*consistent* project volunteers who will keep the work going on.  A lot
of past efforts here (or in infra) have fizzled when everyone +1'd great
ideas, but rarely showed up over the long term to actually do the work.

> 
> However, the details seem like they are pretty sticky: 1. How would
> these donations handled for a financial and technical perspective? 

Don't worry about finances, that's an ASF corporate question - to start
with, look at the directed funding proposal from the past President's
report in a board report.

> 2. How are decisions made on how to spend the money? 

For technical perspective, the PMC needs to come up with your own plan
on how to ask for, and in particular how to use any per-project funds in
a way that is fair and transparent how spending decisions are made.

> 3. What would be the guidelines on what is a “kosher” expense? 

Whatever the PMC can consistently justify as furthering the goals of the
project.  There will be a few specific restrictions that the ASF is
likely to impose, but beyond that it's up to the PMC.  One of those
rules might be not paying for donation of core development services *for
the normal coding work of the project itself*.  That is, building new
Flex modules or fixing bugs should come from people donating their time
and code, not by paying them.

> 4. Practically, what expenses do we have that would benefit from earmarked 
> donations? 

> 5. Could donations be given with the expressed desire for it to be
> used for a specific purpose? (i.e. if Acme company wants to invest
> in better docs for a project, is that okay?) 

That's mostly up to the PMC.  Note that the details at this level rely
on trust between the PMC and the donor(s), not legal agreements.


> 6. Would recognition for donations be allowed? (i.e. company logo on
> a project homepage for donations above $XX)

That's a question for fundraising@ which we'll work on when a project
comes forward with a likely donor.  The issue is ensuring that formal
recognition on project pages doesn't harm the overall Sponsorship
program, which needs to be clearly separated from this.

...snip...

On Feb 10, 2017, at 11:46 PM, Alex Harui  wrote:
...snip...

> My reasons for spending time on this are several.
> 1) The ASF is growing and so are expenses. Expenses rarely change based
> on the economy, but donations can. If a time ever comes to discuss
> cutting expenses, I want to protect Flex by being able to make a case that
> we don't cost the ASF any money and in fact, help.
> 2) We should be donating money to the ASF, but how many of you do? I
> don't myself. And would it be easier to justify if the money went
> directly to Flex? It would for me.

I don't donate personally, because I spend so much of my own unpaid time
working on Apache governance: my job has been wholly unrelated to ASF
work for a dozen years.  And I don't think we should 

Re: Donating to Apache Flex

[Harbs]

> On Feb 12, 2017, at 2:16 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> The direction of Apache seems to be moving to a more project-centric 
>> approach like we’re seeing with ApacheCon.
> 
> Not sure that's case, for instance the other streams include Cloud, Big Data 
> and IoT which involve multiple projects. The IoT stream is likely to involve 
> a dozen or so projects. If we can band tonight with other projects for a 
> steam/summit we're are more likely to attract more speakers, attendees etc. 
> The ASF has talked about a 50 year plan. It's not expected that the projects 
> that exist today will exist in 50 years.
> 
>> We could also benefit from conferences/hackathons.
> 
> The best way to do this is to submit talks to conferences (which I know there 
> has been some success at) - and promote the ApacehCon FlexJS summit :-)

Sure, and I’m going to make an effort to be there. But ApacheCon is once a year 
(possibly twice?) If we could help arrange smaller get-togethers around the 
world, it would likely be productive.


>> Of course this goes into the question of #3 and #5. AFAIK, paying for 
>> professional services is currently a major no-no.
> 
> I think that’s set in stone and isn't not possible. See the minutes in that 
> board report for instance, but it doesn’t stop other companies hiring people 
> and paying them to do the work. 

I realize this. I’m just raising the question as to whether things might 
change. What’s the reason for the current rule? Would the reasons be mitigated 
if projects raise funds?

I’m trying to put out food for discussion. I don’t have an opinion yet on these 
issues.

Harbs

Re: Donating to Apache Flex

[Justin Mclean]

Hi,

> The direction of Apache seems to be moving to a more project-centric approach 
> like we’re seeing with ApacheCon.

Not sure that's case, for instance the other streams include Cloud, Big Data 
and IoT which involve multiple projects. The IoT stream is likely to involve a 
dozen or so projects. If we can band tonight with other projects for a 
steam/summit we're are more likely to attract more speakers, attendees etc. The 
ASF has talked about a 50 year plan. It's not expected that the projects that 
exist today will exist in 50 years.

> We could also benefit from conferences/hackathons.

The best way to do this is to submit talks to conferences (which I know there 
has been some success at) - and promote the ApacehCon FlexJS summit :-)

> Of course this goes into the question of #3 and #5. AFAIK, paying for 
> professional services is currently a major no-no.

I think that’s set in stone and isn't not possible. See the minutes in that 
board report for instance, but it doesn’t stop other companies hiring people 
and paying them to do the work. 

Thanks,
Justin

Re: Donating to Apache Flex

[Harbs]

My thoughts:

Conceptually, I like the idea of donating to projects (and in our case Flex). 
The direction of Apache seems to be moving to a more project-centric approach 
like we’re seeing with ApacheCon. That makes sense to me in general as Apache 
has grown quite a bit and diversified a lot in recent years. Large companies 
have business units with funds earmarked for them, and it seems logical for 
projects to have a certain level of autonomy in terms of justifying their own 
existence. (I’m not saying that every project needs to be “profitable”, but it 
also should not be shackled because it’s owned by the foundation.)

Having earmarked money which has a foundation tax seems like a win-win to me. 
In all likelihood, project-specific donations will increase over-all donations 
to the foundation which could be very good to projects in particular and the 
foundation as a whole. Either way, it seems to me like a worthy experiment.

However, the details seem like they are pretty sticky:
1. How would these donations handled for a financial and technical perspective?
2. How are decisions made on how to spend the money?
3. What would be the guidelines on what is a “kosher” expense?
4. Practically, what expenses do we have that would benefit from earmarked 
donations?
5. Could donations be given with the expressed desire for it to be used for a 
specific purpose? (i.e. if Acme company wants to invest in better docs for a 
project, is that okay?)
6. Would recognition for donations be allowed? (i.e. company logo on a project 
homepage for donations above $XX)


Re: Infra. Chris has some good points, but the pain points that Alex brings up 
are real. Finds don’t necessarily mean that we need to run the infrastructure 
ourselves. There’s no reason why project funds cannot go to Infra to pay for 
resources that Infra can not otherwise justify. That would give us the best of 
both worlds: we are guaranteed the resources we need, while not having to 
manage them. Of course, if a project would feel the need to manage something on 
their own, I see nothing wrong with that.

Re: #4 I think we could REALLY benefit from professional documentation and 
possibly design. We could also benefit from conferences/hackathons. Of course 
this goes into the question of #3 and #5. AFAIK, paying for professional 
services is currently a major no-no. The question to me is whether that’s 
something that’s set in stone or not.

I think things when they go down this track can spiral pretty quickly. I’m not 
saying we shouldn’t try this, but we need really clear guidelines fro the board 
on which steps to take, and when…

> On Feb 10, 2017, at 11:46 PM, Alex Harui  wrote:
> 
> Hi,
> 
> In case you were wondering, Apache Flex and the entire Apache Software
> Foundation and the other 300+ ASF projects are funded by generous
> donations.  Some donations are in terms of people:  I get paid by Adobe to
> work on Apache Flex but Adobe doesn't write a check to the ASF
> specifically for other costs of hosting Apache Flex.  But some companies
> and individuals do write checks to the ASF.  Big donations are termed as
> sponsorships and those folks are recognized here [1].  This money pays for
> servers that host Git, manage mailing lists, host our website, distribute
> releases, and pays for accountants, legal and PR people, among other
> things.
> 
> All projects are encouraged to encourage its users to donate to the ASF.
> On our website [2], we have the "About Apache" menu item that has the
> "Donation" option that takes you to [3].
> 
> Historically, any donations could not be "directed" or "targeted".
> Instead any money you donate to the ASF goes into the general fund and is
> used however the Apache board sees fit.  There was no way to specify that
> the money you want to donate should be used to help Flex.
> 
> However, in January 2015, the board decided to entertain proposals for
> directed donations.  No project has made a proposal so far, but I want to
> see if our community is interested in proposing the following:
> 
> The Summary:  I want to see if we can get enough donations from the
> community to pay for all costs of having Flex at Apache.
> 
> How much money that is isn't clear.  My guess is that Flex is a
> below-average consumer of ASF resources.  Our share of the costs could be
> as little as $1000/year.
> 
> My reasons for spending time on this are several.
> 1) The ASF is growing and so are expenses.  Expenses rarely change based
> on the economy, but donations can.  If a time ever comes to discuss
> cutting expenses, I want to protect Flex by being able to make a case that
> we don't cost the ASF any money and in fact, help.
> 2) We should be donating money to the ASF, but how many of you do?  I
> don't myself.  And would it be easier to justify if the money went
> directly to Flex?  It would for me.
> 3) I am currently paying for one of our CI servers.  If we could get
> directed donations to pay for it, 

Re: Donating to Apache Flex

[Christofer Dutz]

Ok … responding to this part first:

3) I don’t see the need of this. I think our CI servers are now setup nicely. 
We have build-times of about 8-10 minutes. I don’t see a need to jump through 
all the hoops of having to maintain our own infrastructure. Yes, the Ant build 
doesn’t run on Infra, but I don’t see this as a problem of Infra, but more of 
the Ant build. The Maven build works nicely and I currently can’t think of 
anything that’s not possible at the moment. We now even have automated UI tests 
in Browsers and whenever I needed anything, I got it in the end. Yes it did 
usually take some time and convincing, but in the end things turned out exactly 
as we needed them. 

4) I don’t see this as a valid argument towards requiring our own Jira … ok … 
it is somewhat sluggish every now and then, but for example, being a TAC judge 
I like the option to search for a user’s Jira activity over several projects. 
If TLPs started having their own JIRAs, things would get a lot harder.

So now to some general thoughts:
- If we started this, probably a lot of the big projects would start getting a 
lot of funds. Funds that no longer go to the foundation, reducing the funds 
shared upon projects without their own funds. We have 3xx TLPs, but I doubt 
most of them would receive the funding they would need. So, we would have a 
hand full of rich projects and a lot of poor ones. I don’t think that’s the 
spirit of the Foundation. What about Apache Commons? Probably one of the 
most-used project, but probably also not one of the sexiest ones for getting 
funds? What about the Incubator? It’s one of the most important Projects of 
Apache, but it doesn’t have that outside marketing value.
- Having companies pay for individual Projects sort of produces a bad feeling 
in my gut. Even if they don’t say so, they still could and probably would 
expect something for their generous founds. I don’t want to be in the situation 
of having to implement something a company wants, because otherwise they 
threaten to cut funding.
- I think we suck at running infrastructure … at least compared to having a 
team of skilled people watching for Infra 24/7. What happens in the time lights 
are out in the US, if a service goes down just before Christmas? I don’t want 
to rely on volunteers to run our systems. That’s also the reason why Infra 
people are the only paid contractors at the ASF.
- There is a huge number of things you must deal with when running your own 
infrastructure. A lot of the things are quite restrictive on Apache Infra, but 
it’s not because they want to make our life harder, it’s because of damage that 
had been done in the past. We would have to re-learn all those lessons already 
learnt by Infra. Setting up a server is super-easy. Setting one up that’s not 
hackable in a handful of minutes by a Script-Kiddie is super-hard. 

So, if it’s just that one VM you are looking for, I don’t have any objections 
as I don’t see any difference to what we are doing now. But I don’t want to 
have an essential part of our Projects infrastructure outside of Infra. 

Chris



Am 10.02.17, 22:46 schrieb "Alex Harui" :

My reasons for spending time on this are several.
1) The ASF is growing and so are expenses.  Expenses rarely change based
on the economy, but donations can.  If a time ever comes to discuss
cutting expenses, I want to protect Flex by being able to make a case that
we don't cost the ASF any money and in fact, help.
2) We should be donating money to the ASF, but how many of you do?  I
don't myself.  And would it be easier to justify if the money went
directly to Flex?  It would for me.
3) I am currently paying for one of our CI servers.  If we could get
directed donations to pay for it, we might be able to upgrade to a faster
server.  I would personally donate more since I would get a tax break on
the donation.  And anyone who wants to pitch in can help and at least in
the US, get a tax break.
4) There are certain resources we share in the ASF like JIRA that are not,
IMO, optimally set up for us.  We can't create custom JIRA fields, for
example.  And more than one person has tripped over the Infra-centric
buttons on each JIRA issue.
5) I, and I think several board members, want to understand if handing off
more server responsibilities to the project would scale to other projects
and help the bottom line or hurt it.

Re: Donating to Apache Flex

[Alex Harui]

On 2/10/17, 3:52 PM, "Justin Mclean"  wrote:

>Hi,
>
>> However, in January 2015, the board decided to entertain proposals for
>> directed donations.
>
>This proposal doesn’t see to match with what in that board report [1] as
>it's for $50,000 sized experiments. Are you sure you get board support
>and VP funding approval for this proposal?

The discussion on board@ invited me to pursue this approach.  Once it is a
more detailed and concrete proposal and is approved by the PMC it needs
official approval by VP Fundraising and the board.  So it could get
blocked there at any point in time.

>
>> 3) I am currently paying for one of our CI servers.  If we could get
>> directed donations to pay for it, we might be able to upgrade to a
>>faster
>> server.
>
>Why not talk to Infra they should be able to help and give up a better
>server? Sure Is it easier to setup up one ourselves short term, but long
>terms costs may be greater.

I've asked twice for a VM.  Each time the answer was "Yes", then "No".
I've given up trusting that the answer will stay "yes".  That's just ends
up with us using more Infra resources.  If they ever need to cut costs,
they'll start saying "No" again.  The goal of the experiment is to see if
we take on more responsibility ourselves, do we get more donation money we
can use in case costs are higher?

>
>My concerns:
>- I’m not sure it’s in line with ASF mission of  “for the public good”.
>If the ASF only accepted project that could pay for themselves it would
>be very different to what it is today.

I forgot to mention that at least 15% of every dollar donated must go to
the ASF general fund.  That will be the starting "tax rate".  So yes we
still benefit the general foundation, but the math looks like of every
dollar, we get 85 cents to spend.  The ASF has 300 projects so for every
dollar our share should only be 1/3 of a cent.

>- The PMC will need to spend more volunteer time on setting up and
>maintaining and updating servers.
>- Security and the risk around self hosting, particularly if we offer non
>static services on it. What happens if our server gets compromised. Would
>that damage our project and the ASFs reputation?  What would the board do
>in this situation?
>- Bus factor. If the person who’s set up a critical piece of the
>infrastructure leaves the project that knowledge is lost.
>- Risk to uptime of services. If a server goes down who can fix it
>quickly it not like we have people on call or have monitoring systems (or
>we could but that’s more cost).
>- Administration of donations, who has access to the bank account,
>auditing and legal responsibilities around what we can and can’t spend it
>on. Would we need to pay for professional services here?
>- Risk towards the ASF 501(c) status, is anyone here an expert on US tax
>law and what we can and cannot no in that regard? Would we need to pay
>for legal services here?
>- Risk of outside influence / perception of non neutralitily to companies
>who directly donate

All good discussion points.  The board is not currently worried about
501(c)3 status except if we start spending money on things we shouldn't so
there will be some rules on that.  But paying for things the ASF currently
pays for isn't a worry.

>
>Now I'm sure that most of these can be sorted up but my first impression
>is seems like a lot of effort, risk and potentially increased costs over
>what we currently have, but if you want to run with it and manage to get
>support from the rest of the PMC, the board and VP funding then go for it.

The philosophy is to take on more work and responsibility and costs in
order to guarantee our future by proving that we are a positive financial
contribution to the foundation.

-Alex

Re: Donating to Apache Flex

[Justin Mclean]

Hi,

> However, in January 2015, the board decided to entertain proposals for
> directed donations.  

This proposal doesn’t see to match with what in that board report [1] as it's 
for $50,000 sized experiments. Are you sure you get board support and VP 
funding approval for this proposal?

> 3) I am currently paying for one of our CI servers.  If we could get
> directed donations to pay for it, we might be able to upgrade to a faster
> server.

Why not talk to Infra they should be able to help and give up a better server? 
Sure Is it easier to setup up one ourselves short term, but long terms costs 
may be greater.

My concerns:
- I’m not sure it’s in line with ASF mission of  “for the public good”. If the 
ASF only accepted project that could pay for themselves it would be very 
different to what it is today.
- The PMC will need to spend more volunteer time on setting up and maintaining 
and updating servers.
- Security and the risk around self hosting, particularly if we offer non 
static services on it. What happens if our server gets compromised. Would that 
damage our project and the ASFs reputation?  What would the board do in this 
situation?
- Bus factor. If the person who’s set up a critical piece of the infrastructure 
leaves the project that knowledge is lost.
- Risk to uptime of services. If a server goes down who can fix it quickly it 
not like we have people on call or have monitoring systems (or we could but 
that’s more cost).
- Administration of donations, who has access to the bank account, auditing and 
legal responsibilities around what we can and can’t spend it on. Would we need 
to pay for professional services here?
- Risk towards the ASF 501(c) status, is anyone here an expert on US tax law 
and what we can and cannot no in that regard? Would we need to pay for legal 
services here?
- Risk of outside influence / perception of non neutralitily to companies who 
directly donate

Now I'm sure that most of these can be sorted up but my first impression is 
seems like a lot of effort, risk and potentially increased costs over what we 
currently have, but if you want to run with it and manage to get support from 
the rest of the PMC, the board and VP funding then go for it.

Thanks,
Justin

1. 
https://www.apache.org/foundation/records/minutes/2015/board_minutes_2015_01_21.txt