I can see how you're coming away from this article with that perception, but, this needs to be read in the context of everything said prior: its intent isn't to provide you a full narrative of the situation, just additional context.
This article is the missing piece explaining why:
1. Shopify, allegedly, "specifically demanded that at least one of the RubyGems maintainers, André Arko, be excluded from returning to the project."[0]
2. Rafael França, a member of Rails Core, publicly listed concerns[1] about "competitor tooling"/"admin trust" r.e. rv.
Both are components of Joel Drapper's post that gave me pause on my first read, as these statements aren't something said without basis. That basis being correct or not is another matter, but I wouldn't expect either Shopify or a member of Rails Core to have such concerns simply because they don't like someone.
Personally, I don't come away from this article with the sense the author dislikes André, just that there's perhaps more rationale coming from a camp that's largely not said much so far.
Looking into the crystal ball of future predictions, the battle lines we're going to see in the Ruby community will be based around the acceptance or rejection of some of the allegations here about Ruby Together's spending.
I recall Ruby Together advocating for personal sponsorships in addition to corporate. It's one thing to be treating Apple adapters as disposable HB pencils & buying dinners on the company card if companies are funding you, but it's a different matter of fiscal responsibility when you're potentially spending personal donations.
Coming out of this, I'll suspect everyone will align that open-source contributors should be paid, and companies should in some way support open-source, but we'll see fractures over if André's alleged behaviour is acceptable.
I'm looking forward to someone/something assembling an entity which is trustworthy & responsible. If Ruby Central can't be that entity, we'll need a replacement.
Going by Hologram's public pricing, a GNSS "heartbeat" per-minute would cost $4/month on a PAYG model. With tiered contract pricing, I'd expect that to drop to $1/month for a mid/large-sized telematics organisation.
Looking at the definition of "premium cards"[0] they're actually business/commercial/corporate cards, not premium consumer cards. A horrendous term that's bound to cause confusion.
The scariest part of this pricing split is that Stripe seems to be determining the fee "based on the information available from card networks at point of capture", instead of being directly told what the card type is, and even allude to this determination being potentially incorrect.
This gets even more frustrating when you think that business spend is on average higher than personal/consumer spend, so charging a higher fee for this is just a triple whammy.
It's easy to crucify Stripe for this, but this is probably a product of a cost review they're undertaking as part of IPO/next round prep (if The Information is anything to go by). We need a new Visa/Mastercard.
It's next to impossible to get the clearance for an Apple Developer Enterprise account unless you know someone at Apple. It's necessary to have an Enterprise account to sign MDM certificates, so I've had an application open for over six months without hearing from them, and the first application was rejected after 10 months without any dialogue.
With this article shining yet more negative light on the program after the Facebook/Google spying-on-the-internet-access-of-kids debacle effectively shut the Enterprise program down, the MDM space will be even harder to innovate in, considering no startup will ever meet the required bar for signing up for an Enterprise account.
The experience is a little rough with the redirect, and I'd love it if I could put an email somewhere for a reminder when it launches. Otherwise though I'm really looking forward to ordering soon!
This looks absolutely incredible, and given the supply issues with Intel's NUCs, couldn't have come at a better time!
Do you have an estimate of when the Framework Marketplace will be available for UK customers? Currently Marketplace links redirect to the UK homepage, and is only accessible after manually selecting "United States" as a country.
Ah! I knew I was forgetting something: much like that dude living in a cave in Lost, I have to SSH into that server and HUP nginx every ~80 days, as the user that does the certificate renewal isn't the same user that runs nginx.
One day I'll overengineer something to solve this, but for the meantime it's "ssh statichost -- sudo kill -s HUP 947" every so often. Thanks for reminding me, much appreciated!
Oh absolutely, and that's something I'm taking into heavy consideration as I figure out the next move with Apple: I have next to no social clout or network, so if the loudest move I make in the tech sphere is "Apple screwed me", is that all I want to be known for?
I'm not hopeful for any change in these sort of review processes without any legislation changes, but it would be a truly tragic state of affairs if it were to escalate that far.
I don't doubt that from your perspective as the founder of Stripe, that's the workflow you'd like to have for when things "go wrong", but from the perspective of someone currently interacting with Stripe support, I strongly doubt that simply raising a support ticket or reaching out on Twitter would result in any meaningful movement on a rejection like this.
Regarding Stripe's support: I emailed last night to confirm how to delete a user's card when it's represented as PaymentMethod, and in reply I received a link[0] to the cards/delete API documentation (which, in case you're not as steeped in PaymentMethod's as I am, won't work because the two objects are fundamentally different).
Given this rather lacklustre handling & having also been on the receiving end of someone trying to fraud the company I'm working for, I highly doubt someone who is asking for reconsideration after receiving a fraud ban would actually receive an escalation via the front-line agents manning [email protected], and if they could, the actual legitimate bans that Stripe no doubt needs to put in place would simply abuse that channel and waste everyone's time.
I appreciate it's a really challenging balance of trying to provide an escalation/appeals process that won't be abused itself, and by comparison Stripe's approach of direct-founder-contact seems easier than Apple, as if your developer account application is rejected[1] you have absolutely zero recourse apart from going H.A.M. on Hacker News & hoping the community helps you out, whereas in this case there is a magic button that starts an invisible and unaccountable appeals process, that ultimately resulted in another rejection.
The only "solution" (if any) I can see to counter the negative experience (& associated PR) would be involvement in the appeals process, where you are allowed to effectively "state your case" via video call or submission of evidence, but this draws a thorny parallel to the judicial system, and I doubt Legal would sign off on such a process.
This is a problem that impacts basically any kind of appeals process, and Stripe's not alone in suffering from it, but that perspective doesn't help the dozens of founders that don't have the connections to sort this issues out in private, and are burning the attention span of Hacker News in the process of unblocking their businesses. Front-line support also isn't the answer, unless specific processes can be put in place to handle rejection escalations and get them into the eyes of the right people.
[1] Long story short: to use Apple's Mobile Device Management APIs, you need an Enterprise developer account, which thanks to The Verge & gambling apps skirting the App Store, isn't possible unless you went to Stanford with a future Apple PM. Admittedly, the chances of an Apple executive personally addressing this if I were to email is statistically quite low compared to emailing you.
If someone from Apple is reading this & would like to pre-empt the classic "Apple screwed me" Hacker News post, do feel free to email me on [email protected] and I'll happily brief you on The Great Saga of Enrollment 4HZY7VX69S.
R.E. "unified experience", this slots so cleanly into Stripe's stable of products: all of your reporting would be available in Sigma, all of your fraud data available in Radar, and with a little magic in the SDK side, all of your customer data available (unified) in Stripe's database.
Imagine if you're running a web store, and you want to go to a conference or convention or something and start selling your stuff there. All of your tools still work, all of your reporting still works, and crucially your accounting flow remains identical.
The customisation options are probably up in the air right now - I imagine developers won't get the ability to customise the UI available on the PIN pad in the first release, but I imagine that's where they want to get to.
I don't know about you, but every time I've attempted to use Sinatra for a project, it's either been for something that wouldn't ever see the light of production, or I've just ended up with franken-rails.
We had this problem at work: a Sinatra app that had pieces and pieces of ActiveSupport bolted on, and it got to the stage where we needed a beefier database than Redis before the CTO eventually generated a new rails app and transplanted the Sinatra app on top of it.
It's all well and good saying "use Sinatra", but when you get to the stage where you're adding ActiveRecord because it's the most mature ORM out there, it's usually late enough in the game that you're actually writing a poor excuse for a Rails application.
You make a very good point, but it took me about three minutes to build a git mirror which we can push/pull to, can re-configure CI to if we need to, and can be used to run a full deploy from on the company VPS server.
* Create an unprivileged account & set a password that you don't need to remember -> sudo adduser git
* Add your public key from your laptop to the unprivileged user's authorized_keys file -> sudo su git; cd ~; mkdir .ssh; vim authorized_keys - then copy and paste your id_rsa.pub to that file
* Repeat that for all public keys on your engineering team
* In git's home directory, git init --bare <name of repo>.git
* On your local machine, git remote add doomsday git@<DOOMSDAY SERVER HOSTNAME>:<NAME OF REPO FOLDER>.git
* git push doomsday --all
* On colleague's box, git clone git@<DOOMSDAY SERVER HOSTNAME>:<NAME OF REPO>.git
Let me know if there is a better way of doing this, or if it's monumentally screwed somehow.
* Git is decentralised, if Github drops off the face of the earth, it will take the two of us about half an hour to fix it as we each have a copy of the codebase on our laptops.
* If I wanted the build server to point to our internal git mirror, I would configure it to point to our internal code mirror, but I want it to build off of Github webhooks.
* The "eggs in the basket" analogy is probably best saved for a situation where I'm dependant on a cloud service, such as Twilio.
* I would expect an amateuristic private server to have better uptime than a monolithic service such as Github because there are a lot less moving parts, and in our case, a lot less people doing things with it.
* The "company impact" of Github going down is next to nil. It's one o'clock in the morning on a Sunday, I'm eating string cheese, and I feel like being productive. The company is not paying me for this, and have encountered zero losses from it. We have a very simple mirror which we can use to push code to production if Github goes down, which we have never actually had to use.
Personally, I find the "keep a torch in every corner of every room because for 15 minutes last year the power was out" attitude to life is a bit over-rated, and you're planning for an edge case. I'd much rather remember where the torch is and learn to walk in the dark.
I'm amazed at how much this has knocked me on my arse.
I first attempted to redo the README for a service I've just open-sourced, before realising Github is down.
Then, I attempted to fix the company CI server (OOM errors because of Carrierwave needing more than 500MB of memory to run 1 spec in, for some unknown reason), which failed because it couldn't check out the code.
After giving up on that, I attempted to install Graphite to a company server, where I hit another roadblock because the downloads are hosted on Github, and so I had to use Launchpad, which I had an allergic reaction to.
Also, when I was shelling into the server, oh-my-zsh failed to update because, you guessed it, Github was down.
Still, shouts to the ops team in the trenches, we're rooting for you.
I agree with the "Don't build anything for twitter" motto (and it would look good on a t-shirt), but part of me wonders if twitter could get by charging 25 cents a token past 100k, so developing apps is still possible, and twitter still gets its slice of the pie.
Although, it still kills the advertising cash cow.
Eh, it's not the only thing I find wrong with Tumblr, and I'm yet to try out your latest release (stepped on debit card, broke it, cancelled it, iTunes charge failed, no upgrade for me)
Please try going native, the performance increase would be in the order of magnitudes.
As amazing as writing an application relying on a UIWebView for its core functionality, it still crashes when you scroll for long periods of time, and instacrashes when you attempt to look at your likes.
I am admittedly on v.3.0.x, but the version previous behaved the same way, so I have little hope for future versions.
I must admit, the Tumblr app is one of the few apps that make me want to throw my phone against a brick wall.
This article is the missing piece explaining why:
1. Shopify, allegedly, "specifically demanded that at least one of the RubyGems maintainers, André Arko, be excluded from returning to the project."[0]
2. Rafael França, a member of Rails Core, publicly listed concerns[1] about "competitor tooling"/"admin trust" r.e. rv.
Both are components of Joel Drapper's post that gave me pause on my first read, as these statements aren't something said without basis. That basis being correct or not is another matter, but I wouldn't expect either Shopify or a member of Rails Core to have such concerns simply because they don't like someone.
Personally, I don't come away from this article with the sense the author dislikes André, just that there's perhaps more rationale coming from a camp that's largely not said much so far.
Looking into the crystal ball of future predictions, the battle lines we're going to see in the Ruby community will be based around the acceptance or rejection of some of the allegations here about Ruby Together's spending.
I recall Ruby Together advocating for personal sponsorships in addition to corporate. It's one thing to be treating Apple adapters as disposable HB pencils & buying dinners on the company card if companies are funding you, but it's a different matter of fiscal responsibility when you're potentially spending personal donations.
Coming out of this, I'll suspect everyone will align that open-source contributors should be paid, and companies should in some way support open-source, but we'll see fractures over if André's alleged behaviour is acceptable.
I'm looking forward to someone/something assembling an entity which is trustworthy & responsible. If Ruby Central can't be that entity, we'll need a replacement.
[0]: https://joel.drapper.me/p/rubygems-takeover/#:~:text=Shopify...
[1]: https://bsky.app/profile/rmfranca.bsky.social/post/3lz7alpob...