But build times are often really inconsistent, and sometimes just stall indefinitely rather than "failing".

When you're paying per-minute to run on Unity's hardware, this can become an expensive frustration..

I felt it myself recently, when I noticed Unity had been running a build for 11 days... without the build even ever starting on the runner, yet billing me for the time.

Unity were super helpful and refunded me thankfully, but this really highlighted for me the need for having an enforced timeout on the build.

So we just built this feature into Buildstash and our existing integration with Unity.

Teams using Buildstash with Unity can configure timeouts for each Unity build configuration - since you might know you expect an Android build to take longer than an iOS one, for example!

Buildstash will watch for the build stalling, and send an API request to Unity to cancel the build if it does.

Super simple, but hopefully solves a major frustration for Unity devs.

Comments URL: https://news.ycombinator.com/item?id=47683100

Points: 2

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=46309490

Points: 4

# Comments: 1

We just launched open sign up on Buildstash. It's a platform for managing and sharing software binaries.

I'd worked across game dev, mobile apps, and agencies - and found every team had no real system for managing their built binaries. Often just dumped in a shared folder (if someone remembered!). No system for versioning, keeping track of who'd signed off what when, or what exact build had gone to a client, etc.

Existing tools out there for managing build artifacts are really focused on package repository management. But miss all the other types of software not being deployed that way.

That's the gap we seen for Buildstash. It's for organizing and distributing software binaries targeting any and all platforms, however they're deployed.

And we've really focused on the UX and making sure it's super easy to get setup - integrating with CI/CD or catching local builds, so accessible even the smallest teams can get easily up and running.

For mobile apps, it'll handle integrated beta distribution. For games, it has no problem with massive binaries targeting PC, consoles, or XR. Embedded teams who are keeping track of binaries across firmware, apps, and tools are a perfect fit.

We launched the product Monday and then another feature every day this week -

Today we announced Portals - a custom-branded space you can host on your website, and publish releases or entire build streams to your users. Think GitHub Releases but way way more powerful. Or even think about any time you've seen some custom-built interface on a developers website for finding past builds by platform, looking through nightlies, past releases etc - Buildstash Portals can do all that out the box for you, customizable in a few minutes.

Here's a demo video - https://youtu.be/t4Fr6M_vIIc

and launch week page - https://buildstash.com/launch-week

Comments URL: https://news.ycombinator.com/item?id=46244184

Points: 4

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=46211986

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46197940

Points: 2

# Comments: 0

Will take on board leading more with.. this is for app, game, and embedded teams!

We're not really focused on smaller teams exactly, but more all the teams who don't currently use a dedicated binary management tool, but whose workflow would benefit from one they'd actually enjoy using (which we think are most teams..)

I've been building a tool for teams to manage their software binaries and releases.

Obviously tools like Artifactory exist - but coming from an apps/games background we found the vast majority of teams didn't use any dedicated tool for managing binaries. Finding what's out there too complex / expensive / missing features they'd find useful.

A lot of Google Drive, SharePoint, and Slack dumping grounds - with context lost, and not really suited to keeping track of past builds, distribution, etc.

Idea for Buildstash is to bring binary and release management to all software teams, making it so accessible even for small teams that it becomes as much a no-brainer as having source control or CI.

Less focus on just package repository management - but really focusing on the features devs across app/games/embedded need for managing their builds and releases. Whether around collaboration (linking builds to related issues etc), integrated beta distribution, sharing build streams and releases on their website, and rolling out to distribution platforms like the App Store / Google Play/ Steam etc.

Here's a product demo video - https://youtu.be/t4Fr6M_vIIc

Comments URL: https://news.ycombinator.com/item?id=45362860

Points: 15

# Comments: 5

Here's a thing I wrote on the history of App Center from its HockeyApp origins, why it's a loss for many teams, and why we're building something new (Buildstash) to replace it across all platforms.

Comments URL: https://news.ycombinator.com/item?id=43540819

Points: 4

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=37848047

Points: 1

# Comments: 0

There's a lot of leave / time-off management applications out there, quite a few we've tried.. We hope Picnic is a more accessible solution, particularly for smaller businesses.

An overview of Picnic functionality:

- Employees can submit requests for vacation and other time-off, and be notified of their manager's response

- Managers and supervisors can process requests for leave, and provide explanation

- Team members can view their personal calendar, and managers can view their team's calendar to see upcoming time off, and plan resourcing

- Browse all company employees in the employee directory (with the option to make the list visible to all employees, or managers only)

- Manage employees information, including personal details, and emergency contacts

Picnic is HR software designed to scale to companies of any size, but is especially suited to small and medium businesses.

We'd welcome your thoughts on the product, and where we might develop it further!

Comments URL: https://news.ycombinator.com/item?id=37312466

Points: 3

# Comments: 0

That said, AFFiNE also appears to be genuinely open source, while Anytype is only source available.

I did want to echo some of the points already raised regarding licensing.. From the outset, when I heard of the Anytype project some time ago, the whole thing that got me excited about it, and why I've been following it so attentively for so long, was the promise of an "open source, privacy-first, p2p, Notion alternative". While I'm sure we can all respect the licensing model you've settled on from a commercial perspective, and being source-available with select open source components is far more welcome over a fully closed model, it clearly does not make the project as a whole open source. While that's quite disappointing, it's positive to see you're acknowledging this and tweaking how you present the open source nature of the project to accurately reflect!

I did just want to ask however if you might have considered a licensing model similar to a project like Sentry? They also fully open source select components under permissive licences (MIT/Apache), but for key commercial elements they instead adopt the Business Source Licence (https://open.sentry.io/licensing/). This is very similar to the terms of your "Any Source Available License" in allowing personal use but restricting commercial use, with the very key caveat that it only enforces these restrictions for a period of 36 months, after which point the licence for those elements reverts to Apache 2.0.

Such a restriction would in theory protect commercial interests in a similar manner (only code from more than 36 months ago, or whatever delay preferred, is fully open sourced), but make the project far more open in spirit, and critically allay concerns Anytype will otherwise attract as a non open source project. For example - what happens if Anytype go closed in future once people are already bought in / if the organisation or development ceases at some point / if some decision was to be made in future which compromises user privacy or security, etc! A key element of open source is that trust doesn't just come from saying "trust me, honest!", but also from the licensing model - if the project disappears or is somehow compromised, it can be forked. Such a licence would allow this (with a delay!)

Might you have considered such a license, and if so would be curious your thoughts on why that isn't your preferred approach?

We previously used SVN for similar projects, and made the switch to Git once LFS made it a feasible choice for projects with lots of large binary assets (games), and honestly never looked back, it's massively improved our workflow.