Meteor Apollo - Now with Apollo Server 2!


#41

I agree, but this is what I’m saying, until it reaches the level where we can’t be surpassed by someone with more resources keep it as secret weapon, then if we want people to use it, open-source it. There’s nothing decided yet, it’s a complex problem.


#42

I respect your point of view and all the work you have been doing for the community, at the end decision is yours.

Let me just share my experience ( which can be wrong in your case ) : People are not scanning the internet to find ideas that they will replicate with more ressources, especially in the context of development ( I agree with csiszi about Open Source standard today.

You ( including cult of coders ) are the only person today capable of pushing such tools today, you have the expertise, a community that believes in what you do, and because of that you are way ahead of everyone else.

You could have done the same with redis-oplog, why did you not do so ?

You mention “Premium support” on the Home page.
Did it work in any way ?


#43

To share or not share, I think it’s worthy of a debate.

Cult of Coders did contribute a lot to the community, so for that I think the whole Meteor community is grateful.

However, I think not everything that can be open sourced should be open sourced. I think open source is great for foundational common infrastructure tech, grapher & redis-oplog are foundational to the Meteor ecosystem and they solve very generic shared challenges so they were perfect for open sourcing.

On the other hand, small businesses need to compete in a market and if a certain tech/process that is core to their business operation gives them competitive advantage I think it’s wise to be conservative with what they share. However I do agree with others comment that Cult of Coders contribution to the tooling ecosystem is certainly a competitive advantage on it’s own…

I think this a business strategy decision and I really recommend Michael Porter’s article on how to sustain competitive advantage.


#44

Would MDG be interested in pushing this ahead? Have you thought about being backed by MDG some how?


#45

BTW, this sounds very interesting to me. Could be just what I need, as I only have very limited time to realise my project, as I’m doing it in my spare time.


#46

@alawi @stig this tool will become open-source, it’s merely a question of when, we have to pick the right time.

We’re most likely going with an inward-focus approach, to evolve it internally with our own projects first so we can really head into real-life necessities, and once we perfect this iteration we begin a hyping strategy, maybe do something like: “When this repo gets X stars we open-source it” to draw a little bit of attention. This way we can have an additional competitive advantage “Look how quick & cheap we build your enterprise CRM”, that can help us get some traction for projects and grow our team further.

There were other ideas like making it pay-to-use, but the real problem is that this is not very hard to implement, it’s just the ideas behind it that hold the real value.

There’s the other side if by any chance this will not be a success (~10k stars on github) and people won’t see the potential value, it’ll benefit a very small niche that get this without work, and open-sourcing it will prove to be a bad decision. RedisOplog benefitted Meteor giants & gave hope and confidence to the community to use or continue using Meteor. If we would have sold it, RedisOplog would have been further away in terms of development and maybe a sustainable business.

There’s another example, the tool: https://github.com/cult-of-coders/react-molecule we built for React, did not get traction, even if it’s hands down the way to work with a shared context, maybe people will realise this later :smiley:

Stressing this out: we’re going to open-source this, at some point, so anyone on the planet, can get up and running with an app or a react-native mobile app in few minutes, and set up a foundation for it in 1 hour, then just focus on services and tests and the client-side part.


#47

Sounds reasonable.
Would there be anything that the community could do in advance, to help back up your project? Of course, not knowing much about the project, the community would have to trust your words, that it is as promising as you say. Maybe what we could do, would be a community plan to do a coordinated hyping of the project, to get it as far as possible?
How far away are we to a possible release?


#48

Look at Robomongo experience. Monetize first. Do not listen advice from people who have not built and sold a tool like that to the world.


#49

In my opinion an exceptionally well written post touching upon somewhat related questions of monetization of developer tools is the RethinkDB post-mortem. And I’d echo what @Volodymyr said - be rather picky when it comes to sources of advice. Including my own thoughts here :slight_smile:


#50

Thank you all for tuning in. I think releasing this thing MIT-licensed may be better. Hear me out.

What if we just open-source it from start, and people who love this idea can donate money or contribute by code or both. If it’s pure quality, people will donate, people will contribute. Our goals with this is to increase our company but, more importantly, share the knowledge to the world (It’s one of our Core Values), and maybe just by sharing we can earn much more.

All donated money will be spent in developing the idea further (nowhere else). This way we shoot two birds with one stone:

  1. we get enough coding power and code testers
  2. we can get a lot of funds if this idea really resonates with people

We prepare a nice presentation for it. Solid documentation. Video walkthroughs. Basically what we’re “selling” here is: “with this you reach production app much faster”.

The vision is grand, I’m talking about linking a credit-card (from your terminal, securely), and prepare for you a full “Google” account, link with AWS services, and create everything for you, you can by domains with it. You could purchase already made components (Notifications, Invoicing, Order Processing, etc), that are compatible with the entire ecosystem and extremely customisable, or you can just try the free ones. The potential of scaling this is extremely huge.

I think right now the decision ways more towards OpenSource, but do the mandatory things first, take care of every detail from documentation, to learning curve and developer experience. We don’t release messy repos, so it’s a must to meet an important set of criteria. First impressions matter.

Would anyone be interested to help out with this? If yes, PM me.

Really love the Meteor community. Always a source of great inspiration.


#51

You could think about support memberships. This could ensure a more steady cashflow to keep development going on. Get some inspiration how it’s done by TYPO3 here: https://typo3.org/project/association/membership/


#52

Just my two cents, but @diaconutheodor has been making substantial progress in multiple areas of app development, which I think is due in part to two things: great vision and solving realistic problems.

I think when projects move to open source, both of those things are immediately compromised.

Instead of focusing on vision, there is a shift to filtering, prioritizing and politics. Instead of solving realistic problems, the project inherits all of the parallel issues that users are facing when implementing, which often only creates a larger (worse) API and pulls dev time from other more relevant issues.

I think even if funding were an option, I’d lean more towards in house development and then a subsequent open sourcing when the project is at a true 1.0. Similar to react. The vision and scope of concerns were dictated long before someone from the community opened a PR against react, and so they were able to build something amazing that the community eventually contributed to.


#53

About realistic problems: IMO no-one is looking for notifications right now, but since there are a lot of tech choices, devs are looking for easy to setup but future-proof and extensible boilerplates/frameworks/etc. People can use mup for free, yet they pay for galaxy because it’s easier to use, they don’t have to deal with devops and they have integrated kadira/apm.
What I’d pay for is a one click redisoplog “upgrade”. I have no experience with redis, how to install, config, manage, etc. I’m happy with mongo oplog tailing right now, but if I knew I have the option to use redisoplog easily with your solution, I’d use it for my next project for sure.

Also, note that meteor 1.8 came out with the promise of an “official” recommendation for meteor+apollo project structure.


#54

Do you think that in general no one is looking for notifications? Or is it an observation about the meteor community? I’m looking for notifications for my project. Should I not?