Dropbox maakt zakelijke chatapplicatie opensource

Dropbox heeft de broncode vrijgegeven van Zulip, een chatapplicatie die bedoeld is voor gebruik door bedrijven. Ook de bijbehorende applicaties voor Android, iOS en desktopbesturingssystemen zijn vrijgegeven. Dropbox hoopt dat gebruikers vervolgens de software gaan verbeteren.

De benodigde broncode voor Zulip is al online gezet op een Github-repository, waardoor geïnteresseerden meteen aan de slag kunnen. Er is code om de webserver en webapps op te zetten, maar ook van de al uitgebrachte applicaties voor Android en iOS is broncode beschikbaar. Ook de benodigde code voor apps die geschikt zijn voor de desktopbesturingssystemen Windows, Linux en Mac zijn aanwezig. Het geheel is vrijgegeven onder een Apache-licentie, zo liet Dropbox weten in een aankondiging op zijn blog. Op zijn website helpen de ontwikkelaars van Zulip bij het opzetten van een eigen chatserver, iets dat vooral bedoeld is voor bedrijven.

Met het opensource maken van Zulip hoopt Dropbox dat gebruikers het product gaan verbeteren. Een groep met ontwikkelaars zou al hebben aangekondigd met de broncode aan de slag te zullen gaan. Waarschijnlijk hoopt Dropbox dat de stap om Zulip opensource te maken meer gebruikers oplevert.

Dropbox nam Zulip in 2014 over, in een periode dat het ook een aantal andere start-ups overnam. Zulip is bedoeld voor zakelijke communicatie, waarbij verschillende chatvensters kunnen worden opgezet en gesorteerd op basis van onderwerp. Dat moet zakelijke communicatie overzichtelijker maken.

Reacties (51)

[Fuzzillogic]

Of een chatclient open source is, is nauwelijks relevant. Wat veel meer boeit is of het protocol open, vrij en decentraal is. Dan komen er vanzelf open en close source clients, waardoor de keuze juist veel groter is. Voorbeeld: E-mail.

[martijnsch]

Je haalt de woorden uit mijn mond. Maar het is allemaal niet zo eenvoudig.
Diaspora, Jabber/Google Talk, Google Wave... Allemaal hoge verwachtingen, zo goed als niks meer van over.

[ShatterNL]

Dat die Google diensten floppen is niet gek, want de integratie met andere diensten is gewoon altijd extreem weird bij Google. Net als bijvoorbeeld AdSense en YouTube met Google+ nu, het werkt allemaal voor geen meter samen eigenlijk, maar het MOET op 1 of andere manier wel...

[martijnsch]

Jij hebt het meer Google diensten onderling. Maar Google Talk werkte met XMPP Dus iemand met Jabber kon met iemand op Google Talk chatten. En Wave was een volledig open protocol. Iedereen kon daarvoor een server en client maken.

[Reactie gewijzigd door martijnsch op 23 juli 2024 00:52]

[Fuzzillogic]

Dat deze decentrale systemen geen hoge vlucht genomen heeft komt omdat bedrijven dan de controle verliezen. (Gelukkig) is er niet één partij die unilateraal over e-mail kan beslissen. Dat moet op basis van consensus gaan van belanghebbenden.

Maarja, zolang gebruikers lekker makkelijk blijven kiezen voor de shiny solution van bedrijf X, zonder zich te bekommeren over de totale vendor lock-in, dan zal bedrijf X uiteraard hun controle over het platform niet opgeven.

Ik hoop dat nu open source gemeengoed wordt, en bitcoin/blockchain nogmaals aantoont dat een open, decentraal protocol gewoon veel robuuster is, er meer mensen zullen kiezen voor open protocollen. En ja: ik gebruik enkel Jabber voor IM.

[Zack_Leonhart]

Jabber wordt in de lokale overheid nog veel gebruikt. Onderlinge samenwerking en zo.

[mae-t.net]

Dat de client open source is, impliceert dat het protocol dat ook is. Lijkt me dus absoluut relevant.

