On Wed, 31 Oct 2018 at 08:44, Myrle Krantz <my...@apache.org> wrote: > > On Fri, Oct 19, 2018 at 10:32 PM James Dailey <jamespdai...@gmail.com> wrote: > > > > +1 on this civil discourse. > > > > I would like to offer that sometimes large code drops are unavoidable and > > necessary. Jim's explanation of httpd contribution of type 1 is a good > > example. > > I suspect that Jim's example of Robert Thau's httpd contribution may > not have been necessary were he working with the source control tools > and methods available today. That was in 1995. Even when we assume > it was necessary in 1995, it was risky and probably only succeeded > because of an abundance of communication and real good will with the > community. I'm guessing though. I haven't given up hope that Jim > will provide more details. > > > I think we would find that many projects started with a large code drop > > (maybe more than one) - a sufficient amount of code - to get a project > > started. When projects are young it would be normal and expected for this > > to happen. It quickly gets a community to a "thing" that can be added to. > > Many do start with a large code drop. They go through incubation, and > sometimes fail to attract communities. If they fail to attract > communities, they eventually reach the attic.
FTR: Podlings which fail to attract a community do not graduate - they are retired. They do not go to the Attic, which is reserved for TLPs. > Many projects also > succeed in starting at the ASF with an empty repository and building > from zero. These are often very successful at attracting communities. > People like to work on things in which they are empowered to > participate in decision making. People like the feeling of trust and > community which results. PLC4X which Chris Dutz is working on is an > excellent example. > > > It obviously depends on the kinds of components, tools, frameworks, etc > > that are being developed. Game theory is quite apropos - you need a > > sufficient incentive for *timely* collaboration, of hanging together. > > > > Further, if your "thing" is going to be used directly in market (i.e. with > > very little of a product wrapper ), then there is a strong *disincentive* > > to share back the latest and greatest. The further from market immediacy > > the easier it is to contribute. Both the Collaboration space and > > Competitive space are clearly delineated, whereas in a close to market > > immediacy situation you have too much overlap and therefore a built in > > delay of code contribution to preserve market competitiveness. > > This is one important reason that there are very few full applications > at the ASF. Fortunately for Fineract, we don't have to function as a > full application. This might be an argument for our community to stay > away from customer-facing front-ends. > > If working together with others on your code would cause you important > market disadvantages, then you probably don't want to take part in > open source as it is conceived at the Apache Software Foundation. If > a vendor's goal is simply to publish their source, then a plain old > github account is probably the least expensive method available to > that vendor. If a vendor's goal is to dominate a project, then there > are 501(c)6's out there which have the latitude to make that sort of > collaboration possible. Those are valid and reasonable approaches. > The ASF isn't trying to compete in those spaces. The ASF wants its > projects to be built as a community of equals. > > > So, combining the "sufficient code to attract contribution" metric with the > > market-immediacy metric and you can predict engagement by outside vendors > > (or their contributors) in a project. > > A "Sufficient code" metric isn't one I've ever personally used to > decide which project to contribute to. I don't believe vendors use > this either. I think some developers are even turned off by the > existence of massive amounts of code. It triggers the "not invented > here" complex many developers have. : o) But I'm happy to look at > data that shows I'm wrong. > > Perhaps you mean a "sufficient business functionality" metric? But > even then, what I've seen more often is a "sufficiently healthy > community" metric. Ie: how long has the project existed, how long is > it likely to continue to exist? These are the questions I get asked > by people outside of our project. > > > In such a situation, it is better, in > > my view, to accept any and all branched code even if it is dev'd off-list. > > The Apache Software Foundation does not "accept any and all" off-list > development. There are reasonable arguments to be had about the grey > areas and how far they extend, but there is *never* carte blanche. > > > This allows for inspection/ code examination and further exploration - at a > > minimum. Accepting on a branch is neither the same as accepting for > > release, nor merging to master branch. > > Inspection/examination can also be accomplished on github. We don't > need to accept code into an Apache project in order to be able to see > it. If a vendor wishes to propose merging a branch, we can look at > that code and determine whether it is inside or outside our project's > grey area *before* we accept the code. If code is large, that > proposal can be made available in reviewable-sized chunks by the > vendor, as Upayavira described doing. This not only has the advantage > of improving code quality, it also means community members have a > chance to participate meaningfully in the decision-making process and > learn how to work within the new code. Learning by doing is always > the deepest learning. > > > Now, the assumption that the code is better than what the community has > > developed has to be challenged. It could be that the branched code should > > be judged only on the merits of the code (is it better and more complete), > > or it could be judged on the basis that it "breaks the current build". > > There can be a culture of a project to accept such code drops with the > > caveat that if the merges cannot be done by the submitting group, then the > > project will have a resistance to such submissions (you break it, you fix > > it), or alternatively that there will be a small group of people that are > > sourced from such delayed-contribution types - that work on doing the > > merges. The key seems to be to create the incentive to share code before > > others do, to avoid being the one that breaks the build. > > Shall we call this the "preemptive architecture" approach? Certainly > programmers sometimes engage in this kind of adversarial behavior. > I've seen it. I've never been happy with the consequences. I would > not wish to work for a company which was racing to get there first > with the largest possible chunk of code, with the consequence of > failure being resolving months of merge conflicts. Not to mention > that there's more to software engineering than just lines of code to > merge. Entire problem-solving approaches can be in conflict. And > resolutions of these will involve more than just staring at a > three-way merge of files all day. > > The consequences for employees aside, it doesn't seem likely that > anybody in the scenario you describe actually has time to test the new > code or its merge, nor to participate in the community aspects of > teaching others about the code being contributed and collaborating > with people outside their company. I'd be very concerned about the > quality of code produced using this approach. > > I hope we can avoid incentivizing vendors to treat their employees and > our projects this way. > > Best Regards, > Myrle > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
