The State of Vue - <AUTHOR> https://medium.com/the-vue-point/the-state-of-vue-1655e10a340a#.sygdkj502 <comment><USER2> Vue has a lot of great ideas. I originally found it to have just enough power over Backbone, without the heft of Angular. Despite a great premise, my time with Vue was turbulent.

Vue version updates are tremendous time sinks. API thrashing was common from the original 0.x.x releases to 1.0.0

This was justified as all versions under 1.0.0 being "under development". That's fine, but call it what is, "non-production-ready software". A public beta that should have a prominent disclaimer.

The removal of the built in event system was also handled poorly. There was no migration path other than build-your-own shim using the Vue constructor.

My beef with Vue these days is the growing Vue-specific tooling. I'm not fond of the single file .vue approach as it doesn't make it easy to separate components into different contexts.

The standard rebuttal for this complaint is "but JavaScript, CSS, and templates are the same context." I agree that the approach of scoping CSS and template to a component is great. Not being able to use separate files leads to a lot of noise. I don't need to see the CSS when I'm working on the component JavaScript. The best solution I've had in the meantime is using my editor's "block folding" feature.

Combine this with a .vue specific syntax highlighting, and a .vue eslint configuration.

It's really not what I signed up for in the beginning. I sense I'm coming off as entitled. Evan's countless hours of work is commendable and I'm grateful for his vision.

I hope Vue will find that illusive balance of configuration and opinion in its lifetime.

<comment><USER3> > Vue version updates are tremendous time sinks. API thrashing was common from > the original 0.x.x releases to 1.0.0

I didn't have to endure this, although pre-1.0 API breakage goes with the territory (of pre-1.0 software...).

