<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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 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 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 <Javier.Serrano@cern.ch> 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="">discuss@lists.oshwa.org<br class="">http://lists.oshwa.org/listinfo/discuss<br class=""></blockquote><br class="">_______________________________________________<br class="">discuss mailing list<br class="">discuss@lists.oshwa.org<br class="">http://lists.oshwa.org/listinfo/discuss<br class=""></div></div></div><br class=""></body></html>