On Wed, Aug 2, 2017 at 21:55 Taylor Swift <[email protected]> wrote:
> Swift Breeze *was* on Github <https://github.com/swift-breeze>,, i don’t > know whose argument that strengthens here :) > No, no, I mean, doesn't GitHub itself fit the roles you defined earlier? And by implication, why would a project on GitHub do any better than GitHub itself at being a collection of repositories and at facilitating collaboration? Here was the original thread > <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/008134.html> > it was introduced in. It got a lot of attention and +1’s but never > attracted much involvement, possibly because the Swift FOSS community was > much smaller back then, possibly because people on mailing lists are by > nature all-talk, no-action. I’m also a library author so I understand the > reluctance to give up your children to a collective repo lol. > > On Wed, Aug 2, 2017 at 10:47 PM, Xiaodi Wu <[email protected]> wrote: > >> Hmm, I'd never heard of Swift Breeze. Doesn't seem like it'd be a >> successful model to follow. Is there a reason why GitHub itself doesn't >> meet these criteria? >> >> >> >> On Wed, Aug 2, 2017 at 21:42 Taylor Swift <[email protected]> wrote: >> >>> Trying to gather together a bunch of unpaid people won’t automatically >>> solve the problem. (We *can* agree that there *is* a problem, yes?) I >>> think Swift Breeze demonstrated that. (Incidentally, throwing a bunch of >>> money at the problem won’t automatically solve it either — look at the US >>> government.) But then again, it can still *help*, and while it sounds >>> cheesy, *how much* it can help depends entirely on the attitude of the >>> contributors; whether they see themselves as solo authors listed on a >>> package index, or as part of a bigger effort. I’m not really a fan of >>> waiting for Apple to save the day. One of the things I’ve argued for that >>> *can* be done without Apple’s help is setting up another Swift library >>> incubator like Breeze. Obviously it won’t magically lead to a Swift math >>> library but it does remove some of the obstacles I mentioned earlier: >>> >>> - it links together disparate solo projects and provides discoverability >>> to users >>> - it provides a package index and serves as a dashboard to check up on >>> the “state of Swift library support” >>> - it gives a venue for interested people to discuss the general topic of >>> library support >>> - it helps network people who are working on similar things (a “soft >>> factor” but important!) >>> >>> tldr; self-organization isn’t a panacea, but it helps. >>> >>> On Wed, Aug 2, 2017 at 10:14 PM, Xiaodi Wu <[email protected]> wrote: >>> >>>> That's not what I'm saying at all. I'm responding to your contention >>>> that no library without "backing" will see wide adoption: if, as you say, >>>> you would like to have a math library with sufficient "backing," then >>>> realize that you're arguing for someone to devote financial resources to >>>> the problem. Your proposed solution of getting together a bunch of unpaid >>>> people does not address your identified problem. >>>> >>>> On Wed, Aug 2, 2017 at 21:07 Taylor Swift <[email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Aug 2, 2017 at 9:18 PM, Xiaodi Wu <[email protected]> wrote: >>>>> >>>>>> On Wed, Aug 2, 2017 at 7:29 PM, Taylor Swift <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 2, 2017 at 7:54 PM, Xiaodi Wu <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> On Wed, Aug 2, 2017 at 6:29 PM, Taylor Swift <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> See, my problem with statements like this one, is that the answer >>>>>>>>> “should be supported as a third-party library” can also be >>>>>>>>> interpreted as >>>>>>>>> “not my problem, go figure it out yourselves”. The idea that central >>>>>>>>> entity >>>>>>>>> can only pay attention to what they want to, and the Community™ will >>>>>>>>> magically take care of the rest is one of the most pervasive, and >>>>>>>>> untrue, >>>>>>>>> myths about open source. What’s worse, is that Swift has the benefit >>>>>>>>> of >>>>>>>>> hindsight, in the form of many, many examples of languages that came >>>>>>>>> before >>>>>>>>> and fell victim to this fallacy, and now have 15 competing “private” >>>>>>>>> classes for basic mathematical objects like *vectors*. >>>>>>>>> >>>>>>>>> I agree that a core math library, for example, *could* in theory >>>>>>>>> be supported as a third-party library. >>>>>>>>> >>>>>>>> >>>>>>>> The core team has said that they're open to a core math library >>>>>>>> being part of the Swift open source project; they just outlined that >>>>>>>> the >>>>>>>> _process_ for doing so is best initiated with a third-party library as >>>>>>>> a >>>>>>>> starting point. >>>>>>>> >>>>>>>> >>>>>>>>> But this will never happen on its own, for reasons that I will >>>>>>>>> reiterate here: >>>>>>>>> >>>>>>>>> - no one influential enough has bothered to jump start any such >>>>>>>>> project >>>>>>>>> >>>>>>>> >>>>>>>> Karoly Lorentey has a wonderful, and quite mature, BigInt project: < >>>>>>>> https://github.com/lorentey/BigInt>. Also, as I mentioned, I just >>>>>>>> started a project for protocol-based additions to Swift's basic numeric >>>>>>>> types. These are just two examples. >>>>>>>> >>>>>>>> >>>>>>>>> - there are no avenues to encourage members of the community to >>>>>>>>> come together and organize a project (look how this thread got >>>>>>>>> derailed!) >>>>>>>>> >>>>>>>> >>>>>>>> You're welcome to join me in my endeavor to create a math library. >>>>>>>> I'd bet Karoly feels the same way about his project. >>>>>>>> >>>>>>> >>>>>>> You don’t know how happy reading that sentence just made me, i’d >>>>>>> assumed no one was willing to team up to build such a thing. In which >>>>>>> case, >>>>>>> it’s a good idea to start an incubator organization on Github. I think >>>>>>> David Turnbull tried doing that 2 years ago, I’ll reach out to him if he >>>>>>> wants to be a part of something like this. >>>>>>> >>>>>>> We should also maintain an index of promising pure swift libraries >>>>>>> so they are discoverable (like docs.rs does for Rust). >>>>>>> >>>>>> >>>>>> I believe there has been mention on this list that the core team >>>>>> would like to revisit this idea at some point. >>>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>>> - there is no “soft” infrastructure in place to support such >>>>>>>>> collaboration (look at the fuss over discourse and mailing list spam!) >>>>>>>>> >>>>>>>> >>>>>>>> The GitHub environment has excellent tools to support such >>>>>>>> collaboration, IMO. For example: >>>>>>>> >>>>>>>> Based on my experience implementing a library, I wrote a Gist to >>>>>>>> outline some lessons learned and suggestions for improvement. Not only >>>>>>>> did >>>>>>>> the document find an audience, these suggestions were in turn used to >>>>>>>> inform core team-driven revisions to the integer protocols. As a >>>>>>>> result of >>>>>>>> these revisions, it became possible to implement some initializers that >>>>>>>> could be useful for people writing generic numeric algorithms. >>>>>>>> Recently, I >>>>>>>> submitted a PR to the Swift project on GitHub to implement these >>>>>>>> initializers. Now, everyone will be able to use them. Collaboration, >>>>>>>> positive feedback loop, win-win for all involved. >>>>>>>> >>>>>>>> Likewise, Karoly used his experience updating BigInt for Swift 4 to >>>>>>>> inform certain improvements to the integer protocols. He implemented >>>>>>>> these >>>>>>>> improvements in a series of PRs. Now, as a result of these >>>>>>>> developments, >>>>>>>> Karoly's library will be better designed *and* everyone else will >>>>>>>> benefit >>>>>>>> from a better implementation of the integer protocols. Again, >>>>>>>> collaboration, positive feedback loop, win-win for all involved. >>>>>>>> >>>>>>> >>>>>>> Great!! can you link me to the gist? >>>>>>> >>>>>> >>>>>> https://gist.github.com/xwu/d68baefaae9e9291d2e65bd12ad51be2 >>>>>> >>>>>> >>>>>>>> - there are no positive feedback loops whereby a promising project >>>>>>>>> can gain market share and mature >>>>>>>>> - because there is no organization backing these projects, >>>>>>>>> potential users are reluctant to depend on these libraries, since >>>>>>>>> they will >>>>>>>>> logically bet that the library is more likely to fall out of >>>>>>>>> maintenance >>>>>>>>> than reach maturity. >>>>>>>>> >>>>>>>> >>>>>>>> Addressing this point is clearly impossible. When Apple wishes to >>>>>>>> commit its own resources to the maintenance of a Swift math library, >>>>>>>> swift-corelibs-math will appear on GitHub. Suggestions such as opening >>>>>>>> an >>>>>>>> empty repo and letting people contribute to it would either give the >>>>>>>> illusion of organizational backing that doesn't exist or would in fact >>>>>>>> commit Apple to support a repo that it doesn't wish to support. I fail >>>>>>>> to >>>>>>>> see why the former is good for anybody; in fact, it's strictly >>>>>>>> inferior to >>>>>>>> the same repo honestly representing itself as a third-party effort. And >>>>>>>> asking for the latter is essentially asking Apple to create a Swift >>>>>>>> math >>>>>>>> library--which, again, is not in the cards. >>>>>>>> >>>>>>> >>>>>>> My point wasn’t really to exhort Apple to create a Swift math >>>>>>> library, just that people are more willing to depend on a library if the >>>>>>> library’s bus factor is greater than 1. A lot of great Swift packages in >>>>>>> one one guy or girl’s github repository who later disappeared. >>>>>>> Turnbull’s >>>>>>> SGLOpenGL library is a good example of this; his library no longer >>>>>>> compiles >>>>>>> which motivated me to write swift-opengl >>>>>>> <https://github.com/kelvin13/swift-opengl>. Then again, I’m sure >>>>>>> people feel the same way about depending on swift-opengl today as I felt >>>>>>> about depending on SGLOpenGL. >>>>>>> >>>>>>> There just has so be some semblance of organization. That >>>>>>> organization doesn’t have to come from Apple or the swift core team. A >>>>>>> community initiative with sufficient momentum would be just as good. >>>>>>> (The >>>>>>> problem of course is that it is rare for a community initiative to >>>>>>> arise.) >>>>>>> >>>>>> >>>>>> Well, hang on now. There are plenty of products put out by even major >>>>>> organizations that are unceremoniously and abruptly cut. There are plenty >>>>>> of projects worked on by one or a few major people that are long-lived. >>>>>> Projects that have longevity have some sort of financially sensible model >>>>>> for their continued existence. Three, thirty, or even 300 unpaid people >>>>>> working on an open-source project won't make it much more reliable (in >>>>>> the >>>>>> eyes of others) than one unpaid person, and again I disagree that the >>>>>> veneer of an organization is superior to presenting the status of the >>>>>> project honestly. (Example--what is commonly thought to be a bigger >>>>>> threat >>>>>> to Firefox's continued health: the possibility that there will be a >>>>>> shortfall in unpaid contributors, or the possibility that there will be a >>>>>> shortfall in funding?) >>>>>> >>>>>> Rounding up all the goodwill on this list will not do you any good if >>>>>> your goal is to convince users that a certain project will be maintained >>>>>> into the future--because it won't rustle up a single dime. Whether or not >>>>>> you explicitly equate these in your mind, "backing" == money, and if you >>>>>> want this point addressed, you're claiming that someone somewhere should >>>>>> be >>>>>> spending money on a Swift math library. I'm personally committed to >>>>>> making >>>>>> sure that my code will work for the foreseeable future, but I fully >>>>>> accept >>>>>> that there's simply no way for me to convince a sufficient number of >>>>>> people >>>>>> of this fact without a credible showing of funding. In that sense, a >>>>>> community initiative with "momentum" is decidedly not going to be a >>>>>> just-as-good alternative to a core library. >>>>>> >>>>>> >>>>> Well that there is a rather defeatist attitude. If you are correct >>>>> that Apple-funded development is the only way to get core libraries built >>>>> (and maintained), and Apple has expressed they have no intention of doing >>>>> so, then we are all pretty much f****d. >>>>> >>>> >>> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