The 2.0 API changes look pretty sane ([https://github.com/vuejs/vue/issues/2873);](https://github.com/vuejs/vue/issues/2873\);) once it is official and the vue-cli webpack template is updated, it looks like only a little work to upgrade. Vue's documentation (in the present) is really good, and was a motivating factor for me choosing it over React.

</comment></comment><comment><USER4> Cool. Vue is such a godsend in the ever more complicated world of Javascript frameworks. It combines the simplicity of jQuery with the power of Angular. The documentation is excellent as well. I hope Evan can keep up the good work for a long time!

</comment><comment><USER5> I really like Vue and wouldn't want to use anything else right now. it feels much more natural to use for me than for example React. it is however quite a struggle when first using vuex for storing. I haven't looked into 2.0 much yet but vuex is said to get easier to use then. keep up the good work!

</comment><comment><USER6> > fastest growing libraries in the past few months

reminds me of [https://xkcd.com/1102/](https://xkcd.com/1102/)

</comment><comment><USER7> If you guys liked vue, you will absolutely love riot.js. It's so simple and minimal that I only had to look at their docs for a couple minutes and I was on my way. In this day and age where client side frameworks are overly obese , riot was afresh air. I like it more than any other frameworks out there.

<comment><USER8> Really? I couldn't even figure out how to get started with Riot. Vue's Guide walks you step-by-step from scratch how to get up and running. It also has a section on how to structure larger apps once you understand the basics. Riot's Guide is a topic overview. I had to find tutorials outside the main site.

<comment><USER7> What got me started in a jiffy was just looking at their live demo, [http://riotjs.com/play/](http://riotjs.com/play/). Sometimes code is it's best documentation.

<comment><USER8> I don't think that link points to what you intended: it links to a simple html file with a blank script file.

Code can be great documentation if you already understand how to get there. Sometimes maps are better for people new to the tech.

</comment></comment></comment></comment><comment><USER9> I really hope the patreon model catches on with open source.

<comment><USER10> Me too. It is awesome people ensure he can get $8k per month to work on Vue. We tried donations with GitLab years ago and the highest we got was $1200, but this was a one time think. I think the Patreon model of 'subscribing' to sponsor is really fitting.

I do think that it is easier to get a handful of people funded with this model than a large group. GitLab Inc. now has 25 developers working 80% of their time on open source. Getting 20 people funded with Patreon seems like a stretch.

<comment><USER11> Worth noting that most of the money comes from big donors. In Vue's case, there are 79 donors, but 9 donate $500/mo, and 1 donates $2000/mo. (and those are essentially ad placements)

</comment></comment></comment><comment><USER12> Evan gave a recent talk at Laracon about Vue.js [https://streamacon.com/video/laracon-us/evan-you-vuejs- works...](https://streamacon.com/video/laracon-us/evan-you-vuejs-workshop)

</comment><comment><USER13> "2.0 is now in RC [...] From this stage on we will be in API freeze and there will be no more breaking changes before official release"

Please take note @angular team.

</comment><comment><USER14> Here the changelog: [https://github.com/vuejs/vue/issues/2873](https://github.com/vuejs/vue/issues/2873)

I love VueJS. I found it very easy, specially when you aren't building a SPA, but want something more powerful than jQuery without being overkill like React.

</comment><comment><USER15> I find this fascinating:

"Patreon Campaign Going Strong The Vue.js patreon campign now has over $8,000 monthly pledge from the community and sponsors."

It's only a bit tongue in cheek to say this is a shining example of socialism. The biggest, and collosal difference is that now it's voluntary, and it's awesome.

<comment><USER16> I'm not sure I understand how... people are paying for something that they use (or otherwise benefit from) and the producers are asking for that payment and reap the benefit: it's a trade, a win-win transaction. To me this sounds much closer to capitalism than socialism where the exchange requires no such win- win proposition for the parties directly involved. That such voluntary payment is voluntary, again, is closer to capitalism where transactions are entered into voluntarily by the parties which is a fundamental feature of capitalism and not socialism. Just because the producer is accepting that payment is not required doesn't mean that it's socialism (the false alternative)... they are after all asking for compensation albeit on a voluntary basis.

Or are you suggesting that people are giving for some other reason than they benefit from the work?

<comment><USER17> But one could say that he does not own the "means of production" but instead it is owned by community, which has democratic control (for example a fork might become more popular). I'd say that is a trait of socialism and perhaps anti-capitalist.

<comment><USER16> No. "Copyright (c) 2013-2016 Evan You" ... he clearly owns the product or at least makes claim to do so. Such a claim of ownership, and likely valid claim at that, immediately refutes your position. While others are entitled to create derivative works, it is only by the good graces of the property holder.

But more importantly, there is a fallacy that the material goods or machinery that are used in the creation of a product (the "means of production") are somehow responsible for that product coming to be. That's nonsense. It was nonsense in the industrial era and it's even more apparently nonsense in software development. Sure, factories were hard come by back in the day, but having a factory didn't mean you'd be successful: you had to think and if anything is an individual endeavor, it's thinking. Now that the means of production can simply be owning a computer... something open to a wide variety of people of all backgrounds... one sees the relative individual contributions to success or failure more dramatically.

As for someone going off and, with the owner's permission, forking the project: they will only be more successful due to the individual contributions of those making the fork. Some vague abstract notion of "community" will not suffice.

<comment><USER18> You don't need the owner's permission to fork it. It's MIT licensed.

[https://github.com/vuejs/vue/blob/dev/LICENSE](https://github.com/vuejs/vue/blob/dev/LICENSE)

<comment><USER16> Oh come on guys... think a bit... just a little.

You _do_ need the owner's permission to fork the project. The owner has granted that permission in advance by distributing it under the MIT license, provided you agree to terms of that license as imposed by the owner. That you do not need express written consent doesn't change the fact that you can only use the code by permission of the copyright holder. Note that the permission to use/modify the software is not unconditional. If you fork it, you cannot change the license terms, _the owner hasn 't granted anyone permission_ to change the terms of his license for his property and the license itself is explicit on this point.

Really, the first line of the license starts, " _Permission is hereby granted..._ ," and ends with, " _...subject to the following conditions:_ ,". Don't agree to that stuff and you _don 't_ have permission from the owner and you can't use the software.

<comment><USER18> > You do need the owner's permission to fork the project.

The MIT license is the permission.

[http://programmers.stackexchange.com/questions/253925/how- to...](http://programmers.stackexchange.com/questions/253925/how-to-avoid- being-forked-into-oblivion-by-a-more-powerful-contributor)

> That you do not need express written consent doesn't change the fact that > you can only use the code by permission of the copyright holder.

Which is granted by the MIT license.

> If you fork it, you cannot change the license terms, the owner hasn't > granted anyone permission to change the terms of his license for his > property and the license itself is explicit on this point.

No one's suggesting changing the license terms. You must retain attribution, as required by the MIT license. A fork would need to carry the required attribution to Evan You.

The OSI's definition of Open Source includes "The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software."

</comment></comment></comment></comment></comment></comment></comment><comment><USER3> I picked up Vue a couple of weeks ago for a small dashboard project where client-side makes total sense: consuming JSON from HTTP APIs. I'd previously played with Ember (good, but not using Ember Data feels punishing), looked at Riot (neat, but very small community), and of course React.

I'd dabbled with React before, but there's a huge gap between 'dabbling' and 'building something reasonably production-worthy'. Webpack (and its contemporaries) are neither accessible nor straightforward to modify, and create-react-app[1] is still maturing _.

Vue's fantastic documentation[3], ready-made project templates[2], well-sized community, sane-looking 2.0 API changes, and lifecycle methods that are similar to React (but a little less verbose) were all pluses for me. Making HTTP calls, populating a simple central store and passing that down to components was easy, and for a less-often-a-frontend-dev like me, writing Handlebars templates with helpers for looping, binding form inputs to state (v-model), and adding classes to CSS based on helper methods (e.g. :readonly="isReadOnly(key)") was easy to pick up.

I can see the advantages of React's JSX approach (limiting template-logic, as templates don't exist), although Vue 2.0 will have JSX support as well.

Like with most tools, your decision is part-requirements and part-subjective ("I'm familiar with X, Y & Z approaches"), but Vue made sense and I'd definitely build something else with it again. That Evan has such a huge amount of support on Patreon[5] is impressive as well.

_ I hope Dan Abramov can keep create-react-app focused: there are an incredible amount of feature-requests, and if create-react-app grows flags to accomodate even half of them, it'll be a monster. Thus far the dam seems to be holding!

[1]: [https://github.com/facebookincubator/create-react- app](https://github.com/facebookincubator/create-react-app) [2]: [https://github.com/vuejs/vue-cli](https://github.com/vuejs/vue-cli) [3]: [https://vuejs.org/guide/reactivity.html](https://vuejs.org/guide/reactivity.html) [4]: [https://vuejs.org/guide/application.html#Single-File- Compone...](https://vuejs.org/guide/application.html#Single-File-Components) [5]: [https://www.patreon.com/evanyou](https://www.patreon.com/evanyou)

</comment><comment><USER19> _1 million+ downloads on NPM at 125k~150k per month_

But doesn't Node download from NPM every time it runs? Hence the left-pad debacle. So this "downloads" figure doesn't necessarily mean what someone used to a more conventional language might think it means.

<comment><USER2> NPM modules only download when explicitly fetched with `npm install`

<comment><USER18> Which, if you're running CI, might be every time you push a build to it.

</comment></comment></comment><comment><USER20> Does anyone know how this compares to [http://www.ractivejs.org](http://www.ractivejs.org) ? Ractive looks like a simple no fluff framework

<comment><USER21> When I looked into it some months back, I arrived at following :

>Template syntax wise it's mostly subjective preference: Ractive uses mustache templates, Vue uses attribute bindings.

>Vue has a more intricate reactivity system - plain Objects made reactive, and can be externalized and managed elsewhere if necessary.

>Vue has more support libs/tooling (vue-router, vueify, vue-loader etc.)

>I actually know Rich who is the author of Ractive. AFAIK he's not that actively maintaining Ractive now (just look at the issue count) and is focusing on some other projects.

-Evan You(Author of Vue) [1]

But, that's 8 months ago. As of now, Vue has gone way high up in terms of popularity and features.

[1]([http://forum.vuejs.org/topic/849/differences-between-vue- and...](http://forum.vuejs.org/topic/849/differences-between-vue-and- ractive/2))

<comment><USER20> Thanks for your insight and reply.</comment></comment></comment>


AT&T CEO's net neutrality plan calls for regulation of websites - <AUTHOR> https://arstechnica.com/tech-policy/2018/01/att-ceos-net-neutrality-plan-calls-for-regulation-of-websites/ <comment><USER2> I can't think why we should have network neutrality but not search engine neutrality or OS neutrality.

<comment><USER3> How would 'OS neutrality' look, and what does that even mean? Some question for 'search engine neutrality'..</comment></comment>


Test websites in IE 9, 8 and 7 under Linux / Mac OSX - <AUTHOR> http://www.webupd8.org/2011/09/test-websites-in-internet-explorer-9-8.html

<comment><USER2> I still haven't been able to get this to work on Lion. Here is the actual github page where you can read more about the issues.

<https://github.com/xdissent/ievms>

<comment><USER3> jreposa, you should be fine on Lion - it's what I used to initially develop the script. What issues are you seeing?

<comment><USER2> A few different ones at first, but now I get the setuuid issue.

<comment><USER3> Ah, well I have a branch called "uuids" that should fix that across the board, but you could also upgrade to VirtualBox 4.1 if you can and that will fix it too. That branch should be merged this weekend too, I just have to test on older versions in Linux.</comment></comment></comment></comment>


Canada MPs vote to strip Aung San Suu Kyi of honorary citizenship - <AUTHOR> https://www.bbc.com/news/world-us-canada-45647073 <comment><USER2> I'm curious what people think a solution to a seemingly recurring trend throughout the world ought be. Let's create a scenario. It may not entirely precisely describe this exact case, but it's not terribly far off and generalizes well in any case. You have a midsized population of uniquely homogeneous people - let's say in the low millions. Of these people a small percent are actively radicalized and will indiscriminately murder and engage in other violent activity to pursue their agenda. A moderate percent will not engage in the criminal behavior directly, but will actively aid or assist the radicalized individuals. And a large percent may not be willing to participate in the radical element or directly assist them, but remain, at minimum, complicit in their behavior and will certainly do nothing to aid in any law enforcement effort. They've never seen anything, or heard anything - even when they have. And a secondary effect of this system is that there tends to be a trend towards radicalization rather than away from it, and you even have incidents of the radicalized murdering members within the population that are found to be too cooperative with law enforcement.

What is the proper way to handle the problem? The numbers and lack of cooperativeness make it practically impossible to remove the radical element. How do you solve the issue while also ensuring respect for human rights? Makes the _Kobayashi Maru_ look like a cakewalk, and this is real.

<comment><USER3> Except you are completely wrong with your hypothesis or understanding of the situation. This is an issue with Hacker News, so called armchair experts providing their analysis.

The majority are not complicit in anything. Fundamentalists have killed more muslims in a year in some of these countries than in total in the west or any other non Muslim country.

This rhetoric that somehow muslim populations don't cooperate with law enforcement when in fact they have been the greatest victims is frankly dishonest.

I think a lot of people would benefit from looking at the facts rather than trying to push their pseudoscientific theories on the internet.

The issue here is actually pretty clear cut. You have a stateless people systematically killed and eradicated by Buddhist extremists. I suggest people do a deep dive on the actual crisis.

<comment><USER4> This survey makes it seem like more Muslims are radicalized than you seem to think based on what you wrote

[https://www.gatestoneinstitute.org/7861/british-muslims- surv...](https://www.gatestoneinstitute.org/7861/british-muslims-survey)

<comment><USER3> First of all that is looking at British Muslims who are a tiny minority of the 1.6-2 billion Muslims in the world.

Maybe take a look at the number of muslim civilians killed in Somalia, Iraq, Syria, Pakistan, Bangladesh by the number of Muslim extremists. It's a lot more than you seem to think.

<comment><USER4> British Muslims would seem to be one of the least radical Muslims. After all, they don't kill gays like Muslims in Iran, Afghanistan, Yemen etc.

I never claimed that radical Muslims don't want to kill other Muslims. In fact the Sunni and Shiite conflict probably killed more Muslims than non-Muslims.</comment></comment></comment></comment></comment>


Multiprocessing with Python - <AUTHOR> http://www.ibm.com/developerworks/aix/library/au-multiprocessing/index.html?ca=dgr-lnxw97Python-Multi&S_TACT=105AGX59&S_CMP=grsitelnxw97

<comment><USER2> For those who want this functionality but use a version of Python older than 2.6, there is a backport of this module:

<http://code.google.com/p/python-multiprocessing/>

</comment><comment><USER3> How does this relate/interoperate with stackless python? <http://www.stackless.com/>

<comment><USER4> It's doesn't matter. It can run with stackless/within it, and you can use tasklets. This was designed to step around the GIL, not get involved in the coroutine/tasklet/etc rats nest.</comment></comment>


Never Use a Warning When You Mean Undo (2007) - <AUTHOR> http://www.alistapart.com/articles/neveruseawarning/ <comment><AUTHOR> Last submission two years ago went unnoticed, so I figured out it might be of some interest (as it was for me).</comment>


An economist's explanation of Groupon's success - <AUTHOR> http://mises.org/daily/4657

<comment><USER2> A few issues:

1\. Groupon deals aren't only valid for one day, thus the restaurant owner has no idea when people are going to be in the restaurant or not.

2\. I reject the notion that I restaurant owner would prefer to serve a full restaurant at half price over a half full restaurant at full price. From my discussions with businesses who use Groupon, they mostly see it as a tool to drive repeat customers not one-time customer volume. Very few restaurants can make ANY money at 50% menu price, much less at 25% menu price (after Groupon takes their cut).

3\. I would be willing to bet the 'tipping point' effect of Groupon on the sharing of deals is nearly insignificant. I think a far larger driver of sharing these deals are deals that require multiple individuals to participate. (e.g. I bought a coupon with 15 of my friends to go paintballing in a few weeks)

</comment><comment><USER3> _There are problems with this strategy too. No matter how hard he tries to isolate his target audience, the owner can't really control how many people show up. Or, the numbers might turn out such that (conventional) advertising is too expensive._

I call BS on this. I have ran into many store owners(though they are rare) who have been having similar success as Groupon for _years_ simply by giving a good damn offer in the paper. I have ran into even more who consistently have crappy coupons and get crappy results. I find very, very few who try a groupon-like offer in the paper and don't see results.

This article is typical keyboard-jockey analysis from some supposed expert.

</comment><comment><USER4> Evan Miller (I forget his nick on HN) wrote the first - and the best - explanation of the analysis of Groupon's economics: <http://www.evanmiller.org/golden-football.html>

<comment><USER5> I just put out a call.

</comment></comment><comment><USER6> I found this analysis (previously posted to HN) a bit more rigorous and less ideological:

<http://www.evanmiller.org/golden-football.html>

The mechanism has some superficial similarity to 'Assurance Contracts', an economic idea for coordinating group actions that are best done all-or- nothing. However, it seems that at least now, with Groupon in its galloping stride, there's no real doubt most promotions will hit their target participation level. That is, it's more a promotional mechanism for focusing consumer attention, rather than a solution for a coordinated-decisionmaking problem.

There's room for other innovations in these areas, as well. The 'dominant assurance contract' gives an extra sweetener back to pledgers if the threshold _isn't_ met, to make assurance contracts work for otherwise nonexcludable 'public' goods where bystanders might normally hope to free-ride after others fund. See:

[http://www.marginalrevolution.com/marginalrevolution/2005/05...](http://www.marginalrevolution.com/marginalrevolution/2005/05/assurance_contr.html)

<http://en.wikipedia.org/wiki/Assurance_contract>

<comment><USER7> Agreed, the Evan Miller piece is far more thoughtful than the OP. Still, it doesn't consider that many groupon deals are un-, not barely-, profitable for the business owner.

For example: <http://posiescafe.com/wp/?p=316> The deal was $6 for $13 worth of merchandise, but after Groupon's take, she gets to keep $3. No way to cover costs with a deal like that.. never mind profit.

And if the deal is unprofitable, there's no way to economically justify the offering unless you start factoring in soft effects like return visiters, name recognition, etc.

<comment><USER6> Indeed, there must be other effects, perhaps more important than the 'golden football' zone, that explain these loss-leader deals.

Almost any business should be willing to lose a little on product if that loss displaces more in other promotion/customer-acquisition costs. A business would be more willing to do so if they're sure the cost is reaching new customers. Perhaps that's an important part of the Groupon secret sauce -- the purchase of the 'coupon' with credit cards that provide a relatively strong identity signal. That could be used -- eventually, at least -- to target future promotions to unique new customers.

Does anyone know what sort of data the business gets from Groupon? Have any businesses offered repeat Groupons that _aren't_ available to people who bought the first one?

<comment><USER8> _> Does anyone know what sort of data the business gets from Groupon?_

The only customer data Groupon shares with the merchant is first and last name.

 _> Have any businesses offered repeat Groupons that aren't available to people who bought the first one?_

Highly unlikely. Imposing a conditional like that would complicate Groupon's process and confuse many users.

You mentioned identification by credit card number... Problems I see in that scenario: PCI compliance, UX, lower revenue per deal. And since many people have more than one credit card there is a loophole.</comment></comment></comment></comment>


Ask HN:  Visual FoxPro for charity POS app? - <AUTHOR>

I need some technical advice for a pro bono legal project.  I'm helping a local charity, staffed almost entirely by volunteers, to negotiate a software development contract with an independent developer. The project is to build a point-of-sale and inventory-management system, to replace the antiquated custom-build system they have now.
(The charity's management has already explored off-the-shelf and FOSS possibilities, after another developer's prior attempt to build a new system ended badly.)
The developers are proposing to use Visual FoxPro 9.0.  I'm vaguely familiar with that platform, and have just read the Wikipedia entry and the Microsoft landing page.
YES-OR-NO QUESTION: Granting that there might be better tools than Visual FoxPro 9.0, is that at least a not-unreasonable choice?
Thanks in advance. <comment><USER2> Yes, it is a good choice to develop small database centric applications. In a certain way is similar to Delphi ou VB but more database centric than VB.However it has been shelved by Microsoft in favor of .Net, so support may be a concern in the future.

<comment><AUTHOR> Thanks jojosime.</comment></comment>


The $70,000 Minimum Wage Experiment Reveals a Dark Truth - <AUTHOR> http://www.cheatsheet.com/money-career/the-70000-minimum-wage-experiment-reveals-a-dark-truth.html/?ref=YF <comment><USER2> I think this makes an interesting observation, but I don't agree with the conclusion about "crab mentality".

Flip it into an experience that many people experience in their lives, they buy product X and they pay $Y for it, then due to circumstances they don't control, the seller decides to start selling that product at $Y-$Z dollars, a big discount. The original buyers feel "ripped off" because the seller changed how they valued the product, without changing the product.

There has to be a real name for it, but I call it value dissonance. Where the value you assign to a good or service is suddenly different than the market value. Everyone who bought a house in 2007 experienced it in 2009 :-(.

Work output is just as much a good or service. And you consciously or unconsciously assign a value to it based on what other work around you "gets" as salary. So if you change what you pay one set of people but not everyone, you introduce this dissonance. And it can be hard to process.

<comment><USER3> How isn't that a zero sum mentality? Unlike in your housing example, nobody lost any true value, just perceived value.

No doubt it can be hard to process, but that doesn't mean it's not a case of zero sum mentality.

</comment></comment><comment><USER4> Please change to one pager.

[http://www.cheatsheet.com/money-career/the-70000-minimum- wag...](http://www.cheatsheet.com/money-career/the-70000-minimum-wage- experiment-reveals-a-dark-truth.html/?a=viewall)

</comment><comment><USER5> A lot of the events are specific to the business discussed (the ownership structure with passive investors with preference for dividends, big-ticket customers with strong opinions).

Paying above average to increase retention rate is not new. Henry Ford pioneered it for automated assembly line, Costco pays above average compared to others in retail, tech companies attempt to lock in four-year commitments by issuing stock options.

The idea is that the company gets competitive advantage by minimizing employee onboarding/training costs and maximizing said employee's productivity. For some industries it's a good bet, for others not.</comment>


Encrypted Google Search - <AUTHOR> https://encrypted.google.com/

<comment><USER2> This has been around for quite a while now. What makes this news?</comment>


Your App Is Not Better than an Open Protocol - <AUTHOR> http://www.andjosh.com/2015/02/15/using-open-protocols/ <comment><USER2> Perhaps a bit naive - these companies that start by embracing open standards then pull back from them are just pulling a classic bait-and-switch, with a bit of freeriding off open-source efforts thrown in. They bootstrap their user base and arrive to market quickly by using tools built by others. Then once they grow and gain market and mind share, they can start closing themselves off, walling the garden.

And it's just business - it's a logical step for a profit motivated organisation. You're value is in your users and your brand. So you take steps to lock in your users, prevent third parties from using your services with through open protocols (which dilutes your brand). Nearly all the current crop of (once-idealistic) companies are at it. It's really time to start learning from history that you can't depend on private, for-profit companies to act in the common good - because doing so spreads the value around, and a company wants it all for itself.

<comment><USER3> Here's an idea: there should be a maximum number N of employees a company can have. This enforces companies to think about the greater good, because if you're in a company that is split because of size, you might end up in a different company. Also, a maximum on the number of employees stimulates the "modularity" of the market: large conglomerates with internal markets will not be possible anymore.

I'm not sure of all the repercussions, but perhaps we can start with N at a large value, and slowly (over several decades) decrease it, and see what happens.

<comment><USER4> An interesting idea, but it would likely result in the creation of a crap ton of (what in effect would be) umbrella companies.

"Google? No, I technically work for Search Ad Services by Google."

<comment><USER3> But think about it... Suddenly every company can have Search Ad Services as good as Google's.

Also, if you don't like what company X is doing, you just need to find N qualified people, and you can start your own X.

<comment><USER4> That's assuming that Search Ad Services by Google will have--or will be allowed to have--clients other than Google. And that, of course, is the entire point: to split a company up into what are technically smaller companies that, in effect, are just part of the head company.

<comment><USER3> Of course a company cannot be selective about its customers in a way that is anti competitive.

<comment><USER4> Ummm...yes. Yes, they can.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> I think the question is - better for who?

Clearly for many businesses, walled gardens, avoiding "openness", works. That might be because they use it to create an artificial moat to protect their business (arguably LinkedIn here), or because it's the best way to serve their customers (Steve Jobs' argument, not saying I agree).

For customers, if the best experience is gained through a native app, then a native app makes sense from the company's point of view. This is why native apps took off in the first place, right?

Just because you or I believe in open standards and information sharing doesn't mean it's better from everyone's point of view.

<comment><USER6> As much as the tech world loves to hate Apple, walled gardens are a huge part of why their stuff 'just works'.

Suppose you want an app to play videos. If your app uses a custom format no problem. If you support an open standard, the file might not, it might require more processing power than you have, it's probably for a different screen resolution, it...

In the end tech people are willing to trade stuff breaking occasionally for flexibility, but most people flip out when stuff breaks.

PS: I think you can break it down as do you want a VCR to show a movie to your friends, or a VCR that gives you an excuse to tinker.

<comment><USER7> Nonsense. Why does Apple have their own plug format instead of supporting USB? Is it somehow better? Easier? Blatantly not. This is just vendor lock in, the opposite of the fundamental ethic of the Internet.

<comment><USER8> > Is it somehow better?

Apple's magsafe and lighting adapter plugs are _far_ better than USB connectors. They are reversible and don't have tabs to break off on the device side.

<comment><USER9> Tabs?

<comment><USER8> [http://cdn.ndtv.com/tech/images/gadgets/Samsung_Galaxy_S5_fl...](http://cdn.ndtv.com/tech/images/gadgets/Samsung_Galaxy_S5_flap2_ndtv.jpg)

If you look close at in the connector on this S5 you can see there are two separate 'tabs' that are rather fragile if you are not careful removing and inserting your power cable. I've seen these break on phones before.

[http://images.anandtech.com/doci/8554/DSC_1380.jpg](http://images.anandtech.com/doci/8554/DSC_1380.jpg)

The iphone connector has no small fragile pieces like that.

</comment></comment></comment></comment></comment></comment><comment><USER10> > When Twitter was gathering steam back in 2009-10, it did so because tweeting > was done via SMS and not over a proprietary interface.

I don't believe this for a second. In 2009-2010, there were already a huge number of smartphones and Twitter clients out there. In fact, that time was probably better for third-party Twitter clients than today. Smartphone growth exploded in 2009-2010, so the idea that "everyone was getting a featurephone" is complete bullshit.

Has anybody here ever even used Twitter via SMS? Desktop and mobile apps _made_ Twitter. SMS was a niche thing at the very beginning.

I wouldn't even bother raising the issue if he weren't trying to premise his bigger point on it.

So that gets to his bigger point, which I'm not so sure about. Yeah, I can reply to Jira tickets from my email. But it's a huge pain. The replies end up with a whole bunch of email crap jammed into them, and it makes it harder to follow conversations. I usually edit other people's email responses to remove that stuff. So yes, it _can_ be done. And maybe it's just Jira, but in this case at least, it's a much degraded experience.

<comment><USER11> Don't forget about Twitter's API and liberal usage policy that made the plethora of clients and mashups possible -- I think this accelerated their growth more than anything.

Their API is not so "free" now -- you need to register your app, always authenticate, and there's no public firehose access any more.

<comment><USER12> This is a far better point. Twitter happened along in that magical time of AJAX when everyone was willing to share their data because we all talked about how everything should be free and open.

Then the social media companies realized that this was a gigantic mistake, and started to seal everything up. How could they be expected to make their billions when their services were so open that they were essentially becoming abstracted protocols for third party apps? The opportunity to sell advertising and personal data is far greater when what you have is closed.

I understand why they did it; I just hate that they did. It always felt like a massive bait and switch and I'm betting that Facebook and Twitter aren't going to be the last ones that do this.

</comment></comment></comment><comment><USER13> I feel like I'm missing something. We should use open standards like WhatsApp, who actually use a proprietary protocol that just seems familiar? We should avoid creating custom technologies like Flipboard, who actually embraced the open Canvas standard? Let's reminisce about SMS on Twitter in 2010 when smartphones were exploding and SMS was likely no longer the primary mode of interaction... This all makes no sense.

</comment><comment><USER14> SMS isn't an open protocol. So using it as an example of "what to do" is strange in and of itself.

This article falls flat because the author never defines what they mean by "open." SMS is a walled garden, it is controlled by the cellular industry in case the author missed that. Costs you actual cash money to use too (!) which might be a detriment to many.

</comment><comment><USER15> I don't like the shot at Flipboard here. HTML was designed for marking up (hypertext) documents. It's a perfectly fine language for marking up documents. It's a terrible kludge for defining application user interfaces, as anyone who has ever built such an application can attest.

What we're seeing now is a shift to JSON-over-HTTP from HTML-over-HTTP as the protocol of choice for connecting the internet, along with a whole pile of different tools for defining application user interfaces (partially because, up to now, no decent standard exists).

<comment><USER16> Not to mention that they open sourced their interface for rendering React on canvas, which is opens the door for more (smaller) companies to do the same. What they did is phenomenally friendly to the open source community.

<comment><USER17> Also Flipboard is no less accessible then it already was as a native application. The problems with making an app rendered in canvas can be solved (largely because they open sourced their work).

</comment></comment></comment><comment><USER18> This is far too naive. User Experience drives everything. If your open protocol is the best thing since sliced bread but it's too complicated for the audience who should be consuming it? It will die and an application with great user experience will take its place.

While I love open protocols and will use them as much as possible, at the end of the day I'm still going to do whatever it is that provides my users with the best user experience.

<comment><USER19> Lack of open protocol implies that client choices will be essentially limited to what the service provider offers. This is bad user experience.

<comment><USER18> > Lack of open protocol implies that client choices will be essentially > limited to what the service provider offers. This is bad user experience.

You're conflating the inability to develop for a protocol / platform for user experience. Having an open protocol can make a user experience better but it certainly doesn't have to.

<comment><USER19> I understand your point - the proprietary applications offered might be so vastly superior to any potential alternatives that would use an open protocol as to make the whole idea irrelevant.

But that supposes that all user needs can be met that way, which in a resource-constrained world cannot be true: the proprietary application provider will inevitably have to prioritize some classes of users over others. Those users whose needs are not within the functional scope of the application are going to find their experience quite horrible.

Only open protocols guarantee the potential for diversity that can cover provide all users with good experience - or with an experience at all...

<comment><USER18> > But that supposes that all user needs can be met that way[...]

No, it doesn't. Giving the user a good user experience does not mean it's the absolute best-end-all experience.

> the proprietary application provider will inevitably have to prioritize some > classes of users over others. Those users whose needs are not within the > functional scope of the application are going to find their experience quite > horrible.

The problem you're outlining here completely applies to open source communities, standard bodies and companies (it has nothing to do with open versus proprietary protocols). Everyone has to prioritize things and certain priorities will not meet the needs of all users. I would also argue that users whose needs are not within the functional scope of an application...should look for an application that meets their needs as best as possible. Not everyone is going to have all of their needs met with anything.

</comment></comment></comment></comment></comment><comment><USER20> I totally appreciate the point, and I think there's a certain amount of validity to it. Open standards and interfaces make it better and easier to consume data – in theory.

That said, there are complexities. Monetisation is the obvious one; if you have an app or service that relies on advertising—Twitter is the obvious example—then the first thing that you'll find is an app that strips your advertising out.

It also seems quite reasonable that a company like Twitter is entitled to payment by people who want to use the data they aggregate. Sure, they're not the publisher, but they do provide the infrastructure. We could hypothesise about replacing that with an open, peer-to-peer infrastructure, but nobody has done so yet.

</comment><comment><USER21> From the Flipboard page:

> You cannot build a 60fps scrolling list view with DOM.

I simply do not believe that. I have no problems scrolling around the internet. And the examples they give (flipboard.com/@flipboard) give me no clue about what their problem with the DOM is. I find it _really_ hard to imagine you couldn't do that in the DOM.

I wonder what is going on over there.

<comment><USER22> You cannot build a <dynamic> 60fps scrolling list view <with custom animations> with a DOM.

Can't complain; their results do look gorgeous.

<comment><USER21> I would love to see a minimal example of a "dynamic scrolling list view with custom animations" that does not work smoothly on my old Nexus 4.

<comment><USER23> As someone who spends almost every day working on mobile web stuff, I promise you - doing anything involving custom animations on scroll is awful. Because you have to hook into the onScroll JS event and change properties on the fly, the effect is usually janky at best. Particularly on iOS < 8, because it didn't fire onScroll events regularly.

</comment></comment></comment></comment><comment><USER24> I dunno, Instagram did pretty well for itself, despite being an (iPhone exclusive!) app at first. For a while, they didn't even have a web interface for viewing images, much less posting them.

</comment><comment><USER25> _"...Flipboard just announced their migration to full-canvas..."_

Ha-ha-ha, awesome!

So it's open, but you are not practically allowed to fix inconsistencies due to compatibility (especially outside of turtle-speed committees) and you are also not allowed to do things own way?

No, no. You have to use a document-oriented mark-up to create GUIs and for business logic you have to use/compile to a legacy language flawed from the day one which cannot be fixed!

"Open"? Really?

</comment><comment><USER26> True - and hopefully you'll keep that up with your new site/app once marketers, CFOs, and investors get involved, I think that's when things start growing walls and controls. As soon as someone mentions "monetization," hopefully it's only explored as charging your users a reasonable rate for a good service.

<comment><USER27> Pretty much any time someone mentions "monetization" they mean abandoning "reasonable rate for a good service" and "tricking users into paying more for subpar service" instead".

The whole talk about "monetizing" and stuff reminds me of 'dsirijus comment[0], "Any sufficiently advanced business model is indistinguishable from a scam."

[0] - [https://news.ycombinator.com/item?id=8227941](https://news.ycombinator.com/item?id=8227941)

</comment></comment><comment><USER28> "When I built out..." Saw that coming.

</comment><comment><USER23> Your app might be better than an open protocol if the open protocol doesn't do what you want it to. RSS is great, until you want to add a feature that RSS doesn't include. And let's face it, if you tie your business to standards ratified by standards bodies you're going to need funding for the next ten years or however long it takes them to ratify something.

</comment><comment><USER12> First:

"Open protocols power the web...RSS, SMS, plaintext-email, HTML5 - these are the easiest, fastest ways to get users into your system."

Then: "Flipboard just announced their migration to full-canvas"

Unless we have different understandings of what HTML5 is, I think you just invalidated your own point.

</comment><comment><USER29> The iOS 8 extension model could improve support for open standards. Some active iOS apps already support open standards:

WebDAV: GoodReader, Notebooks (Alfons Schmid), OmniFocus, Textastic, TouchDraw, Transmit (includes extension)

CalDAV: 2Do

Other recommendations?

</comment><comment><USER30> Flipboard addresses the accessibility issue in their article. While moving to canvas limits it for now, at least they are making an effort to incorporate it, which is more than can be said for most sites.

<comment><USER31> They're saying " _Whooshy effects are more important than disabled people accessing our app. We 'll let those people in when it doesn't impact our fancy UI._" It could definitely be worse, because they could ignore accessibility completely, but that doesn't make their approach good.

<comment><USER32> > They're saying "Whooshy effects are more important than disabled people > accessing our app."

It's a world of trade-offs. There are contexts where accessibility is obvious more important than most other concerns -- the IRS's web site should obviously be as accessible as possible because everybody needs to pay their taxes. On the flip side of things, the point of Flipboard IS the UI. Flipboard is all about aggregating other people's content and providing a different user interface to it. What Flipboard is doing is it is taking limited resources and trying to allocate them, and they're choosing to focus on improving the user experience for the vast majority of their users. Is that the right choice? I dunno. But I don't think condescendingly referring to their focus on user experience as "whooshy effects" adds anything to the conversation.

</comment></comment></comment><comment><USER33> So we should never create anything new, then?

<comment><USER34> No. You just must build your new things in such ways that your competitors can easily repeat them and your customers can easily migrate to your competitors.

<comment><USER35> Your competitors are going to "repeat" you and take your Customers anyway. If lock-in is your value proposition then you have no value proposition. Using open protocols allows your Customers to do interesting things with your service that you never envisioned.

</comment></comment></comment><comment><USER36> People don't pay for open protocols.

<comment><USER37> The aim should be to use protocols as a tool rather than direct source of revenue.

<comment><USER36> That's not what I mean. What I mean is that given two products -- one with an open protocol and one with closed -- very, very few customers will exercise a buying preference for the former.

</comment></comment></comment><comment><USER38> But how do you disrupt the industry, then?

<comment><USER37> In my opinion, disrupting an industry is more of "what you do" thing than how you do it.

</comment></comment><comment><USER39> This is crazy. Every open protocol starts with a proprietary app. Also, the examples cited make no sense.

<comment><USER40> > Every open protocol starts with a proprietary app.

Historically not true.</comment></comment>


Ask HN: Is the UI/UX in sci-fi usable? - <AUTHOR> Primarily asking UI/UX specialists. All those gestures and spoken words like in The Expanse seem quite tedious. <comment><USER2> They would be usable if the world's entire data (websites etc) would be stored as data (without any visual information) in classified databases and the interface would query the said databases. Then you would be working with streams of data and the UI would work as a set of filters, manipulated by the user in accordance with the desired outcome.

This would work similar to the UI in Oblivion and the interface to do the above would somewhat resemble it.

</comment><comment><USER3> Most of the UI/UX you see on movies are made just to appeal to your eyes. I've used the same models of some movies and they were increidble useless. They are made just for seconds of filmming not for daily use. They don't scale at all.

</comment><comment><USER4> What's not usable (besides some accessibility concerns) in "Computer, get me this", "Computer, do that"?

</comment><comment><USER5> I've always found the Sentry Gun UI in Aliens (1984) to be one of the more realistically usable ones.

</comment><comment><USER6> They're mostly appealing, yes. The question of usability should be changed to "Is it researchable?".</comment>


Raya – Real-time sound simulation library for games [video] - <AUTHOR> https://www.youtube.com/watch?v=EWatzCC7rk0

<comment><USER2> Nice. It remembers me what Carmack wanted to do in Quake 1: add a Potentially Hearable Set (PHS) in addition to the Potentially Visible Set (PVS) used for hidden surface removal of the game. After investigation, it seems that it was actually used in QuakeWorld:

 _An interesting extension of the PVS is what John calls the potentially hearable set (PHS)—all the leaves visible from a given leaf, plus all the leaves visible from those leaves—in other words, both the directly visible leaves and the one-bounce visible leaves. Of course, this is not exactly the hearable space, because sounds could echo or carry further than that, but it does serve quite nicely as a potentially relevant space—the set of leaves that have any interest to the player. In Quake, all sounds that happen anywhere in the world are sent to the client, and are heard, even through walls, if they're close enough; an explosion around the corner could be well within hearing and very important to hear, so the PVS can't be used to reject that sound, but unfortunately an explosion on the other side of a solid wall will sound exactly the same. Not only is it confusing hearing sounds through walls, but in a modem game, the bandwidth required to send all the sounds in a level can slow things down considerably. In a recent version of QuakeWorld, a specifically multiplayer variant of Quake I'll discuss later, John uses the PHS to determine which sounds to bother sending, and the resulting bandwidth improvement has made it possible to bump the maximum number of players from 16 to 32. Better yet, a sound on the other side of a solid wall won't be heard unless there's an opening that permits the sound to come through. (In the future, John will use the PVS to determine fully audible sounds, and the PHS to determine muted sounds.) Also, the PHS can be used for events like explosions that might not have their center in the PVS, but have portions that reach into the PVS. In general, the PHS is useful as an approximation of the space in which the client might need to be notified of events._

[http://www.phatcode.net/res/224/files/html/ch70/70-02.html](http://www.phatcode.net/res/224/files/html/ch70/70-02.html)

</comment><comment><USER3> It uses same algorightms 3d engines use to compute lightning and shadows

[http://youtu.be/IyUgHPs86XM](http://youtu.be/IyUgHPs86XM)

should be easy to implement in hardware in GPU.

BTW I seem to remember vaguely Carmack wanted to implement fully software 3D sound engine for Doom3, but some patent dispute forced ID to support Creative EAX.

<comment><AUTHOR> It's quite different from what we do. However we also do have working GPU implementations in CUDA and OpenCL :)

<comment><USER4> I have to admit, I thought it was just pretty standard ray-tracing as well. I'd be curious to find out how it's different. I followed the link through to the website, but didn't see much additional information on it.

<comment><AUTHOR> It's different mostly due to diffraction which is neglible in case of light and very important when simulating sound.

<comment><USER5> Diffusion is important for light too; see [https://en.wikipedia.org/wiki/Radiosity](https://en.wikipedia.org/wiki/Radiosity)

<comment><AUTHOR> Diffusion is not diffraction, they're different phenomena.

<comment><USER5> Radiosity simulates diffusion, though. Are you saying you also simulate diffraction? In visual rendering, that might fall under something called "caustics" or "photons" (I use quote marks because renderer photons are not quite the same as real photons).

<comment><AUTHOR> Caustics are caused by refraction or reflection, not diffraction. There are many analogies between simulating light and sound, but you take different shortcuts to make those simulations fast. E.g. you don't simulate diffraction when simulating light (it's effect is neglible) and you discard small objects when simulating sound. Those differences exist mostly because visible light spectrum and hearable sound spectrum are so far apart.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> Looks very similar to GSound: [http://www.carlschissler.com/gsound/index.php?page=home](http://www.carlschissler.com/gsound/index.php?page=home) But sounds like none of those uses HRTF for producing realistic binaural audio.

</comment><comment><USER7> Please don't even bother trying to peddle your stuff on HN. No technical content, nothing open source, why are you wasting our time? If readers in interested in this area: [http://googl.com/#q=acoustic+ray+tracing](http://googl.com/#q=acoustic+ray+tracing)

</comment><comment><USER8> It's actually pretty impressive, what do your licensing terms look like?

<comment><AUTHOR> Please contact bziolko [at] agh.edu.pl for information about licensing.

</comment></comment><comment><USER9> Does it simulate different delays for left / right ear?

<comment><AUTHOR> Yes, we have implemented HRTF ([http://en.wikipedia.org/wiki/Head- related_transfer_function](http://en.wikipedia.org/wiki/Head- related_transfer_function)).</comment></comment>


Followup on ERP Thread: How I Plan To Do ERP - <AUTHOR> This is a follow up to an earlier thread about a custom firetruck manufacturer who went bankrupt because of a bad ERP implementation.  I mentioned that this was a great area of opportunity and was the focus of my start-up.  After a little discussion and debate, I received several emails asking what I was up to.  As promised, here goes...
First a little of my background.  I have built a career working on roughly 30 clients' ERP systems.  They ranged from $1 million in annual revenues up to about $100 million with a several more in the Fortune 1000.  Many different industries were represented, mostly in manufacturing, distribution, and retail.  I also wrote several modules for ERP software vendors.
My "typical" assignment went something like this:  We bought this extremely expensive state-of-the-art ERP system that our auditors insisted we get (and probably received a kick-back for).  We got the thing up and running, but it doesn't do business the way we do, so we are hurting.  It must do <requirement>.  We do have the source code (at least someone was thinking).  We want you to get <requirement> to work.  As long as I had the source code, I was always able to satisfy their requirements.
I realize that my view may be a little skewed because I only got calls from clients in pain, but in all those years:
- I never saw a Class A ERP Implementation.
- I never met anyone who saw a Class A ERP Implementation.
- I am still shocked by how expensive software and services are.
- I am still shocked by how utterly poor the software is.
- I am not surprised by how ineffective ERP (and enterprise software in general) is.
Because the software is so complex (sometimes for good reason, often not), the general concensus is that it's too hard to write your own; you must buy a package.  Since the software is already written and field tested in other businesses, then you should be way ahead.  But you're not.  Here's why.
No two businesse are exactly alike.  Often not even close.  The very act of survival requires many businesses to differentiate themselves to find a competitive edge.  This differentiation is often in an area already standardized by their packaged software.  So it doesn't work.  And can't.  I've seen it over and over again, in every function of the business.  The nomenclature for SKUs, customers, vendors, you name it, the method of processing orders (sales, work, purchasing), accounting methods, unique ways of marketing, selling, pricing, branding,...  I could go on and on, but you get the idea.  It could be anything, and as soon as it's in a function controlled by your standardized software package, you have a choice: do it their way with their software or do it your way without the software.  Or call someone like me.
Then there's the elephant in the living room problem: the software is loaded with bugs to begin with, complicated to use, and difficult, expensive, and time consuming to implement.
After living this life for too many years, I have developed several beliefs:
- If a business is satisfied with a process, then the software should be made to support the process, not the other way around.
- Quality software has an extremely solid base, is well written, and easily maintained.
- Good software requires little or no training, documentation, or procedures, and is ALWAYS easy to use.
- The current state of packaged enterprise software is almost the exact opposite of everything that I believe in.
- Many business people are dying for what they really want while tolerating what they have.
- Current web-based technologies (and people like us) have finally made the unthinkable possible:
CUSTOM ENTERPRISE SOFTWARE IS THE ONLY WAY TO GO.
25 years ago, everyone laughed when the engineers from Wang, DEC, HP, and Qantel put ERP on mini-computers.  It'll never run, they said.  It did.  Then they laughed when the next generation of engineers got it to run client-server.  But that ran, too.  Now they'll laugh when a nut like me starts telling my customers that they don't need to buy an ERP package anymore.  They can roll their own with modern technology and people like those on this board.  Between AJAX, web apps, new languages, frameworks, and platforms, and the people who know how to use them, it is now becoming more effective to write your own.
The critical path will once again be the analysis phase - determining exactly what to build.  This has always been and will probably continue to be the weakest link; so few know how to do it well.
So here's what I'm doing.  I'm NOT writing an ERP package.  I'm building a platform and methodology upon which a small but very effective "tiger team" of analysts and developers can roll out a custom enterprise solution for any small or mid market business.  A solution without compromise, better than any "lowest common denominator" software package available, even in their SIC code.  Something that can be delivered in weeks or months, not years, and can be priced competitively and reasonably.
I welcome feedback on what I've just presented here, but please don't tell me it's stupid or won't work.  I've already heard plenty of that.  I'd rather not share much detail in a public forum like this one, but would be glad to continue this discussion with anyone who'd like to. <comment><USER2> I work at a fortune 100 company; my only ERP interaction is occasionally entering an equipment purchase order via an Oracle system. It sucks, so you're preaching to the choir.

Nevertheless, I'd still have to ask the following:

1) Your beliefs are easy to agree with, but how do you get your first 10 customers to believe that your solution upholds these beliefs?

2) How do you sell the idea of 'writing your own' to a business person who doesn't want to become the head-contractor for a software team?

3) Keeping in mind my white-hot ignorance about this particular vein of software, I'd want to know if the problem is really with the software? Or is it a problem with understanding the process and the implications of implementing it a certain way (ie, can processes interact? do we know if they will at specification time?)

4) How smart does the tiger team need to be? An ideal system should be reasonably easy to implement by average programmers.

5) How do you sell developers on learning your platform? A customer might be concerned that not enough developers know your ERP well enough to implement future extensions.

6) How do you sell customers? You're competing against the well-oiled sales machines of your larger competitors, and all but the smallest businesses may not mind spending $1M to ensure that their all-important business processes are implemented with a well-known ERP (poorly implemented or otherwise) that they can trust their business to....

I guess one way to counter this may be to make the ERP free (open source), and have a team of core developers/contributors who could then charge $ for implementation.

Don't mistake my concerns for a lack of enthusiasm. This is a field ripe for improvement, and you seem to have the ideal background for it.

<comment><AUTHOR> Thanks for the feedback. Great questions.

1\. You deliver.

2\. You deliver superfast.

3\. My experience: 95% of the time the problem is with the software. They will willingly teach you their processes if you know how to ask and are patient enough to listen.

4\. Very smart. That is one of my biggest challenges right now. My compliments on a great question.

5\. Success breeds following. I don't want customers that are worried about the wrong things. There are plenty out there who aren't.

6\. Every way you can. They are everywhere. I don't worry about "competing with well oiled sales machines", I relish the challenge. In the first hour, while they're still pontificating over their 4 color brochures, I can have a prototype up and running that addresses their biggest challenge. They should be worrying about me.

Great questions. Spot on. I never signed up for easy.

My experience over and over and over is: when you find out what's needed and deliver "something" very quickly that addresses it, you get their attention. Right now, I'm salivating just thinking about it.

<comment><USER3> Why is this approach better than starting with Apache Open For Biz project or some other OSS ERP system (if they exist)?

<http://ofbiz.apache.org/>

</comment></comment></comment><comment><USER4> That is exactly what I'm doing for my day job. We evaluated a ton of ERP/MRP providers, and they were all A) Extremely expensive, and B) Awful. So I lobbied them to have it be made in-house.

It is currently being done with only one developer. We're 6 months into the implementation, and are piloting in several of the modules. It is going pretty well so far.

If it continues to go well, we're considering spinning it out into its own company. A well-designed and user-friendly ERP system is a killer asset to have, and being able to resell it is an even bigger one.

I've come to pretty much the same conclusion as you, about customizing. I figured we'd have a "standard" set of modules, which would either be completely replaced or slightly modified as necessary to fit the client company. Certain things like maintenance, receiving, purchase orders and sales teams probably don't vary much between companies. Other things like manufacturing routers and change orders probably do. This would allow us to be flexible where it is necessary, and to reuse code where it is not.

As a side note, we're hiring another developer to work on this system. IC to start. Let me know if you're interested.

<comment><USER5> If you're developing an in-house system you should try to stay away from thinking about spinning out into a separate company. If/when you are successful you can asses what is needed to make the software into a viable product. I would focus on building something that works for in-house use only and not try to make it any more modular or extensible than absolutely necessary.

</comment></comment><comment><USER6> "Vanilla is the best flavor."

One of the smartest healthcare IT managers I have dealt with said that regarding enterprise hospital software. The major hospital products have the same issues as ERP products: they are very expensive and implementation projects tend to involve a lot of painful customization. After getting burned a few times that manager swore off customization altogether. Now if they decide to buy a commercial product they implement it as-is, even if that means changing the business workflow to accomodate the software. Over the long run this has delivered much better results.

I don't have much direct experience with ERP but I question whether all those businesses are unique and special snowflakes that really need custom software. Are organizational differences in common areas like inventory control and accounting actually adding any value? In most cases I think they could be standardized without any long-term loss. So then the only reason to customize is to avoid the short-term pain of reengineering current processes.

I don't think your idea is stupid. There are already plenty of other custom development shops doing similar work. So if you hustle and deliver results I'm sure you can win a decent share. But unless you focus more on building a real product I think you may get stuck at just having a small "lifestyle" business rather than something that would be attractive to VCs.

<comment><USER7> Incidentally, this is how all software used to be. When software was an add-on to the millions of dollars of hardware you bought, all the software was custom-written for the purchasing business. Once computers got cheap enough that many, many more businesses could afford them, there was an economy of scale that enabled mass-produced shrink-wrapped software. When the software cost went from hundreds of thousands of dollars down to thousands of dollars, businesses changed their practices to match the packaged software because it was cheaper than writing custom.

I'm not sure what would ignite that change in ERP because I think the number of businesses that need that scale of organization isn't going to increase dramatically, so there won't be economies of scale. I guess a valid question would be - how many companies aren't using an ERP at all that would benefit if one was available at the right price? My computer centric view makes me forget that some people still use paper and pencil, land lines, and write checks.

</comment></comment><comment><USER8> Great minds etc.

I was also looking at ERP after working in the field for a number of years. I was planning on coming from a very different angle. Hosting a very configurable system that required little or no manual intervention. Aiming at small business for a $20 per month per user fee.

Then I discovered I hate running a business, not just dis-like but hate so much I never want to do it again :-(

I think your idea could take off but the software has to be malleable, this is in contrast to nearly every piece of software written to this day which is brittle. I was looking at this as just a way to predict how software will be written in the future.

First off read a couple of books to understand better where I'm coming from :-

        Necessary But Not Sufficient by Eliyahu M. Goldratt
        Naked Objects by Richard Pawson

From a business perspective I want a group of classes that mirror real world items e.g. Order, Invoice, Address, Amount, Price, Date etc. Then I want another group of classes that handle business actions e.g. Enter Order, Print invoice. Lastly a group of classes that handle business process e.g. Process Order, Calculate invoice etc.

The above would give you a group of objects that you can model the business with and forget about technical details.

Then the underlying system could be built e.g. fully temporal, fully redundant etc. etc.

The idea being that you could focus on business processes without thinking about implementation details. In true naked object style the UI would be automatically generated from the business action/process classes.

To make what you are thinking about work _ALL_ design has to be KISS and DRY. Also, the more you can generate the better you'd be.

I was thinking of using Lisp or SmallTalk to gain an advantage, must use a VM to be able to separate business from technical. I want to my software running 24/7 with zero downtime including during upgrades, automatic rudundancy, load balancing etc.

If you are thinking of something along these lines then drop me a line and I'd love to help.

If you just want to re-implement the current paradigm don't bother contacting me. The current paradigm is so broken it's not even funny.

<comment><AUTHOR> The quality (and apparent sincerity) of your reply merit a full inhaling of your 2 references. I'm off to Amazon as soon as I finish typing this.

"The idea being that you could focus on business processes without thinking about implementation details."

Bingo! In 18 months of sharing this concept, I think you may have closest to understanding it (or at least explaining your understanding).

"Then I discovered I hate running a business, not just dis-like but hate so much I never want to do it again :-("

I may be the yin for your yang. I can't wait to have a business to run and customers to serve! Seeing a customer achieve their goals with my support is like oxygen to me. I have to have it. I love hacking, but it's only a means to an end. If I had something to implement, I'd be implementing, not hacking.

Kindly put your email address on your profile and stay in touch.

<comment><USER7> I'm in the same boat as ajmoir. I thought of implementing is as a DSL for businesses - let the "tigers" specify it in the DSL and then the implementation can be upgraded underneath the definition. Naturally, Lisp would be a good fit. I do enjoy the success of seeing customers achieve goals, but I prefer the tractability of engineering systems over the political systems of the real world. I'd certainly love to hack for businesses if there was a thin wrapper over them (ie business oriented cofounder). I've already emailed you expressing interest in your project, so keep me in mind too!

I haven't read naked objects - maybe that would help me get over my general distrust of OO. Thanks for the recommendation!

<comment><AUTHOR> I'm sure we'll be talking again. In the meantime, save $60 (for the time being) and get started on-line:

<http://www.nakedobjects.org/book/content.html>

</comment></comment></comment></comment><comment><USER9> I worked at Black & Decker for 5 years implementing SAP. I also wrote custom software to integrate into SAP when their modules didn't "fit" B&D's needs. A Manufacturing operation is really an incredible orchestration of different people in different departments, but those departments incentives and measurements aren't always aligned with one another. A large ERP system like SAP makes these departments tightly integrated and there is a lot of battling for territory. One department may make and entry to move inventory around for their own purposes and that will affect another department adversely. My experience makes me believe that ERP systems should take a more loosely coupled approach so that each department can have it's on custom software and communicate with other departments via a standard interface like XML. Also don't discount the fact that some corporations benefit from the inflexibility of ERP software. Most high level people I worked with liked the fact that they could dictate from a high level how things were to be carried out, even if they weren't the people who knew the process the best. I can promise anyone who interviews 4 different people in a manufacturing plant, at different managerial levels, about processes in the plant, will receive at least 3 different answers. Every guy there thinks he knows what is best and he controls his fiefdom how he sees fit. Very often the Corporation uses software to dictate to him how he will do his job, and that person will usually bitch about the ERP system because if they bitched about the plant manager they would get canned. You are tackling a huge problem and I would be interested in keeping up with your progress, so if you need anyone to bounce anything off of...feel free to drop me a line.

</comment><comment><USER10> In my experience, the best way to break in is to find a process that either isn't handled or handled only tangentially by existing ERP packages. It helps too if that process represents a new way of doing business for your customers. That way you get to pitch for growing the top-line (i.e. creating dollars that didn't exist before your software came on the scene) vs. bottom-line savings that just cut costs.

Not to throw cold water on your idea, but I have deep reservations that pure technical expertise in generic enterprise development/implementation will win anyone over. All of the big guys plus numerous other consulting companies already offer this, with much more name recognition (deserved or not) than you will have. Additionally, one of the main features of packaged software is that customers not only are loathe to manage a development process, they are reluctant to even engage one in the first place.

But if you can distinguish yourself by being The Smartest and Best (TM) in a particular business area, all of your skills in execution can back that up and create a winning operation. But without that domain focus and expertise the story is much less compelling.

</comment><comment><USER11> Here's the biggest challenge I think you face. Because ERP is so entwined in a how a company does business, it's really hard to create a "bottom-up" solution. Executives have to be involved, you'll need sales people to explain things, and - most important - you won't really know how it goes until after the implementation. This means there is little incentive to create good software. Once the customer has spent a ton of time customizing it and retraining employees, they're not going to switch away just because the product kind of sucks. The highest quality software is found in consumer apps like GMail that are really easy to switch away from.

Is there any way you can make your solution have minimal up front cost and to be rolled in gradually, similar to the way that Salesforce and now Google Apps spread? That way you can compete just based on quality - not on sales ability. That will in turn force you to make the solution great, and you'll end up kicking everyone's ass.

<comment><AUTHOR> "Here's the biggest challenge I think you face. Because ERP is so entwined in a how a company does business, it's really hard to create a "bottom-up" solution."

Right! That's why packages are the default.

The way to break the "software package mindset" is to learn how to conduct analysis. There are a lot of good hackers out there, but hardly anyone knows how to do analysis anymore.

There's not much magic here. Just unrelenting legwork...

"So, Joe, what do you do with the Work Order Traveler when Julie runs out of X17 components? You give it to Fred? Fred, what do you do with it? What, Joe doesn't really give it to you, he passes it by Jose first? Is this true, Julie? Why does Jose need to see it?..."

"Then what happens?"

"What do you do if...?"

"How do you know if...?"

How do you know when you're done. When everyone agrees that you're done. Then you build it.

Ever seen anyone do this well? I didn't think so.

</comment></comment><comment><USER12> Sounds like you have a track record, you've hit upon a legitimate pain that people would pay to make go away, and you're starting to think about how to fix this by doing it, which is probably the only way to do it.

This puts you way ahead of a lot of other entrepreneurs.

<comment><AUTHOR> Thanks. For years, I've toiled in an area where there's often not much logic. I've always said, "There's gotta be a better way." Now is my chance to put my money where my mouth is.

</comment></comment><comment><USER13> Your complaints are not limited to ERP systems; I can certainly vouch for this viewpoint.

I think you biggest problems is going to find the first few clients. Nobody is going to believe you when you say that you can do more with less. Elephants in the room are impossible to see before you tear down the wall and lead it out into the sunshine.

Any ideas? I'm in a similar situation regarding group benefits administration, and I think I could even pull a sale or two based on past encounters, but you're talking about changing entire industries (and shifting a lot of profits in the process) here.

<comment><AUTHOR> You're right. It's hard to get started. But they're out there. Everywhere. They just don't know what to do and where to turn. Finding a way to get connected is one of the biggest early challenges.

<comment><USER13> You need to find a CEO willing to take a chance. I'd look at one who has built a smaller company from scratch, (say 250 ee's) and is now finding it difficult to expand into the leagues of the big boys. He/she is looking for an edge, and is likely to take a risk to obtain it.

</comment></comment></comment><comment><USER14> The worry there is you have to have a big part of your business be for a sales force to cater to these large companies which take forever to make up their mind - unless I'm missing something?

<comment><AUTHOR> Yes, large companies do that. I'd rather pick the lower hanging fruit. Small and midmarket companies often approach me with ideas and questions. THEY are the ones I'm targeting.

(Just for a laugh, go to any local Chamber of Commerce or Tech meeting. Ask how much they like their business software on a scale of 1 to 10. Take plenty of business cards and find a way to deliver "something".)

</comment></comment><comment><USER15> This business adventure seems GREAT! I totally agree that each company needs software designed to their needs not that their needs must revert to match the software.

However, Your biggest problem is going to be. Can the company truly convey their needs so that you the programmer can build an ERP system for them.

Yes a Tiger Team can aide in this process but it has been my experience that not all companies are aware of all their assets when it comes to selecting a team that can convey their needs.

</comment><comment><USER16> I hate to sound harsh, but there's nothing here to disagree with. You're not taking any deep principled stand. You're saying "I like puppies." and "Ice cream is yummy."

What is your system NOT going to to do?

What are you going tell you customers you WON'T do?

If you're just saying YES to everything, there's nothing left to argue. And, from my experience, the company will die a death from a thousand papercuts as your sunk under the weight of over-promising.

<comment><AUTHOR> So then, all I have to do is deliver what I promise, right?

<comment><USER16> At one level, yes.

But again, that's feel like an empty platitude.

The exercise I think you should consider is examining what you're NOT going to do. Don't reduce this to a BS exercise interview question of "What are my weaknesses" and answering "working too hard."

Give it a real go: figure out what requests you're going to answer NO to.

Look, I don't mean to be harsh, but is really, really easy to say YES. It's our default setting. Especially if you're in sales.

But if you don't figure out how to say NO, then delivering is extraordinarily difficult.

Start small: say no to clients that are too big (or too small). Set a threshold. Limit the number of backends you have to interface to. Limit it to non-realtime.

But try to bound the product to something you CAN deliver.

<comment><USER7> While I agree that it's a good idea to start with some limits, with a business model like this (few customers, mucho $$/customer), it's probably better to let the first few customers dictate what to start out with. Of course the early product can't be everything to everyone, but it can be everything to one client! Then it's a base to build off of, finding the next client with similar needs and adding the diff to the product base. This way, as the diversity of customers grows, the product will grow with the business and open new opportunities.

Having said that, I'm curious to know what you think your first customers will be like (size, industry, etc).

</comment></comment></comment></comment><comment><USER17> This is all about business processes, application integrations, and integrity (and security) of data.

Think SOA, ESB. Combine that with Utility computing (Amazon EC2, IBM, Microsoft, and Google also entering that space eventually) and many many provider's with connected or disconnected processes but with compliant interfaces into the extended (internet) service bus...

Big fat ERP is so 4 years ago.

</comment><comment><USER18> > CUSTOM ENTERPRISE SOFTWARE IS THE ONLY WAY TO GO.

I don't want to be repetitive, but this is the same conclusion the OFBiz guys arrived at, which is why they have a very flexible, open system that is licensed under a liberal license. I'm not wild about all the Java and XML involved, but they've got a really good community going, which counts for a lot.

</comment><comment><USER19> I won't tell you your plan is stupid. On the contrary, I believe it's an idea whose time has come (I think it's come more than once). Nor will I say that it won't work, though it will certainly be a hard road to slog.

I comment as someone involved in roughly three dozen ERP implementations (along with a dozen or so CRM and HRMS) over the past decade, for a number of mid-market and larger enterprises (mostly North American, a few international), across the manufacturing, software, healthcare, and pharmaceutical industries, in many roles ranging from developer, to technical architect, to implementation manager.

We have a number of experiences and opinions in common: (a) I too haven't seen (nor met someone who has seen) a class A implementation, (b) I'm still appalled at the poorness-of-fit and poor quality of this class of software, (c) I remain utterly unconvinced that the current model of ERP software development and implementation will _ever_ produce a modest-cost system.

Of your line "No two businesses are alike", nothing could be more true, and nothing could be more at the heart of the misfit between desire and reality in this software space.

Every business has grown their own a wide variety of their own processes. In smaller businesses, these process are unique. In larger ones, these are fairly standard, but only to a point. There isn't a single company where one can 'drop-in' a business process from another company and have it work without mistake. (You realize the impossibility of this by how silly my example sounds.)

Not only are there dissimilarities between businesses that prevent standardized software from working out-of-the-box, there are also dissimilarities within businesses that make the off-the-shelf solution unappealing.

Consider that a good number of mid-sized and large businesses are an ungodly combination of merged, acquired, downsized, and spun-off companies. (Somewhat like the custom firetruck manufacturer you used in your example.) How often does the surviving company from a merger, acquisition, or spin-off cleanly adopt a uniform set of business processes from their predecessor organization(s)? In my experience, not very often. You will find many pockets of heavily-resistant 'non-standardization' in mid-sized and large firms.

So no two businesses are alike from the outside, and few are even uniform from within. Now consider how many forces of change are pressing on a given organization.

New management: how often has the new CEO, new division head, new head of operations come in wanting to put "their stamp on the place" and decided that the old way of doing things just won't work? The new sales head decides a territory realignment and new incentive compensation plan is the way to start. Hey Mr. ERP? We need something from you.

New competitive responses: Oh I see that our main competitor now has a new offering that completely sinks ours. Time for more than a SKU respin, time for a whole new product, new packaging, new bundling, new discount strategy. Hey Mr. ERP? We need something else from you.

New channel strategies: Your distributors and their resellers are now pressing you on margin, they're demanding better insight into supply chain, their business systems are better, faster, and more responsive than yours. Hey Mr. ERP? Here's another thing we need from you.

New regulatory environments: Sure you can usually see these things coming years ahead (HIPAA, Sarb-Ox), but they demand change to the business, which means change to the businesses software systems. Hey Mr. ERP? Are you listening?

New IT changes: moving from Unix to Windows, moving from self-hosted to colocated, moving from insourced to outsourced, moving from here to hell and back. Hey Mr. ERP? I'll understand if you want to stick the shiv in yourself and save me the bother.

Lightly into this morass tapdances the ERP software industry. It promises the essentially undeliverable: we can sell you a bunch of software that _will_ allow you to uniformly conduct business across your enterprise. Forget about all of the sources of non-uniformity described above, and forget about the fact that your business is itself different from one division to the next, and from one year to the next, and that change is a constant. We'll give you a modular system which you can glue together (using the expensive services of our various third-party partners) to fit your unique business requirements.

Strangely familiar lyrics? That's right. You're listening to the pied piper. Keep your children close at hand.

But, you say, the ERP industry _is_ doing this (for WalMart, for Boeing, for the Home Depot; for 3M, for AT&T, for Staples; heck, even for your neighbor's mid-sized $50M dollar electronics manufacturer, or your former bosses $20M industrial supply firm.)

Just how are _these_ companies making ERP work? They're squeezing their size 12 body, with their 38DDs, into that svelte little one piece they saw on the runway, hoping like hell a seam won't bust before the photographer gets the money shot in the bag. Short answer? They're shoe-horning their business into the ERP-maker's box.

If one of their existing business processes doesn't fit, they'll stop performing that process to make themselves 'work' with the software. If one of their processes is more efficient, they'll forgo efficiency for the sake of harmony with the software. If an existing practice gave them the flexibility to deal with odd customer requests, they'll become rigid in order to keep from changing the software.

In the end, though they don't know it, they've tied themselves to a rock, and are slowly wading into deep water. Yes, they're now standardized and have mated their business to an ERP, but the real cost of doing so is a hidden one. Everyday, their business loses time, money, efficiency, and customer goodwill, as their business now does business according to the dictates of the ERP firm.

Sure, it's natural for ERP proponents to counter that the business is now truly more efficient for having standardized their business processes across the board, is now faster as the computer can calculate things much faster than people could, and is far less error-prone by being able to check and double- check things in real-time.

Well there's no point in getting into a huge he-said, she-said over this. Just ask yourself, though, when was the last time you truly ever saw a real apples- to-apples comparison of the cost-benefits of an ERP implementation? May I say, after having been involved in well over 30 of these myself, I've never seen a real comparison. I've talked to many colleagues, who've also never seen a real one.

So all the damage behind this is what (I presume) prompts your idea.

Forget about the large-scale ERP software packages--they are too bloated to be the right fit for any single organization, too crufty a code base to ever be called well-written and maintainable, and too buggy to be reliable, bet-your- business platforms.

And yet, it's not as though the ERP makers deliberately set out to write shitty software. At one time or other in the distant past, they hired some really smart people, and had them grew some fairly impressive software. Impressive (when viewed through the eyes of a software developer, at least) for it's depth, breadth, flexibility, documentation, platform adaptability, updateability, price, etcetera.

So there's a lot for you to do, and a great deal of resistance to overcome. I wish you the best of luck.

</comment><comment><USER20> What is ERP?

<comment><USER21> ERP = Enterprise Resource Planning

In this context, you're buying a database and an application to manage inventory. And people. But people are just inventory with different expiration dates. They really are designed to do contain EVERYTHING a business does. If there's a procedure for doing something, it needs to be in the ERP.

You mostly have two options in the status quo, as the poster said: Pay to have it customized ($10,000,000 total budget (hardware+software) for a 4,000 employee organization isn't unusual) or conform to the ERPs methodology.

<comment><USER20> Thanks for the info.

I must admit, it sounds like a horrible idea to me... I strongly believe that business processes should be able to evolve, which would presumably not be the case with very expensive software (every change is complicated and expensive). The evolution should also be bottom up - the people involved in a process should be given the ability to change it, if they see that it has flaws.

It sounds to me as if ERP is just a LOT of TPS reports waiting to be written...

<comment><USER22> For big companies the continued survival is stability in their operating process. ERP plays heavily into the role of managing large amount of resources.

</comment></comment></comment></comment><comment><USER23> When I gaze into my crystal ball, I see Amazon offering the best components of their ERP system as API-based services. Web developers will move up the value chain and provide custom interfaces for companies who want that.

</comment><comment><USER24> Your analysis, as far as it goes, is spot-on. Here's a link to somebody else who appears to share your vision: <http://www.thingamy.com>

Go tiger, go!

<comment><AUTHOR> Cool link. Thank you.

</comment></comment><comment><USER21> Let me say from the outset that I agree. So this criticism really is friendly criticism. Also: I have little hope, though I want to hope. So...

1) The concept of ERP is flawed.

ERPs are basically trying to solve the problem of documentation. Remember, ERPs were developed by IT. And they're what happen when IT people try to solve a problem using IT tools and IT methodologies. Now, is there some good there? Yes. Steve the Secretary can't quit and take his 20 years of experience out the door with him. "Where do I find <x>?"is never[1] a question post-ERP, because the process is well-defined.

Think of it this way. You already have a business (program). But you have a problem in that the founders are getting old, or workers are getting old, or things aren't being done consistently (no commenting). So with this massive program, you're going to cull through the processes people are already doing (source code), and evaluate them (optimize) and then implement a consistent approach (document the new code).

Guess what? That's hard to do with 20,000 lines of code. Now do it with a thousand employees. Oh, and make sure they remember that "one person" they call once a year to make sure your biggest customer gets their fruit basket every Christmas.[2]

"Well, all this sounds like a good idea!" you're saying? Sure, in a sense. But here's the flaw: just like good code, a good organization needs documentation from the very beginning. And that's my first criticism: don't get into the business of going back and documenting things that should have been done. Get involved in being involved from the very beginning. Of course, that's harder to "sell" -- small businesses have smaller ERP needs because there's less of an enterprise. So you'll make less profit. What makes me hope against hope: your solution could grow as the organization grows.

2) Big business is better than small business

There's a reason most ERP customers are big businesses: they have a lot to lose with knowledge leak.

But that's not the real reason. The real reason is that they're most able to benefit from the ERP while minimizing the cost of implementing the ERP. How do I know this? Big businesses usually get big because they have good business practices. And they're good at communicating those practices to employees. That is, they have good procedures and good documentation -IN THE FIRST PLACE-. So the process of encoding that is, while not without incident, not as hard as it could be. A small business that stays small because of the high training costs they incur every time someone moves on, or who doesn't follow procedure well so is unreliable, or what have you--THEY'RE the ones that have the most to -gain- from an ERP, but they're also the ones least able to bear the costs of documentation. If you're following the analogy, large enterprises already have some documentation, but have some poorly-documented interactions or classes. On the other hand, many small businesses have far LESS documentation - either because they don't need it ("Only 100 people, we can communicate it!) or they're just bad at it.

All that to say: the people you're marketing to are least able to meet the needs of the requirements / planning phase. That's a problem. I think there are solutions, but your post makes it sound like they're (smaller enterprises) are the EASIER customer, and I don't think that's necessarily (or even often) true.

3) ERPs are not modular

ERPs are almost the perfect example of the corporation existing to protect its own existence. "We've got a good thing here," says someone high up, "Let's keep it that way." ERPs -sell- themselves as being modular and adaptable and nimble. "Nimble" doesn't need a multi-million dollar budget, a hoard of consultants, and two years.

Say your HR department figures out a method of processing applications that increases processing speed by 10% with no degradation in quality. Without an ERP, the head of HR (maybe) checks with their VP and then tells everyone below them to change, and that's that. Good luck making that change post-ERP.

And this is the downside to the upside I mentioned above. Steve the Secretary can't quit, but Gillian the Genius can't get hired and have a brilliant insight that rapidly streamlines processes. (Which, I suppose if you really think about it, is what enables ycombinator: large organizations with non- malleable standards need to outsource innovation. Lucky us!)

The plus side: although the cost of inter-departmental interaction change goes up, the intra-departmental change is (comparatively) easier.

I think your system could benefit in modularity, especially if the ERP were "in the hands" of the people. But that, of course, increases risks.

The bottom line: if you build for modularity (really build for it, not in the "The salesperson told me it was modular" sense) from the beginning, it would be amazing. But you have to really build for it. And I know you get that, but I don't think I can say "really" enough times here.

The BEST of luck!

[1] If you listen to marketing. There are still problems with finding things post-implementation, but I will concede these types of problems are significantly reduced. The -real- loss now is, "How do I get <x> done when the ERP doesn't want to let me?" - and THAT answer is far more valuable, in my opinion, and far less often documented.

[2] Dramatization (barely)

<comment><USER4> 1) I don't think so. The real win is for an ERP is not processes, it is reporting. Being able to examine every aspect of the business in ONE place in a real-time fashion is an amazingly huge boon for businesses. Businesses succeed not because of good processes, but because of constant improvement. You can't improve if you don't know what to improve. A good ERP implementation will solve this with good reports.

2) For a startup, small businesses might actually be better. They might still be able to spend a decent chunk of change (.25-1M) on an ERP system, but have much lower requirements making an easier implementation that is less likely to fail.

3) ERPs aren't really modular, that is true. I'm not sure there is a win to a real "modular" ERP system. The who idea behind an ERP is that everything in a business is connected, so the systems should be connected too. Sales people are connected to orders are connected to finished goods are connected to build processes are connected to inventory are connected to purchase orders. Removing one "module" in that chain defeats the purpose of the ERP.

<comment><USER21> 1) While that's nice in theory, the dashboard data has to come from somewhere. And it comes from the processes people go through. Combining the multiple application interfaces into one isn't merely a process of collecting data: it's also collecting processes. If all you had to do was collect data, ERPs would just sit at the junctions of your current data interconnects and feed all the data upwards. But that's not what happens.

2) I agree that smaller is better. But smaller isn't better when it comes to being able to set up requirements.

3) And it shouldn't. I should be able to say, "We're now doing A B C 4 E instead of A B C D E" and not have that change (assuming it's low enough) initiate a 4 week process of review before it ever has a chance of "going live". That -keeps- people from making the suggestions that evolve an organization.

Thanks for the comments.

</comment></comment></comment><comment><USER25> If you get the execution right you are headed for greatness :-)

</comment><comment><USER26> You are spot on.

</comment><comment><USER27> How about in some way using emacs? The tiger team would develop the elisp needed to cater to the company.

<comment><USER28> I so almost distroyed my keyboard with coffee.

Well except I read that there was an emacs macro that business folks at Amazon used for years. Hmm, maybe if there's an ArcEmacs rewrite?

<comment><USER3> The last thing Emacs needs now is a web server embedded in it.</comment></comment></comment>


Sony confirms Lulzsec compromised server data - <AUTHOR> http://news.cnet.com/8301-31021_3-20068857-260/sony-confirms-lulzsec-compromised-server-data/

<comment><USER2> they should really make a department for hack cases now.</comment>