Am 08.03.2017 um 13:05 schrieb Richard Brown:
On 8 March 2017 at 08:23, Stefan Schäfer firstname.lastname@example.org wrote:
let's stop the discussion about the meaning about the acronym "SMB". What Klaas talked about was indeed "Small and medium business". The german acronym for this is KMU (Kleine und Mittelständische Betriebe).
What we (Klaas and me) want to talk about was the qualification of openSUSE Leap to fulfill a lot of needs of small business companies.
About 98% of all tax paying companies in Germany (an I think in he EU at all) have less than 50 employees. The IT infrastructure of a lot of them is a mess and dominated by Windows.
We the invis-Server Projekt (as an very unknown openSUSE Spin Off) build a cost effective server system for these companies. Klaas whith his "pet project" ;-) Kraft develops an accounting software for small business. With our projects we try to deliver cost effective IT for these small companies.
What we want to do is to start an openSUSE Team with other people of the openSUSE community who uses openSUSE to build up IT Infrastructure in small business companies.
With Klaases words: "We think and hope that there are other community members around who have experience in SMB, and a Project Team's task would be to collect the information, create and document solution proposals and hints, and promote openSUSE and the existing SMB solutions together."
Please substitute the acronym "SMB" with "Small and Medium Business". ;-) ... and let's talk about this.
Am 06.03.2017 um 22:01 schrieb Klaas Freitag:
with this email I like to ask about the status of the openSUSE Projects Teams, such Education or Medical, as listed at , and see if openSUSE would support the founding of a new Project Team which would be openSUSE for Small and Medium Business, or short 'openSUSE SMB'.
With Invis-Server  which builds on the openSUSE distributions and the openSUSE community and tools we have a very successful and hardened offering for SMB, that is exclusively built on openSUSE. Stefan Schäfer, the Invis Server founder is a long standing openSUSE promoter and very experienced system integrator in real life SMB scenarios. He started many years ago to build Invis on (open)SUSE, and has moved his project consequently closer to openSUSE by using the OBS, building up community and promoting the work on various openSUSE- and other FOSS conferences.
As I am also interested in the SMB area doing my pet project Kraft  for more than 14 years now, Stefan and myself often worked together for example by giving talks together about the topic.
In the recent Hackweek we were thinking about how to make the whole activity more visible to a broader community and one idea was to found an openSUSE Project Team for SMB. We hope that this will increase the visibility of the solutions.
For the openSUSE project this is a perfect reference that demonstrates how valuable openSUSEs technical precision and ease of use are for these kind of "special usecases". For SMB, that is in place for years, with very practical experience in lots of installations.
We think and hope that there are other community members around who have experience in SMB, and a Project Team's task would be to collect the information, create and document solution proposals and hints, and promote openSUSE and the existing SMB solutions together.
What do people think about this?
I think this is an awesome idea! I congratulate you on your initiative and look forward to seeing what you come up with.
I have some ideas which I think could make this "openSUSE SMB" idea a real success
I expected that. ;-)
First, the technical stuff, I'd love it if the team could look at both openSUSE distributions, but especially Leap, and help make them exceptional options for SMB's
In my mind, that would mean
- Identifying and ensuring openSUSE TW/Leap contain the packages
SMB's need, and that they are suitably well maintained and polished. This could also mean contributing tests to openQA to ensure we keep them that way.
- Ensuring openSUSE TW/Leap has suitable documentation for SMBs. This
hopefully will just mean encoraging, supporting, and collating documentation that already exists in a relevant portal on the wiki for SMBs
- Ensuring the 'User Experience' (or SMB Experience?) of openSUSE
TW/Leap is nice, polished, and meeting the expectations of SMB users. This might mean tweaking and tuning things like patterns to make things like software discovery and quick-setup easier for SMBs.
- Investigating how to market openSUSE directly towards SMBs. Idea's
that immediately spring to mind would be including a clear section for SMBs on www.opensuse.org, clearly sharing our story of how Leap is a perfect choice for them.
Note, all of the above suggestions assume that the work this SMB team will do will be part of the existing openSUSE Distributions.
I'm with you. But this is a lot of work. which means we need a lot of people joining the team.
While I love and respect the work that the Medical and Education teams have and continue to do, I think it would be safe to say that their experience by running their projects as 'derivatives' ultimately ends up being too much work for them - and then backfires on the openSUSE Project as a whole as we often saw less direct contributions in the area of Education and Medical in the main distributions, which then causes a spiral of endless work..
Let's avoid that with this SMB idea, and try and do everything 'upstream' (ie. in openSUSE-proper) first and do our best to avoid a separate openSUSE-SMB flavour for now. I also don't like the idea of openSUSE directly competing with invis-server, especially as I think we need every single contribution those experts can give us to make this work.
We the invis-server team (I think, that I can speek for them all) hope that our work and project can move clother to openSUSE. We are not looking for competition, we are looking for integration.
We talked about this last year at osc. I think more than 75% of all packages we build in our OBS repos are only build caused by dependecies an because they are not part of the openSUSE distros
It would be nice if we had to maintain much less packages by our own. ;-)
If we go down this road and we find it necessary, if we start off on this road very tightly together we should be able to ensure we stay better in sync than deciding to make a derivative from Day1.
That's my 2c, I'm really excited to see where this goes
Maybe we should schedule a first meeting to start the Team.