Indie Manufacturing

Final Indie Manufacturing Report Published

Sun, 16 Aug 2020 00:00:00 -0500

At the start of 2017, Andy and I finished writing up our research for the Indie Manufacturing project.

We’d planned to tidy up the website and publish the report there for anyone to read, but other things got in the way and that got lost down the to-do list.

We’ve shared the report with anyone who asked about it in the intervening period, and reminded by this tweet from Hannah (who commissioned the work), I’ve found the time to wrap things up.

Rereading the Indie Manufacturing report for the Future Makespaces RDM work led by @amcewen - kinda shocked and impressed at how current it still feels, the tectonic plates still haven't quite shifted even though the landscape has different players now https://t.co/2xTbHqGhhW )
— ¯\_(ツ)_/¯ (Hannah) (@Freerange_Inc) July 28, 2020

This post is mostly for anyone who still has the RSS feed in their feed reader, to let you know that you can now read the final Indie Manufacturing research report.

A Brief Critique of Ship-Bits-Not-Atoms

Sun, 27 Nov 2016 00:00:00 -0600

Prompted by a mixture of thinking about the wider research that the Indie Manufacturing project falls under, the recent Maker Assembly, and yesterday’s celebration of 40 years since the Lucas Plan, I’ve been pondering the idea that we should aim to “ship bits, not atoms”.

It’s a nice concept. Rather than transport physical goods round the world from centralised factories we should send the instructions on how to make the goods over our digital networks to the place (or a place much nearer to) where the good is needed, and only “convert” it into physical form close to where it will be used. That way we minimize the transport cost - usually the environmental cost reduction is more important than the monetary cost, but you would reduce both. There could also be savings in waste - because goods are only realised as tangible items when they’re wanted, and so there’s no oversupply; and you might also reduce warehousing costs as there’s no longer a need to keep stocks of product spread out geographically in order to keep delivery times short.

For certain classes of product it works. Opendesk is a good example. The furniture is constructed from commodity, well-understood materials and the assembly process is reasonably straightforward. The customer can easily see the quality of the wood their desk will be made from (and there are established industry grading systems) and most customers probably have the requisite skills to build one from years of experience assembling Ikea furniture.

For more complex products, such as consumer electronics, the advantages of just-in-time individual assembly are less clear. Electronic circuits are made from a much larger range of source components and although you can encourage designs to pick from a stock library of parts, there will always be one or two parts which are specifc to that one device. Plus electronic components get cheaper pretty quickly as the purchased quantity rises. And assembly is also more complex - both in the tools required and in documenting the steps involved in building the finished item.

In these cases, I can see three possible futures playing out:

The master craftsperson. In this version there are networks of craftspeople who have the requisite skills to produce a well-polished finished product the first time that they make one. They’ll have the plans and instructions to assist them, naturally, but they’ll need the attention to detail and conceptual skills to realise how the instructions translate into actions in order for the item to come together in the way the designer intended.
Lots of “good enough” or “not quite good enough but we can live with it” products being made. Where the workshops manufacturing these haven’t made enough of them to learn the tricks in putting them together properly, and so end up making things that work, but the fit-and-finish leaves a lot to be desired.
The completely de-skilled assembler, who can’t fail to assemble the product successfully.

I assume anyone proposing the completely distributed factory of the future is aiming for either the first or the third of those.

The first is very appealing but will surely result in expensive products. It feels like an updated version of the Arts and Crafts movement. William Morris with a 3D printer…

My guess is that most people think that the third is the most likely (or the best compromise between achieveable and desirable). In the ideal world the assembler would own their own manufacturing equipment, so while it’s not necessarily taxing work, there’s more variety in what’s produced and they get to profit from the output of the machines.

