Meteor Dev's Thoughts on Laravel Spark?

community
21

Good sell techniques showed here. The author of this post is good. Congratulations!!

Bye!

22

This what I mean when I say open source dogma. This is a legit debate to have, but it usually doesn’t happen because people take “open source is best” as the bible.

They also seem to have trouble imagining something like Spark working along with open source.

And no, I am not taylor otwell, or affiliated with Spark. I’m just genuinely interested about sparks business model. I could care less about Spark specifically, and am only interested in the model. To me, it would result in better outcomes than we see with blaze, autoform, and many other instances that get swept under the rug.

Open source is great until you’re the one who invested heavily in the next autoform or blaze-- and you’re the one who has to write the check to your dev team to get out of it.

23

Meanwhile, everywhere on the web:

What?? [MEAN GREEDY COMPANY X] is trying to get paid for their hard work?? After I’ve successfully invested in using their open source products for multiple years, and brought in a tonne of money for my company using their awesome stuff?? Now they want me to pay them?? Who do they think they are???

1 Like
24

Spark actually seems pretty cool. That said I disagree with what you’re saying. Meteor Toys is both free and paid. Aldeed could have done the same thing if he had the conviction to do so. It is his choice not “Open source is bad”.

Open source is really a marketing strategy. I don’t need to explain this. If it doesn’t come to you right away, just sit back, light up a blunt, and think about it.

4 Likes
25

really the best advice yet

2 Likes
26

@a.cm I will agree with you until it becomes overpriced.

1 Like
27

haha.

I will “pass” on that. But, I didn’t make this thread because I didn’t understand the merits or uses of open source. I get it can be used as marketing by individuals (like aldeed) or even groups (like kadira).

Again, my “question” (or rather, point of discussion), is if there is a place for something like Spark. The reason I ask this is:

  1. We see many open source projects die off (blaze/autoform). Some of these are very specialized, and it’s tough for some average joe to just casually send in a PR. It seems it’d be better to have a specialized team working on each… obviously this isn’t really possible with open source. Hence the death of these two.

  2. We see many projects ask for donations to keep things moving ( see robomongo). Which seems like a round-about-way to do what Spark is doing. It’s the politically correct way to try and get to Sparks model. You can almost get there, without infuriating the open source zealots. It’s like they ask themselves “would che guevera be okay with this”? before deciding if they should get infuriated or not.

  3. I ask myself "would meteor/blaze be ‘better’ if MDG was focused 100% on just making the framework amazing? With Spark’s model, they hypothetically can focus on it more. They can also still offer ancillary products, but they at least have the incentive and funding to justify investing in taking in PRs, making their own improvements. We’ll never know the answer to this, but part of me thinks “yes it might be better”.

  4. Unlike others, I don’t see why this “privatized” models can’t be mixed with open source. Again, Spark is $99. It’s built on laravel (which is built on composer packages and NPM packages). You can integrate Spark with any NPM package you want. I’m sure you could send PR requests into Spark.

  5. I’m not saying everything should be privatized. I’m mostly curious if people think more Spark-like situations could pop up that work nicely with open source, but save significant time, and can limit some of the risk that comes with depending on random internet people to work for free.

To me, it seems like you can do anything you could with open source. The only difference is taylor otwell (guy who invented laravel and I think started spark) is asking for $99 straight up, instead of (1) doing a round-about ask like the robomongo guy or (2) letting the project die.

Again, just thought it was an interesting conversation to have. I’m a little bummed it’s turned into scoughing at me for bringing it up rather than real discussion.

It seems the general consensus is that nobody would ever pay for something like Spark because (1) they couldn’t fork it and (2) they could just glue it together themselves with npm packages (albeit it may take 3-4 months).

In a few months I’ll try to do some research on Spark and see if they lived or died. I’ll try to report back.

28

I know that Laravel is the most popular framework for PHP/MySQL and I was excited to know that a Laravel based framework is now available in Node.js/MongoDB (Please correct me if my knowledge is not up to date). It has given an opportunity to the Laravel developers to move to Node.js/MongoDB without learning a lot and they’ll be able to most of the knowledge/skills that they got while doing development in Laravel.

I haven’t checked Spark so far, but if it’s working well - it’s a big advantage to Laravel developers.

1 Like
29

My two cents here.

  1. Code is cheap and easy to copy.
  2. Developers time should be paid.

Paying for code doesn’t make sense because there is no way to determine value. Especially a one time fee. Like many others have mentioned that doesn’t incentivise the devs to make a better product. And it turns away people who might otherwise make the product much better. (i.e. Only people who pay for spark will contribute PRs to it.)

Creating a product meant for developers and getting paid to create stuff with that product (MDGs approach) means that everyone can use it and can contribute to it. And since MDG is constantly using their own product (Creating/Maintaining Meteor projects through consulting) they are able to find issues first hand.

1 Like
30

yeah i find this “payin for code is really lame” attitude to be self-defeating. we are all software developers here, and i think we’d all agree, it is nice to get paid. stop being cheap.

1 Like
31

I’m using Laravel Spark in the recent project for work. And honestly, I wish Spark was at least half as good as Autoform is.

Spark is fine as long as you want to make a Spark application. That is an application where its main purpose is to present Spark. But once you try to write a real webapp, you end up having to fight with Spark for control over each feature.