Misschien bedoel je dat het niet noodzakelijk is. Immers kan een gesloten client ook wel een open protocol gebruiken.

@Durandal: goed punt, hoewel er in de praktijk altijd wel clients opstaan, en interoperabiliteit ook wel iets van wettelijke basis kent.

@Fuzzilogic: ik ben in elk geval geen voorstander van gesloten en centrale protocollen.

[Reactie gewijzigd door mae-t.net op 23 juli 2024 00:52]

[Durandal]

Dat het protocol, of the client, open source is, wil niet zeggen dat het protocol ook rechtenvrij is. Rechten op een protocol dat effectief open source is kunnen nog steeds wel (in bepaalde mate) verhinderen dat er andere clients gebruik van gaan maken.

Een protocol moet dus niet alleen open source zijn maar ook free (as in beer), en bij voorkeur ook nog beheerd door een organisatie die verder geen conflicterende belangen heeft.

[Fuzzillogic]

Wat Durandal zegt, en verder: zolang één bedrijf de totale controle over dat protocol heeft en het niet mogelijk is je eigen server ervoor te draaien, dan moet je op je hoede zijn. Bedenk in ieder geval goed wie er baat bij heeft om een protocol gesloten en centraal te houden.

[vinx77]

De API vind je hier: https://zulip.com/api/. Niks IRC-achtigs, maar JSON (en veel Python). Bots zijn mogelijk, maar ik zie er niet echt veel.

[Rafe]

2014 en 2015 lijken wel de jaren van de zakelijke chatapplicaties. Slack en HipChat zijn erg populair geworden, en als je niet in de cloud wil/kan (en hun on-premise oplossingen zijn te duur) zijn er alternatieven in de vorm van Rocket.Chat, Mattermost (dat straks ook mooi integreert in GitLab) en nu ook Zulip.

[Toettoetdaan]

Ik gebruik Slack en HipChat, ze zijn allebij prima. Maar daarvoor zou ik ook Skype kunnen gebruiken.

Wat het verschil maakt is de intergratie met andere tools, als de commits en de tickets ook langs komen in je chat, is het ineens een stuk nuttiger dan iets als Skype.

Dat is mischien waar dropbox op hoopt door het open source te maken, dat de community voor integratie gaat zorgen die met andere tools nog niet mogelijk is.

[Dreamvoid]

Ronkende PR teksten, maar het is voor mij onduidelijk of dit een serieuze open source applicatie is, of een laatste reddingspoging voor een geflopt produkt waar ze geen dev tijd/geld meer in willen steken en dus hopen op gratis developers van buiten? Ik heb niet het idee dat Zulip erg succesvol is namelijk. Kent iemand een bedrijf waar het draait?

[Martinspire]

Mja lijkt me dat ze in principe gewoon de hele support droppen en er weinig tijd of energie meer in gaan steken. Ik bedoel, hoe gaan ze er nu nog geld aan verdienen.

[johnkeates]

Waarschijnlijk gebruiken ze het zelf en zullen bedrijven die het ook gebruiken dit als een kans zien om hun geld niet in contracten voor support te stoppen, maar in engineers die zorgen dat het doet wat ze willen.

[Anoniem: 149075]

Je ziet toch ook overal die WhatsApp Webcare paddestoelen uit de grond schieten ? Mensen zijn zich bewister van data en vaak gaat het om de hype en is het daarna weer over.

Het lijkt lekker makkelijk communiceren maar bij het meeste zakelijk contact wordt er utieindelijk toch ook weer gebeld na veel gemail... dat is namelijk geaccepteerd en persoonlijk contact is genoodzaakt.

[maplebananas]

Dit is een zeer mooie zet van Dropbox, zeker als het om de zakelijke markt gaat!
Het opkopen van startups vind ik persoonlijk een slechte zaak, maar als ze er zo mee omgaan is het alleen maar toe te juichen!

[Reactie gewijzigd door maplebananas op 23 juli 2024 00:52]

[Greyish]

