We may be unable to provide a concrete definition of what intelligence is, but we can certainly provide definitions for what it isn't. E.g. we don't need a concrete definition of intelligence to say that a rock isn't intelligent. A pencil isn't intelligent. A calculator isn't intelligence
I don't disagree for the items you listed, but for something that exhibits what in many aspects can AT LEAST be mistaken for 'intelligence' (among signs of the complete opposite, of course), I would just say that there is no way for anyone to know.
Ignoring your insults, I think there are many valid use cases for smart home devices.
For example, automatically turning lights on and off on a schedule, changing light color to red at night, being able to casually set reminders without bothering with a phone, controlling your TV without needing your phone (e.g. for netflix), being able to change temperature on a schedule, all kinds of things.
Just because they occasionally have bugs for some people doesn't mean they are entirely useless. Many people (myself included) have few to no problems with their smart home devices.
My company uses GitLab and I think the CI is fantastic, especially compared to Jenkins, Travis, Circle, etc. It's very easy to setup, incorporated into the rest of our workflows, intuitive, reliable, powerful. I have a few complaints but i see they are on the upcoming roadmap.
Something to consider, VS Code being free means it will eat into IntelliJ's marketshare, even without all the features of IntelliJ. They'll be the people who need the advanced features who will continue buying it, but many people may not need the full suite, and will use VS Code to save money.
The IntelliJ community edition is free as well, and has features galore. (I'm an Emacs guy through and through, but some Java stuff makes me break out IntelliJ)
Join us and help build the next generation in telecommunication retail software, such as electronic document signing software, point of sales, inventory management, and business intelligence. We have customers in over 40 countries around the globe, and we're looking to expand our team as we build our next generation of products. We currently have 75 employees, and a very relaxed and fun culture. This is no startup, we value work life balance.
1. They only have four tiers (four equivalent tiers for hosted and on-premise technically). This is quite reasonable, as they need to provide flexibility for their customers. They are quite clear about which tiers provide which features.
2. This is purely subjective. I quite like the design, both more than GitHub and Bitbucket. They do have a UX team, and they conduct regular user tests. They've also made a lot of improvements and continue to make improvements, but design will always be subjective. You CANNOT please everyone
4. GitLab is a company and needs to make money to continue employing developers to continue developing their product. Open source devs volunteer their time on GitLab CE, not any of the closed source features, and GitLab has open sourced enterprise features in the past if the demand is high. Also, there is nothing wrong with comparing them to Microsoft, as Microsoft has thousands of open source projects and is quite the open source contributor.
I'd flip #4 on it's head. They aren't greedily restricting features, they are generously open sourcing features and giving them away for free. As a business, they have no obligation to do so.
When my company subscribed there was only a community and enterprise tier.
Now this has become the starter edition and I feel we are losing a lot of value.
We are 200 employees, but only 10 developers using the advanced features. We really want to make GitLab our hub (GitOps and all), however the the cost of going beyond starter edition is mind blowing (x5).
So if we are to embrace GitLab further we must abandon the idea of letting the whole company use GitLab freely and limit it to devs only.
Being small doesn't mean that we are not in need if advanced features, we just have a smaller scale.
Also as our initial tier was the top tier, and now is the bottom one, I fear GitLab will fence off future functionality with even more tiers at random.
Further, the tiers creates some artificial barriers where we several times feel the some of the new features we receive are just barely functioning and are just there to entice you to upgrade to the next tier.
We are all in all very happy with GitLab, however we are no longer pushing it as a central hub for the company.
That one is exactly ours, too. We have 275 users in license, bought when GitLab Enterprise was the thing. We set up GitLab to help establish innersourcing (e.g. https://about.gitlab.com/2016/07/07/trends-version-control-i...), where all employees are users -- no exceptions. We run a GitLab introduction as part of onboarding of all employees, whether techies, marketing people or recruiters.
Our 275 users are an eclectic mix. There are a few projects that really pound the product, there are lots of internal playground repositories, and even a few non-technical documentation repositories. The requirements are scattered.
I think that that perhaps 25 of the 275 users have need for Ultimate Edition, but that is not possible, we'd have to pay $325.000 for the pleasure. And that is going nowhere.
An interesting question then is what do we do next? Perhaps our innersourcing strategy has to go, and each team will get to choose their own platform. People will chose what they know, and soon most will be on GitHub.
The 250 users who don't need Ultimate are using our GitLab-installation for entirely different things (different projects, different repositories, etc) than the 25 who do.
For example, our training academy keeps a bit of training material in asciidoc format, stored in GitLab, and available to everybody in the organization . GitLab Starter is fine for this need, and this is one reason why every employee has a GitLab license.
On the other hand we have a software project with 6-8 team members who could benefit from GitLab Ultimate. Their needs do not apply to the rest of the company, so we will not get 275 Ultimate licenses for this purpose.
We want (wanted) to have a single GitLab instance to rally around, where we could keep track of all sorts of projects across the company. We went for the Enterprise edition to make sure we could use it without limitations, but we're slowly realizing that it ain't so.
Also, some quick stats: 264 users with altogether 76 groups and 887 projects, adding 5-10 projects a week and 5-10 users a month. We managed to create the hub we wanted, but the hub we bought is no longer catering for our needs, and the hub we need is too expensive.
We're facing the same problem at my company, I heavily pushed towards switching to GitLab and am currently overseeing the process. While we can probably make due with CE, there are a few features that only the 10 to 15 developers in our 300+ employee company would actually use. I don't think that in the foreseeable future the price point of Ultimate will make it viable for us to go that route. Having every employee being able to use GitLab is essential to my idea of how GitLab can be of use to the company, but unless free guest users will also come at least to Gold tier, I think we will have to live with the limitation of CE rather than becoming paying customers. (Please don't get me wrong, I definitely value the product a lot, but I'm not making these decisions alone and I'm merely stating what I know to be the facts for our company. As a fan and developer who would like to use some advanced features I'm hoping that free guest users will come to the other tiers as well.)
IMHO, guest users should be free for everyone. Why should I use GitLab Ultimate instead of GitLab CE + JIRA + JIRA Service Desk and even BitBucket? If I have less than 10 contributors (ie: developers), I can self host Atlassian stuff for less than $100 / year and JIRA Service Desk lets me have unlimited customers for no additional cost.
GitLab's issue tracker and Wiki would be a perfect fit for me to support customers and non-contributors. I really think you should try to make that type of distinction. I would describe a "non-contributor" as someone that generates work for contributors. Ex: Customers submitting issues that a developer needs to fix.
I don't understand the reluctance to make guests free for everyone. If you're worried about existing licenses getting dropped in favor of free guests, you've got a big problem that's going to catch up with you eventually. People don't like paying for things they're not using.
If you think free guest users will encourage people to upgrade, I don't like that either. It's really frustrating to get locked out of features that would be useful to me just because I'm not a huge developer that can afford Ultimate licenses. I'd say that limiting my ability to develop good processes and workflows, as a tactic for "encouraging" me to upgrade, isn't going to leave me felling confident in my choice to use GitLab. Giving me the ability to scale up when I need it / can afford it will.
I want licensing that scales up with me, not licencing that I need to buy if I want to scale up. Get it? I'm already making a HUGE trade-off to move from CE to a paid license because I can't add contributors for free any more.
As a general observation, the way GitLab's cost scales up seems weird to me. If you plot the incremental cost of adding users to (ex:) JIRA, it looks like a hill that gets easier to climb as you add users. If you do the same for GitLab, it looks like a set of stairs (aka steps). Every time you jump tiers there's a huge pricing cliff you need to be able to climb. If the features I need to scale up (my business) are locked behind those pricing cliffs, I think it's risky to buy into that, isn't it?
I really like the way Microsoft does their licensing with Office 365. They let you arbitrarily assign licenses on a per user basis. For example, I can have one user on "Business Premium" and everyone else on "Business Essentials". Have you ever considered something similar?
I feel like I get really good value out of the Office 365 model. To use GitLab as an example, I "make do" with "Starter" because I don't want to bear the cost of an upgrade for every user. With Office 365 I'd simply buy a "Premium" license for myself and leave everyone else with "Starter" licenses.
I would also say that if you ever decide to allow arbitrary, per-user licenses, the first user should get a free Ultimate license. I've used GitLab for 2+ years and I have no idea what features are available in Ultimate. I pretty much live in CE / Starter. There's no way for me to discover the features I don't have.
I'd also be willing to buy short term licenses, if that were an option, which is another reason guest users being free for everyone might be a good idea. For example, if I'm working on a project for 1 month, it would be nice to be able to give a few people access as collaborators / contributors. However, I don't want to "kick them out" once the project is done, so a downgrade to a free guest user would make a lot of sense. As it is, there's no chance I'm buying licenses for anyone because it's annual only pricing and kicking them out when the project is done makes it seem like I don't want to support the project.
To add something positive, the GitLab (product) issue trackers are amazingly well run. I've never run into a problem with GitLab where I felt like it wasn't worth my time to create an issue for it.
You pay 200 employees but don't want to spend $19/user/month on software for a company hub? That's not really a small company, and this seems like a budgeting problem if money is that tight.
You can also try running multiple installations with a separate dev-only instance with more features. Also have you tried contacting Gitlab to negotiate? A few emails can go a long way.
I would say 200 employees is fairly small company; and depending on the line of business it is certainly small enough that profit margins and thus spending may need to be closely watched.
If you consider that the OP has only 10 out of 200 users that need the advanced features, but has to purchase the advanced features for all 200 users for anyone to use those features that is $45,600 a year.
Now if it were possible for example to have a mixed licensing model; buy 10 Premium licenses for the users who need it and 190 Starter licenses for everyone else then that is $11,400 a year. That is a difference of $34,200 a year so it may be the difference between being able to hire another employee or not.
As stated, they can run separate instances, or spend 5 minutes contacting GitLab to negotiate.
200 employees is not small, that is considered a medium sized business. Millions of companies around the world never get past single-digits. With payroll extending into 10s of millions, $35k sounds rather trivial if it really is powering the company hub and the value that brings.
"200 employees is not small, that is considered a medium sized business"
I'm just curious what your basis for that is? To go with some kind of standardization on the term "small business" I would say the safest definition (within the US) would be to follow the SBA guidelines that define a small business. Depending on the industry a small business is defined by the SBA as a maximum of anywhere from 100 to 1500 employees. So it is not cut and dry that this is or is not a small business; industry and also potentially revenues in millions of dollars would need to be known to determine absolutely if it by definition a small business.
"I fear GitLab will fence off future functionality with even more tiers at random" our goal when introducing the new tiers was to put new functionality in then, not to move existing functionality away. In the future we might move functionality between tiers to keep the grouping logical but we won't do that lightly let alone randomly.
New functionaly is made iteratively starting with the minimal viable change. But they should always function and additions should land in the same tier. If we missed the mark somewhere please let us know.
I think the problem for us is that not all users are equal.
To embrace devops/gitops I really want most of the company involved through our GitLab instance, but only a subset of the license seats would actually use the kubernetes features for instance.
Most of our users would not venture beyond the features of the community edition (except for the LDAP auth we use).
So while we enjoy GitLab and do some software development, we are not a software company. I think this is becoming all the more common.
I recognize this. Not every company with developers is a software develop company. Those 190 others that dont use the advanced features, what subset of functionality do they require?
Primarily logging in, filing issues and using the wikis. A few might be able to request changes by submitting a PR instead of issues.
We do need to have authentication and cannot simply mark all repos public either.
The 10 power users want to take advantage of the kubernetes and devops features - especially since we are a small team covering a lot if ground.
I prefer VS Code over native alternatives. Don't conflate your anecdotal evidence with facts. Many users don't know much RAM a process consumes or what an Electron app is, they just care about what the app can do, how fast it is, etc.
That's because, as the parent said, there are no good (e.g. equivalent) native alternatives.
If there was a native editor with feature parity with VS Code (including the number of plugins and dedicated MS resources speeding up its development, and free), nobody would be using it.
> If there was a native editor with feature parity with VS Code (including the number of plugins and dedicated MS resources speeding up its development, and free), nobody would be using it.
Is it possible that VS Code (for example) exists (in its feature specific incarnation ) only because Electron is a cost cutter in terms of portable development?
In other terms: Maybe the portable native full featured VS Code is the middle of the cheap-fast-good venn diagram.
>Is it possible that VS Code (for example) exists (in its feature specific incarnation ) only because Electron is a cost cutter in terms of portable development?
It could -- though I doubt it.
But I was concerned with a more limited question: if there was a good VS Code alternative that's native, would many still prefer an Electron version?
> But I was concerned with a more limited question: if there was a good VS Code alternative that's native, would many still prefer an Electron version?
I understood what you meant. I respect you disagreeing with my premise, but in the scenario where that premise is true, your question is not applicable.
Scenario: Would anyone choose MDF boards at IKEA if they could choose plywood or natural wood, or assemble their own furniture if given the choice (at the same price)? Barring a few applications, probably not. But IKEA wouldn't be IKEA if they were just another producer of wood furniture, meaning they got to market and stayed there because of the shortcuts and limitations they could justify when reaching a price.
Same thing here (IMHO). VS Code could have some cross-platform code and some platform specific code, but the cost would be higher and the output velocity would likely be lower. Assuming that is true, your question is misleading, albeit not on purpose.
Which is what I use. But ST3 doesn't have the full power of a 20+ strong MS team behind it, but a single person (and another hired to help here and there), and so doesn't have the same momentum -- and it's getting behind in features as well.
I never kept tabs on the development effort on neither VSCode nor Sublime Text, but it was always my impression that much of the power either editor has comes from 3rd party extensions rather than the editor core. As such, I believe it was the hype around Atom and VSCode that drove people to write extensions for them, leaving ST behind.
>but it was always my impression that much of the power either editor has comes from 3rd party extensions rather than the editor core
A lot of it, yes. But VSCode also invests a lot in core functionality (in what in other platforms would be plugins). The Git integration is one such example -- or the ability to debug Chrome in it.
>That's because, as the parent said, there are no good (e.g. equivalent) native alternatives.
But that's not true. I use Sublime Edit and have happily used BBEdit and TextMate. Emacs is fine for many people, and I still use vim for fast edits in terminal mode all the time. There are plenty of other great native editors for just about all platforms.
Well that's just not accurate. With our Electron app, the main process consumes 40mb of RAM, with each window using 30mb of RAM, so if you have a windowed app, thats a minimum of under 70mb of RAM (results will differ, our app is quite large).
Yeah, this is realistic. I wish people would stop perpetuating the myth that "That's just how Electron is". It's perfectly possible to write Electron apps that don't automatically hog half a gig of RAM.
That's news to me, and people who make electron stuff tell me they can't get it down below a few hundred mb of memory usage. Can you point me to some resources about reducing that?
Are there any examples of Electron apps that don't do that, though? I've never seen one that didn't like to eat at least a few hundred MB, and most of them seem at least somewhat leaky, too.
