[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.
>>> But editors, Javascript libraries, and similar need to be out there, not private versions hidden away in opaque cloud 
>>> infrastructure.
>> 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 
> features.
>> 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.
> sdw
> _______________________________________________
> FoRK mailing list
> http://xent.com/mailman/listinfo/fork

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 mailing list