Here are some arguments I have heard to support the competition between open-source application generator projects and my rebuttals. Let me know if you see any holes in my logic.
Competition drives innovation
1) In capitalism, companies competing against each other drives innovation – TRUE
2) Open Source software is like capitalism – FALSE
3) Therefore: Open-source teams competing against each other is necessary to achieve innovation
In capitalism, people are motivated by money – a limited resource for which companies must compete. Innovation is a happy by-product of competition in this particular situation, but there’s more than one way to get innovation. Just look at all the innovation that comes from university research of teams that are either the only ones researching something or are cooperating with separate teams.
In open-source software development, people are motivated by a few things: reciprocity and social acknowledgment are up there. An opportunity to learn something new, a sense of community and just working on something cool without having a boss yelling at you about deadlines all factor into the motivation of a software donor.
But defeating the competition in order to capture market share and revenue are not in this list. This is what makes it so different from capitalism.
If you absolutely have to have a competitor, that’s not a problem. Here are some for starters… Microsoft, IBM, Oracle, Apple, SAP…..
The only way to achieve something great is for alternatives to fight it out
1) In the natural world, species evolve through the Darwinian process of competing for limited resources – TRUE
2) Open-source app generators are like the natural world – FALSE
3) Therefore: Competition is necessary for the evolution of app generators
In the natural world, species are unable to willfully design themselves however they want – with arms, legs, wings, gills and so on. So the only way for them to acquire functionality is through competition. This is different from software which can be designed however we want to an unlimited level of complexity and sophistication.
It is good to have multiple types of car, house, shoe, music, etc.
1) It is good to have multiple types of car because each one serves a different set of needs or tastes – TRUE
2) Open source application generators are like cars – FALSE
3) Therefore: It is good to have multiple generators to serve different sets of needs
Short answer: Regarding cars, most people want choices. Regarding application generators, most people do not want choices. They want excellence. See survey results ->
Cars are different from application generators. A car has limited and fixed functionality. A Ferrari cannot carry a family and a Sprinter can’t win the Grand Prix. They are stuck with their abilities and you can’t use one of them one way today and a different way tomorrow. But an app generator can generate both an SQL app and a NoSQL app. jhipster and CleverStack both do. Generators are general by definition and so one of them can be used to make applications of any sort.
But the analogy is still bad even if we limit it to just cars within the same class, let’s say 4-door sedans. Cars with the exact same functional value still have aesthetic value to differentiate them and justify their variety. For things that are purely aesthetic, like paintings, it is unquestionably good to have more than one because the aesthetic value of each is not subject to mathematical comparison and everyone appraises aesthetic value differently. But what if we remove aesthetic value from cars to improve the analogy to generators. Let’s say people are all blind and cannot tell the difference between how two cars look. Let’s say it’s a time when cars are all self driving, so blind people can have them. In this case, there is no good reason for having two options except to prevent monopolistic price gouging. Functional software like app generators has no aesthetic value and is free of charge. Its value can be completely measured by the number of hours of work spent by developers to achieve their goals and the performance of the generated apps.
So the value of a generator isn’t aesthetic but just mathematically measurable in terms of developer time and app performance. But what if some developers can deliver an app faster with one generator and others can do the same thing faster with a different generator? Isn’t this a case for having a generator to suit each style? To answer this question, we need to compare total time expenses – that under the status quo (with a variety) to that of a world with only one generator. It’s a tough calculation to do, but for starters, the latter sum would eliminate all the time spent by developers evaluating the options and switching around until they found the one whose style they liked best. The latter sum also eliminates all of the time spent by developers implementing things left out by their chose starter which is necessarily incomplete because the contributors are not on the same team and they are wasting time duplicating functionality. Moreover, in a world without standards, the vast majority of people come into a project whose style has already been determined by the founding CTO and, by simple probability, most likely not the style that best suits them assuming there is such. Everyone working on the team must use the same set of best practices. If each set suits different people, it’s unlikely that a given set of best practices is the best style for everyone (or anyone) on a team. So in a world with so much variety, this style- or preference-matched time savings is limited to one-man, new projects. Lastly, and possibly most importantly, in a world with standards instead of variety, all sorts of time saving tools and interchangeable components can be made that otherwise could not and documentation will be written that otherwise would not. So in which scenario is the total development time less: one with multiple generators to accommodate different styles or one with a single standard? I don’t think the comparison is even close.
Back to the cars. What about two cars that provide the same functionality but to different degrees – one is faster and the other can carry more and it’s not possible to make one car with the best speed and the best capacity. This is the case of mutually exclusive benefits. So the question becomes: Are there mutually exclusive benefits of an application generator? If so, then it is good to have more than one application generator. If not, then it is best to have just one that excels in every way. Some generators work with Node.JS and some with Java. It is in fact possible to have a single generator with options that let you use SQL or NoSQL databases. So I can imagine one with an option to use either Node.JS or Java, but haven’t seen one like that yet. The fact that Angular apps accommodate a variety of browsers makes me think it’s also possible for an app generator to accommodate a variety of application server platforms. But If it is technically impossible to do this, then this is a valid argument for having two generators and the list should be reduced from 20 to 2 instead of 20 to 1.
A better analogy is inches and meters. Is it good for us to have both inches and meters? No. There is no reason to have both. And since meters are in every way better than inches, there is no good reason why inches should exist. They do simply because of conditioning and historical roots which are not at all salient in a thing as new as an AngularJS application generator.
You should just use angular-seed because it is simple
1) angular-seed is simple – TRUE
2) Complex things are always harder to use and than simple ones – FALSE
3) Therefore: You should use angular-seed for simple projects. You can use another one for complex ones.
Something can be both powerful and good at simple tasks. My computer has only one operating system, but it is great for both simple things like running a notepad application and complex things like running computer aided design software. A car can move me around, entertain me, keep me cool, keep me warm, keep me dry, carry my things. Would it be better to have separate objects to serve each of these purposes? Would it be better to drive around in the winter without a heater and then pull over and go into a warming house whenever you got too cold?
With less to it, doesn’t that mean angular-seed is always easier to use? No. Standardization means that it is easy for anyone familiar with the standards to work on any project that follows the standard. Observance of standards determines difficulty much more than just how complex and capable something is. Switching to a project in a simple but unfamiliar system will take longer for someone than getting up to speed on another project in the same, sophisticated system.
In software, the ability to do simple things well and complex things well are not mutually exclusive. If you are just learning, it is much better to use a tutorial with step-by-step instructions and a functioning application than to use an empty application seed just because it can’t do very much. The Angular phonecat app is an awesome tutorial and would be even better if it had been generated by the best generator according to best practices and structure.
This argument is also short-sighted in how it looks at effort and time savings. Starting quickly does not mean that the entire development process is going to take less time. It will definitely take a lot longer. You have to count the effort of the whole process to determine which one saves the most work.