2 Likes
32

1°) Nobody can know for sure why Facebook is doing this
2°) They get back from the community somehow improving their code
3°) They can see other people code and detect new engineers to hire
4°) They improve their image among developers, which bring them more good engineers

But AFAIK, Facebook is not really making money through the open sourcing of their tools. They are making money through other means which we all know, and the free release of their tools is anecdotic. Facebook is not a tool developing company. But for a tool developing company, you have to make money somewhere to succeed. I think this has been the real problem with Meteor. They have been developing product A (a JS framework) with the intention to make money with product B (sophisticated hosting). However developing product B was another work than developing product A, and it’s not because your users like your free framework that they will like your paying hosting solution.

1 Like
33

It forces them to chase two rabbits at once… where sparks model lets them focus on spark 100% (in theory). That is all I’ve been trying to say. The old proverb:

If you try and chase two rabbits, you will not catch either one.

The regular “open source” model— from the meteors or the world to the most basic packages-- forces the maintainers to chase two rabbits at once. This is okay for Facebook and Google where react/angular were afterthoughts to their business. But for the 99% of other open source could, we’ve seen the result of this (see meteor, blaze, and autoform just to name a few that are close to home).

Now you’re stuck trying to decide which of the 15 react form packages to use… instead of everyone putting their time and money into one or two solid, trustworthy, sustainable options.

Now, that doesn’t mean everything should be paid-source… there are plenty of places where open source is working great… the question is should everything be open source?

Again, from what I can tell, Spark is just giving you a head start (in the same way something like autoform gives you a head start). You can still use any npm package you can imagine. It doesn’t lock you into some closed-source 1990s microsoft in-house ecosystem— that’s a fallacious argument.

It just seems like the open source dogma is so strong that people sweep all of the examples of it failing under the rug. It’s taboo to mention them and you’re labeled a luddite for even suggest a discussion about alternative approaches… when ironically it may be the open-source-dogma crew that are the luddites.

34

another example from the angular world: restangular

TONS of hype… then 6 months later"

“Six months later, looks like Restangular is dead. No commits for the last 8 months, almost 300 outstanding issues in github, dozens of ignored pull requests.”

Does anyone know similar things to Spark? I’d like to keep an eye on how they all turn out but I only know of Spark.

35

This seems like a contracting statement as that’s the goal of open source: having lots of people ready to contribute. Usually when authors of projects move on, there are always people willing to continue maintaining the project.

36

Let’s not make an impression that there is more than one person working on Spark.

37

That’s true. It seems to be one guy.

38

Great. One guy.

And then this one guy gets hit by a bus, becomes ill or simply doesn’t want to work on the project anymore.

Naw.

1 Like
39

Is the risk your mention here worse than betting on an open source library maintained for free by one guy?

Again, look at autoform. He didn’t get hit by a bus and the repo still died. Look at blaze. They didn’t get hit by a bus but it still died.

It’s arguable that if aldeed was getting paid from the autoform library, and he didn’t have to go find other paid work, that autoform would be much more alive today… maybe it would be successful enough he could hire another developer or two. Now, for [insert license cost of autoform], you get to use an autoform package maintained FULL TIME by a TEAM of developers… instead of getting it for free but the package being essentially dead.

So I don’t think your complaint is logical. And the situation you mention could easily be circumvented-- see below:

I think if there was a sort of mechanism-- a clearing house or broker website (if you will)-- that this model could be really good… something like a GitHub-like marketplace for buying/selling “commercial packages” or frameworks. If the repo (i.e. business) were to die, or the maintainer died, the broker website could pass along the repo to the public for forking… all they would really need is a common boilerplate license-- like the MIT license-- but with some stipulations about how and when the repo could move from the paid repo to a MIT license.

It would have GitHub features (the public could submit PRs). All the packages would be integratable with whatever they were built with (npm, composer, whatever). So it wouldn’t be a “closed system” like people have been saying here… rather it’s just introducing SOME commercial aspect to SOME packages in the npm (or other) ecosystems… the main difference being you are formally paying instead of just asking for “paypal beer donations”.

This could open up a whole new area of work for entrepreneurial developers and could potentially provide some more stability for the packages you are using.

I’ve actually been thinking about trying to put something like this together after reading some of the feedback in this thread. My main question is how could you fight piracy… so somebody just buying a license, and then publishing your code an npm module. It’s possible it could work on the honor system, but ideally there would be some mechanism for deterring this. At the same time, it would be nice if it were closely tied into npm somehow… instead of using a separate package manager for these “commercial packages”.

40

[quote=“a.com, post:39, topic:24394, full:true”]

Is the risk your mention here worse than betting on an open source library maintained for free by one guy? [/quote]
Yes?

Risk with open source: Someone now has to maintain the code. The code itself is openly available for all. Thus, if you don’t run into any issues, the upkeep may even be as low as zero.

Your model: You now have to create a hideously and laughably complex construction. Which, by the way, someone has to maintain. And then, when you gain access to the code, you then have to find someone to maintain the code you got.

And your “counterarguments” regarding blaze and autoform are not countering my argument - which amounts to:

Paying money for a single-man “team” to maintain something you want to rely on comes under the heading of:

A very bad idea.

Just look at Sublime. There were two years of no updates. Even when the guy was paid for it.

1 Like