On Wed, Jul 18, 2012 at 12:27 PM, Tony Lâmpada <t...@freedomsponsors.com> wrote: > Hi Benson, > > thankings for bringing that subject up. > > We have been giving a lot of thought into questions like
Tony, I'm just one Foundation member. This isn't the list to be communicating with if you want to engage with the Foundation in a more formal way. Anything I write here is just my opinion. The community development project would be better. It seems to me that this model of yours has the least risk of community problems when the issues are relatively small and compact -- 'fix this bug.' Often, though not always, a bug is a bug, and a clean patch for a bugfix, complete with test case, will be gratefully committed. However, even this has room for entertainment. When I commit patches, sometimes I do some pretty serious rework on them. If I thought that the poster was going to get paid as a result of my efforts, I might be troubled. Even bug fixes can be the subject of design and architecture disagreement. If someone has money riding on getting a patch committed, I could see some additional friction. I don't see the fuss about forks. The person either putting up the money either wants the change integrated into the trunk or not. If they are happy with a fix made in their very own fork, why should anyone else care? The AL is fork-friendly. The other side of this coin is that forking, as a development strategy, is a great way to fail to get your work into the trunk, especially forking without community engagement. The Apache approach works best with small, incremental, changes. If the posted bounty is for some gigantic feature, this creates friction. The person doing the work only gets paid for the whole thing, but the process will extend over time and might bog down in the middle. The Foundation has a very strong set of values around volunteer status. Yes, people get paid for their work on ASF projects. However, they interact with with the projects as individuals, not as employees or contractors. Once again, for small stuff, this is fine. Contributing a patch works fine so long as the contributor is willing to work with the community. For a bigger, strategic, contribution, the expectation is that someone is going to earn the respect of the community on small stuff before proposing something major. People who show up and say, 'I'd like to add this giant thing' often are met with some resistance. > > 1) What problem-scenarios might arise when a lot of people starts using > FreedomSponsors? > 2) And what would be the best way to address those problems? > 3) How should FreedomSponsors evolve to best serve the open source > community? > > And forking is one of our concerns as well. It surely fits (1) > We believe that, generally speaking, forking is a bad thing. > > Please take a look at this "Feedback issue" (which is curently an > improvement under develeopment) --> > http://www.freedomsponsors.org/core/issue/7/add-two-checkboxes-to-the-offer-form-1-no-forking-2-require-release > > We want to encourage sponsors to fund the original projects - so the "No > forking" checkbox will come checked by default in the "Sponsor Issue" > screen. > If the user unchecks it, a popup window will be displayed, explaining the > bad effects of forking, and maybe that decision should be reconsidered. > > Hopefully what will happen is that most offers will have "no_forking = > true" on their acceptance criteria. > Developers then will have to actually get involved with the already > well-established OSS communities to have access to bounties. > > If you have more thoughts regarding (1), (2) or (3), we're listening! :-) > > Thanks > Tony Lâmpada > > On 18 July 2012 11:09, Ron Wheeler <rwhee...@artifact-software.com> wrote: > >> The biggest danger is that projects will get funded that do not fit into >> the strategic direction being followed by the ASF committers. >> When the funded artifacts are turned over to the ASF team (assuming that >> they are not doing the work) and they refuse to incorporate the changes >> into an official release, there will be a fork in the project which will be >> supported by the companies that paid for the enhancement. >> >> ASF will have to be very careful not to let egos interfere with good >> long-term management. >> >> On the whole, this could be a good thing for ASF, if it is handled >> properly. >> >> Ron >> >> >> >> >> On 18/07/2012 9:19 AM, Tony Lâmpada wrote: >> >>> Hi Benson >>> >>> Then I think that all will be well indeed. >>> Building that kind of relationship with ASF is very much aligned with our >>> goals. >>> >>> Right now we're working on multiple fronts to improve our service and get >>> a >>> small scale operation going, so we can make the necessary tweaks to make >>> the model actually work. >>> When the time comes, I believe approaching ASF (and Codehaus, JBoss, etc) >>> will come very naturally. And donating part of what we get just makes a >>> lot >>> of sense (even if we were thinking as investors). >>> >>> FreedomSponsors is made by developers who love open source, and our main >>> goal is to serve the OSS community, while also being able to work on the >>> open source projects that we love ourselves! >>> >>> But those are still dreams for the future. Now is the time for us to do >>> the >>> best we can to get there. >>> >>> So... Wish us luck! :-) >>> >>> Thanks for getting involved! >>> Tony Lâmpada >>> >>> PS: Speaking of OSS, just as a side note: We are going to open source >>> FreedomSponsor's website code as well (there's some code cleanup we have >>> to >>> do first, though) >>> >>> >>> On 17 July 2012 15:41, Benson Margulies <bimargul...@gmail.com> wrote: >>> >>> It is extremely unlikely that the Foundation will be interested in any >>>> participation except to gratefully accept any unrestricted donations >>>> your organization might happen to make. If you want to state on your >>>> website that you are going to donate something to the ASF when the >>>> issue is an ASF project JIRA, and you conform the ASF trademark and >>>> branding guidelines, I predict (speaking without wearing any official >>>> ASF hat) that all will be well. >>>> >>>> ------------------------------**------------------------------** >>>> --------- >>>> To unsubscribe, e-mail: >>>> users-unsubscribe@maven.**apache.org<users-unsubscr...@maven.apache.org> >>>> For additional commands, e-mail: users-h...@maven.apache.org >>>> >>>> >>>> >> >> -- >> Ron Wheeler >> President >> Artifact Software Inc >> email: rwhee...@artifact-software.com >> skype: ronaldmwheeler >> phone: 866-970-2435, ext 102 >> >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> users-unsubscribe@maven.**apache.org<users-unsubscr...@maven.apache.org> >> For additional commands, e-mail: users-h...@maven.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
