Because you see the IC side of the Atlassian toolkit. The management side is much more expansive and this starts mattering when you are coordinating larger projects.
That said, if you are a smaller company, you absolutely could kill Jira pretty quick.
The frustrating thing is I also thought about this as a natural conclusion - but as a natural workflow that corporations will do when they see AGPL dependencies they want to use. (I also think there's a world where we start tightening our software bill of materials anyway.)
I do not believe it will ever again make sense to build open source for business. the era of OSS as a business model will be very limited going forward. As sad and frustrating as it is, we did it to ourselves.
I mean, this is a task board and not a Kanban board - Kanban implies things like Work In Progress limits, continuous improvement, and measuring flow to get rid of blockers.
But you're right - you can visualize your workflow without using Kanban - I think it's weird how the term gets appropriated here.
People tried reinventing terminals, SSH, and tmux for phones. It's a pretty terrible experience using your thumbs. And it takes significant know-how to set up.
And in modern stacks, it almost necessitates a man in the middle - tailscale is common but it's still a central provider. So is it really the most inefficient way possible?
The cost of those remaining maintenance items are the issue. That said, it's a reasonable hypothesis to say that this is an economies of scale issue.
(Also, as I understand it, tires are used up more quickly on EVs still, but tire companies are learning to adapt to EVs so that may not be as true today.)
I heard a story from someone whose relative was in the Korean War - apparently people manning radar stations used to warm up by getting in between some microwaves. I just looked it up and the danger isn't cancer - but you stay too long you can get unexpectedly cooked (particularly eyes) because your body isn't detecting being warmed up like that.
My Grandfather was around in the early days, had a ham call sign from the early 1930s and was involved in the Manhattan Project as a senior non-scientific engineer.
He was also involved in the development of radar/microwave comms after the war.
He and colleagues did the same - warming their hands in front of microwave antennae.
He developed and later died of some unknown neurological issues related to nerve transmission in the early 1990s.
He had been exposed to so many different possible dangers that it's impossible to tell.
After he died I helped clean out and save/donate the double-garage full of ham equipment and home-built telescopes - one was ~.75metre diameter and ~3 metres long, just huge - I was just a teen and let most of it go as my grandmother didn't care by then.
There were also many containers of classified documents, related to WWII and after. Those were appropriately dealt with.
I've always HAD microwaves but have been aware of the issues.
I'm a ham as well and still occasionally use the morse key he gave me when I was 7. Still miss him, he taught me so much.
> According to legend, one day while building magnetrons, Spencer was standing in front of an active radar set when he noticed the candy bar he had in his pocket melted. Spencer was not the first to notice this phenomenon, but he was the first to investigate it. He decided to experiment using food, including popcorn kernels, which became the world's first microwaved popcorn. In another experiment, an egg was placed in a tea kettle, and the magnetron was placed directly above it. The result was the egg exploding in the face of one of his co-workers, who was looking in the kettle to observe. Spencer then created the first true microwave oven by attaching a high-density electromagnetic field generator to an enclosed metal box. The magnetron emitted microwaves into the metal box blocking any escape and allowing for controlled and safe experimentation. He then placed various food items in the box, while observing the effects and monitoring temperatures. There are no credible primary sources that verify this story.
Put a culture of stopping work at 40 hours. Allow the work to be the work and stop deadlines.
Otherwise, people will take every time savings possible. If I'm using AI for anything, it's because it's important enough to someone else for me to do but not important enough to sacrifice my own time.
I don't think it's about people being scared, at least from what I've seen. It's about people being exhausted.
> Otherwise, people will take every time savings possible
And you're saying they won't if you only cap the maximum amount of time they can work?
> It's about people being exhausted
Work can be difficult and exhausting and I don't think that's necessarily a bad thing. When I started my job I was tired often because it was hard. I got better at it over time.
I'm really not into any job where my value is strictly tied to the time I put into it. I much prefer a job that some weeks takes me a lot of time and some weeks takes not as much time.
If people are limited in how much time they work, they'll use AI to try to get more work done in that time. You'd have to also limit how much work people are expected to do. Good luck advocating for that change in modern corporations.
It turns out it's very slow to evolve a protocol. How long did it take for IRCv3 to handle channels having persistent history? How about channel takeovers via network splits? We knew these were problems in the 20th century but it took a very long time to fix.
Oh, and the chathistory Extension is still a draft! So is channel-rename! And account-registration?
And why is it still so painful to use Mastodon?
That's but one of many examples. Consider how the consolidation of HTML and HTTP clients was the only way that we ended up with any innovation in those services. People have to keep up with Chrome who just does their own thing.
I want to want a decentralized world governed by protocols, but good software that iterates quickly remains the exception rather than the rule.
All you've said here is that you (and many others) have shown in the past that they've valued convenience and rapid feature development over freedom and stability.
That is good to understand, but when that trade starts causing issues, it is important to remember that there was a trade made.
We aren't as stuck as we think we are, unless we decide not to reevaluate our past choices.
Yes, essentially everyone on the planet was willing to trade some freedom for chats that work on mobile or could send images.
Matrix has shown how incredibly difficult it is to make a modern service in a decentralised way. Requirements like preventing spam become immensely difficult.
Preventing spam may not be possible for much longer without verified IDs considering how advanced ai agents are.
Do any fully trustable ID validation services exist? Ones that verifiably never store your ID but just a validity status for a given ID on a blockchain?
Assuming you want ID verification, why would you need a blockchain? Your identity is deeply linked to who you are and we have identity documents and trusted entities to provide them. These entities can absolutely act as a third-party to verify who you are. This can happen with several different parameters: whether your identity is provided to the site you are using, whether the site your are using is known to your identity provider, whether identities across sites are identical or only linkable by the trusted party. But in all those examples (that are currently implemented by some countries), blockchain is not a requirement.
Assuming you don't want actual ID verification, the choices are even larger but with different trade-offs.
In theory yes, in practice it requires lots of different government services to get on the same page. How do you verify a state ID? Usually the DMV. Have they released an API endpoint for that? Almost certainly no. What if instead you're using a passport? Then the federal government needs to do it. What if your passport is from a country with weak government that doesn't have a lot of capacity?
And of course governments attract hackers because they tend to not be up to date on security best practices.
A single abstraction layer on blockchains allows more developers and security experts to contribute and innovate.
Preventing spam is as easy as gatekeeping. We should be bringing it back. Perhaps there should be multiple layers of social media. There’s deeper and deeper level of authenticity as you go deeper into the network
Phone numbers + phone number country + account age + behavior can be used to build a trust score. It might not be bulletproof but it cuts down spam enough for now.
Imagine a messaging app for example, a 1 month old account with a Nigerian phone number cold DMs an account in Australia. The likelihood of this being spam/abuse is extremely high. Vs a 5 year old account that mostly messages mutual contacts cold DMing an account in their own country.
In many countries, phone numbers are a proxy for ID and are difficult to get without having a local ID. The countries which have not secured their phone number system will be less trusted by spam filters.
Spam is an issue mainly because there are conspicuous meaty targets to be spammed, not in fragmented environments. And a target is meaty for spammers because that target has gathered, more often unnecessary, critical mass (large scale services, broadcast type news /thought leaders/influencers). Else even a small overhead for sending requests will drive away spammer incentive.
E.g. OS exploits were targeted towards Windows, not so much for so many of those Linux distros.
There's also this annoying flash perception that wins. As the big companies abandoned XMPP, less people considered it.
It's pretty good today! Lots of things improved a lot! Some big clean ups!
But think of how much better it would be if people stayed woke, if they didn't just throw up their hands call defeat & say it was never going to work. If there wasn't such a bleak rot in our soul, if we could try to play slightly longer games, I think in the medium & long run it would be much much better for us all.
It feels so easy to spread sedition, to project these fatalisms that only big dumb lumbering central systems win. I'm so tired of this bleakness, this snap to convenience as the only perceived possible win. Let the prophecy self fulfill no more, let us arise from this torpor. A little Ubuntu would be ao good for us all. Ubuntu the old saying (that the distro was inspired by) goes: "If you want to go fast, go alone. If you want to go far, go together"
Nobody said how hyper the HT in HTML and HTTP had to be, so here we are.
Oh, TLS also. Encrypted connections over HTTP are trivial.
Arguably this has created far more freedom by making encrypted network traffic default and free. Convenience is also freedom when it comes to accessibility.
Short-term yes, long-term it is often the other way around. In many cases, abandoning an open standard for a closed, centralised solution is surrendering to future enshittification for short-lived instant gratification.
Is Mastodon really hard to use for most people? I guess there's some very specific scenarios it may be.
Also the article presents a false dichotomy in my view: protocols need services to be useful to virtually 99.9999% of humans (or at least they do in the architecture we have built since... email?).
Who uses email without relying on servers? Where is your selfhosted email box sitting on if not in a hosting service?
Even IRC relies on servers for people to talk to. I love to experiment with protocols that do not rely on servers - secure scuttlebut? - but even ssb relied on some seed peer that provides a service to initialize the peering
Under-appreciated factor: the problem with decentralization is that it pushes work on to the end user, who is least equipped to deal with it. People actively want centralization of things like anti-spam because it lightens the load. The fact that this gets paid for in insidious ways rather than directly paying for a service causes all sorts of weird market distortions.
Note that Discord doesn't replace IRC, it also competes with TeamSpeak; there's a whole voice and video sub-feature to it. Not everybody uses it but the fact that it's available in the same software was advantageous to the original market, gamers.
I can't tell if you are replying to the comment or the post because the topic of TFA is literally comparing protocols and services. Discord and IRC are both mentioned in the post.
Pretty sure they're replying to the post that directly contrasts Discord/Slack and IRC.
TFA mentions both, yes, but as a direct example of service/platform (Discord) vs protocol (IRC, XMPP, etc). The comment asks a question that kinda misses the point of TFA.
Discord could be considered to have "won" in that it's got a lot of (new) users and removes some of the limitations of IRC, but that's _because_ it is a service/platform, and comes with all the trade-offs being discussed in other threads here.
Or one could consider IRC to have "won" because as a protocol it simply can't have some of the restrictions possible with a centralized platform.
It's trade-offs all the way down, but protocols will always have fewer restrictions of the kind currently in the zeitgeist, especially decentralized protocols.
That's why I'm pretty optimistic about the AT protocol: you get the advantages of app-driven innovation (need a new feature? just define a lexicon for it) without requiring data reliant on that feature to live in that application's silo; the records all exist in each users' PDS, under each users' own control, no matter which applications use those records. And of course, if those features prove to be good ideas, other applications can adopt those lexicons and they're immediately interoperable.
Totally understand, I am all for decentralized world too. In reality tho most ppl just choose whatever works fast and ships fast and more production-ready I guess, no drafts. Would be great if the world sees an opposite example, by far centralised approach just worked better
Not true at all, having seen the other side. In a large enough organization, entire divisions will be cut if a product is missing. Sometimes productive people are on the wrong product that gets slashed to maintenance mode, or they have the wrong manager. Sometimes deep cuts are necessary because the product is failing and a productive person on a growth initiative is cut for subject matter expertise in the core product that will allow maintenance mode to continue. Sometimes tenure is rewarded. Sometimes directors don't see the full story because the managers can't be told of the layoff.
Tenure, in this case, is rewarded by not being laid off - because this person had old knowledge and friends with people who were in power and knew them from earlier in the company.
It absolutely does happen. But I have also seen people rise through the ranks by just being there long enough and being competent. That said, it is not a way to maximize wage growth or general career progress by any stretch.
That said, if you are a smaller company, you absolutely could kill Jira pretty quick.
reply