I think this does a great disservice to the tacit knowledge accumulated by the workers as they go about their tasks. I remember a conversation with one of the members of DoES Liverpool, who worked in the Halewood plant of Ford (and then Jaguar Land Rover) his entire career (while desiging and building CNC mills in his shed in his spare time). We were discussing workers moving between different jobs in the workshop in order, I proposed, to make things more varied and so less boring.

While agreeing that was true, he countered that such an approach would noticeably slow down their work-rate and they’d much rather stick with the particular machine with which they had the greatest expertise. They all knew how to use the different tools, but would have particular aptitude or just a finely-tuned familiarity with that particular instance of the tool as to be much more productive on it than their colleagues.

I’ve experienced it myself. As you become more experienced with the tools in the workshop, even on such “hands off” items as a 3D printer, you’ll be able to tell just from the sound it makes when something isn’t right. Or you’ll spot that the filament isn’t quite extruding smoothly and tweak the temperature, or nudge the bed to minutely raise or lower it in order to get the first layer to properly adhere.

The tools will get better and better (particularly when the people operating them have the skills to modify and improve them), but it will remain the case that the hundredth item you make of any product will be better than the first.

The fully-automated replicator is an alluring dream, but it feels as though it comes from a naivete about working with materials and the real world. The pursuit of that dream has undoubtedly moved our technological capabilities on immensely, but does the aim of replacing the workers blind us to the greater possibilities of augmenting their abilities?

Fieldnotes for 2016-10-12

Thu, 20 Oct 2016 00:00:00 -0500

To give a flavour of what we're up to, we'll be tweeting and instagramming notes and points of interest as we go. Then each week we'll collect them together and post them here on the blog.

These are our fieldnotes from the past seven days.

Things of Note

Adrian McEwen: Awesome chat with Elizabeth Corbin just now plotting my talk at Maker Assembly next month #making #scale #people #networks #indiemfg
Adrian McEwen: Added SIC code 26400 Manufacture of consumer electronics to MCQN Ltd's filing at Companies House (to help researchers) #indiemfg #weeknotes

Lessons In Mapping

Mon, 17 Oct 2016 00:00:00 -0500

We’ve already written about why we wanted to map suppliers, factories and making facilities and also covered the way we’re gathering the data and how we’re storing it in Open Street Map.

Collecting the data is only half the story. What do we do with it once it’s gathered? How can people use it? How can we share it to make that easier?

We chose to use Open Street Map to store the data in part because that gives us access to a raft of existing tools and guides to use the information collected. Some of the things we’re mapping—particularly the trade counters, but also some of the factories and machine shops—will show up in the standard rendering on the Open Street Map website, but many of them are too specialist to be displayed (including all the data in Open Street Map on the standard map would make it far too crowded!)

That extra detail is still available, you just need to know how to find it.

Querying the Data

One of the easiest and most powerful tools for querying the OSM dataset is Overpass Turbo. It lets you run queries to retrieve different datasets, which can then be displayed on a map or returned as JSON-formatted text. You have to write the queries in the Overpass Query Language, but it’s not too complicated to get to grips with. There is a wizard built into the Overpass Turbo website to help with simple queries and for more complicated work the API/Lanugage Guide is a good place to start. We also created a few example queries to pull out the Indie Manufacturing data which we shared at the end of that blog post.

The Indie Manufacturing Map

To save people having to query the data themselves, we also built an Indie Manufacturing map page on this site. It took a couple of iterations to get to the map you see now which, although there are things we’d like to improve (we’ll return to that), was something we’re happy with as a starting point.

Given that indie.mcqn.com is built with Jekyll I started out with the jekyll-mapping plugin.

It was nice and easy to get up and running, but seems a bit more focused on linking to individual posts on the site which have an associated location. That’s to be expected, and wasn’t a deal-breaker—I extended the code to pull in the list of markers from the Jekyll data folder. However, that was what sent me looking for an alternate approach. If your dataset isn’t too big then this approach would be fine (and was for the current makerspace, machine shop, and factory sets); but there are a lot of trade counters in Open Street Map already, and just to cover the UK would mean processing half a MB of data each time the map was loaded, which made the map rather slow to render.

