3 ms·

The problem nobody wants to admit is that any competitor to SAP will just become SAP. SAP grew to what it is because it was made to fit everybody's workflow to

The problem nobody wants to admit is that any competitor to SAP will just become SAP. SAP grew to what it is because it was made to fit everybody's workflow to make sales to businesses wanting ERPs. Business is a wild world of so many ways to structure the org down from workflows to departments which is basically the only thing that differentiates a large majority of businesses these days. Sure, you could enforce a single cookie cutter approach for everyone, but then, how is corp A any different B anymore when everything is identical besides the people itself, heck their costs should equalize as they should in theory have the same workflow optimizations and inefficiencies.

jerf 7y ago
"The problem nobody wants to admit is that any competitor to SAP will just become SAP." This is an entire category of software. Closer to most of our homes, see "bug tracking software", "web frameworks" (frontend or backend), or "programming languages". Countless examples of someone getting frustrated and starting a "lightweight alternative", gets lots of attention, gets lots of customers who find various issues and features get added to address them, and before you know it, 5-10 years later, the "lightweight alternative" has become the monster the next generation of "lightweight alternatives" are being started up against. I'm actually at the point where I consider advertising something as a "lightweight alternative" to be nearly a strike against one of those things; it likely means the author doesn't understand how the previous things got to where they are and are just going to follow them down the same road. If you've got a coherent story on how to address that, talk directly to that. Of course, if you're a new bug tracker/framework/language author, you'd probably rather get the numbers you can get from advertising "lightweight!" rather than the smaller numbers you'll get from advertising "we're going to contain complexity by an aggressive modularization system based on the principles of ...".
- friendlybus 7y ago
  The majority of these projects are created to explore an idea, they are not meant to get big. They work well for small companies or niche customer bases. When the public and investors show up with demand to be big and cash is the author supposed to turn it down? The amount of good money thrown after bad on Kickstarter shows the money has no idea what it's investing in.
- pmart123 7y ago
  I think the big difference is that you can re-implement your website in a new web framework, open source it, and then get traction, etc. You can also do this with ETL frameworks (i.e. Airflow) too. Disruptive software is easier here as developers can run this new framework in parallel, or even as a side project to test it, provide feedback, or even help implement changes upstream. If something goes wrong, it usually has minor consequences. Something like an accounting system has challenges as it involves historic records and data, but at least you can test inputted data and results. With an ERP system, it touches the physical world so if a shipment is sent to the wrong place or doesn't happen, etc. the cost could likely be a much larger headache to deal with IMO.
  - hyperpape 7y ago
    It's easy to roll your eyes when you hear "disruption" because it's often used as a meaningless buzzword, but it describes a very real dynamic where "lightweight" products can disrupt outcompete heavyweight products in a large chunk of the market (https://en.wikipedia.org/wiki/Disruptive_innovation https://en.wikipedia.org/wiki/Disruptive_innovation). There are good business reasons that the products became heavyweight, but it leaves an opening where a smaller product can steal a chunk of the competitors. JSON disrupted XML. There really are ways it's strictly less capable.
    - jandrese 7y ago
      And now you see people trying to make JSON schemas and validation and all of the associated headaches that made XML such a pain.

jerf 7y ago

"The problem nobody wants to admit is that any competitor to SAP will just become SAP." This is an entire category of software. Closer to most of our homes, see "bug tracking software", "web frameworks" (frontend or backend), or "programming languages". Countless examples of someone getting frustrated and starting a "lightweight alternative", gets lots of attention, gets lots of customers who find various issues and features get added to address them, and before you know it, 5-10 years later, the "lightweight alternative" has become the monster the next generation of "lightweight alternatives" are being started up against. I'm actually at the point where I consider advertising something as a "lightweight alternative" to be nearly a strike against one of those things; it likely means the author doesn't understand how the previous things got to where they are and are just going to follow them down the same road. If you've got a coherent story on how to address that, talk directly to that. Of course, if you're a new bug tracker/framework/language author, you'd probably rather get the numbers you can get from advertising "lightweight!" rather than the smaller numbers you'll get from advertising "we're going to contain complexity by an aggressive modularization system based on the principles of ...".

friendlybus 7y ago
The majority of these projects are created to explore an idea, they are not meant to get big. They work well for small companies or niche customer bases. When the public and investors show up with demand to be big and cash is the author supposed to turn it down? The amount of good money thrown after bad on Kickstarter shows the money has no idea what it's investing in.
pmart123 7y ago
I think the big difference is that you can re-implement your website in a new web framework, open source it, and then get traction, etc. You can also do this with ETL frameworks (i.e. Airflow) too. Disruptive software is easier here as developers can run this new framework in parallel, or even as a side project to test it, provide feedback, or even help implement changes upstream. If something goes wrong, it usually has minor consequences. Something like an accounting system has challenges as it involves historic records and data, but at least you can test inputted data and results. With an ERP system, it touches the physical world so if a shipment is sent to the wrong place or doesn't happen, etc. the cost could likely be a much larger headache to deal with IMO.
- hyperpape 7y ago
  It's easy to roll your eyes when you hear "disruption" because it's often used as a meaningless buzzword, but it describes a very real dynamic where "lightweight" products can disrupt outcompete heavyweight products in a large chunk of the market (https://en.wikipedia.org/wiki/Disruptive_innovation https://en.wikipedia.org/wiki/Disruptive_innovation). There are good business reasons that the products became heavyweight, but it leaves an opening where a smaller product can steal a chunk of the competitors. JSON disrupted XML. There really are ways it's strictly less capable.
  - jandrese 7y ago
    And now you see people trying to make JSON schemas and validation and all of the associated headaches that made XML such a pain.