I like the way you phrased the advantages and disadvantages of moving to a TLP. I think its not a question of if, but a question of when this should happen. Should we set some goals to achieve before moving to a TLP?
Here are some ideas for such goals, some of which may already be met: * Clearly define what a "core" feature set contains for languages. * "Core" functionality in at least Java, C/C++, python, and one other language. (ProtocolBuffers +1) * Define some sort of usability goals for the languages above. * Performance goals and tests for the languages above. * Improved project documentation WRT vision, wish-lists, etc. These will often be language specific. Perhaps a separate page for each language easy to find from the home page. I feel that in order to take advantage of being a separate TLP, it will require most of the things above. That does not mean we need all of the above before becoming one. Attracting users and contributors as a TLP will require a different approach to how the project presents itself and exposes its status. The change to a TLP also presents a unique opportunity to attract attention on its own, and when that additional attention comes, we should make sure our site, documentation, and feature set are in what we feel is a good position to take advantage of the extra attention and grow our user/contributor base. -Scott On Mar 18, 2010, at 9:22 AM, Matt Massie wrote: > I like the idea of Avro as a TLP. > > Avro has appeal to groups outside of the Hadoop community even though Hadoop > will likely be our biggest "customer" for some time. Our release cycle and > decisions should be driven by this broader user community. The fact that > Avro is a subproject of Hadoop can imply that Avro is "Hadoop RPC" or that > it "requires" Hadoop or that it's only useful for huge datasets. I think > having Avro as a separate TLP would help disabuse people of those notions. > > There is a lot of buzz around Hadoop now and leaving could have a negative > effect on our visibility. However, I think we'll have no trouble generating > our own buzz. We can, for example, develop strong benchmarks that show we > beat other serialization/RPC systems in performance and announce it loudly. > We already have a generous Apache license. If we make Avro an easy drop-in > replacement for other systems, we'll likely see broad adoption. Lots of > happy Avro consumers == buzz. > > -Matt > > > On Wed, Mar 17, 2010 at 2:09 PM, Doug Cutting <cutt...@apache.org> wrote: > >> I'd like to start a discussion about promoting Avro from a Hadoop >> sub-project to a top-level Apache project (TLP). >> >> This is not yet a vote. Once we have established general understanding and >> agreement, I'll call a vote. >> >> I propose we move Avro from hadoop.apache.org/avro to avro.apache.org. >> Avro would then have it's own Project Management Committee (PMC) so that it >> can elect committers and create releases on its own. Currently these >> actions require votes by the Hadoop PMC. However I think Avro now has a >> sufficiently large, diverse and distinct community that it can fend for >> itself. >> >> I suggest that initial Avro PMC consist of all active Avro committers at >> the time we make the formal proposal. This is typical for new TLPs. >> (Subsequently PMCs tend to promote committers to the PMC. The Hadoop PMC >> generally promotes committers to the PMC after a year of consistent >> activity, while some projects immediately add new committers to their PMC. >> But we don't need to decide our policy for new PMC membership now, only the >> makeup of the initial PMC.) >> >> I nominate myself as the initial chair of the Avro PMC, with the proviso >> that we adopt a policy of regular chair replacement. I suggest that Avro >> PMC chairs serve a one or two-year term. A PMC chair has no more power than >> other PMC members, but rather has a few more duties. In particular, the >> chair must submit written quarterly reports to the board describing the >> health of the projects developer community. The chair also maintains >> subversion permissions and committer account creation. >> >> Do these proposal sound reasonable? Any improvements or questions? >> >> For some background, please read: >> >> http://www.apache.org/foundation/how-it-works.html#roles >> >> The steps I imagine are roughly: >> - discussion by Avro developers (what I'm starting here today) >> - vote by Avro developers >> - discussion by Hadoop PMC >> - vote by Hadoop PMC >> - draft resolution sent to board >> - board votes on resolution to form TLP >> >> Formally, the board alone has the power to create a TLP: all prior steps >> are merely an ordered means to make the case to the board that all involved >> parties support such an action. >> >> Thanks, >> >> Doug >> >> >>