Dat is nou het fijne aan open source! Goedwillenden bekijken de source en verbeteren het als het kwetsbaarheden bevat. Kwaadwillenden bestuderen natuurlijk ook de source, maar als een kwetsbaarheid door een kwaadwillende is gevonden dan is dat waarschijnlijk ook gevonden door een goedwillende .

[Gomez12]

Dat is het idee, de uitvoering is dat veelal echter niet.

De uitvoering is meestal : De core-developers kijken naar de source en voor de rest enkel nog de kwaadaardigen.

En voor de core-developers maakt Closed of Open-Source niets uit want zij kunnen er toch bij.

[Reactie gewijzigd door Gomez12 op 23 juli 2024 00:52]

[core_dump]

Klopt helemaal, alleen de roze brillers hierboven geloven nog in de mythe dat open source software door duizenden goedwillende debuggers die urenlang gratis code doorspitten om deze te verbeteren..

[Superstoned]

Ik weet niet hoeveel open source projecten jij draait, maar ik ben bij ownCloud betrokken en je kunt hoog en laag springen maar het is gewoon een feit dat door de beschikbaarheid van de code wij enorm veel input krijgen op veiligheid van de code. En dat zou niet zo geweest zijn met gesloten code. Dus ja, het werkt, heel goed zelfs.

https://hackerone.com/owncloud/thanks/prior voor een lijstje van mensen wat hun naam aan hun melding wilde verbinden (we krijgen ook regelmatig audits van mensen of bedrijven die dat niet willen).

En dat zijn ALLEEN de mensen die een probleem als eerste rapporteerden, EN waarbij we het probleem belangrijk genoeg achten voor melding. We krijgen vaak genoeg dubbele problemen of minder belangrijke issues gemeld.

Edit: en ik ken zat mensen van zat andere projecten die je precies hetzelfde zouden vertellen. Ja, je moet een gezonde community hebben, een beetje redelijk bekende broncode, een groot aantal gebruikers die om security geeft etc, het is niet automatisch dat open source veiliger is. Maar het is wel vaak zo en ik zou een goed gemanaged open product meer vertrouwen dan een goed gemanaged gesloten product. Met slecht management is alles slecht dus dan maakt het weinig uit...

[Reactie gewijzigd door Superstoned op 23 juli 2024 00:52]

[Gomez12]

Maar closed source projecten hebben dit soort lijstjes ook gewoon (alleen dan veelal niet toegankelijk).
En daar komen ook gewoon bug-reports binnen van vrijwilligers en van testers en van partners en van auditors etc etc etc.

Dat lijstje van jouw dat vind ik eerlijk gezegd het bewijs dat het niet werkt, schijnbaar zijn er in 2015 3 mensen geweest die en de source gelezen hebben en er bugs uitgehaald hebben.
Houd er eens een bug-tracker naast of een black-hat feature list en die gaat veel en veel groter zijn.

[Blokker_1999]

Met closed source kan je wel een bug melden als je deze tegenkomt, maar je kan geen audit doen om potentiële problemen op te sporen zonder dat ze als bug zichtbaar worden.

En nee, het klopt dat het bij FOSS vaak ook niet gebeurd, maar de mogelijkheid is er, en dat is het belangrijkste. Je bent zeker dat je code ziet zonder een achterdeur in en je kan die code zelf opnieuw gaan compileren.

[Superstoned]

Audit MAG vaak niet eens, zie de recente nonsense rond de uitspraken van Oracle's hoofd security maar eens.

[Superstoned]

je weet helemaal niet of closed projecten dit hebben. Veel daarvan zijn zelfs erg vijandig tegen externe input qua veiligheid en proberen 'security through obscurity', ook wel 'struisvogel veiligheid' genoemd. Kijk maar eens naar de recente uitspraken van Oracle's hoofd van security - die gaf aan dat ze klanten die met security feedback kwamen absoluut niet waardeerden, nog gekker, dat het een licentie overtreding was om zelf security audits te doen op de software van Oracle die je gebruikt. Serieus.

