Ross Gardler was last year on the ASF board and is a well-respected community member. He knows a lot about driving open source projects, because knowing that is also his day job. On Apache Con EU he held a great presentation on open source risks:
http://de.slideshare.net/rgardler/managing-project-risk-15725610 It pretty much sums up a lot of things On Sat, Jun 15, 2013 at 5:22 PM, Andrew Kaplanov <akapla...@gmail.com> wrote: > Totally agree with all, we need to get better and do more to just became > bigger and better. > > > 2013/6/15 John Blossom <jblos...@gmail.com> > >> Christian, >> >> Thanks for clarifying this. One of the factors which I hope that the >> developers new to Apache consider is that just because one calls their >> product open source does not mean that you have the resources to manage an >> open source program in a way that will lead to successful product >> implementations. For people to commit major development resources to a >> platform like Wave they will need assurances that there is a legal and >> administrative framework that will protect their development investment >> when they commit custom/bespoke assets on top of open source Wave. This >> sort of assurance for infrastructure like SMTP/POP email is what led to its >> explosion decades ago, as did the growth of the LAMP stack incorporating >> Apache's web server assets. We want to be aggressive, innovative and >> attract as many people as possible to the power of Wave through outlets >> such as Github. But at the end of the day, if we want to change the world >> with Wave, then we want to play it smart. >> >> Best, >> >> John >> >> On Sat, Jun 15, 2013 at 3:20 AM, Christian Grobmeier <grobme...@gmail.com >> >wrote: >> >> > On Fri, Jun 14, 2013 at 9:29 PM, Joseph Gentle <jose...@gmail.com> >> wrote: >> > > On Fri, Jun 14, 2013 at 11:48 AM, Christian Grobmeier >> > > You mentioned that the code has to be first committed to the apache >> > > repositories for legal reasons. What exactly are the requirements >> > > there? Is it bad if I have my own local mirror of the project and >> > > commit there? (Technically, my local machine is a private mirror that >> > > gets my commits first). >> > >> > Please see Upayaviras response. >> > What I actually meant it, the official repository for the source code >> > needs to be the ASF one. For example, if 99% of the team works on GitHub >> > and does not reflect the changes to the ASF, one clearly cannot say the >> ASF >> > hosts the one canonical repository. >> > >> > Besides the social impact Upayavira has mentioned, there might be >> concerns >> > on the IP. Do we really have every ICLA on file for every GitHub pull >> > request? >> > How is it documented? If all documentation on code contributions are only >> > on GitHub, then we might not have access to that information if we need >> it. >> > >> > There is no legal problem if you commit something to a github repository >> > and later decide to contribute the code to the official repository. >> > >> > > Are the problems around public distribution? >> > >> > The ASF releases source packages in first place. Binary packages are >> > optional, >> > but many projects release them. One requirement is to provide >> > distributions from >> > an ASF server. This is done by committing the package to a specific svn >> > tree. >> > From there it will be mirrored. >> > >> > Optional you can release your code as maven artifact to the Maven >> > Grand Repository. >> > Its done by releasing to there: repository.apache.org/ >> > We have a maven parent pom which deals with a lot of the specifics for >> > this task. >> > >> > These are our official distribution channels so far. >> > >> > In some cases you can request/build up new channels. For example, in the >> > log4php >> > project we wanted a pear channel, because back then it was usus to use >> > that. >> > http://pear.apache.org >> > >> > What you cannot do is to use a third party as official distributor. >> > >> > For example, consider the Chrome App Store. It's not within our reach, it >> > can't be official. But of course you can open an account there, share the >> > account details across the PMC and upload your binary to this place. >> > You should link to the official sources and tell the world, it is not >> > an official >> > channel but maintained by some PMC members. Then you should be fine. >> > >> > Apache OpenOffice had some special requirements to distributions too. >> > I don't know about the specifics, but they spoke a lot to our infra and >> > somehow >> > teamed up with SourceForge. Now they have an official channel there >> > too (I think). >> > >> > Basically you can say, i have never seen a project which wanted a >> specific >> > channel which they couldn't get. >> > >> > It is just necessary to properly fill up our own channels. >> > >> > More on releasing can be found here: >> > https://www.apache.org/dev/#releases >> > >> > > Does it then also matter where code review happens? >> > >> > Just consider the social impacts, then you are fine. You can make code >> > reviews on IRC, >> > if you wish. But others from the project cannot jump in, nor is it >> > properly documented. >> > You can use Hangout, but its the same there. Also consider, even when the >> > whole >> > team is on Hangout to review code, outsiders cannot access this and thus >> > not >> > join the project. >> > >> > I think there are no legal implications if you would use some Github >> > tools for review. >> > But of course, there is an social impact. Also decision making should >> > happen on the list. >> > If a code review fails, the discussion to solve the problem should >> > happen on list, not >> > on f.e. GitHub. >> > >> > > I ask because while I don't have a problem with an apache git >> > > repository being the ultimate source of truth, I also quite like >> > > github's pull requests as a system for code reviews. >> > > >> > > I'm not interested in taking the project away from apache. I actually >> > > think the community ownership model works well for this project. >> > > Github works much better with a benevolent dictator. But that said, >> > > I'd like to know what tools we can and can't use. >> > >> > Sure, that's why mentors are usually on the project and help. >> > The project needs to find out how we (ASF) work. >> > >> > I also believe the community model will work well for Wave. >> > >> > Its good to bring up such questions, keep them coming. Also don't be >> > afraid to >> > bring up ideas for improving the workflow. I am a bit conservative >> > when it comes to tooling. >> > Others may have different opinions. If a concrete proposal of workflow >> > comes in, >> > we also might consider to bring this question up to general@incubator, >> > where more people >> > might have recommendations for us. >> > >> > Cheers! >> > >> > >> > > >> > > -J >> > >> > >> > >> > -- >> > http://www.grobmeier.de >> > https://www.timeandbill.de >> > >> -- http://www.grobmeier.de https://www.timeandbill.de