I'm sorry to hear about your experiences. I find it hard enough to deal with pushy people who have mismatched expectations (and yes, I'm not proud of it but at times I have been an entitled user.) I don't think what you're describing is limited to open source software though. Any time you make yourself available to the general population you're going to attract the full spectrum of human behavior. I guess the trick is to not make your project a honeypot for the debilitating stuff.
> I've learned to draw much stricter boundaries.
Could you elaborate on what has worked for you?
I imagine people who work in customer service have strategies too.
After much back and forth with the community and the team internally, we can reveal a bit more of what's happening. Tindie transitioned to new ownership on April 14. Due to circumstances beyond the control of the new owners, the site was immediately put into maintenance mode.
Since then, the process of transitioning the site to new infrastructure and upgrading the aging codebase has been ongoing. The intention was, as I originally thought, to do this seamlessly with no downtime. However, once the site was put into maintenance mode and the transition happened. it was decided to take the time to work on the site and get things up to modern standards.
The new owners are genuinely excited about Tindie and what the platform can be. After a year or so on cruise control, we're finally going to make substantial investments in the platform and community -- something which in my humble opinion is long overdue.
# Timeframe
Again, I still don't have an exact timeframe for the completion of this work. I know that is what the community wants to know more than anything, and it's very frustrating that I can't satisfy your answers about that.
I know that the new tech team is working hard with the Supplyframe team to complete all the transition steps and ensure things are done properly.
# Who Am I?
I figured many of you already know me, but my name is Alexander Rowsell. I'm the editor of the Tindie Blog and the social media manager. I've been with Tindie for a few years, and I'll be around for the foreseeable future. I do embedded development work, but I also really enjoy writing about what the community is up to. It's always a blast to go through the newest listings on Tindie to see what people are creating!
I'll be honest with you, I was worried about Tindie over the last few months. I could see that the site needed attention from a professional dev team and was worried the site would break totally before that happened. Well, there has been downtime, but the upside is that the site will be refreshed and ready for the long term. Short-term pain for long-term stability -- that's where we're at.
I wanted to write a longer statement, and seeing as how the Tindie Blog itself is down I figured this was the next best thing. To verify this statement is actually from me, I've signed it with my GPG key - B5CFBEB4EE9FE813. You can verify this signature by getting the raw text of this post, and verifying the signature using GPG.
Generous interpretation - perhaps this is the default for posts on that site.
Less generous interpretation - definitely quite a weird way of posting something, including references to a GPG key, rather than some kind of pre-existing public social media account (which I'm assuming a social media manager would have) or a page on the Tindie domain.
It does not appear that Hackster.io have received responses to their inquiries made >5 days ago (I assume they would make a follow-up post if they did):
> Tindie, Supplyframe, and Siemens have been approached for comment. Rowsell's full statement was available on document sharing site PrivateBin at the time of writing, but was set to automatically delete in the next six days.
> Makers' marketplace Tindie has been down for over a week, following its acquisition from former owner Supplyframe by parties unknown — with claims that it is undergoing a major overhaul following a period of apparent neglect failing to fully placate its sellers.
> Rowsell's announcement has done little to placate buyers wondering if their payments have vanished into a black hole, and sellers who have been left unable to fulfill — or even view — orders and to withdraw their funds.
Ah yes, definitely the language of an organization that totally wants to communicate with candor.
Also zero information about the new owners other than the name of a shell corp associated with an existing "EETree" company in Jiangsu, China that gets (mis?)represented as “a Washington State company”. Much honest, such wow. Sure, there's technically an LLC in Washington, but that's like calling pre-2020 Google "a Bermuda company" (which, tbf, is what Google did to avoid taxes via their Irish ~~subsidiary~~ "parent" company).
And still no information, remarks, or even acknowledgement for all the tindie sellers who’ve been unable to withdraw their funds.
The address listed at https://ccfs.sos.wa.gov/ ( 1475 NW SWENSON CT, POULSBO, WA, 98370 ) is shown on Google Maps as just being a completely empty plot by 2026 aerial photography. There's no way a whole house was built in < 10 weeks and someone was actually living there on February 25, 2026 when that address became their legally official place to reach someone at the company.
It's probably illegal to list that as the address -- the whole point of having a "Registered Agent" for businesses is so that if someone needs to serve the business with legal papers (like Tindie sellers suing for not being able to access their funds) then there's an actual person at an actual place where legal documents can be legally served. If someone doesn't want to make their own address public or isn't actually located in the state, "renting" a proper registered agent only costs $125/year - it doesn't require much more than a glorified mail-forwarding service, they receive your documents, scan them, and email them to you and the courts are happy with that because the business officially got served. It's a bit hard to serve papers to an empty lot.
Not providing a real address where someone can be located is a pretty bad sign for how much this ownership intends to respect any US laws. It's also potentially in violation of RCW 23.95.405, .415, .605 and RCW 43.07.210 & RCW 40.16.030, with penalties up to 6 years of incarceration and/or $15,000 in fines, dissolution of the company, and (most relevant to anyone who can't withdraw their funds from Tindie) a loss of "limited liability" status making the owners/directors/officers personally responsible for anything the LLC owes to anyone.
On the plus side, this year is the first year since the 2023 incorporation that the mandatory annual report wasn't a delinquent filing.
The business has had 3 addresses filed for it since incorporation:
(2023-2024) Principal place of business (a townhome): 1605 S WASHINGTON ST STE A, SEATTLE, WA, 98144-3193, UNITED STATES
(2023-2025) Registered agent (a house with 3 boats): 23022 49TH A VE SE, BOTHELL, WA, 98021
(Effective Feb 25 2026) Registered agent (which was photographed in 2026 to be a completely barren residential plot): 1475 NW SWENSON CT, POULSBO, WA, 98370
Thanks, this is exactly the content I come here for. Apt handle :P
I am very not comfortable with the situation, as a seller. I mailed out the stuff that was paid for before the outage...but I don't think I'm mailing anything else until I can disburse.
Great read. A question: what is the status of this problem on other architectures such as ARM and RISC-V, would the analysis and solution be the same? e.g. does ARM have invariant TSC?
riscv has mtime. it is somewhat implementation defined, but it should be a single hardware timer shared by all harts. The Zicntr extension defines user space rdtime psuedo instruction to acesss it from userspace.
aarch64 has cntvct_el0 status register that can be read from userspace.
Excellent post. Two stand-out points are deskilling through abolition of apprenticeship (or equivalent progression through the rank and responsibility), and loss of institutional knowledge, especially tacit knowledge stored in individual people. These are people problems more than they are technology problems. Without continuity of process and practice stuff gets lost. Sometimes change really is progress, for example software safety and security practices have progressed over the past 50 years, but other times change is just churn, or choices driven by misaligned incentives which will bite later, as the article describes.
If you're interested in audio, PortAudio is an established project with a lot of users. I have no doubt that the docs could be improved. I know this because I wrote a large chunk of the docs and I am frequently impressed by the docs of other projects. I'm not sure what the best way to improve them would be (improve structure? replace missing content? presentation? unify doxygen docs, README, and website, something else?). You could make an impact by reviewing our docs and posting your review as a GitHub ticket with a prioritised list of low-effort, low-churn, high-impact improvements. Even better if you submit some PRs. At the moment us maintainers have to allocate most of our limited time to maintenance.
I'd also like to make a general comment about "making an impact" on open source projects. There are many ways to help out on an open source project, but one good way is to maximise the benefit:maintainer-cost ratio. Maintainer cost comes in a number of forms: cognitive and time cost of reviewing PRs, engaging in design discussions, iterating on PRs, coordinating a "live" work in progress PR for long periods of time, you get the idea. With this in mind, I like it when the contributor owns the PR from submission to merge, don't just make the PR, help the maintainers get it over the line however is needed. A lot can be done by simply submitting PRs that follow project guidelines and established conventions, are targeted at a single improvement, making them uncomplicated, quick and easy to review, and most importantly such obvious improvements that there is no question about merging the change. A pet peeve of mine is PRs that include one excellent insta-merge change and an unrelated change that is controversial or requires significant rework. Keep PRs orthogonal, atomic, simple. It might be more work for you but if you are available to contribute you are not the time-poor party.
I'm not sure what all of the hazards are, but I could imagine a language (or a policy) where public APIs ship with all of the inline fix directives packaged as robust transactions (some kind of "API-version usage diffs"). When the client pulls the new API version they are required to run the update transaction against their usage as part of the validation process. The catch being that this will only work if the fix is entirely semantically equivalent, which is sometimes hard to guarantee. The benefits would be huge in terms of allowing projects to refine APIs and fix bad design decisions early rather than waiting or never fixing things "because too many people already depend on the current interface".
When I first started working with dataflow computation I was fortunate to have a computer scientist point me in the direction of an introductory compiler textbook.
It's worth considering that the dataflow graph (as an abstract mathematical graph), the computation graph (the partial order of function execution required to compute the data), the traversal strategy, the runtime representation of the graph, the runtime data structure for the graph, and the runtime data structures for efficient reactive update are all separate but related aspects.
For instance, push and pull are both directed graphs. They have the same connectivity, but the direction of the arrows is reversed. You can only efficiently traverse edges in the direction that you represent. A dataflow graph has edges pointing from sources to sinks, a data dependency graph has edges pointing from sinks to sources. [Side note: if a computation can produce multiple results the data dependency graph and the computation dependency graph are not exactly the same thing and you need to be clear on the distinction, but I am assuming here single-output nodes]. In a dataflow graph you want to evaluate the changed nodes prior to evaluating the downstream nodes that depend on them. As TFA states, this necessitates a postorder (children first) traversal of the data dependency graph, starting at all terminal sinks, and terminating at sources or already visited nodes. You can use a sense-reversing "visited" flag on each node to avoid a reset pass. As noted in the article this traversal need only be performed when the graph topology changes. But for stable traversal order the topological sort can be cached in an array. Needless to say that arrays are much faster to iterate over than any kind of pointer chasing. [Witness the rise of Entity-Component systems over OO models]. I suspect that there is a cut-over point where it is more efficient to iterate the entire array (perhaps with memoized results, or JIT compilation) than to perform a more surgical "update only what is downstream of the changes" approach. Another approach is to assign all nodes a contiguous integer id, and maintain a dirty node bitmask where bit-indices correspond to node ids. In addition, each source has a bitmask that is 1 for all downstream dependent nodes. When a source changes, bitwise-or source.downstream_dependents bitmask with the global dirty_nodes bitmask. To evaluate (not necessarily immediately), iterate in topological order processing only the dirty nodes. In any case, the point I'm trying to make is that the data structure that is best for building or manipulating the graph could very well be different from the data structure that is best for computing the desired results. There will be trade-offs to be made. For this reason alone it's best to keep the graph-theoretic properties and the implementation data structures separate in your head.
In my view the interesting requirements raised by the article are (1) lazy evaluation (e.g. of expensive or conditionally required data). This might be where control flow graphs of basic blocks enter the story. and, (2) dynamic reconfiguration during node evaluation. Some questions I'd be asking about dynamic reconfiguration are: what happens if you delete a node that has yet to be evaluated? will new subgraphs "patched in" to the existing graph (how exactly?), or are they always disconnected components that can be evaluated after the current graph traversal completes?
Pretty sure in the USA you can patent mathematics if it is an integral part of the realisation of a physical system.* There is a book "Math you Can't Use" that discusses this.
> Pretty sure in the USA you can patent mathematics if it is an integral part of the realisation of a physical system.
Yes, that's true. In that example, you're not patenting mathematics, you're patenting a specific application, which can be patented. In my reading I see that mathematics per se is an abstract intellectual concept, thus not patentable (reference: https://ghbintellect.com/can-you-patent-a-formula/).
There is plenty of case law in modern times where the distinction between an abstract mathematical idea, and an application of that idea, were the issues under discussion.
> I've learned to draw much stricter boundaries.
Could you elaborate on what has worked for you?
I imagine people who work in customer service have strategies too.
reply