struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Leland <lel...@speakeasy.net>
Subject Re: Feature sponsorship proposal
Date Mon, 07 Apr 2008 19:44:37 GMT
James Mitchell wrote:
> I'm inclined to vote down anything mixing Community and Corporate agenda.  I
> think that's just a bad mix.  In fact, the ASF has specific rules/guidelines
> with respect to corporate involvement (employment) with too many project
>   
Do you have that reference ?


> leads.
>
> There's a reason that Apache projects are so successful, in one word ...
> "community".  I hate it as much as the next guy when movement seems to
> stagnate for weeks/months, but that's never just cause to bring in
> money/free stuff as incentive.
>
> The folks who want to help when there's a prize at the end will be the first
> ones to dump your a## when you really need them, but don't have an incentive
> to offer.
>
> If Struts (or any project) doesn't have enough volunteers to keep the work
> going, then we have bigger issues.
>
> Just my $0.02!
>
>
>
> On Mon, Apr 7, 2008 at 10:47 AM, Robert Leland <rleland@apache.org> wrote:
>
>   
>> Don I have a few questions
>>
>> 1) I agree that this contribution has to be valuable to the contributing
>> company
>> both technically and marketing. Back in 2003 when I obtained free IntelliJ
>> licenses from Jetbrains for the Struts
>> Committers all they wanted was acknowledgment on our web page and that was
>> voted down as too commercial.
>> To IntelliJ's credit they still provided the license and later expanded it
>> to all of Apache.
>> How has the Struts PMC changed since then to allow what your proposing ?
>>
>> 2) What if a proposal isn't on the short list of features, however when it
>> is proposed the Struts community
>> its viewed as a useful idea ?
>>
>> 3) What if it turns out that two competing companies have different
>> implementations, which is a great place to be in.
>>    Do we need to think this far ahead or using Agile methods do we not
>> want to over design this process  initially ?
>>
>>
>> -Rob
>>
>>
>>
>>
>>
>>
>> Don Brown wrote:
>>
>>     
>>> As more and more companies start using open source software, many,
>>> like mine, are looking for ways to give back to the community.  They
>>> want a way to contribute and ensure their contribution will be noticed
>>> and appreciated.  What if we had a feature sponsorship program that
>>> encouraged companies to donate engineering time to filling out needed
>>> features in Struts?
>>>
>>> I imagine it would work like this:
>>>  1. The Struts community comes up with a short list of desired
>>> features with high-level specs
>>>  2. Companies (or individuals) could "sign up" for a feature and
>>> donate internal engineering time to implementing the feature
>>>  3. The Struts community would review then commit the feature
>>>  4. The release notes for that version and perhaps somewhere on the
>>> website would note who gets credit for the feature
>>>
>>> This would help those that want to donate time what features are most
>>> needed by the community and give them a way to receive recognition for
>>> their work in a very public way.    A key component in this proposal
>>> is the way credit is given to the work, something that might encourage
>>> the marketing departments of the respective companies.  The list of
>>> desired features is also important as it ensures their effort will not
>>> be in vain, and it also implies the support of the Struts dev
>>> community to work to apply the patch in a timely manner.
>>>
>>> Thoughts?
>>>
>>> Don
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>>
>>>
>>>       
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>     
>
>
>   


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message