Voor veel bedrijven is security negeren een kosten besparing en omdat ze gewoon niets zeggen of bekend maken kun je als gemiddelde consument/gebruiker/koper helemaal niet zien hoe veilig je product is.

Bij ownCloud en andere open source producten is dat anders - je kunt zo zien of er mensen naar kijken, en hoe daar op gereageerd word, en wat er gevonden is, en je kunt zelf een audit (laten) uitvoeren als je je zorgen maakt. Allemaal dingen die moeilijk, meestal niet, ongewenst zijn of onmogelijk kunnen bij gesloten software.

Transparantie over security is de enige manier om veiligheid te garanderen en bij closed source is dat niet onmogelijk maar veel lastiger. Bij open source is het sowieso transparant en hoewel dat het probleem nog niet helemaal oplost is het een stap in de goede richting.

Tussen haakjes, ik wil het niet op authoriteit gooien, maar ik moet de eerste serieuze security expert nog tegenkomen die zal beweren dat transparantie en openheid niet het beste idee zijn. Lees de blogs van Bruce Schneier maar eens.

[Dorank]

Het hoeven er geen duizenden te zijn, 1 paar extra ogen is al genoeg om het nut van opensource aan te tonen. Ik kan verder niet voor andere praten, maar gezien ik zowel professioneel als prive vrijwel alleen opensource spul gebruik en indien ik dan tegen een bug/ongewenste feature aanloop soms in de source kijk wat het probleem is en in die gevallen soms nog een patch maak die ik weet upstream aanbiedt, maakt dat het gebruik van opensource, voor mij en het bedrijf waar ik voor werk, de voorkeur heeft.

Het nadeel van opensource is dat er van mij wordt verwacht dat ik op onderzoek uit ga om problemen te fixen, closed source spul is veel makkelijker in dat opzicht: blackbox, neem maar contact op met de leverancier.

Ik zou dan ook bij voorkeur overstappen op closedsource software, zodra deze bug vrij is.

[mae-t.net]

In je laatste zin zeg je dat je nooit overstapt op closed source

Probleem met het idee achter blackbox, neem maar contact op met de leverancier is dat die ook niet altijd met oplossingen komen. Vaak zijn dan de mogelijkheden om zelf de fout te vinden ook extreem beperkt (zelfs bij een groot en veelgebruikt project als MS Windows zijn foutmeldingen ultiem obscuur, en het oplossen middels officiele oplossingen vergt alsnog veel probeerwerk).

[CAPSLOCK2000]

Er is een hele "cover your ass" cultuur waarbij het enige doel lijkt te zijn om niet verantwoordelijk te zijn voor de problemen. Het doet er niet toe hoe groot of hoe klein het probleem is, zolang het maar het probleem van een ander is.
Op papier zijn alle risico's afgedekt maar in praktijk zit je met boze gebruikers aan de ene kant een aan de andere kant een leverancier die al drie weken zegt dat jouw probleem de hoogste prioriteit heeft en dat ze niet meer kunnen doen.

Daarom vind ik dat je kritieke techniek zo veel mogelijk zelf moet doen en afhankelijkheid van leveranciers moet vermijden.

[Anoniem: 80466]

Het is vaak ook een teken aan de wand als een commercieel bedrijf bepaalde closed software ineens open source maakt.
Dan gaat het meestal om een product wat mislukt is en waar het bedrijf zelf niet mer de resources in wil steken.
Een product dus wat in essentie is afgeschreven door Dropbox.

[mae-t.net]

Het is goed dat abandonware open-source gemaakt wordt, maar dat betekent niet per definitie dat iets dat open-source gemaakt wordt ook meteen abandonware is. Hoewel er natuurlijk best bedrijven zullen zijn die zo redeneren.

[ONiel]

Inderdaad, wat je wel vergeet is dat nu de rest zonder kwade bedoelingen ook makkelijker exploits kan vinden.

