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]