<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Malcom,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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 ...<br>
<br>
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.<br>
<br>
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.<br>
<br>
vejmarie<br>
<br>
Le 19/03/2017 à 16:43, Malcolm Stanley a écrit :<br>
</div>
<blockquote
cite="mid:5D18B30C-F815-40D1-8B6B-191A925F6F11@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div class="">Phil just said something really important.</div>
<div class="">Let’s all not just ignore it:</div>
<div class=""><br class="">
</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><i
class="">the biggest that we seem to hear is forced cloud
storage and "software as a service" is not desirable.</i></div>
<div class=""><br class="">
</div>
<div class="">I live in this world.</div>
<div class="">Let me try to unpack this.</div>
<div class="">Please be kind if I get some of the FOSS side of the
discussion wrong.</div>
<div class="">Sorry to be so wordy in the explanation.</div>
<div class=""><br class="">
</div>
<div class="">Used to be that the biggest single user-visible
difference between FOSS and commercial offerings was license:</div>
<div class="">the delivery cadence was somewhat similar and in
some cases better on the FOSS side, </div>
<div class="">the teams were organized somewhat similarly from a
work assignment perspective, </div>
<div class="">and the mechanics of downloading/installing/using a
software product were somewhat similiar: </div>
<div class="">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.</div>
<div class="">(opinions may vary on some of this, I get it, I’m
making a high level point).</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class="">This continuous delivery of value is used to justify
subscription fees instead of perpetual license fees; Cloud
hosted ‘as a service’ models also contribute.</div>
<div class="">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. </div>
<div class="">'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.</div>
<div class="">The goal, of course, by the vendors, is recurring
revenue. </div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class="">In commercial world, you paid once, and got
something to install, on your machine, in your datacenter, which
you operated.. </div>
<div class="">In FOSS world, a functionally similiar artifact was
free, with differing support assumptions.</div>
<div class=""><br class="">
</div>
<div class="">The current aaS subscription models do not work like
that:</div>
<div class="">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.</div>
<div class="">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.</div>
<div class="">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, </div>
<div class="">so a cost heavy model which only recurring revenue
can support.</div>
<div class=""><br class="">
</div>
<div class="">This is fundamentally a new business model for
delivery of software based value. </div>
<div class=""><br class="">
</div>
<div class="">ok, so what does that mean for FOSS?</div>
<div class=""><br class="">
</div>
<div class="">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. </div>
<div class="">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. </div>
<div class="">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).</div>
<div class="">Companies like Autodesk are abandoning this segment
as they seek the recurring revenue that managed aaS provides,</div>
<div class="">but toying with fee models which achieve lock in
while allowing extended trial and initial low cost use. </div>
<div class=""><br class="">
</div>
<div class="">The challenges in gaining acceptance in this segment
will be in making the argument that:</div>
<div class=""> - the FOSS ‘installable’ option is functionally
capable, as discussed here, </div>
<div class=""> - 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.</div>
<div class=""> - 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.</div>
<div class=""><br class="">
</div>
<div class="">Some interesting questi0ns for the community arise:</div>
<div class=""> - if you write an open source client to the (for
instance) autodesk cloud offering using their published API, is
that a FOSS offering? </div>
<div class=""> - 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?</div>
<div class=""> - can an operations-based model ever be FOSS?</div>
<div class=""><br class="">
</div>
<div class="">I’ll stop here. </div>
<div class="">it’s a complex world we live in. </div>
<div class="">FOSS model was a reaction to an emergent commercial
business model, opposing a structure of activity which had many
drawbacks.</div>
<div class="">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. </div>
<div class="">Something to think about.</div>
<div class=""><br class="">
</div>
<div class="">/malcolm</div>
<div class=""><br class="">
</div>
<br class="">
<div>
<div class="">On Mar 19, 2017, at 09:35, phillip torrone <<a
moz-do-not-send="true" href="mailto:pt@adafruit.com"
class="">pt@adafruit.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">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.<br class="">
<br class="">
either way, send anything my way, i'll ask on tuesday to
altium.<br class="">
<br class="">
<a moz-do-not-send="true"
href="https://blog.adafruit.com/2017/03/15/interview-with-altium-32117-430pm-et-altium-adafruit-adafruit/"
class="">https://blog.adafruit.com/2017/03/15/interview-with-altium-32117-430pm-et-altium-adafruit-adafruit/</a><br
class="">
<br class="">
right now the most prolific makers in oshw generally seem to
use:<br class="">
<span class="Apple-tab-span" style="white-space:pre"> </span>EAGLE<br
class="">
<span class="Apple-tab-span" style="white-space:pre"> </span>KiCad<br
class="">
<span class="Apple-tab-span" style="white-space:pre"> </span>Altium<br
class="">
<span class="Apple-tab-span" style="white-space:pre"> </span>Frtizing?<br
class="">
<span class="Apple-tab-span" style="white-space:pre"> </span>online
tools?<br class="">
<br class="">
the biggest that we seem to hear is forced cloud storage and
"software as a service" is not desirable.<br class="">
<br class="">
cheers,<br class="">
pt<br class="">
<br class="">
<blockquote type="cite" class="">On Mar 19, 2017, at 8:43
AM, Javier Serrano <a class="moz-txt-link-rfc2396E" href="mailto:Javier.Serrano@cern.ch"><Javier.Serrano@cern.ch></a> wrote:<br
class="">
<br class="">
Thanks Alicia!<br class="">
<br class="">
On 03/18/2017 09:54 PM, alicia wrote:<br class="">
<blockquote type="cite" class="">Yes, OSHWA stands by this
clause.<br class="">
<br class="">
"Ideally, your open-source hardware project would be
designed using a<br class="">
free and open-source software application, to maximize
the ability of<br class="">
others to view and edit it. For better or worse however,
hardware design<br class="">
files are often created in proprietary programs and
stored in<br class="">
proprietary formats."<br class="">
</blockquote>
<br class="">
Yes, of course, I read this in the OSHWA website and I
even quoted it in<br class="">
my original message. The question I was asking is rather:<br
class="">
<br class="">
On 03/17/2017 10:52 AM, Javier Serrano wrote:<br class="">
<blockquote type="cite" class="">Happily for software
developers, those days are<br class="">
long gone. Is such a state of affairs acknowledged as
desirable by<br class="">
OSHWA, and is OSHWA willing to be more than a spectator
in this regard?<br class="">
</blockquote>
<br class="">
I take it the answer is that OSHWA currently has no plans
to take an<br class="">
active role in the promotion/endorsement/support of FOSS
tools for OSHW<br class="">
development. Is this correct? If it is, I'd like to
advocate for a<br class="">
change in that regard, but before I do so I would need to
know what<br class="">
exactly is the current position of OSHWA management on
this. The<br class="">
paragraph you quote seems a bit vague to me. Also, is this
list the<br class="">
appropriate place for such advocacy? If there is a better
channel I will<br class="">
be happy to use it.<br class="">
<br class="">
On 03/19/2017 02:58 AM, Rick Altherr wrote:<br class="">
<br class="">
<blockquote type="cite" class="">I know my employer pays
huge licensing fees for CAD software. There is<br
class="">
certainly an economic incentive to using FOSS. I'm
working with others<br class="">
in the cloud/server industry to move toward using FOSS
tools for open<br class="">
hardware designs. With my employer's CAD team, I'm
hearing mostly<br class="">
resistance to change, concern the tools can't actually
complete the<br class="">
design and that is an unacceptable risk. I'm eager to
work with anyone<br class="">
who has interest or ideas on how to convince big
companies FOSS is a<br class="">
viable alternative.<br class="">
</blockquote>
<br class="">
Thanks Rick. From the sounds of it, you deal with quite
complex designs.<br class="">
To be fully clear, when I talked about big OSHW companies
I was thinking<br class="">
about Sparkfun, Adafruit, Arduino... Current FOSS tools
can easily cope<br class="">
with the complexity of their designs. The understandable
inertia of<br class="">
designers to keep using the same tools would be a more
plausible<br class="">
explanation, I think, in their case. Plus the investment
in know-how and<br class="">
libraries, which is far from negligible. I may be
completely wrong<br class="">
though. I'd be very interested in reading their take on
this. As I see<br class="">
it today, these companies have little incentive to migrate
because,<br class="">
among other things, "For better or worse however, hardware
design files<br class="">
are often created in proprietary programs and stored in
proprietary<br class="">
formats." But it would be great for FOSS projects if they
did migrate,<br class="">
because FOSS tools will become much better if more people
use them and<br class="">
provide feedback and other types of support.<br class="">
<br class="">
Regarding your particular case, I have always thought that
licensing<br class="">
costs are not a very strong argument, especially for
complex products<br class="">
like yours. Even if high, they typically get dwarfed by
engineering<br class="">
costs, and good tools more than pay for themselves in time
savings of<br class="">
designers. Besides, that might reinforce the misled belief
that FOSS<br class="">
developers should not be paid for their work. As we have
seen in the<br class="">
software world, a sustainable ecosystem is most often
fuelled by paid<br class="">
developers. For both complex and simple designs, I think
the stronger<br class="">
reason to use FOSS tools is that they allow sharing and
collaborating<br class="">
without any artificial and unnecessary hurdles, which is
one of the<br class="">
tenets of OSHW. So the big decision should be whether to
do OSHW or not,<br class="">
and once one has decided to do OSHW, I think the goal of
doing it with<br class="">
FOSS tools, or at the very least with file formats which
are openly and<br class="">
completely documented, should be a natural one.<br
class="">
<br class="">
Cheers,<br class="">
<br class="">
Javier<br class="">
_______________________________________________<br
class="">
discuss mailing list<br class="">
<a class="moz-txt-link-abbreviated" href="mailto:discuss@lists.oshwa.org">discuss@lists.oshwa.org</a><br class="">
<a class="moz-txt-link-freetext" href="http://lists.oshwa.org/listinfo/discuss">http://lists.oshwa.org/listinfo/discuss</a><br class="">
</blockquote>
<br class="">
_______________________________________________<br class="">
discuss mailing list<br class="">
<a class="moz-txt-link-abbreviated" href="mailto:discuss@lists.oshwa.org">discuss@lists.oshwa.org</a><br class="">
<a class="moz-txt-link-freetext" href="http://lists.oshwa.org/listinfo/discuss">http://lists.oshwa.org/listinfo/discuss</a><br class="">
</div>
</div>
</div>
<br class="">
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:discuss@lists.oshwa.org">discuss@lists.oshwa.org</a>
<a class="moz-txt-link-freetext" href="http://lists.oshwa.org/listinfo/discuss">http://lists.oshwa.org/listinfo/discuss</a>
</pre>
</blockquote>
<br>
</body>
</html>