3 ms·

The big issue here being that Adobe has zero interest in selling this, and this kind of model would not lead to a $250B market cap business. Adobe wants to tigh

The big issue here being that Adobe has zero interest in selling this, and this kind of model would not lead to a $250B market cap business. Adobe wants to tightly control the experience, record how you use the software, display their own branding, try to upsell you on their other products and services, etc etc. Software businesses care about controlling the UX/branding/etc. tightly, because that's where the money is - not selling "menus of filters". That's why every webpage is nowadays is a SPA that hijacks standard browser features like scroll and copy paste and no one looking to make money was ever interested in the semantic web. I'm very aligned with the views exposed in the article and your comment, and have been working on some open source approaches to it in my free time for a few years now. I figure that the only way that it can maybe work is to make something for myself that I love using, and maybe some other enthusiasts will like it too and it can grow a bit from there. But there's probably no way it would ever meaningfully compete with Photoshop, because it goes against every economic incentive that software companies have. In parallel, I also suspect that that's why the design/UX of open source applications tend to be extremely poor in general - great, tight design is expensive and needs strong economic incentives.

rogual 6y ago
Yes, open source sounds like the right place for ideas like this, for the reasons you mention. Consider Emacs, whose hundreds of extensions give you this mix-and-match setup, or something similar to it. I think I might really like working with a system that works in this way, with a bit from here, a bit from there -- but I'd want access to the code, because it would take a lot of tweaking to make things nice.
SilasX 6y ago
That is exactly my thinking. This model goes contrary to the needs of propriety software, to lock you into a whole system you can charge for. (And FWIW, I don't have the vendetta against proprietary software like a lot of HN seems to, so I'm sympathetic here about breaking the incentives for production of software that legitimately needs paid devs and can't get enough via donations. But if Open Source teams can make it work, I'm all for that!) OTOH, as a general model ... I can see why it has failed to pick up, at least with typical devs and prevailing software practices. It requires a level of care about interfaces and interoperability that is not very common. More often, you see APIs broken willy-nilly with no functional need to. Stable standards for exchange of data require a lot of work and are the exception -- even when you have them, there will be the warts that reveal abstraction leakage. (Another comment mentions how HTML was quickly broken.[0]) The no-app approach with basically be that fight, but for every external touch point, of every module. I do hope the dev world can make that work ... but also: understand what you're fighting against. [0] https://news.ycombinator.com/item?id=25021180 https://news.ycombinator.com/item?id=25021180

rogual 6y ago

Yes, open source sounds like the right place for ideas like this, for the reasons you mention. Consider Emacs, whose hundreds of extensions give you this mix-and-match setup, or something similar to it. I think I might really like working with a system that works in this way, with a bit from here, a bit from there -- but I'd want access to the code, because it would take a lot of tweaking to make things nice.

SilasX 6y ago

That is exactly my thinking. This model goes contrary to the needs of propriety software, to lock you into a whole system you can charge for. (And FWIW, I don't have the vendetta against proprietary software like a lot of HN seems to, so I'm sympathetic here about breaking the incentives for production of software that legitimately needs paid devs and can't get enough via donations. But if Open Source teams can make it work, I'm all for that!) OTOH, as a general model ... I can see why it has failed to pick up, at least with typical devs and prevailing software practices. It requires a level of care about interfaces and interoperability that is not very common. More often, you see APIs broken willy-nilly with no functional need to. Stable standards for exchange of data require a lot of work and are the exception -- even when you have them, there will be the warts that reveal abstraction leakage. (Another comment mentions how HTML was quickly broken.[0]) The no-app approach with basically be that fight, but for every external touch point, of every module. I do hope the dev world can make that work ... but also: understand what you're fighting against. [0] https://news.ycombinator.com/item?id=25021180 https://news.ycombinator.com/item?id=25021180