On Mon, Apr 7, 2008 at 11:02 PM, Don Brown <[EMAIL PROTECTED]> wrote:
>  The core issue in this proposal is something that has bothered me
>  about Struts for years - we do a poor job giving credit to
>  contributors.  I remember this one Open Source project I started
>  playing with that would include a little note of thanks/credit next to
>  a feature in the release notes, something simple like, "Added feature
>  foo.  Thanks Wendy for the patch!"  Just that little note, a few
>  characters really, did so much to encourage participation and build a
>  community.  Community members want to feel like they make a difference
>  and when the only recognition they get is a patch buried in the depths
>  of JIRA or even in a commit no one will ever see, the motivation isn't
>  there.

Following up on what James said, I think this much would be OK so long
as "Wendy" had filed a ICLA (or a CCLA, if the work was done on
company time). We already try to do that in the commit logs, and, for
more substantial contributions, the release notes would be an
extension of that practice. (The original Apache HTTPD voting rules
even gave contributors (or
"authors") a binding vote over something like this!)

But, saying thanks to Wendy's employer might cross the line. One of
our precepts is that ASF projects are "composed of individuals, and so
we give the credit to individuals. The farthest we might be able to go
is to say "Wendy of BigCo, Inc.", if that's how Wendy wanted to be
described.

And, of course, if "Wendy" continued to make welcome contributions to
the project, we should consider her for committership, the BigCo
paycheck notwithstanding. And, if she changes jobs, then she's still a
committer. BigCo is transparent to us. We don't want their money, we
want Wendy's brain.

As for BigCo's motivation, it should be the same as anyone else's
motivation. If BigCo is using our software, then BigCo should want the
software to be the best that it can be. And it should want that
regardless of attribution. If BigCo is using our software, then it
should not be difficult for BigCo to calculate a positive ROI without
a marketing element. Working with an open source project can eliminate
or mitigate a good portion of the cost of developing equivalent
software independently.

To me, the most valuable part of this proposal is not only the list,
but the specification. Where we really, really suck is planning
features without actually coding them first :)

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to