ChatOps Roadmap Meeting (17 Nov 2020) #56
Comments
blag
added
community
plan
TSC:meeting
|
@blag Do you currently have a proposal for some of these questions? Maybe document your thoughts here for the team to research & align with? |
Background2020 ChatOps User SurveyClick to expandChatOps is a majorly used feature of StackStorm, according to the results of our 2020 ChatOps User Survey Results (question #5):
One of the major blockers is that ChatOps does not have RBAC (question #6):
Most users just use action aliases to define commands (question #11):
The vast majority of StackStorm users integrate ChatOps with Slack, although MS Teams is used more than we would like or realize (questions 14 and 15):
The top three highly requested features are: RBAC, more interactivity, and better integration (questions 16 and 17):
ConclusionsClick to expandMost users find that ChatOps are important, but they want more from it. st2chatops right now works just fine, but does not have the deep integration with the rest of StackStorm that it could have, nor does it support more interactive features of chat platforms. To provide the most value to users, we should focus on pushing integration with both StackStorm and chat providers to the fullest extent reasonably possible Comparison of AlternativesAlternatives: Chat Provider SupportClick to expand
Python SupportClick to expand
Feature SupportClick to expand
Additional Considerations
|
|
errbot does support Python3.8, it looks like the setup.py needs updating. Errbot main branch is tested against Python3.6, 3.7 and 3.8 https://github.com/errbotio/errbot/blob/89c2fb2a6399739f8f9c97fdfce6b0414fff2150/tox.ini#L2 |
|
Errbot GPL-3 license related:
|
Follow Ups
Discussion Details
Conclusions
|
|
Folks, GPL is no-go: While there are ways to make it work with StackStorm opensource, it makes StackStorm toxic for anyone who considers basing an installable product on top of it. Noone will be able to add StackStorm to their commercial offerings. This - deferring companies who want to build a product powered by StackStorm - will be a terrible blow for us. It is vendors who embed stackstorm who are most likely to contribute to the core - what we miss the most. We already have some - HP (ex Plexxi), or a new company orchestral.io, we might turn them into contributors, and we need more because _this is the kind of companies who will most likely. |
|
@dzimine I think we have a chicken and egg problem with attracting outside contributors. We want ChatOps to be a well developed "killer app" for StackStorm to attract users, some of whom will turn into contributors. But we also need contributors to keep the StackStorm project healthy. So which one do we attract first? Frankly, I don't see us attracting corporate contributors much more than we really already have any time soon. The StackStorm community has lost the corporate outreach and business connections from Extreme, and to my knowledge we don't really have any salespeople working on StackStorm. The results of the 2020 StackStorm ChatOps Users Survey seem to be evidence of this point - we really didn't see any resellers represented in those results. If we do have corporate resellers and they are simply being silent on the direction of ChatOps, I think that tells us that they aren't reselling ST2 ChatOps. We have also been pretty clear that we need donations from the community, and I would think any resellers would take that pretty seriously since they are basing their product on our code. If we never attract corporate resellers then the licensing issue is entirely moot. I think there's a real risk of st2chatops dying on the vine unless we invest significant resources into improving st2chatops integration with the rest of StackStorm (eg: RBAC for ChatOps). If corporate resellers aren't willing to get involved in the direction of the project, or devote resources towards our upstream project, then I really don't have a lot of empathy for them regarding GPL licensing. They need to get and remain involved in StackStorm, or they have to accept the direction we decide to take the project. Finally, if corporate resellers do devote development resources to st2chatops directly, instead of trying to maintain their own fork, they will not be subject to the GPLv3 anyway. The GPL only applies if/when they distribute their own version of Errbot, or if they bundle Errbot itself into their package. Thanks to the exception clause in Errbot, merely writing an Errbot plugin does not mean that the plugin must be GPLed. The GPL would only apply when they go to distribute their version of st2chatops with Errbot already bundled in. Now, perhaps even this is too much of a risk for them and they wouldn't do that, but they could still resell and distribute their own fork of StackStorm without st2chatops and they would remain free of the GPL obligations. To sum up, I don't see the point in already catering to potential future resellers, or to current resellers who aren't already involved in the development process. If they want to improve the current JavaScript based st2chatops, they're more than welcome to, but the TSC subcommittee working on ChatOps thinks that with our current development resources the best solution for the StackStorm project is to switch to using err-stackstorm. It is unacceptable to me for them to dictate how st2chatops is developed without being involved in the process so if those people already exist, let them speak now or forever hold their peace. |
|
As a contributor, I wanted to add that I had raised concerns about the GPL license at the ChatOps meeting and how it might be an issue for some companies. I did promise I'd explore further, and I'm still exploring the consequences. I had paused further investigation, as at the last TSC meeting we seemed to state that we were trying to explore non-GPL options, but I'll resume to see if I can add to discussion. At the moment StackStorm bundles hubot. If StackStorm were to bundle errbot then would that not have license consequences on StackStorm? Or would we have to avoid it, and therefore loose our single installation. If st2chatops ends up being GPL, then it does affect StackStorm as a whole, and I think being able to only use StackStorm without chatops would lessen it's advantage over other offerings. |
|
My understanding is the GPL3 licence can only be imposed on work derived from it. Since errbot would be conveyed in an unmodified form it would not require other software in the st2chatops package to use the GPL3 because they are independent works. https://www.gnu.org/licenses/gpl-faq.html#GPLCompatInstaller. |
|
This is where I am unclear, as that example was about an installer. So the installer doesn't have to be GPL but what about the software that relies on the GPL software. There was arguments before on forums (and not necessarily resolved in agreement!) about a separate UI that was for a GPL CLI program. As the UI didn't stand up by itself as a product - therefore did it also have to be GPL, and you could see st2chatops being similar scenario, if it relies on errbot. But then I am not sure if the exception on plugins means that isn't true. ie does the copy left stop before the plug-in. So st2chatops if left of the plug-in - so not included. But I am not a lawyer. And it sounded like we didn't get a definite answer from Linux Foundation. But I would agree that it would put people off, as if nothing else they might look elsewhere rather than researching with lawyers what exactly they can and can't do. Being able to use stackstorm but not chatops I think would be a big limitation. |
|
usual disclaimer: I'm not a lawyer, so this is just my understanding of the situation Software that relies on GPL3 work could be tainted by the licence based on how that software integrates with it. For example, I've read in forums that if code calls out to a REST API written with a GPL3 licence, the GPL3 does not apply to the calling code. (couldn't find the source it was too long ago). If the code is a plugin of the GPL3 work and there's significant sharing of data structures, it can be considered a single combined program and would be subject to having the GPL3 applied to it. https://www.gnu.org/licenses/gpl-faq.html#GPLPlugins Based on that information, one would argue that err-stackstorm is a single combined program under the definition of the GPL3, however the authors of errbot wrote an explicit exemption for plugins permitting them to be allowed to use a licence other than the GPL3. https://github.com/errbotio/errbot/blob/master/gplv3-exceptions.txt. err-stackstorm is licenced using Apache-2.0 I hear what you and Dmitry are saying that the GPL3 is unacceptable for some use cases. |
|
I think this is the main problem with GPL, it gets unclear what does and does not cover derivative work, and that seems up to interpretation. I don't know if the errbot plug-in caveat is enough,it might be. It all means some will just flat refuse GPL, as it's the easy option, rather than get legal departments to work out if their use case is ok or not. |
|
Following up Teams support in OpsDroid is WIP: opsdroid/opsdroid#1679 |
|
any teams users want to share their integration how-to? |
|
@blag nice work |
One-off @StackStorm/tsc and @StackStorm/contributors 1 hour meeting will take place on Tuesday, 17th Nov 2020, 09:30 AM US Pacific.
JOIN ON ZOOM. Meeting guidelines described in #33.
Host: @blag
Meeting Agenda
We have gathered some community feedback on our ChatOps roadmap for how to rewrite ChatOps in Python for better integration into the rest of StackStorm. This meeting will be focused on deciding which Python-based chat framework we want to use (Errbot, OpsDroid, or something else). In the unlikely even that we have extra time we will start charting the roadmap for the ChatOps switchover.
The text was updated successfully, but these errors were encountered: