Dave - appreciate the thought and the willingness to raise the issue. Here's another sticking point for many vendors around ASF projects.
Most (if not all) commercial software today has some ways of tracking how this software is used in an anonymous way (OS version, language, country, time of the day, JVM version, components used, etc.) since such information immensely helpful for the product development (proper prioritization of fixes, testing and new features, documentation, etc). Obviously, there could be some privacy violation but by and large most reasonable companies collect only anonymous information and require at least implicit consent. As you know, ASF is 100% categorically against this in any shape or form what-so-ever. I find it really counterproductive, *especially* for the community driven project where time and resources are very scarce and their optimal utilization is of highest concern. At Ignite - we've had this functionality before joining ASF, and had to remove after. And we felt, and continue to feel, completely blind as to how our project is used by the real users (outside of committers) - what to concentrate on, what to fix first, whether certain usage is one-off or a pattern, etc. It doesn't help to say the least as we have to rely on some questionnaires and other "marketing" techniques to gather some semblance of the same information - which ultimately lacks in quality and irritates the community in general. Something to think about. Thanks, -- Nikita Ivanov On Thu, Oct 8, 2020 at 11:50 AM Dave Fisher <[email protected]> wrote: > > > > On Oct 8, 2020, at 11:34 AM, Dave Fisher <[email protected]> wrote: > > > > Hi - > > > >> On Oct 5, 2020, at 1:10 PM, Nikita Ivanov <[email protected]> wrote: > >> > >> Dave, > >> So, if the project wants to do a nightly builds it cannot even mention > >> their existence on the project's website? How would developers even know > >> they exist to ask about them in the first place? I'm not arguing here - > but > >> merely asking about the right approach here. What if website has a clear > >> disclaimer that these artifacts are only for the project's dev community > >> and not official ASF releases? > >> > >> GridGain/DataBricks/Confluent/DataStax went another way of doing their > 100% > >> own builds off of the Apache counterparts (which I don't think this > project > >> is ready for). > > > > These commercial entities must follow branding requirements. The > relevant PMC Members as individuals must enforce branding with their > employers. > > > > Project community members earn merit in the project based on their work > in the community and not on their work for their employer. If they leave > their job they remain members of the project community. > > > > Apache PMCs must beware of taking advantage of a vendor’s offer. Here is > an example involving Confluent and Kafka. Confluent hosts their own set of > community extensions to Kafka. A couple of years ago they relicensed their > contributions to an “Open Core” license going away from OpenSource. > > > > A project should be getting developers involved in project development > on the dev mailing list. Having developers ask for the CI build on the list > is a good thing. This assure that their contributions can be made more > easily on the list rather than captured by a vendor. > > > > By listing the vendors and not the projects you show how insidious this > capture really is. > > > > This may be an argument for changing the Apache Policy about > “advertising CI builds”. > > See LEGAL-541 Relaxing No Advertisement of CI or Nightly Builds > https://issues.apache.org/jira/browse/LEGAL-541 > > Regards, > Dave > > > > > Regards, > > Dave > > > > > >> > >> Thanks, > >> -- > >> Nikita Ivanov > >> > >> > >> > >> On Mon, Oct 5, 2020 at 12:50 PM Dave Fisher <[email protected]> wrote: > >> > >>> Hi - > >>> > >>>> On Oct 4, 2020, at 5:52 PM, Nikita Ivanov <[email protected]> > wrote: > >>>> > >>>> NLPCraft-ers, > >>>> I've looked at the velocity of the development on the project and the > >>>> frequency of the releases and it appears to me that they don't sync up > >>> very > >>>> well. The project is still very young and the pace of > >>>> changes/fixes/improvements greatly outpaces the pace of official ASF > >>>> releases. However, it's unclear if master branch (or other branch) > >>>> is stable and can be used for play-around... > >>>> > >>>> As with many other ASF projects I propose to consider doing > >>> ASF-unofficial > >>>> nightly or (less frequent) community builds and make them available on > >>> the > >>>> website. > >>> > >>> The project can make snapshots from CI available, but not from the > website. > >>> > >>> http://www.apache.org/legal/release-policy.html#publication > >>> http://www.apache.org/legal/release-policy.html#host-rc > >>> > >>> The location may be given to community members on the mailing list when > >>> they ask. > >>> > >>>> This will allow many users to simply try some of the experimental > >>>> features or provide quick fixes/feedback when necessary without a need > >>> for > >>>> the NLPCraft team to cut an official ASF release and go through the > >>> process > >>>> every time for every small fix or feature iteration. We will, > obviously, > >>>> continue to release official ASF releases once we accumulate enough > >>> "meat" > >>>> for such a release. > >>>> > >>>> At Apache Ignite we've decided to do Community Edition (built and > hosted > >>> by > >>>> GridGain Systems) for pretty much exactly these reasons. > >>> > >>> These can be problematic. > >>> > >>> https://infra.apache.org/release-distribution.html#unreleased > >>> > >>> Community Editions that are called Apache NLPCraft (incubating) must be > >>> based on Released Source Code. > >>> > >>> GridGain community edition is not Apache Ignite, it’s not the same. I’m > >>> unclear what is going on here, but that is an issue for the Ignite PMC. > >>> https://www.gridgain.com/products/software/community-edition > >>> > >>>> > >>>> Thoughts, comments? > >>> > >>> Regards, > >>> Dave > >>> > >>> > >>>> -- > >>>> Nikita Ivanov > >>> > >>> > > > >
