[Discuss] CAD software: where does OSHWA stand?

Sun Mar 19 15:43:17 UTC 2017

Phil just said something really important.
Let’s all not just ignore it:

	the biggest that we seem to hear is forced cloud storage and "software as a service" is not desirable.

I live in this world.
Let me try to unpack this.
Please be kind if I get some of the FOSS side of the discussion wrong.
Sorry to be so wordy in the explanation.

Used to be that the biggest single user-visible difference between FOSS and commercial offerings was license:
the delivery cadence was somewhat similar and in some cases better on the FOSS side, 
the teams were organized somewhat similarly from a  work assignment perspective, 
and the mechanics of downloading/installing/using a software product were somewhat similiar: 
there was an install process, and a thing to be installed, and you did that once or twice a year, and otherwise nothing much would change in between.
(opinions may vary on some of this, I get it, I’m making a high level point).

Now, commercially the trend in MANY areas is toward Agile delivery cycles on two (or six or n) week sprint cycles with continuous integration and delivery of new features on a real-time or semi-realtime basis.
This continuous delivery of value is used to justify subscription fees instead of perpetual license fees; Cloud hosted ‘as a service’ models also contribute.
it is a huge break with traditional business models and is very disruptive of capital budgets as access to software becomes a monthly operating expense. 
'As a service' offerings also threaten IT jobs as well, as management of installations becomes a vendor responsibility and the IT guys who run the servers and manage updates are made redundant.
The goal, of course, by the vendors, is recurring revenue. 

FOSS value propositions were originally developed in a world where SW was installed on a local machine and could work independently or at least semi-independently of any external infrastructure or systems.
In commercial world, you paid once, and got something to install, on your machine, in your datacenter, which you operated.. 
In FOSS world, a functionally similiar artifact was free, with differing support assumptions.

The current aaS subscription models do not work like that:
managed service, cloud hosting, and ci/cd-updated client models are sort of semi-network computer implementations where a large portion of the delivered value is derived from proprietary infrastructure and processes upon which the proper operation of the software ’service’ is dependent, coupled with a ‘service’ offering which makes continuous the relationship between vendor and customer.
It is a fast cadence, tightly coupled feedback loop environment where bug Tuesday has become deployment Tuesday and the installed product gets upgraded automatically every two weeks.
In companies which do this you often see large scale SW teams working in Agile delivery, with large amounts of supporting back end infrastructure and operations teams to manage it, 
so a cost heavy model which only recurring revenue can support.

This is fundamentally a new business model for delivery of software based value. 

ok, so what does that mean for FOSS?

if value propositions are wrapped in aaS / managed service offerings, it will be difficult to replicate them in FOSS offerings because by definition there are operational costs to those offerings that FOSS business models will not support. 
As Phil identified above, a market segment will become available, possibly significant in size, where companies continue to wish to make one time installations on local equipment and are looking for software to install. 
This decision may be economic (lack of monthly budget) OR may be for other reasons (some people don’t want to be dependent upon or limited in their freedoms by others).
Companies like Autodesk are abandoning this segment as they seek the recurring revenue that managed aaS provides,
but toying with fee models which achieve lock in while allowing extended trial and initial low cost use. 

The challenges in gaining acceptance in this segment will be in making the argument that:
 - the FOSS ‘installable’ option is functionally capable, as discussed here, 
 - the perceived pace of innovation of the FOSS development team will be sufficient to meet any future perceived needs in a reasonable time frame. For relatively static challenges, this may not be an issue. For more dynamic environments, it may be less possible.
 - the infrastructure you need to enable productive use is not so costly and time consuming to manage that it impairs the value proposition of the FOSS offering. This clearly includes indirect things like team management and file sharing and other things that teams need access to to work productively, which are being aggressively embedded in managed service offerings.

Some interesting questi0ns for the community arise:
 - if you write an open source client to the (for instance) autodesk cloud offering using their published API, is that a FOSS offering? 
 - what if you started that way and then started replacing bits of their dependencies with functional equivalents of your own? at what point is the offering considered FOSS?
 - can an operations-based model ever be FOSS?

I’ll stop here. 
it’s a complex world we live in. 
FOSS model was a reaction to an emergent commercial business model, opposing a structure of activity which had many drawbacks.
Now it feels like there is a new structure of activity emerging, and the reaction to it may need to be very different from traditional FOSS offerings to be appropriate to open source goals and objectives. 
Something to think about.

/malcolm

On Mar 19, 2017, at 09:35, phillip torrone <pt at adafruit.com> wrote:

