[FoRK] Deep Learning links, Re: Microsoft gets a new religion: VisualStudio Core, aka Atom
Stephen D. Williams
sdw at lig.net
Sun May 3 16:04:38 PDT 2015
To complete my point about open source deep learning:
Even if there are better solutions in well-funded proprietary labs, this is a many problems, many minds research area, with good
academic publishing and talent churn.
Deep Learning Links
Cute: Sparkling Water: Spark + H2O
On 5/3/15 3:55 PM, Stephen D. Williams wrote:
> On 5/3/15 2:58 PM, J. Andrew Rogers wrote:
>>> On May 3, 2015, at 12:38 PM, Stephen D. Williams <sdw at lig.net> wrote:
>>> Yes, sure. True for something like Hadoop. And even to some extent for Linux, such as all of the private improvements Google has.
>> Open sourcing software invites a considerable amount of cost and overhead. In my experience, the majority of moves to open source
>> software are ultimately scuttled because the benefit is negligible and the costs are often significant. This selects for a
>> certain type of software to be open sourced.
> You are now talking about the company economics of changing a closed-source product to an open source one? That isn't what we
> were discussing. Your second sentence is ambiguous, perhaps referring to that subject, perhaps to companies moving their apps to
> rely on open source.
> Different software has different characteristics, quality, direction, and economics. Some software has always been open source
> and wouldn't really work any other way (Linux). Others become open sourced when the owner is no longer very viable (Star Office
> -> Open Office maybe, Blender definitely). For companies making products open source for purely commercial and marketing reasons,
> that's more complicated. In some cases, a substantial part of the market will give much more attention and investment to
> something with the right license. That's simply a matter of investment optimization. Some of complicated situations, like
> Android, but complicated doesn't necessarily mean it won't work.
>> Keeping software closed is often explicitly a cost saving measure.
> Of course. Making something open source can be difficult, cause confusion, and even hurt market positioning if not handled well.
> And there may be no measurable benefit.
> Blender is a good example: There was no substantially complete 3D modeling / rendering authoring system, mainly because it takes
> substantial investment to create. If I recall correctly, there was a kickstarter-like public funding drive to reach $100K to buy
> the rights, whereupon it was open sourced with a liberal license. And it continues and improves today, providing some back
> pressure and educational opportunity.
>> So we’ve now narrowed it down to developer tools. Yet even on Linux some fraction of the best dev tools are closed source.
> Not necessarily narrowed, just excluded from that objection. I wouldn't necessarily call app libraries, frameworks, servers,
> services, systems, etc. "developer tools".
>> Also, why do editors need to be open source? I am not going to use crap software because it is open source if there is a better
>> closed source software available under reasonable terms. Being open source is a secondary concern relative to not sucking.
> Editors don't "need" to be open source. But they are a natural things to be open source. Every developer needs one or more.
> Every developer has pain points that they would invest a little time to improve. The cumulative need, effort, and simplicity of
> most of the relevant problems means that it would be strange not to have a fairly complete open source solution. In other words,
> a commodity.
>>> Another interesting problem providing a little back pressure on privatization of open source is that private rewrites need to
>>> keep up with open source evolution. There have been several companies in recent waves that went deep on their own
>>> implementation, but the market moved on and they couldn't afford to keep redoing it. Android, databases, CMS, libraries, AI
>>> algorithms, firewalls of various kinds, etc.
>> You are conflating two categories of software here, and your assertion is only true for one.
>> You are correct for software where almost all of the value is in the availability of well-defined interfaces, such as standard
>> libraries or operating systems. It is *not* true for software where almost all of the value reflects the quality of the
>> architecture and underlying implementation, such as databases or AI algorithms. In this latter case, it is quite simple for a
>> competent reimplementation to stay ahead of the open source version because it is cheaper and faster for them to deliver what
>> users value.
> For narrow or highly leveraged use cases, true. But others not so well financed will want similar capabilities. When many are
> interested in following, using, and extending an area, they're going to pool resources, especially when the best stuff is closely
> guarded. Additionally, patent and other licensing issues can be sticky. Google's release of Kubernetes is a good example: They
> are finally releasing a version of their internal container management system as Docker and related layers take off, perhaps to
> stay relevant, to popularize their model, increase likelihood of cloud computing business, etc. The best examples of rapidly
> advancing algorithms in open source libraries are OpenCV in the past and the new Deep Learning libraries now. The cost to
> redevelop, optimize, and validate all of the algorithms, APIs, and data sets is too much for all but a handful of companies.
> Better that everyone else work together to have a baseline of known good methods so that they can all get to use and innovation
> both at the edge and with new uses. Robotic / drone operating systems are following a similar trajectory. I don't know of a term
> for this yet. Let's call it a Shared Research Market.
> If you are Oracle or whoever who can buy and otherwise lock up the best techniques and then leverage them into high-end sales,
> that's great for you. And in some cases, that might be the best thing to happen, providing a necessary level of funding and
> stability for something important and widely needed. In other cases, people and organizations just don't have to go along because
> there may be enough energy to share a solution for something that is a commodity or shared research market. This is one of the
> big types of struggles in the market right now in a number of areas.
>> Databases are possibly the perfect counter-example. Most of the commercial closed source databases are forks of open source
>> databases *and* they consistently stay ahead of capabilities, features, and performance of open source as a group while retaining
>> some semblance of compatibility.
> Most use of databases, by count, are completely run of the mill commodity use. A few cases need extreme efficiency or exotic
>> The dynamic is simple:
>> The open source software community, as a whole, does not think about TCO and will readily throw TCO under the bus in support of
>> other priorities. The gap between the TCO typical of open source and the TCO that is possible for a competent reimplementation is
>> so large even if there are no license costs, combined with being able to hide the differences in implementation in the cloud, has
>> given companies a way to make big margins off open source software, albeit indirectly, that they haven’t seen since the days of
>> enterprise license sales.
> Yes, for a few cases.
> FoRK mailing list
Stephen D. Williams sdw at lig.net stephendwilliams at gmail.com LinkedIn: http://sdw.st/in
V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407
AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres
Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer
More information about the FoRK