[Discuss] CAD software: where does OSHWA stand?
jean-marie.verdun at splitted-desktop.com
Sun Mar 19 16:32:26 UTC 2017
In some way I disagree on your vision. FOSS have been devloped against
proprietary software solutions, and the as a service is a thing, but the
key thing to me is to be able to understand the physics behind the
physical object we tend to produce by doing open hardware as well as the
industrial process we could put in place. Designing FOSS solutions means
that some part of the Open Hardware community people understand this
deep scientific issues. As an example on FreeCAD, I do work (when my
times allow me) on the Fem workbench and improving it, as to get a good
understanding of the physical phenomena that could appears within a
computer when it is heating up.
If we use proprietary tools, or even as a service platform we can face
challenges to understand what's going on or rely on proprietary stack
which avoid how to properly transfer knowledge to next generation.
There is a full business model to setup behind FOSS, as we can see, but
that should be doable. When you design a system the most challenging
part is not into the design (I don't think so), but more in
understanding the physic involved and the way you can understand it.
Designing a car as a an example requires understanding CFD if we wish to
improve the design etc ...
From a control perspective, and the aaS approach I do believe this is
where non profit foundation should be efficient, as to ensure the
openness of the data they will get access to if they drive the aaS
platform. We do have proposed to the OCP foundation to take the control
of the ohub platform, as we do know that the company who will control it
will have a very strong power on open hardware. One of the option for
the aaS is to provide open file format, like we do with FreeCAD and
KiCAD to the private company (like github) and keep a local copy, which
is also a good tradeoff, as the data will be always available for somebody.
Now I agree with you we do not have the critical size to compete with
proprietary tools, (FreeCAD is a matter of about +30 active people), we
need more people to code, but this is a chicken and egg issue.
Le 19/03/2017 à 16:43, Malcolm Stanley a écrit :
> 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
> 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
> (opinions may vary on some of this, I get it, I’m making a high level
> 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
> - 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.
> On Mar 19, 2017, at 09:35, phillip torrone <pt at adafruit.com
> <mailto: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.
> right now the most prolific makers in oshw generally seem to use:
> online tools?
> the biggest that we seem to hear is forced cloud storage and "software
> as a service" is not desirable.
>> On Mar 19, 2017, at 8:43 AM, Javier Serrano <Javier.Serrano at cern.ch>
>> 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.
>> discuss mailing list
>> discuss at lists.oshwa.org
> discuss mailing list
> discuss at lists.oshwa.org
> discuss mailing list
> discuss at lists.oshwa.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the discuss