ideally oshwa(?) could work up an ideal list of things CAD makers could do to support open-source hardware makers, this way we'd collectively have a voice when asked "what can EAGLE/AUTODESK/ALTIUM, etc" do to support oshw makers.

either way, send anything my way, i'll ask on tuesday to altium.

https://blog.adafruit.com/2017/03/15/interview-with-altium-32117-430pm-et-altium-adafruit-adafruit/

right now the most prolific makers in oshw generally seem to use:
	EAGLE
	KiCad
	Altium
	Frtizing?
	online tools?

the biggest that we seem to hear is forced cloud storage and "software as a service" is not desirable.

cheers,
pt

> On Mar 19, 2017, at 8:43 AM, Javier Serrano <Javier.Serrano at cern.ch> wrote:
> 
> Thanks Alicia!
> 
> On 03/18/2017 09:54 PM, alicia wrote:
>> Yes, OSHWA stands by this clause.
>> 
>> "Ideally, your open-source hardware project would be designed using a
>> free and open-source software application, to maximize the ability of
>> others to view and edit it. For better or worse however, hardware design
>> files are often created in proprietary programs and stored in
>> proprietary formats."
> 
> Yes, of course, I read this in the OSHWA website and I even quoted it in
> my original message. The question I was asking is rather:
> 
> On 03/17/2017 10:52 AM, Javier Serrano wrote:
>> Happily for software developers, those days are
>> long gone. Is such a state of affairs acknowledged as desirable by
>> OSHWA, and is OSHWA willing to be more than a spectator in this regard?
> 
> I take it the answer is that OSHWA currently has no plans to take an
> active role in the promotion/endorsement/support of FOSS tools for OSHW
> development. Is this correct? If it is, I'd like to advocate for a
> change in that regard, but before I do so I would need to know what
> exactly is the current position of OSHWA management on this. The
> paragraph you quote seems a bit vague to me. Also, is this list the
> appropriate place for such advocacy? If there is a better channel I will
> be happy to use it.
> 
> On 03/19/2017 02:58 AM, Rick Altherr wrote:
> 
>> I know my employer pays huge licensing fees for CAD software. There is
>> certainly an economic incentive to using FOSS. I'm working with others
>> in the cloud/server industry to move toward using FOSS tools for open
>> hardware designs. With my employer's CAD team, I'm hearing mostly
>> resistance to change, concern the tools can't actually complete the
>> design and that is an unacceptable risk.  I'm eager to work with anyone
>> who has interest or ideas on how to convince big companies FOSS is a
>> viable alternative.
> 
> Thanks Rick. From the sounds of it, you deal with quite complex designs.
> To be fully clear, when I talked about big OSHW companies I was thinking
> about Sparkfun, Adafruit, Arduino... Current FOSS tools can easily cope
> with the complexity of their designs. The understandable inertia of
> designers to keep using the same tools would be a more plausible
> explanation, I think, in their case. Plus the investment in know-how and
> libraries, which is far from negligible. I may be completely wrong
> though. I'd be very interested in reading their take on this. As I see
> it today, these companies have little incentive to migrate because,
> among other things, "For better or worse however, hardware design files
> are often created in proprietary programs and stored in proprietary
> formats." But it would be great for FOSS projects if they did migrate,
> because FOSS tools will become much better if more people use them and
> provide feedback and other types of support.
> 
> Regarding your particular case, I have always thought that licensing
> costs are not a very strong argument, especially for complex products
> like yours. Even if high, they typically get dwarfed by engineering
> costs, and good tools more than pay for themselves in time savings of
> designers. Besides, that might reinforce the misled belief that FOSS
> developers should not be paid for their work. As we have seen in the
> software world, a sustainable ecosystem is most often fuelled by paid
> developers. For both complex and simple designs, I think the stronger
> reason to use FOSS tools is that they allow sharing and collaborating
> without any artificial and unnecessary hurdles, which is one of the
> tenets of OSHW. So the big decision should be whether to do OSHW or not,
> and once one has decided to do OSHW, I think the goal of doing it with
> FOSS tools, or at the very least with file formats which are openly and
> completely documented, should be a natural one.
> 
> Cheers,
> 
> Javier
> _______________________________________________
> discuss mailing list
> discuss at lists.oshwa.org
> http://lists.oshwa.org/listinfo/discuss

_______________________________________________
discuss mailing list
discuss at lists.oshwa.org
http://lists.oshwa.org/listinfo/discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.oshwa.org/pipermail/discuss/attachments/20170319/de8845ac/attachment-0001.html>