On Sat, Dec 24, 2005 at 11:05:05AM -0800, Dain Sundstrom wrote: > On Dec 22, 2005, at 9:19 PM, Ted Leung wrote: > > >To us an Apache project is an effort of the ASF. To the majority > >of people out there, being an Apache project (rightly or wrongly) > >is branding stamp. You might not like it, but that's how many > >people treat it. And that's why one of the first things a company > >wants do when it proposes incubation is issue a press release. > > I keep seeing this sentiment repeated on this list and I think we > should address this concern directly.
+1. > I've dealt with a few companies involved with projects being > incubated, and everyone of them was very concerned about doing the > right thing. The last thing they want to do is anger the ASF right > when they are getting involved. The problem I have found is that > they are just not familiar with the incubator, and make bad > assumption. Yep, that often seems to be the case. > I bet that if we let the corporations know the "Dos and > Don'ts" of working with the incubator, they will be followed (at > least more often then they are now :) I bet this bet is the very mistake we've made in the past. > I suggest we add a "For corporations" section to the "Incubator > Guidelines Documentation" that could make sense. > which would contain things, like: > > Don't do a press release. An incubating project is not officially > part of the ASF, and a press release will imply that the project is > part of the ASF. This one really makes ASF members angry, so don't > go here. > > Don't "just" print some t-shirts with the ASF logo or the incubating > project's logo. See "Don't do a press release" for reasons. > > Do move copyright notices from all source files to the NOTICE file. > > Do donate to the ASF :) > > I'm sure there are many more. > > What do you think? I've been mulling on this for some time. I don't know how to phrase this just yet. But since you asked, I will try anyway. I think it is a pipe dream that having things like lots of checklists, lots of process documentation, ISO 2000-compliant processes (FWIW, ISO 2000 and the ASF don't mesh well, we are based on self-driven volunteers not on management or top down process monitoring), or anything like that is ever going to address this kind of concern. The ASF is not like a corporation and its processes are not like those of a corporation. Corporations that want to be part of the open source community need to change a whole lot. This documentation should be a little more like: """The below advice is for technical managers, project managers, PR staff, quality assurance staff, marketing staff, and people in other kinds of corperate roles who will be involved with the open sourcing of a corporate project through the ASF. To understand the incubation process you should take a look at a few years of open source development and incubation history at the ASF. Read all of the documentation on http://www.apache.org/, in particular the 'How things work' documentation. Read all of the documentation on http://incubator.apache.org/. Understand that this documentation is and always will be behind on actual practice. Read all of the email from the general@jakarta.apache.org mailing list archives that has to do with the incubation of the Tapestry project. Read most of the email from the general@incubator.apache.org archives. Pay attention to some of the "process threads". Make a case study of one or two projects that graduated successfully (I recommend looking at SpamAssassin, a mature open source project that proceeded through the incubation process very successfully), read their dev-list archives as well (both before they came to the ASF, during incubation, and afterwards). If you are new to open source community development in the apache way (hint: its likely that you are), be prepared to spend a full work week reading about this stuff, thinking about it, etc. You will have questions to which you can't find the answer. Send e-mail to general@incubator.apache.org with your question. You will likely receive several answers, often not completely compatible. Get used to this. If you are somewhat new to open source in general, also read at least * "the cathedral and the bazaar" by Eric S. Raymond * "Open Source Licensing" by Lawrence Rosen * "the cluetrain manifesto" by a variety of authors * "Subversion Version Control : Using the Subversion Version Control System in Development Projects" by William Nagel I'll also recommend watching the movie "FUD". Watch it together with all of your collegues and discuss it afterwards. these sources will contain a variety of details which may be a lot more technical than you're used to and/or far more materials which are not so close to your day job at your corporation. Get used to this too. To continue to be productive at your job with respect to this to-be-open-source project, you will need to understand "how open source works", which involves understanding the moral principles underlying it, its chaotic process and work environment. You will most likely need to get used to using some "programmer tools", including SVN and Jira. Be prepared to embark on a personal path down the open source road that will take you several months to start. Most likely, you'll try to be walking it for the rest of your life if you make it that far. If you're in charge of your corporate open source efforts, you'll understand and recognize that all of the above is going to take your staff many many hours over the course a several months, and has the possibility of resulting in some radical changes to your corporate processes. Yup. """ - LSD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