Doordat software open-source is, zijn er meer mensen die naar exploits zoeken. Het overgrote deel van die mensen geven deze vulnerabilities dan aan. Hierdoor worden meer vulnerabilities gevonden, maar worden er ook meer gefixt. Hierdoor worden de vulnerabilities gebruikt door kwaadwillende niet lang in gebruik, en zijn er op den duur ook gewoon veel minder vulnerabilities.

Open-source betekent meer veiligheid, niet minder.

[Gomez12]

Doordat software open-source is, zijn er meer mensen die naar exploits zoeken. Het overgrote deel van die mensen geven deze vulnerabilities dan aan.

Hoe kom je hierbij?

Er is geen actieve community die naar exploits zoekt in OS software om die keurig te melden (wel eentje om ze actief op de black-hat list te zetten).
Als een OS-project dat wil dan moet die net zoals een CS bedrijf daar gewoon een audit-bedrijf voor inhuren die dit doen.

[ONiel]

Eigenlijk is er wel zo'n community. Kijk maar naar Linux en andere GNU projecten bijvoorbeeld.

Er zijn veel mensen die proberen exploits te vinden in Linux, en ze dan rapporteren.
Daarbij komt ook nog eens dat sommige projecten bug-bounties hebben, dus zijn er sowieso mensen die vulnerabilities zoeken voor geld.

Deze noemt men respectief Ethisch Hackers, en Bug-bounty hunters.

Evenveel mensen die in closed-source zoeken dan in open-source?
Echt niet, ik hoef je niet te vertellen dat het 'makkelijker' is vulnerabilities te vinden in open-source software.

[Gomez12]

Eigenlijk is er wel zo'n community. Kijk maar naar Linux en andere GNU projecten bijvoorbeeld.

Yep, kijk ik naar en dan zie openssh, X-Server waar niemand meer een poot naar uit durft te steken omdat het te oud en te lang niet onderhouden is.
En zo heb je nog wel tig voorbeelden.

Daarbij komt ook nog eens dat sommige projecten bug-bounties hebben, dus zijn er sowieso mensen die vulnerabilities zoeken voor geld.

Deze noemt men respectief Ethisch Hackers, en Bug-bounty hunters.

En elke bug-bounty hunter heeft bij elke gevonden bug de keuze : Of black market of makers, en nu mag jij raden wie er meer betalen...
En waar het merendeel van de bugs als 1e heengaat.

[ONiel]

Zo zijn er inderdaad een tig voorbeelden, maar in al de rest zoeken ze wel fouten.

Mensen die het op de black market verkopen zijn 1) géén ethisch hackers, en 2) géén bug-bounty hunters.
een bug-bounty is een contract tussen maker en potentiële vinder.
Als deze vinder het dus niet aangeeft, is het contract niet geldig en is er dus niet sprake van een bug-bounty(-hunter).

[Gomez12]

Zo zijn er inderdaad een tig voorbeelden, maar in al de rest zoeken ze wel fouten.

"Al de rest" en wat is dat exact? Want als ik een projectje op GitHub dump dan gaan ze daar niet direct overheen.

De realiteit is simpelweg dat er nog niet eens naar 0,00001% van OS code ooit omgekeken wordt qua veiligheid en dat is puur door het volume.

Mensen die het op de black market verkopen zijn 1) géén ethisch hackers, en 2) géén bug-bounty hunters.
een bug-bounty is een contract tussen maker en potentiële vinder.
Als deze vinder het dus niet aangeeft, is het contract niet geldig en is er dus niet sprake van een bug-bounty(-hunter).

Je probeert een zwart-wit scheiding te maken van een grijs gebied.
Als ik vandaag een bug-bounty incasseer en morgen verkoop ik bug aan een black-hatter. Ben ik dan wel of geen bug-bounty-hunter?

[ONiel]

Linux. Er zijn meer als 250 vulnerabilities aangegeven in de Linux kernel alleen al. Niet niks vindt ik persoonlijk.

Voor GIMP zijn er 15 vulnerabilities aangegeven, GIMP is slechts één voorbeeld van GNU applicaties waar vulnerabilities zijn aangegeven.

Dan ben je vandaag een bug-bounty hunter, morgen was je er een.

