[FoRK] Microsoft gets a new religion: VisualStudio Core, aka Atom

Stephen D. Williams sdw at lig.net
Sun May 3 15:55:17 PDT 2015


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



More information about the FoRK mailing list