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.
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.
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.
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.
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.
Let’s not make an impression that there is more than one person working on Spark.
That’s true. It seems to be one guy.
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.
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”.
[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.
another good reason for a broker/clearing house-like website with Git/GitHub features.
Plus, a one-man team for an open source project is not good… as he obviously won’t be working on it full-time. You cant compare this to a situation with one person putting in 40+/- hours a week.
Are you actually guaranteed those 40 hours a week?
Again, I’d like to point out Sublime.
I think another interesting point is that all devs get burnt out on projects after a time. Even if a package dev is making $x/week in donations, s/he will want to work on something else in the future. So then what – a new maintainer needs to be found, willing to commit to $x/week.
At least with open source, forks, prs, etc. exist to keep a project moving beyond the creator’s scope.
one thing i like about programmers is they are constantly trying to find ways to solve problems.
Then, with some things-- like this conversation-- they put that same level of effort and focus into trying to come up with problems instead of solutions.
The funny part is that you’re proclaiming this without recognizing the irony behind your statement.
After all, you talked about plenty o’ problems yourself…
I’m just looking to have a discussion, not fight with you.
The difference that I’m referring to, is that I am pointing out a problem and suggesting potential solutions. Where some people are just pointing out the problems… many of which I can see multiple potential solutions for.
I don’t actually want to join in this discussion, but I do want to add that Patreon is another option.
For example, Evan You from Vue.js (yes, another one man project) is using this: https://www.patreon.com/evanyou?ty=h
I have zero affiliation with Spark (or PHP in general).
What is the status of Laravel Spark? Is it growing in popularity? Can anyone comment who is following it?