[Amanush]

De licentie van software, en de veligheid van software zijn 2 totaal verschillende zaken. Een stuk software wordt niet meteen veiliger zodra het ge-open-sourced is.

[ONiel]

Niet meteen, maar geleidelijk aan wel. Doordat de licentie open-source is worden er meer fouten in de software gevonden en opgelost.

De licentie beïnvloedt de veiligheid wel.
http://www.dwheeler.com/s...open-source-security.html

[Amanush]

Fout: als het project populair is worden er meer fouten in de software gevonden en opgelost. Anders zal het weinig verschil maken. Het is erg kort door de bocht om te zeggen dat Open Source software / vrije software veiliger is dan proprietary software.

[ONiel]

Als het project minder populair is zullen er inderdaad minder fouten gevonden en opgelost worden. Maar, er zullen ook veel minder kwaadwillende zijn die geïnteresseerd zijn in het exploiteren van die applicatie. (Hackers zoeken meestal slachtoffers daar waar de markt het grootst is).

Dus dat heft mekaar weer op.
En alle beetjes helpen.

Ik zeg ook niet dat alle open-source software veiliger is dan het closed-source alternatief. Ik zeg alleen dat als een closed-source open-source wordt gemaakt, het op lange termijn veiliger zal zijn (in meeste gevallen). Als je bijvoorbeeld een 'geheim algoritme' gebruikt om je te beschermen tegen een bepaald soort malware, houd je het inderdaad beter closed-source.

[Reactie gewijzigd door ONiel op 23 juli 2024 00:52]

[Blokker_1999]

Het al dan niet open source zijn van software heeft geen enkele invloed op de veiligheid er van. Dit stelt iedereen in staat om een code audit te doen en op zoek te gaan naar problemen. Daarnaast zal men altijd in staat zijn om problemen op te lossen, zelfs wanneer Dropbox er ooit zelf de stekker uit zou trekken.

Bij closed source software ben je volledig afhankelijk van de maker van die software. Je hebt geen enkel zicht op de kwaliteit van de code en als men ooit stopt met de ontwikkeling blijf je mogelijks met gebrekkige software zitten.

Je moet maar eens opzoeken of Apache danwel IIS meer zwakheden bezit bijvoorbeeld. Niet alleen word Apache meer gebruikt, is het open source, maar bevat het ook minder lekken.

[batjes]

Misschien zelf eens opzoeken of IIS onveiliger is als apache of niet.

Apache heeft afgelopen jaar toch een berg meer exploits verzameld, is tevens de enige httpd die de afgelopen jaren meermaals hard misbruikt is.

http://www.cvedetails.com...d-3436/Microsoft-IIS.html
https://www.cvedetails.co.../vendor_id-45/Apache.html

[w3news]

Je kan het ook anders zien, je hebt meer developer die het product beter en veiliger kunnen maken, en omdat het open source is, is de code kwaliteit en veiligheid extra belangrijk.

Verder kun je als bedrijf meewerken aan de veiligheid, features toevoegen, en alle code inzien waardoor je precies weet hoe het werkt, en kun je zelf zien waar een zwakke schakel zit.

[valvy]

En kan men eerder deze genoemde exploits eruit halen.

Uiteindelijk is het altijd discutabel of het vrijgeven van de broncode veiliger is. Gellukig zijn andere effecten wel positief. (Niet meer afhankelijk van een derde partij, snellere uitrol van updates minder kans op backdoors)

[johnkeates]

Dat valt wel mee, behalve als je code rampzalig slecht geprogrammeerd is zijn exploits nog steeds even 'lastig' te vinden. Het probleem zit vaak niet in de code, maar in afhandeling post-compilatie.

[Anoniem: 481893]

Kun je je reactie toelichten?

[mae-t.net]

Doorgaans wordt het dan juist moeilijker (level playing field - ook goedwillenden vinden ze sneller). Als je een controversieele mening opschrijft wordt van je verwacht dat je hem motiveert. Ik ben benieuwd.