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
