# Enterprise Features, Dgraph Core Values, Open Source, and My Thoughts **URL:** \ **Category:** Users\ **Created:** [June 27, 2020, 2:13pm UTC](https://discuss.dgraph.io/t/enterprise-features-dgraph-core-values-open-source-and-my-thoughts/7399 "2020-06-27T14:13:35Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![zicklag](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/zicklag/32/3636_2.png) [@zicklag](https://discuss.dgraph.io/u/zicklag)\ **Post date:** [June 27, 2020, 2:13pm UTC](https://discuss.dgraph.io/t/enterprise-features-dgraph-core-values-open-source-and-my-thoughts/7399/1 "2020-06-27T14:13:35Z")
## My Response to Dgraph Core Values [http://discuss.hypermode.com/t/dgraph-core-values-v20-05-31/1402?u=zicklag](http://discuss.hypermode.com/t/dgraph-core-values-v20-05-31/1402?u=zicklag) First, I want to say that I love this document! This is a great thing to see for a project and a community. I see too many projects with great promise that don’t define the **vision**. This document is the vision of the Dgraph company and the way that you develop software, and all of these concepts will directly affect Dgraph and any other products you deliver. I love the points that you make here. > [@mrjn](#): > > 1. Create an incredible user experience. This is far to often sacrificed for the fact that a tool “technically works”. “Works” is not good enough! If a tool “does the job” but no user can manage to _make_ it do the job then that doesn’t count. User experience is _crucial_. > [@mrjn](#): > > Prioritize bugs over features, because when you fix a bug you get to keep a user. Exactly! I have seen a project where new features were what took priority and the issue was that users were constantly running into “this one bug” that rendered all the bells and whistles useless. It is essential for users to actually be able to use your product, and beyond that, _enjoy_ using your product. That attitude will create devoted users out of people that may have otherwise used your project just because they had to or because it “did the job”. > [@mrjn](#): > > Obsessively simplify your approach to solving the problem. Thank you! I think that, as engineers, we often get lost in the _engineering_ when what really matters is _creating solutions to real problems_. A simple solution is leaps and bounds better than a complicated solution that solves the same problem. Don’t engineer for the sake of engineering. Keeping things simple will give you more time to actually _make a difference_, and that is what brings user value. > [@mrjn](#): > > Always be curious and willing to take risks. Leadership, good ideas and bad ideas can come from anywhere. Yes. Freedom to experiment and try new things helps people be creative and you never know when someone might come up with something great. > [@mrjn](#): > > Talk about actionable solutions. > [@mrjn](#): > > Respectfully challenge a decision when you disagree. Do not compromise for the sake of social cohesion. But, once a decision is made, [commit](https://en.wikipedia.org/wiki/Disagree_and_commit) to it. This is important. Not being clear about you think or wasting time on unproductive discussion will not be a benefit to anybody. Honesty is important to being able to efficiently collaborate and get stuff done. * * * ## Dgraph Enterprise-only Features You guys are totally saying alot the things that me and my company have been talking about for a while now and it is really cool to see. Now I want to make an appeal to the number 1 point in your core values: **Be Open Source**. Before I start I want to say that I completely respect your business model decisions. You have to maintain your business and decide how you want to do that. Still, it appears that this is a place where the community has a voice and so I want to make a case for the Open Sourcing of the current enterprise-only features, knowing that if the Dgraph Core Values are diligently upheld, I will get a fair hearing. ### Hindrence to Inclusion in Other Open Source Projects One thing that prevents me from wanting to use Dgraph is the fact that I want to include it as a part of the stack in other Open Source projects that target enterprises. The particular project in my case is an enterprise orchestration GUI. Having a database, though, that requires a commercial license to access features such as database backups and ACL would really be detrimental to that tool. Another inhibitor is that the other tools in the ecosystem don’t require commercial licenses to access any features, so adding a new tool to the ecosystem that requires an enterprise license would not fit very well with the rest of the ecosystem which otherwise allowed for any scale deployments without commercial licenses. Even if I were comfortable with purchasing a commercial Dgraph license for a single use-case in my own company, I would not want to force users of an Open Source application that I develop to purchase licenses, regardless of their scale. ### Extra Difficulty When Selling to Legacy Enterprises I have a colleague with lots of experience working in big, legacy enterprises, and there is a lot of red tape that you have to go through to get anything changed, especially when that change costs money. If I can take an Open Source tool, create a solution with it, and start using it without having to tell the enterprise that I need money to do it, it will be much easier to get the clearance to do so. If I can get that solution stood up and working, the enterprise can then decide that they want to pay for support for the tool because they have it deployed and running at large scale and they want to make sure it keeps working. This is a bigger deal the more components that make up the application stack. Modern applications can require many different components and if every component needed an enterprise license that would add up drastically. Can big businesses afford it? Maybe. But it is barrier to adoption when a cost is required just to use the tool. If the business can adopt it without cost and they love it, then I believe that most will come back for support once they are using it. ### Poisoning Future Development At the User’s Expense A very relevant quote from the [CockroachDB License Change Announcement](https://www.cockroachlabs.com/blog/oss-relicensing-cockroachdb/): > Another option we considered was adopting a three-tier model: open source core, enterprise components, and a middle ground of features that are not open source but available at no cost. This is a popular model, and more or less the model we have had up until today. > > However, this creates bad incentives for our company. It creates pressure to avoid creating new features in the core and do as much work as possible in the non-open-source components. Basically, we would be tempted to sell our core users short by permanently putting our most exciting features behind an enterprise license. If you squint towards the horizon, this model does not bode well for the open source ecosystem. This is what I’m afraid of for Dgraph. For instance, database backups seem like a pretty core feature to me. Yes maybe the Export feature is a fine enough stand-in, but it still feels wrong to me. This is just my impression and you do not have an invalid business strategy in any respect, but I think that it has a negative impact on users. CockroachDB went with a license that permitted full use of the database for **anything except hosting the database commercially as a service**. I think this is a great model. It allows you to build your business by offering your product as a service and you can still offer professional support for enterprises. Everyone has access to use and improve all of the features, but large and small businesses can get support and/or hosting to make the Dgraph business sustainable. ### My Background I am the Chief Technology Lead at [Katharos Technology](https://katharostech.com) and at KatharosTech we build pretty much our entire company’s technology on Open Source software. We don’t have support for any of it because we are starting out and we know how to manage our software ourselves. We want to be able to use tools and deploy them highly available if necessary without having to get licenses for all of the software we use. Even if we don’t want to pay for support now, to keep costs down in an environment where we can manage things ourselves, that doesn’t mean that we won’t one day scale to a point where having support would be worth the cost. And if we implement a tool for one of our [Digital Transformation](https://katharostech.com/digital-transformation) consulting clients it would be easier to tell them that they can do anything with the tool without paying for it, but that they can get enterprise support if they want to pay for it. ## Closing Thoughts If you got this far, thanks for reading! Regardless of what you guys decide on, I respect your decision. I’m extremely interested in Dgraph after looking into it just for one day, but at this point I don’t know that I would deploy it for the Open Source projects I’m working because of the license. I hope that this feedback is useful even if you guys don’t change anything. Keep up the good work! I think you’re doing an amazing job. 😃 🎉 ---
**Author:** ![amaster507](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/amaster507/32/4123_2.png) [@amaster507](https://discuss.dgraph.io/u/amaster507)\ **Post date:** [June 27, 2020, 3:11pm UTC](https://discuss.dgraph.io/t/enterprise-features-dgraph-core-values-open-source-and-my-thoughts/7399/2 "2020-06-27T15:11:00Z")
@zicklag Thank you for verbalizing these points. And to the Dgraph team, keep up the good work whatever the decision is. You have created a good product based upon a good set of core values. ---
**Author:** ![Paras](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/paras/32/2768_2.png) [@Paras](https://discuss.dgraph.io/u/Paras)\ **Post date:** [June 27, 2020, 5:51pm UTC](https://discuss.dgraph.io/t/enterprise-features-dgraph-core-values-open-source-and-my-thoughts/7399/3 "2020-06-27T17:51:53Z")
@dereksfoster99 might be able to answer re: Enterprise Features. ---
**Author:** ![MichelDiz](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/micheldiz/32/11873_2.png) [@MichelDiz](https://discuss.dgraph.io/u/MichelDiz)\ **Post date:** [June 27, 2020, 7:04pm UTC](https://discuss.dgraph.io/t/enterprise-features-dgraph-core-values-open-source-and-my-thoughts/7399/5 "2020-06-27T19:04:37Z")
CockroachDB’s enterprise features will continue to use the Cockroach Community License (CCL). Use of enterprise features will always require a license agreement with Cockroach Labs; this license does not convert to open source after three years. ---
**Author:** ![zicklag](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/zicklag/32/3636_2.png) [@zicklag](https://discuss.dgraph.io/u/zicklag)\ **Post date:** [June 27, 2020, 8:21pm UTC](https://discuss.dgraph.io/t/enterprise-features-dgraph-core-values-open-source-and-my-thoughts/7399/6 "2020-06-27T20:21:13Z")
Oh, well that’s confusing, especially after their post saying what it did about not doing the “Tiered Model”. 🙂 ---
**Author:** ![zicklag](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/zicklag/32/3636_2.png) [@zicklag](https://discuss.dgraph.io/u/zicklag)\ **Post date:** [June 29, 2020, 2:11pm UTC](https://discuss.dgraph.io/t/enterprise-features-dgraph-core-values-open-source-and-my-thoughts/7399/7 "2020-06-29T14:11:56Z")
After talking to my partner about it, while I still think that it would be better to not have special enterprise features if possible, the only thing that is a hard blocker for us implementing Dgraph in our Open Source projects is **ACL support**. We don’t need advanced user and access management features, but we need a way to put a password on the database access, even if there could only be one `root` user that had full access. As it stands, without an enterprise license, all that you need to do to get 100% control over database is to get network access to the machine and port. That is a really scary thought from a security perspective, no matter how small your deployment is. Obviously you would want to restrict network access to the database to anything that doesn’t need it, but you don’t design security around “well that should be enough, nobody will get network access”. It is **much** harder to get network access _and_ crack a database password than it is to just get network access. Being that you can backup your cluster with the Export feature, and the rest of the features such as encryption at rest and cluster-cluster replication are more useful to massive deployments, the only real problem for us is the fact that we can’t make the database secure even on a small deployment of the database. Otherwise it is pretty reasonable. ---
**Author:** ![MichelDiz](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/micheldiz/32/11873_2.png) [@MichelDiz](https://discuss.dgraph.io/u/MichelDiz)\ **Post date:** [June 29, 2020, 3:56pm UTC](https://discuss.dgraph.io/t/enterprise-features-dgraph-core-values-open-source-and-my-thoughts/7399/8 "2020-06-29T15:56:48Z")
> [@zicklag](#): > > Obviously you would want to restrict network access to the database to anything that doesn’t need it, but you don’t design security around “well that should be enough, nobody will get network access”. It is **much** harder to get network access _and_ crack a database password than it is to just get network access. You can combine this with TLS [Client authentication](https://dgraph.io/docs/deploy/#client-authentication). e.g using REQUIREANDVERIFY. Network isolation, firewall, plus TLS. It should be fine. Thinking a little further. If someone is able to overcome these barriers on your server (cloud). So nothing would stop him from accessing it in other ways (like having a password approach, would not stop anyone). Overall, if anyone can get through these barriers, he would theoretically have total control over your server even with password and such. In this case, only encryption would prevent the use of the data. So, TLS feels like a solution for your case of “login to DB”. But if your case, it’s not specifically about your server’s security. So you are concerned about the possible abuse of users within the DB. In this case, the recommendation is that you never expose your DB directly to users. Create a mechanism (usually an API) to get between the user and the DB. Thus controlling its use. And also add “Network isolation, firewall, plus TLS”. If you don’t want to create an API or something similar. You can naturally use Dgraph’s GraphQL. Dgraph’s GraphQL feature has mechanisms that allow Auth and etc. Practically an API ready at the time of Schema modeling. And it’s a free open-source feature. In the latter case, you isolate any access directly to Dgraph and expose GraphQL only. The auth system built-in does everything else you need. Cheers. ---
**Author:** ![amaster507](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/amaster507/32/4123_2.png) [@amaster507](https://discuss.dgraph.io/u/amaster507)\ **Post date:** [June 29, 2020, 4:28pm UTC](https://discuss.dgraph.io/t/enterprise-features-dgraph-core-values-open-source-and-my-thoughts/7399/9 "2020-06-29T16:28:17Z")
I am following this because it interests me as well. If I go the route of > [@MichelDiz](#): > > If you don’t want to create an API or something similar. You can naturally use Dgraph’s GraphQL. Dgraph’s GraphQL feature has mechanisms that allow Auth and etc. What is the recommended way to limit access to only the /graphql endpoint and not allow access on the /admin endpoint. If they used separate ports then I could do that with port management and give my ip address access to the admin port and give public access to port 8080 (but this includes the admin endpoint) ---
**Author:** ![MichelDiz](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/micheldiz/32/11873_2.png) [@MichelDiz](https://discuss.dgraph.io/u/MichelDiz)\ **Post date:** [June 29, 2020, 4:34pm UTC](https://discuss.dgraph.io/t/enterprise-features-dgraph-core-values-open-source-and-my-thoughts/7399/10 "2020-06-29T16:34:21Z")
You can use NGINX or Traefik (reverse proxy). Both have ways to limit access to a single path. For me, Traefik is the best, but it is focused on HTTP, the gRPC and other TCP/UDP won’t work well to balance this type of protocol. For that (gRPC), you can combine Traefik with NGINX. ---
**Author:** ![zicklag](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/zicklag/32/3636_2.png) [@zicklag](https://discuss.dgraph.io/u/zicklag)\ **Post date:** [June 29, 2020, 5:20pm UTC](https://discuss.dgraph.io/t/enterprise-features-dgraph-core-values-open-source-and-my-thoughts/7399/11 "2020-06-29T17:20:26Z")
TLS looks perfect for the database. I was already planning on using GraphQL and @auth so that is looking good to. Securing the `/admin` endpoint would be a little annoying because the safest thing would be to put Ningx _inside_ the container to make sure that it is password protected from any other containers that run on the same network, but it would still work. * * * For instance, I have Traefik running already and routing traffic to many different containers that are all on the same “web” network as Traefik. If I used that Traefik instance to enforce the password on the `/admin` endpoint, it would still leave the `/admin` endpoint open to attack from other containers on the “web” network. So if I had a website running and that website got compromised, it will be trivial to now compromise any data in the Dgraph database through the `/admin` endpoint. The way around that would be to run Nginx inside the same container as GraphQL so that the `/admin` endpoint would be protected at the container level and would be safe unless you ran the container in `host` networking mode. Then you have the same problem in `host` networking mode where any process on the host can access the `/admin` endpoint without authentication. I think the best option would be to allow setting a password on the `/admin` endpoint of the GraphQL server at the app config level. That way it would be secure no matter what and there are no extra servers to run and make sure that the gaps have been filled with. I’ll open an issue on GitHub for that probably. * * * Still I think that will work well enough for me to use it for my project. We’ll see how that goes. Thank you everyone. 🙂 ---
**Author:** ![mrjn](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/mrjn/32/775_2.png) [@mrjn](https://discuss.dgraph.io/u/mrjn)\ **Post date:** [June 29, 2020, 7:28pm UTC](https://discuss.dgraph.io/t/enterprise-features-dgraph-core-values-open-source-and-my-thoughts/7399/12 "2020-06-29T19:28:00Z")
> [@zicklag](#): > > Securing the `/admin` endpoint would be a little annoying because the safest thing would be to put Ningx _inside_ the container to make sure that it is password protected from any other containers that run on the same network, but it would still work. There’s a way to secure the /admin endpoint with what we call “Poor Man’s ACL”. For some reason, I can’t seem to find the documentation for it. CC: @dmai @MichelDiz ---
**Author:** ![dmai](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/dmai/32/1254_2.png) [@dmai](https://discuss.dgraph.io/u/dmai)\ **Post date:** [June 29, 2020, 7:49pm UTC](https://discuss.dgraph.io/t/enterprise-features-dgraph-core-values-open-source-and-my-thoughts/7399/13 "2020-06-29T19:49:52Z")
The docs for securing the /admin endpoint with a token is here: [https://dgraph.io/docs/deploy/#securing-alter-operations](https://dgraph.io/docs/deploy/#securing-alter-operations) We can add “Poor Man’s ACL” to its description in the docs so it’s searchable that way. ---
**Author:** ![zicklag](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/zicklag/32/3636_2.png) [@zicklag](https://discuss.dgraph.io/u/zicklag)\ **Post date:** [June 29, 2020, 7:54pm UTC](https://discuss.dgraph.io/t/enterprise-features-dgraph-core-values-open-source-and-my-thoughts/7399/14 "2020-06-29T19:54:54Z")
Is there something similar for the GraphQL `/admin` endpoint, or does that apply to the [GraphQL `/admin`](https://graphql.dgraph.io/admin) endpoint as well? **Edit:** Silly me, sorry I missed it. “GraphQL is built in to the Dgraph Alpha nodes”. So that should work for me, that would be great! 🎉 ---
**Author:** ![mrjn](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/mrjn/32/775_2.png) [@mrjn](https://discuss.dgraph.io/u/mrjn)\ **Post date:** [June 29, 2020, 8:36pm UTC](https://discuss.dgraph.io/t/enterprise-features-dgraph-core-values-open-source-and-my-thoughts/7399/15 "2020-06-29T20:36:34Z")
> [@dmai](#): > > We can add “Poor Man’s ACL” to its description in the docs so it’s searchable that way. Let’s do it, please. That’s how most of us refer to it. ---
**Author:** ![abhijit-kar](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/abhijit-kar/32/3726_2.png) [@abhijit-kar](https://discuss.dgraph.io/u/abhijit-kar)\ **Post date:** [June 30, 2020, 6:20am UTC](https://discuss.dgraph.io/t/enterprise-features-dgraph-core-values-open-source-and-my-thoughts/7399/16 "2020-06-30T06:20:31Z")
If I can’t get/afford Slash GraphQL, I will walk the Poor Man’s ACL path. 😂 ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex007/uploads/dgraph/original/2X/2/2b38fdece2abe5814f2e51bee69d1e67fc304b0a.png) [@system](https://discuss.dgraph.io/u/system)\ **Post date:** [August 10, 2020, 10:20pm UTC](https://discuss.dgraph.io/t/enterprise-features-dgraph-core-values-open-source-and-my-thoughts/7399/17 "2020-08-10T22:20:32Z")
Closed on August 10, 2020, 10:20pm UTC This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.