In looking for other solutions I came across a couple of helpful blog posts from Mappa Mercia (the West Midlands OSM community). They explain how to use uMap to build the map (http://www.openstreetmap.org/user/ybon/diary/23611 gives a good overview of uMap’s capabilities), and then how to tie it into Overpass Turbo to query the dataset on demand.

That would be the ideal solution: the data being displayed would always be up to date, and by only requesting the data for the area of map being viewed it would keep the load on the servers to a minimum. However, in practice the queries to Overpass Turbo take too long to complete, often resulting in error messages and a poorly populated map.

We ended up with a mixture of those two approaches.

For the smaller datasets—the makerspaces/fablabs/etc.; factories; and machine shops—I set up a script which runs periodically to query Overpass Turbo and download the latest information to a file on the Indie Manufacturing server. That’s used to populate those layers on the map (built with uMap), so the data loads quickly at the expense of being a bit stale at times; however, it doesn’t change quickly enough for an update frequency of every-few-hours to be a problem.

The trade counter data, which is much more widely used and therefore a much bigger dataset, is turned off by default (otherwise it would tend to throw an error message at the user when they arrived at the map). It is hooked up to query Overpass Turbo in real time, and just download the relevant data for the geographic area the user is looking at.

For bigger areas (anything beyond a single city, in practice) when it’s turned on the trade counter queries will tend to time out before they’ve gathered that data. If you only want to find the trade counters near to you, however, that’s usually a small enough data set that it will work. Not ideal, but we thought it was an acceptable compromise.

Which brings us to…

Making Things Better

How might we improve things? Both for the Indie Manufacturing map and for anyone else wanting to use maps to help their community.

Easier Submission of Data

By far the biggest challenge for the Indie Manufacturing map was getting people to contribute data. Everyone is busy and the time required (or perceived time required) to learn how to use a new system is too great a barrier to share what you know.

The New Cloud Atlas editor that Tim Waters built is a good example of how it’s possible to modify the standard OSM editor tools to suit a particular subset of mapping. However, that requires pretty good OSM developer chops to deploy at present. Making that easier would be good.

Even simpler could be an online form that lets someone find an existing item on OSM or easily add a new point to it, and then provide a set of useful tags - ideally hidden behind friendlier descriptions provided by the map-maker.

I think either of those approaches would need to find a way round the requirement for an OSM account, if they’re to achieve making it easy to contribute. That runs slap bang into the OSM community’s (completely valid) concerns about data provenance.

Maybe any of those submissions could include some sort of data source tag—which seems a well-established convention in OSM for bulk imports—so that consumers of the data would be able to make decisions on how much to trust the information.

It would also be useful to build more tools to help people with a foot in each of those communities. For example, here I’m both a member of the maker community wanting to map making facilities and the OSM community.

An ability to monitor all the changes which include a certain set of tags would let me keep an eye on what was being contributed, and then intervene and fix up the data or ask further questions if I spot anything amiss. I’m surprised that this doesn’t already exist, but I’ve failed to find it if it does.

If allowing semi-anonymous contributions is too risky for OSM then some sort of approval queue could help. That makes the list of curators of submissions a potential bottle-neck, but being able to run through submissions choosing from “approve”, “deny” and “push to ‘needs more detailed checking’ queue” could be good enough.

Better Maps

On the display side, uMap and Overpass Turbo are already 90% of the way there and it would be good to find ways to help those projects.

Any project looking to fund building a similar map system might find that spending some of the money on more kit for Overpass Turbo is a better investment (for all of us).

However, there are many situations where we don’t need right-up-to-the-minute data and occasional queries to Overpass Turbo which are then cached would reduce load on their servers with negligible impact on the viewers experience.

We’ve shown that for small datasets that’s already possible.

A caching service could be built to slurp in data from Overpass Turbo and then serve it out again to uMap using the same query syntax that’s used to connect the two of them together at present. That would allow the map-maker to insert the small caching server as a shim between the two services, reducing the load on Overpass Turbo and providing data more quickly to uMap as there’d be less of it to sift through in response to a query.

Even nicer would be if the remote data syntax used by uMap was extended to allow something like tile-boundary tags as well as the existing {south}, {west}, {north}, {east}. That would let the map-maker create a set of static files with the data in, much like tilesets are generated at present, thus removing the need to run a database or a particular web language on your server. You’d be able to run a script to query Overpass Turbo and generate a bunch of JSON files to then upload whenever you wanted to update the map. Obviously, more advanced users could set up a cron job on the server to similarly run the update there to automate things.

That would solve getting the data into uMap for it to show. There are a couple of improvements that would make the display even better.

uMap has a template system which lets you use some of that data imported from Open Street Map (or wherever) to populate the pop-up when the viewer clicks on a marker. We use that to show the name and website of the firm, plus some details of the materials they use and such-like from the OSM tags.

That works well, but results in text like “print_shop” rather than “print shop” as it’s just using the content of the OSM tag. If there was a way to conditionally include bits of templates (so we could add a heading of “Materials”, for example, but only if that tag was present) and also provide a set of mappings to let us define more user-friendly names, that would make the maps even slicker.

Finally, and this might be beyond a general solution like uMap (or at least, I’ve not got an easy suggestion of how to implement it…), maps such as the Indie Manufacturing map would be much improved if the viewer could easily filter the results shown.

Coarse-grained filtering can be done by putting the different sets of data onto different layers, as we’ve done with the factories vs. machine shops, etc. However, that doesn’t let the user drill into the data on a single layer. For the Indie Manufacturing map it would be really useful if you could limit the list of machine shops to just the ones offering laser-cutting, for example. That information is held in the tags, so you’d need some way to be able to tell the map interface which tags can be filtered and then choose values or provide a text box to enter the search terms.

The Open Street Map tools make all sorts of mapping activities lots easier. With the addition of a few more pieces it could form an even better toolkit for many more communities of interest.

2016-10-13 Indie Manufacturing Links

Thu, 13 Oct 2016 00:00:00 -0500

A collection of things that we've encountered over the past week that we think might be of interest...

The Fundamentals of Hardware Assembly Design | Fictiv - Hardware Guide Some useful tips on what to keep an eye on when going from prototype to manufacturing, and how the steps to assemble your product can impact the cost of it.
tags: DfM DfA hardware indiemfg
Preparing Your Product For The FCC | Hackaday Good, if US-centric (obviously, as it's about the FCC), article with tips about what sort of certification your electronics product might need. The comments have some more tips and a bit about CE-mark for Europe too.
tags: hardware indiemfg certification testing wireless
Lessons in Small Scale Manufacturing From The Othermill Shop Floor | Hackaday The seven deadly sins of manufacturing waste. Lots of useful things to think about in your assembly process, with a particular slant towards small-scale batch production.
tags: indiemfg assembly DfM DfA

Indie Manufacturing, a Talk at OSHUG

Mon, 26 Sep 2016 00:00:00 -0500

At the 2016 Open Source Hardware Camp, part of the Wuthering Bytes technology festival, Adrian gave a talk about the Indie Manufacturing project.

Here are the slides, and notes on what he anticipated saying - they won't match the talk exactly. The talk was recorded - we'll update this when it's available online.

Hello, I'm Adrian McEwen. You may remember me from such OSHUG talks as (What is) The Internet of Things? (OSHCamp 2012) or Risking a Compuserve of Things (Wuthering Bytes 2013). It's lovely to be back.

I connect strange things to the Internet - for fun, as products for my company, and for others.

Most of this year, the biggest project I've worked on has combined all of those.

The Royal College of Art is doing research into how makerspaces, fablabs, etc. might feed into or enable new ways of manufacturing and organising manufacturing.

As part of that we’ve been looking at how the maker community can hook into local supply chains.

This is the blurb from the project website, so you don’t need to read all of it, but the two phrases at the top help me explain our approach.

The received wisdom is that you can’t make things in the UK – it’s fine for craft, handmade goods with a high cost, but beyond that you have to raise lots of money and go to China.

We wondered if there was a middle way. Are there smaller firms hidden away that can help us build things at a medium scale – 100s or 1000s of units rather than 10s of 1000s? Can we look to different materials and processes to help that?

I love this quote from Saarinen. It's something I think about in how we approach things at DoES Liverpool: a person inside a makerspace; a makerspace in a community; a community across a region...

How does the knowledge developed by the members of the makerspace get captured and shared to make the next person's job easier?

The makerspace allows people to pool resources to gain access to machinery that it doesn't make sense—or is too expensive—to own individually. And that lets someone build one or two of almost anything. What do the people who want to scale up to 100s or 1000s of items need? Does it make sense for the makerspace to provide that?

There's lots of information being built up in maker communities, and shared freely. But only if you know who to talk to, or who needed which production process in which of their projects.

Our maker bus ratio is a problem. If we can find ways to improve that, we'll get more resilience and help people find solutions to their problems faster to boot.

I don't scale. How do we encourage more of the connectors, the mavens?

So, what did we do?

We interviewed a number of people from the community who are going through the transition from maker-of-one-or-two-things to manufacturer.

They were each at a different stage, and generally each approaching it in a different way, so it was interesting to compare their experiences.

We have a couple more to publish, but the interviews are on the #IndieMfg website.

We also did some mapping - of suppliers, makerspaces, factories, and the like.

A combination of trawling round industrial estates and encouraging fellow makers to contribute the places they've used in their projects. From trade counters, to engineering companies who can CNC parts for you from metal, PCB manufacturers, die-cut box makers, and more.

When you talk to the people running these firms, they often tell you that they're happy to work with individuals and small companies.

However, it can actually mean that they're happy to work with you once you reach a certain scale. If you turn up wanting a run of 800 PCBs that's worth their while, but if you only want 50, say, then it doesn't make sense to reconfigure their production line.

To flush out these kinds of issues, we also wanted to get our hands dirty and actually run the process of making something ourselves.

So my company, MCQN Ltd, took one of its product ideas and is putting it through a(n initial) production run of a couple of hundred units. That would let us test these supplier assumptions and no doubt throw up other problems that we wouldn't think of.

The project officially finished at the end of July, so what have we found out?

Getting people to add to the map is tricky. Most people we spoke to had at least one supplier or company to add to the map, and were happy to share what they knew. However, the barrier—or just the perceived barrier—around adding it to Open Street Map was too great for nearly all of them.

The other method we used was trawling round industrial estates. That, in itself, is lots of work; there are lots of them and you don’t find out how good any of the firms you're adding to the map are. It can also be pretty intimidating—we joked that maybe we needed to include a "testosterone factor" in our mapping, to capture how approachable any of the firms or locations are.

If we were doing it again we’d spend more time trying to find what the community knows, as the first step. And most likely concentrate more on how to help the community supply that data more easily.

There were challenges on the software side of the mapping too.

Using Open Street Map as our datastore meant involving another community. That introduced an additional layer of negotiating to work out which tags to use, but will give us a better chance of longevity. I think with hindsight we were a bit too worried about getting things wrong, and so didn’t talk to them as broadly as we should.

And the tools to get data out of Open Street Map are almost there, but there are a few missing pieces. Overpass Turbo (which lets you query the data) and uMap (which lets you build maps) work really nicely together, but the performance isn’t there for it to "just work".

Once you start looking for firms in the UK who make things, you find them all over the place and making all sorts of things. They're just invisible to anyone outside their industry.

In theory that sort of information is captured by SIC codes. These are the industry classification codes that all limited companies declare to Companies House. However, in practice they're useless. As a company there's no indication at all of what they're for, so if you're anything like me then you'll have picked whatever seemed plausible when you first registered the company and then just skip the "do you want to change them" part of your company return each year, regardless of whether the company has moved into a new area.

This seems to be an open secret, but it's still the only tool that anyone trying to look at a bigger area—researchers, government departments, council support organisations, etc.—uses.

Making hardware takes a long time.

We had some discussion about what real project we should make and decided that an Internet of Things device would be best as that (a) plays to my strengths and (b) would let us attack some processes less common in small-volume products.

That was always going to be a stretch in a 6-month project. So, surprise, surprise, it’s not quite ready.

We've got a prototype, and a lot of the suppliers sorted out for obtaining the parts and doing the manufacturing. Still more things to tie down, but we've a good idea of the short-list at least for the remaining tasks.

One thing we've found through making an actual product is that, for off-the-shelf components, particularly the items of lower value, they aren’t made in the UK any more.

The ESP8266 module that’s the core of the product comes from China. I remember back when I was CTO of Goodnight Lamp (before that shifted to GSM for comms), we struggled to find WiFi modules for under £12/unit. And that was without a processor.

The ESP8266 modules, which have both WiFi and processor, are a couple of dollars in quantities of 1!

Similarly, we couldn’t find any bell manufacturers in the UK beyond the expensive, high-quality musical-instrument-grade bells.

Alibaba.com makes it easy to find worldwide suppliers now – it turns out for electronics that’s usually China, but for bells India seems to be the place to be. Alibaba makes it easy at the start, but there is still some complexity hidden behind that. They hook you with an easy search box, but there’s still a fair bit of back and forth in working out which supplier to use, and then you have a new world of shipping terms to get to grips with. And you might need to work out the world of freight-forwarders to get your parts shipped by sea.

Being able to swing factories into action, and kick off things being delivered to docks and put in containers and sent round the world to you, just from your browser and a few emails is amazing! But there are also times where visiting the factory or tapping into the knowledge and skills from a phonecall to the manufacturer are invaluable. Particularly if you need to customize anything.

Once you’ve got a map, then you can start.

Pick the most likely place to offer what you’re after and visit them. They’ll tell you who might really be able to do what you want. Go and visit those people.

Repeat.

The local enterprise partnership, “the council”, enterprise centres, etc. are all organisations that people assume will be able to help you find local partners and manufacturers.

Generally they can’t. They don’t have a list of all the companies on their patch - they make guesses from SIC codes and the like, and know some of the people who come and talk to them.

They want to help, but a combination of being encouraged to run at large scale generic solutions and not knowing how to talk to groups like makerspaces mean that the opportunities are often missed.

To mis-quote Steve Ballmer, it's all about people, people, people!

The best contacts and advice come from members of the community sharing their experiences and address books. We need to find ways to grow the community, infect more of business with our culture of openness and sharing, and help the people in support organisations who "get it". Find ways to expand the number of people in the network, not try to replace the people with software.

So, what next?

The end of the project isn't the end of the product. MCQN Ltd will be finishing off the remaining work to get the Ackers Bell on sale for all your bell-notifications-of-Internet-events needs.

Head to the Ackers Bell catalogue page on the website and sign up to the mailing list to be first to hear about further developments.

We also want the map to live beyond this project. Our intention was always that we'd just be seeding the dataset and then it would be up to the community to continue adding to it and extending it.

So if nothing else, people can add new places to Open Street Map and they'll appear on the map.

It would be good to find ways to make it easier for people to submit new items, and improve the information displayed—and the filtering—on the map. That will need some work on some of the Open Street Map tools, which I'd like to find time to do. There's no more funding in this project for that, so volunteers and/or funders who want to get in touch would be more than welcome.

And given that the rest of the site will become more of an archive of the project, we're not sure that the Indie Manufacturing website is the best place to hold the map for the future.

An obvious place, particularly for those of us in the North, would be the UK Maker Belt Association website.

If nothing else, we want more making, more manufacturing, and more sharing!

Thank you. Any questions?

Fieldnotes for 2016-08-10

Fri, 12 Aug 2016 00:00:00 -0500

To give a flavour of what we're up to, we'll be tweeting and instagramming notes and points of interest as we go. Then each week we'll collect them together and post them here on the blog.

These are our fieldnotes from the past seven days.

Things of Note

MCQN Ltd: Nice patterns in the reel of 650 #esp8266 modules #weeknotes #indiemfg #ibal169 pic.twitter.com/mcDmksNpnF
MCQN Ltd: And another 48 power supplies. #goingtoneedmorestorage #indiemfg #ibal169 pic.twitter.com/T5Dh57RlGj
MCQN Ltd: Boxes and boxes of solenoids #indiemfg #ibal169 pic.twitter.com/o5APw7GTI0

Fieldnotes for 2016-08-03

Fri, 12 Aug 2016 00:00:00 -0500

To give a flavour of what we're up to, we'll be tweeting and instagramming notes and points of interest as we go. Then each week we'll collect them together and post them here on the blog.

These are our fieldnotes from the past seven days.

Things of Note

MCQN Ltd: And so it begins. The first reels of components for http://mcqn/ibal169/ have arrived #indiemfg #weeknotes pic.twitter.com/W0iYVjRo6r
MCQN Ltd: MCQN Ltd Experiencing opposite ends of supply chain - these ordered & delivered in 1d; bells will take 25d to make, 4w to ship #indiemfg
MCQN Ltd: Yay! We're now EORI validated. We're not quite sure what that means, but it'll make importing parts easier/more HMRC-friendly :-) #indiemfg
MCQN Ltd: So, this is what 29 power supplies looks like. Another 171 to follow. #indiemfg #ibal169 pic.twitter.com/zdAovSUjJ8

2016-07-28 Indie Manufacturing Links

Thu, 28 Jul 2016 00:00:00 -0500

A collection of things that we've encountered over the past week that we think might be of interest...

A simple test to see if it's Open Source – MeArm Robotics An excellent rule-of-thumb to apply when looking at projects, platforms, products... which are shouting loudly about "open" to gain attention.
tags: indiemfg opensource testing
The L.E.D. Quandary: Why There’s No Such Thing as “Built to Last” - The New Yorker “What drives the throwaway culture? Well, often people want to have the newest and the latest,” he said. “But there are people who want to have the oldest and the best.” Not completely essential for Indie Manufacturing, but a good target to be trying to nudge the world round towards.
tags: indiemfg economics obsolescence longhaul lifetime

Fieldnotes for 2016-07-27

Thu, 28 Jul 2016 00:00:00 -0500

To give a flavour of what we're up to, we'll be tweeting and instagramming notes and points of interest as we go. Then each week we'll collect them together and post them here on the blog.

These are our fieldnotes from the past seven days.

Things of Note

Adrian McEwen: So, given #Liverpool is a port city, do any of my followers know any freight forwarders I can talk to? #importing #China #India #indiemfg
Adrian McEwen: I've sorted suppliers, now need to work out how to turn "FOB Shanghai" (at dock in China) into "I've got 100s of WiFi modules" :-) #indiemfg
Adrian McEwen: #indiemfg rule of thumb (admittedly from a freight forwarder): if you're shipping >50kg, a freight forwarder is a better option than courier
MCQN Ltd: Applying for EORI validation from HMRC ready for importing parts for our Internet-connected bell product mcqn.com/ibal169/ #indiemfg
Adrian McEwen: So if y'day was the day of payments to China (for electronics parts), today is the day of payments to India (for bells) #indiemfg #weeknotes