Drew,
I felt that I had to comment on your article about open hardware, having
discussed such matters several times on my own blog and also having a
peripheral involvement in some of the initiatives. I last seem to have touched
upon such issues in this article:
"Some thoughts about technological sustainability"
https://blogs.fsfe.org/pboddie/?p=2496
Although your views are obviously coloured by having put down your own money
for hardware that has not arrived (as I have indeed done on a couple of
occasions), I think that it would be unfair not to distinguish between EOMA68
and the DragonBox Pyra. Since I openly advocated supporting the former, you
might then be surprised to hear that it is the latter that perhaps needs a bit
more sympathy, in my opinion.
Certainly, Michael Mrozek not only put his own reputation and business on the
line when bailing out the OpenPandora effort, which descended into fiasco by
most accounts, but he has shown an incredible level of persistence in getting
the Pyra from concept to a delivered product, despite there being many
setbacks along the way. That he has to also run a viable business alongside
pursuing such a project makes me wonder where he gets all his energy. Of
course, the Pyra now has "old" hardware that is not great for desktop-style
computing, but this is more the fault of the unsustainable path of technology
(see above) than any particularly unfortunate choice made by Michael and his
associates.
Naturally, such protracted endeavours are frustrating to those who have put
down money, and one can always question whether those pursuing them are right
to bring a bunch of other people along for the ride. But Michael has been very
transparent about this particular journey and seems to have made it a point of
principle not to go back and hit everyone up for more money (or to find a
bunch of other people, sprinkle pixie dust over the offering, and then pump
them for even more money, thinking of one particular company not mentioned in
your article). Everyone (apart from a couple of career antagonists in the Pyra
forums) knows where they stand with the progress of the effort, even if such
transparency means that Michael has to be open about mistakes, mis-steps or
just plain bad luck.
Now, contrast that with EOMA68, where there was certainly a lot of
communication with potential customers before, during and immediately after
the crowdfunding campaign, which was in 2016. The following years had the
following approximate distribution of updates:
2016 - 43 updates
2017 - 13 updates
2018 - 9 updates
2019 - 7 updates
2020 - 3 updates
2021 - 0 updates
2022 - 0 updates (so far)
(https://www.crowdsupply.com/eoma68/micro-desktop/updates)
Many of these concerned quite separate topics such as actually designing 3D
printers, not simply getting things 3D-printed. One can debate whether such
tangential efforts were really productive activities or not. Indeed, one
fundamental difference between EOMA68 and the Pyra, which was presumably
prototyped using development boards (I wasn't following it then), was that
Luke Leighton showed off prototypes going into the EOMA68 campaign, which made
us believe that the campaign was largely a matter of getting the difficult
stuff made at scale. Where other board variants were being considered, there
was an appearance of straightforwardness about prototyping them and bringing
them to production readiness (thinking about the Ingenic-based boards where
Ingenic themselves appear to have been involved doing layout work). It was
only afterwards that it turned out that a lot of new work needed to be done.
Taking such project-related issues into consideration, I find your remark
about Crowd Supply being constructively involved in open hardware projects to
be overly hopeful. I asked Crowd Supply about how they can maintain their
supposedly excellent record of projects running to a satisfactory conclusion
in the light of stalled projects like EOMA68 and got a non-committal answer
that can probably only be interpreted in such a way that projects effectively
get to live forever, so they never actually fail. If you direct questions to
Crowd Supply about project status, they just forward them on to the "creator",
which in the case of EOMA68 is then thrown over the wall to Luke's associate
at ThinkPenguin. Luke is, of course, too busy getting tens or hundreds of
thousands of Euros in NLnet grants to design a SoC, initially RISC-V-based,
now POWER-based.
Of course, I understand that stalled or failed endeavours retain little appeal
to those who pursued them. It is a hallmark of crowdfunding that when
campaigns start to fail, those responsible disengage, communication decreases,
confidence diminishes and antagonism increases. This serves to feed a vicious
cycle, causing official communication to eventually cease and for everyone
else to get even more upset. Disregarding campaigns run by people who never
expected to be held accountable and just wanted funding to pursue their own
interests, such dynamics are merely the product of human nature and venues
that emphasise roles such as supplier and consumer.
It is perhaps this last point that we should consider most closely. Despite
many of us being advocates for collaborative endeavour, we seem to expect
people to give us open hardware as a result of a transaction. If successful,
things like crowdfunded projects are supposed to lead to greater commercial
success for the creators. But what happens if they fail? On the arm-netbook
mailing list where EOMA68 originated, Luke at times appeared to berate other
people for not stepping up and doing work that needed to be done for the
campaign "rewards" to be delivered. But why should they if the effort is
framed in a non-collaborative way? And if or when such efforts fail, what does
the customer or the community get from their involvement?
The fact is that open hardware endeavours appear to largely revolve around the
expertise of individuals who do not tend to cultivate the transfer of
knowledge and expertise to others. Such individuals may withdraw or disappear,
having had enough, leaving very little behind. Even if we might demand that
they turn over all the project artefacts to the community, it is not certain
that the community will have the ability to continue to pursue the effort or
to salvage something from it.
But it seems to me that without such minimal guarantees - things that genuine
investors in an initiative might have, as opposed to "backers" who have no
such rights - we will be perpetually stuck in a rut speculating on short-lived
efforts. Even if some of them do pay off, we stand only to receive products to
consume as opposed to accumulating capabilities that would allow us to
initiate, support and deliver open hardware projects more reliably.
Anyway, that was more than I had intended to write, so I hope some of it was
of interest.
Regards,
Paul
Aug 5, 2022 11:51:55 PM Paul Boddie <paul@boddie.org.uk>:
> Drew,
>
> I felt that I had to comment on your article about open hardware,
> having
> discussed such matters several times on my own blog and also having a
> peripheral involvement in some of the initiatives. I last seem to have
> touched
> upon such issues in this article:
>
> "Some thoughts about technological sustainability"
> https://blogs.fsfe.org/pboddie/?p=2496
>
> Although your views are obviously coloured by having put down your own
> money
> for hardware that has not arrived (as I have indeed done on a couple of
> occasions), I think that it would be unfair not to distinguish between
> EOMA68
> and the DragonBox Pyra. Since I openly advocated supporting the former,
> you
> might then be surprised to hear that it is the latter that perhaps
> needs a bit
> more sympathy, in my opinion.
>
> Certainly, Michael Mrozek not only put his own reputation and business
> on the
> line when bailing out the OpenPandora effort, which descended into
> fiasco by
> most accounts, but he has shown an incredible level of persistence in
> getting
> the Pyra from concept to a delivered product, despite there being many
> setbacks along the way. That he has to also run a viable business
> alongside
> pursuing such a project makes me wonder where he gets all his energy.
> Of
> course, the Pyra now has "old" hardware that is not great for
> desktop-style
> computing, but this is more the fault of the unsustainable path of
> technology
> (see above) than any particularly unfortunate choice made by Michael
> and his
> associates.
>
> Naturally, such protracted endeavours are frustrating to those who have
> put
> down money, and one can always question whether those pursuing them are
> right
> to bring a bunch of other people along for the ride. But Michael has
> been very
> transparent about this particular journey and seems to have made it a
> point of
> principle not to go back and hit everyone up for more money (or to find
> a
> bunch of other people, sprinkle pixie dust over the offering, and then
> pump
> them for even more money, thinking of one particular company not
> mentioned in
> your article). Everyone (apart from a couple of career antagonists in
> the Pyra
> forums) knows where they stand with the progress of the effort, even if
> such
> transparency means that Michael has to be open about mistakes,
> mis-steps or
> just plain bad luck.
>
> Now, contrast that with EOMA68, where there was certainly a lot of
> communication with potential customers before, during and immediately
> after
> the crowdfunding campaign, which was in 2016. The following years had
> the
> following approximate distribution of updates:
>
> 2016 - 43 updates
> 2017 - 13 updates
> 2018 - 9 updates
> 2019 - 7 updates
> 2020 - 3 updates
> 2021 - 0 updates
> 2022 - 0 updates (so far)
>
> (https://www.crowdsupply.com/eoma68/micro-desktop/updates)
>
> Many of these concerned quite separate topics such as actually
> designing 3D
> printers, not simply getting things 3D-printed. One can debate whether
> such
> tangential efforts were really productive activities or not. Indeed,
> one
> fundamental difference between EOMA68 and the Pyra, which was
> presumably
> prototyped using development boards (I wasn't following it then), was
> that
> Luke Leighton showed off prototypes going into the EOMA68 campaign,
> which made
> us believe that the campaign was largely a matter of getting the
> difficult
> stuff made at scale. Where other board variants were being considered,
> there
> was an appearance of straightforwardness about prototyping them and
> bringing
> them to production readiness (thinking about the Ingenic-based boards
> where
> Ingenic themselves appear to have been involved doing layout work). It
> was
> only afterwards that it turned out that a lot of new work needed to be
> done.
>
> Taking such project-related issues into consideration, I find your
> remark
> about Crowd Supply being constructively involved in open hardware
> projects to
> be overly hopeful. I asked Crowd Supply about how they can maintain
> their
> supposedly excellent record of projects running to a satisfactory
> conclusion
> in the light of stalled projects like EOMA68 and got a non-committal
> answer
> that can probably only be interpreted in such a way that projects
> effectively
> get to live forever, so they never actually fail. If you direct
> questions to
> Crowd Supply about project status, they just forward them on to the
> "creator",
> which in the case of EOMA68 is then thrown over the wall to Luke's
> associate
> at ThinkPenguin. Luke is, of course, too busy getting tens or hundreds
> of
> thousands of Euros in NLnet grants to design a SoC, initially
> RISC-V-based,
> now POWER-based.
>
> Of course, I understand that stalled or failed endeavours retain little
> appeal
> to those who pursued them. It is a hallmark of crowdfunding that when
> campaigns start to fail, those responsible disengage, communication
> decreases,
> confidence diminishes and antagonism increases. This serves to feed a
> vicious
> cycle, causing official communication to eventually cease and for
> everyone
> else to get even more upset. Disregarding campaigns run by people who
> never
> expected to be held accountable and just wanted funding to pursue their
> own
> interests, such dynamics are merely the product of human nature and
> venues
> that emphasise roles such as supplier and consumer.
>
> It is perhaps this last point that we should consider most closely.
> Despite
> many of us being advocates for collaborative endeavour, we seem to
> expect
> people to give us open hardware as a result of a transaction. If
> successful,
> things like crowdfunded projects are supposed to lead to greater
> commercial
> success for the creators. But what happens if they fail? On the
> arm-netbook
> mailing list where EOMA68 originated, Luke at times appeared to berate
> other
> people for not stepping up and doing work that needed to be done for
> the
> campaign "rewards" to be delivered. But why should they if the effort
> is
> framed in a non-collaborative way? And if or when such efforts fail,
> what does
> the customer or the community get from their involvement?
>
> The fact is that open hardware endeavours appear to largely revolve
> around the
> expertise of individuals who do not tend to cultivate the transfer of
> knowledge and expertise to others. Such individuals may withdraw or
> disappear,
> having had enough, leaving very little behind. Even if we might demand
> that
> they turn over all the project artefacts to the community, it is not
> certain
> that the community will have the ability to continue to pursue the
> effort or
> to salvage something from it.
>
> But it seems to me that without such minimal guarantees - things that
> genuine
> investors in an initiative might have, as opposed to "backers" who have
> no
> such rights - we will be perpetually stuck in a rut speculating on
> short-lived
> efforts. Even if some of them do pay off, we stand only to receive
> products to
> consume as opposed to accumulating capabilities that would allow us to
> initiate, support and deliver open hardware projects more reliably.
>
> Anyway, that was more than I had intended to write, so I hope some of
> it was
> of interest.
>
> Regards,
>
> Paul
Not related to your comment, but if you have a blog of something similar,
I recommend turning this email into a full post. This email is an
essay-length email.
--
Dang Hoang Tuan
https://tsk.bearblog.dev