[disc] De dood van de community

[Verwijderd]

GU4DEC (Gnome User And Developer European Conference) werd dit jaar gehouden van 16-18 juni in Dublin, Ierland. De tweede dag is de community ter sprake gekomen. Een community moet hier in de ruimste zin van het woord worden opgevat voor een programma of groep van programma's. Hier horen dus de maintainers, de developers, de testers en ook de users bij. Dood, inderdaad. Jeff Waugh (Gnome Release Manager) en Luis Villa (Gnome Bugzilla Manager) gaven dinsdag hun visie op dit probleem, nadat we (enkele van de Gnome-enthousiastelingen) de nacht daarvoor in de Ierse pubs al aardig ver over dit probleem hadden gefilosofeerd.

Tekort aan developers
Het eerste probleem is dat er het afgelopen jaar een kleine opdroging van developers lijkt te zijn opgetreden. Sommige projecten runnen op de volledige krachten van een persoon. Dit is een gigantisch probleem, omdat het vertrekken van die ene persoon ook het verlies van zijn kennis inzake dat product betekent. In feite zal het product een zachte dood sterven zodra die persoon ermee ophoudt, omdat er verder niemand in staat zal zijn om onderhoud te doen.
Schrikbarend genoeg worden belangrijke projecten in Gnome, zoals Nautilus (Dave & Alex), Gtk+/Glib/ATK/Pango (Owen), libgnome e.d., door slechts een of twee personen regelmatig onderhouden. Door dit tekort komen deze personen er ook nauwelijks aan toe om nieuwe personen in hun product "op te leiden" om die posities deels over te nemen, wat een vicieuze circel tot gevolg heeft. Nieuwe developers lopen tegen een enorme drempel op voordat ze een project kunnen binnenlopen, en zullen dus of enorm veel moeite moeten doen, of simpelweg verloren gaan voor het project. Cijfers zeggen genoeg: GStreamer (mijn project) heeft het afgelopen jaar een nieuwe developer erbij gekregen, waar we er enkelen verloren. We hebben momenteel vijf regular contributors, en in totaal een stuk of 10-15 die het afgelopen halfjaar meer dan een toevoeging hebben gedaan. Elk van deze mensen is een free-time contributor, niemand wertk full-time aan het project, ondanks aanbiedingen van bedrijven om een van ons in dienst te nemen. Het gevolg is dat grote delen van GStreamer hopeloos kapot zijn, en dat niemand tijd heeft om het te repareren. Een vertraging in development is het logische gevolg.

Tekort aan vrijwilligers
Er zijn wel degelijk ontwikkelaars die aan Gnome werken, maar deze mensen werken met name voor grote bedrijven! Luis gaf enkele cijfers: 50% van de bugs in de Gnome-2.0 fase werden gefixt door mensen van Sun. Vul de rest zelf maar in, want naast Sun hebben ook Ximian en RedHat hoog ingezet op Gnome. Aan de ene kant is het fantastisch dat grote bedrijven helpen in de ontwikkeling, maar dit heeft ook negatieve gevolgen. Mensen die in dienst werken hebben veel minder mogelijkheid tot community-vorming. Daarnaast zitten ze vast aan deadlines en aan specifieke eisen, waar opensource development juist vrij hoort te zijn. Dit heeft ook een negatieve invloed op community-vorming. De beste voorbeelden zijn OpenOffice.org en Evolution: beiden worden "bijna" intern ontwikkelt door een bedrijf (respectievelijk Sun en Ximian), beiden hebben absoluut geen community. Ximian kan dit niet oplossen, omdat ze aan de Ximian Desktop 2.0 deadline vastzat. Sun heeft redenen om ontwikkelaars intern op het project te willen zetten, maar het gevolg is niet anders.
Een wilde gok van Luis is dat ongeveer 80% van de code in de Gnome Desktop eigendom is van mensen die voor een van de grote bedrijven werken (Ximian, RedHat, Sun).

De oplossing
Een gedeeltelijke oplossing is wat momenteel in zowel in KDE (waar het probleem nog veel groter is - het enige bedrijf wat veel geld investeert in KDE is Suse!) als Gnome gebeurt: zet mensen op meerdere projecten. Owen Taylor onderhoudt bijvoorbeeld glib, Gtk+, ATK, Pango en helpt nog mee aan enkele andere projecten. Dit werkt echter alleen voor die paar mensen die in dienst van bedrijven werken; vrijwilligers kiezen zelf!

Een echte oplossing is om meer mensen geinteresseerd te krijgen in opensource development. En dit is moeilijk, want slechts de code spreekt. Je moet toch een redelijke C kennis hebben om aan Gnome mee te werken, en zonder code kun je nauwelijks helpen. Of wel?
Toch wel! Maar slechts aan delen. Je kan release management doen, alhoewel hier toch enige basiscodekennis voor noodzakelijk is. Website maintainance, documentatie, etc.
Het enige alternatief is toch om nieuwe mensen te begeleiden in het coden. Zonder dit komt er teveel druk op de bedrijven te liggen. Stoppen de bedrijven, dan stopt de opensource ontwikkeling grotendeels.

Wat kan ik doen?
HELPEN! D'oh. .

Hoe? Ohja... Nou, pak je favoriete project, schrijf je in op de mailinglist en probeer af en toe te helpen met user problemen. Dat scheelt de ontwikkelaar tijd, zodat deze minder aan support hoeft te doen. Je wilt 't niet weten, maar een gemiddelde ontwikkelaar is soms 50% van z'n tijd kwijt aan e-mail voor support e.d.!
Je kan natuurlijk ook proberen te helpen met website maintainance, documentatie schrijven, alles wat niet direct technisch van aard is.
En, als je kan coden, sluit je aan bij een van de grote desktop projecten, ga door Gnome Bugzilla heen en help mee Gnome nog beter te maken! Vele handen maken licht werk, alle beetjes helpen.

Goed, tot zover mijn community-relaas. .

(Overigens gaat 't helemaal niet superslecht ofzo, kijk naar wat Sun, HP en IBM momenteel in Linux investeren en naar hoeveel invloed Linux in 't bedrijfsleven begint te krijgen - dit heeft echter niks met communities te maken!)

[AlterEgo]

Volgens mij is "geld" of in ieder geval middelen een belangrijk deel van het probleem

Met geld kun je ontwikkelaars belonen en/of ondersteunen.
Wat heel gaaf zou zijn: grote bedrijven die OSS gebruiken en/of IT-bedrijven die (mede) hun geld verdienen met OSS, zouden eigenlijk een fonds moeten opzetten: een percentage van het geld dat ze verdienen door OSS te gebruiken/supporten in een potje storten. Met dit geld kunnen dan ontwikkelaars ondersteund woorden met geld en/of middelen.

Stel je eens voor dat alle bedrijven die OSS gebruiken 1% van hun IT-budget in zo'n fonds zouden storten. Verdeling van gelden zal een discussiepunt zijn, maar het gaat om het idee

Iets minder financieel voorgesteld:een groot bedrijf (of de overheid) adopteert een OSS product, als "dank" voor het gebruik, en als investering in verdere ontwikkeling, door webspace/datalijnen/hardware of pizza's en cola te betalen aan de ontwikkelaars.

[CyBeR]

Helemaal mee eens. Ik denk echter wel dat er een drempel is die mensen weerhoudt mee te doen. Welke dat is weet ik niet precies, maar bang zijn onkundig gevonden te worden is er vast wel een. Of inderdaad, denken dat men alleen kan helpen als men C of C++ kan. Niets is minder waar. Documentatie is erg belangrijk. Bij goed gedocumenteerde projecten is het handig om voor een simpele vraag naar een bepaald gedeelte in de docs te verwijzen -- maar dan moeten die docs wel bestaan! En aangezien documentatie toch het minst favoriete werk is van de programmeur (die code tenslotte liever aan het project zelf), wordt daar meestal niet al te veel naar gekeken.

Users helpen op de mailing lists/irc kanalen/gnome forums kan ook mee helpen de developers te verlichten. Alhoewel in sommige gevallen developers stug door blijven schrijven, zal het in andere gevallen betekenen dat ze alleen hoeven te schrijven als geen van de andere subscribers een antwoord weet. Discussies over features uitgesloten, natuurlijk.

Ook vertalingen zijn hard nodig. Persoonlijk wil ik al m'n software in het engels, maar er zijn zat (te veel ) mensen die liever nederlands hebben. Als je daaraan mee zou willen helpen, meld je bij Valium (AFAIK is hij de coordinator voor de nederlandse vertalingen. Hij weet er in elk geval meer van dan ik.)

[Verwijderd]

Tsja, je laat het er allemaal wel erg donker uit zien.

Ik denk nou juist dat er over enkele jaren een soort van baby boom zal plaats vinden in het communitie wezen.
waar op mijn school eerst maar een handje vol linux mensen rond loopt is nu bijna iedereen er mee bezig.

uiteraard de meeste mensen zetten eerst een server neer en zijn dan al blij genoeg.
maar ik denk dat je zult zien dat het ook juist deze mensen zijn die over een tijd ook eens C gaan leren, eens wat aanpassingen doen aan een programma waar ze net een feature missen die makkelijk te implementeren is.

en zo danig toch de communitie in rollen, de communitie waar ze eerst enkel gebruik van maakte.

ik zie het bij mezelf ook, ik ben ~3 a 4 jaar geleden begonnen en deed voor de rest helemaal niks aan communitie. (behalve dan evangelist uithangen)

maar als ik nu rond me kijk dan zie ik dat ik zelf al bezig ben met dingen.
ook redelijk wat mailing lists bij houd.
maar ook de mensen die ik aan de linux heb geholpen ook al bezig zijn.

die mensen komen wel, daar ben ik echt niet bang voor.

een groter probleem is denk ik iets wat ik zo hier en daar al tussen de regels heb gelezen in je bericht.
"Een wilde gok van Luis is dat ongeveer 80% van de code in de Gnome Desktop eigendom is van mensen die voor een van de grote bedrijven werken (Ximian, RedHat, Sun)."
"OpenOffice.org en Evolution: beiden worden "bijna" intern ontwikkelt door een bedrijf (respectievelijk Sun en Ximian), beiden hebben absoluut geen community. "

nee ik denk niet dat de software ooit eigendom van de bedrijven zal worden.
wat wel een probleem is denk ik, is dat bedrijven ook denken als bedrijven.

een goed voorbeeld is wat ik heb met Evolution.
ummm niet dus, Evolution heeft standaart geloof ik alleen Red Hat en SuSe, met de auto download install wizard (wat een brakke uitvinding IMHO) zal hij vast nog wel een paar distro's supporten.
maar b.v. mijn Slackware ho maar.
en als hij slackware niet support dan denk ik dat je met Mulinux, turbo linux, en alle andere kleinere distro's het niet eens hoeft te proberen.
Er is uiteraard ook gewoon een tar.gz te downloaden. (als je goed zoekt, en veel geluk hebt. (ik heb hem moeten downloaden met 5kb/s -ouch-)


als dit een trend word om enkel een selectief aantal distro's te supporten gaat een groot gedeelte van de keuze die je als linux gebruiker gewoon als vanzelfsprekend neemt weg genomen.

[rollebol]

Reactie op StratoS_V2.0: Je suggereert dat distro's slecht ondersteund worden. Is hier niet een taak weggelegd voor de distrobeheerders zelf?

Daarnaast kan je altijd de source downloaden en het zelf installeren, ik zie niet waarom voor iedere denkbare distro een voorgeconfigureerde binary moet bestaan.

[Verwijderd]

rollebol schreef op 18 June 2003 @ 14:39:
Reactie op StratoS_V2.0: Je suggereert dat distro's slecht ondersteund worden. Is hier niet een taak weggelegd voor de distrobeheerders zelf?

natuurlijk is het niet de taak van de distrobeheerder om software te ondersteunen.
het is taak van bijde om compatable te zijn.

Daarnaast kan je altijd de source downloaden en het zelf installeren, ik zie niet waarom voor iedere denkbare distro een voorgeconfigureerde binary moet bestaan.

uiteraard, maar om even mijn voorbeeld aan te halen.
ga maar eens zoeken naar het tarretje met de source van evolution.
het is te vinden, maar je bent zeker een half uur bezig met zoeken.

mijn punt was dat programma's geschreven door (voornamelijk) bedrijven niet zo zeer op compatabilitie zullen letten maar meer zo snel mogelijk hun wonder product willen lanceren, voordat de "concurrent" zijn wonderproduct weer lanceerd. En vooral in een omgeving als linux waar nieuwe versies soms wel maandelijks uitkomen is er bar weinig tijd voor compatabilitie tests.

[BezurK]

CyBeR schreef op 18 June 2003 @ 14:11:
Helemaal mee eens. Ik denk echter wel dat er een drempel is die mensen weerhoudt mee te doen. Welke dat is weet ik niet precies, maar bang zijn onkundig gevonden te worden is er vast wel een. Of inderdaad, denken dat men alleen kan helpen als men C of C++ kan. Niets is minder waar. Documentatie is erg belangrijk. Bij goed gedocumenteerde projecten is het handig om voor een simpele vraag naar een bepaald gedeelte in de docs te verwijzen -- maar dan moeten die docs wel bestaan! En aangezien documentatie toch het minst favoriete werk is van de programmeur (die code tenslotte liever aan het project zelf), wordt daar meestal niet al te veel naar gekeken.

Users helpen op de mailing lists/irc kanalen/gnome forums kan ook mee helpen de developers te verlichten. Alhoewel in sommige gevallen developers stug door blijven schrijven, zal het in andere gevallen betekenen dat ze alleen hoeven te schrijven als geen van de andere subscribers een antwoord weet. Discussies over features uitgesloten, natuurlijk.

Ook vertalingen zijn hard nodig. Persoonlijk wil ik al m'n software in het engels, maar er zijn zat (te veel ) mensen die liever nederlands hebben. Als je daaraan mee zou willen helpen, meld je bij Valium (AFAIK is hij de coordinator voor de nederlandse vertalingen. Hij weet er in elk geval meer van dan ik.)

Maar ook voor het schrijven van Doc's is nog aardig wat kennis nodig. Hoe men man/info-pages bouwt bijvoorbeeld. Daarnaast is het ook nog handig dat je weet HOE het programma precies werkt en dit is aardig lastig zonder documentatie. En als je al wel weet hoe het programma werkt is de kans groot dat er al Doc's voor zijn

Overigens ben ik het wel met je eens hoor, alle beetjes helpen.
Met die veronderstelling heb ik een klein jaar geleden nederlandse vertaling gemaakt voor de Ogle DVD-speler. Ik gebruikte die speler veel en ik zag dat vertalingen op de TODO lijst stond, dus toen heb ik dat gedaan en voor zover ik weet is het aan het project toegevoegd. Of dit nog steeds zo is weet ik overigens niet, ik gebruik die player haast niet meer

[Verwijderd]

Verwijderd schreef op 18 June 2003 @ 13:39:
En dit is moeilijk, want slechts de code spreekt.

En dat is het probleem.

Veel mensen haten C met een passie (waaronder ik).
Gevolg: motivatie ebt weg -> Resultaat: geen nieuwe code.

Als ik bv naar een project kijk als Anjuta, dan zie ik dat vreselijk langzaam vooruitgaan.
Maar KDevelop lijkt (let op dat woord: 'lijkt!') veel sneller vooruit te gaan en heeft ondertussen ook al veel meer features (en is dus veel beter bruikbaar).

De code van KDevelop ziet er 100x beter uit dan die van Anjuta, dat is natuurlijk alleen maar mijn mening, maar ik weet zeker dat dat er heel veel mee te maken heeft..
Hoe kan je aan iets werken wanneer je het eigenlijk afschuwelijk vind?

Je hebt gelijk: 'slechts de code spreekt'.

[Verwijderd]

Ik zeg niet dat je moet werken aan alle projecten, ik zeg dat je kunt bijdragen aan de community van jouw favoriete software-projecten. Daarom werk ik aan GStreamer en draag ik anderzijds bij aan de Gnome-community. Ik vraag niet aan KDE-lovers om opeens aan de Gnome-community bij te dragen. .

[Zwerver]

helemaal eens met je relaas over het smaller worden van de community's. Maar mijn ervaring is dat met name de code van een groot aantal van mijn gebruikte oss progjes *zowel onder Linux als onder mijn win2k laptop* bijna niet om door te komen is. Bepaalde (herstel een groot aantal) functies zijn zeer slecht gedocumenteerd in de code zelf. En dat is iets wat een beginnende coder zoals ik zeer mis. Als ik bij zou willen dragen aan een project dan wil ik zeker weten dat ik de code die er in zit begrijp, voordat ik ga bug-resolven en/of dingen ga toevoegen.
In mijn geval zou je dan ook nog een stukje documentatie en/of website onderhoud aan kunnen geven, zou ik graag willen doen, maar ik ben nog nooit tegengekomen dat er gereageerd werd op mijn mail als ik een projectpage wilde onderhouden, iets wat ik toch al snel doe als ik vind dat het anders (oke, meestal beter) kan.

Bij documentatie staat toch bovenaan dat je zo'n beetje alle functies van een programma moet kennen, en dat vergt toch weer wat kennis van de code. Zie boven waarom ik me daar vaak niet aan waag. Oftewel, ik wil vaak wel helpen, maar schrik heel duidelijk terug voor de complexiteit van de gemiddelde applicatie.

[AlterEgo]

closed source producenten laten betalen aan open standaarden !

"EGOVOS analyzes the recently passed South African OSS plan and proposes a great way to fund Open Source education and development until companies comply with open standards. Microsoft pays a 10% penalty until their products comply with open standards. That would be billions of dollars to Open Source to compensate for an unlevel playing field until it is leveled. All the policy guidelines for governments are worth reading. This looks like a workable plan from a credible group." Reader johndiii clarifies: "From what I have been able to see, the strategy document is 'proposed,' not 'recently passed,' and is not yet official policy of the South African government."

DAT zou nog eens een injectie betekenen voor de OSS community

[Verwijderd]

Verwijderd schreef op 18 June 2003 @ 18:37:
Ik zeg niet dat je moet werken aan alle projecten, ik zeg dat je kunt bijdragen aan de community van jouw favoriete software-projecten. Daarom werk ik aan GStreamer en draag ik anderzijds bij aan de Gnome-community. Ik vraag niet aan KDE-lovers om opeens aan de Gnome-community bij te dragen. .

Ik ook niet

Ik heb het over Linux-lovers die bijdragen aan (een selectie van) Linux-programma's uit een Linux-community.

[Verwijderd]

IMHO had je het over hoe C zuigt.

[Verwijderd]

Dat ook

[odysseus]

Verwijderd schreef op 18 juni 2003 @ 13:39:
Tekort aan developers

Hier ben ik het niet helemaal mee eens. Er is bij Free Software bijna per definitie een tekort aan ontwikkelaars, want meer is altijd beter - er is altijd wat te doen. Je hebt dus gelijk dat er een tekort is, maar ik zie zelf geen werkelijke afname in vergelijking met 'vroeger'. Als ik even kijk naar het aantal posts naar de kde-cvs mailinglist, dan zie ik dat het aantal dit jaar wat lager ligt dan vorig jaar, maar wel ongeveer op het niveau van 2001. Ik verwacht verderop dit jaar nog wel een stijging, vlak na de bijeenkomst in Nove Hrady en rond de {beta,alpha}releases van KDE 3.2. Van een echte daling kun je dus niet spreken, in ieder geval niet voor KDE lijkt het .

Wel ben ik het met je eens dat het vervelend is dat projecten op één persoon draaien. De KDE-corelibs lijken hier minder last van te hebben dan Gnome, als ik jouw verhaal zo lees, maar de losse KDE-applicaties zijn ook vaak persoonlijke projecten. Hoe meer projecten er komen, hoe meer er ook weer afvallen. Heel zonde, omdat het vaak goede projecten zijn, maar ik vrees dat het gewoon de selectie is zoals die binnen Free Software plaatsvindt. Hoeveel mensen stappen niet van vi over op vim? Wie gebruikt er nog KLyX? Wat zal er met lilo gebeuren nu grub steeds meer opkomt? Wat ik persoonlijk erger vindt: non-maintained software die als basis is gebruikt voor andere software. Het is behoorlijk vervelend als je een mooi programma hebt, maar je onderliggende libraries last krijgen van bit rot.

Tekort aan vrijwilligers

Ook hier weer: een tekort is er altijd. Ik ben het overigens niet eens met de bewering uit deze thread dat het een probleem is dat er nauwelijks bedrijven aan KDE werken. Een grote afhankelijkheid van één of enkele bedrijven is niet goed. SuSE helpt aan KDE, Mandrake ook een beetje, maar het meeste werk wordt toch door losstaande mensen gedaan. Voorlopig lijkt dat geen probleem te zijn en het biedt voordelen: een grote groep aparte mensen is veelzijdiger geïnteresseerd dan een bedrijf en bovendien weet je zeker dat ze niet van de ene op de andere dag failliet gaan of zo. Ook leeft het communitygevoel in zo groep veel sterker, zoals je zelf al zegt.

De oplossing
Een gedeeltelijke oplossing is wat momenteel in zowel in KDE (waar het probleem nog veel groter is - het enige bedrijf wat veel geld investeert in KDE is Suse!) als Gnome gebeurt: zet mensen op meerdere projecten. Owen Taylor onderhoudt bijvoorbeeld glib, Gtk+, ATK, Pango en helpt nog mee aan enkele andere projecten. Dit werkt echter alleen voor die paar mensen die in dienst van bedrijven werken; vrijwilligers kiezen zelf!

Nu stap je over naar de eenzijdige belangstelling van veel mensen. Naar mijn mening wordt dit vaak schromelijk overdreven. Niemand zou het schrijven van documentatie leuk vinden. Ondertussen vind ik complete boekwerken over elk stuk software wat ik gebruik. Elk klein spel in KDE lijkt zijn eigen handboek te hebben met een complete uitleg van de regels en elk knopje uit de interface. KDevelop beschikt over een heus boek dat veel uitlegt. De man- en infopages zijn vaak te technisch, maar documenteren over het algemeen bijna alle functies van een programma. Vertalen zou niet leuk zijn, maar KDE is verkrijgbaar in meer dan vijftig talen. Bugfixen zou niet leuk zijn, maar er zijn hele groepen developers die niet zelf ontwikkelen maar constant Bugzilla afstropen om problemen op te lossen. Het heeft geen enkele zin om te proberen mensen dingen te laten doen die ze niet leuk vinden en ik ben er juist van overtuigd dat het succes van Free Software voortkomt uit juist die vrijheid, dat je kan doen wat je wilt - niemand zegt je iets anders te doen en je hebt geen plicht om vervelende dingen te doen. Uit verantwoordelijkheidsgevoel doen velen het toch, maar het is totaal anders dan een plicht zoals je die bij bedrijfsmatige softwareontwikkeling tegenkomt.

Voor zover ik zie is er dus binnen de meeste projecten geen gebrek aan gemeenschapsgevoel. Wel ben ik het eens met een ander (wat mij betreft losstaand) probleem dat je noemt: mensen zijn te vaak alleen verantwoordelijk voor stukken software die voor veel mensen belangrijk zijn. Een oplossing hiervoor heb ik niet, maar ik ben wel dankbaar dat het hier Free Software betreft, zodat er in ieder geval de mogelijkheid is om er zelf aan verder te gaan als dat nodig is .

[wzzrd]

* wzzrd schrok zich de pleuris toen hij de titel van dit topic las

Sja... Ik spreek weinig tot geen C, dus echt helpen op dat vlak kan ik niet. Maar dat is dan ook de reden dat ik (eens kijken) geabonneerd ben op 6 of 7 mailinglists, op NOS en 2 of 3 andere Linux fora rondhol en zo. Ik ben overigens van plan om aan wat free PHP-projecten te gaan werken straks, maar da's naar mijn gevoel net niet "echt".

* wzzrd haalt zijn beginnersboeken C++ maar weer eens uit de kast

Ow, dat vergeet ik nog: ik ben (onder meer met Free Software in het achterhoofd) een paar maanden geleden lid geworden van GroenLinks. Een van mijn toekomstplannen is om me op politiek vlak eens wat meer met FLOSS bezig te gaan houden.

[ Voor 20% gewijzigd door wzzrd op 19-06-2003 14:27 ]

[Heidistein]

Ik zit op de licq mailinglist, en help daar mensen. Ben de laatste tijd idle geweest, druk met school blabla. Nou wil ik graag de GTK2 plugin afmaken. Het enige probleem is een beetje dat ik geen GTK spreek. Ik zoek dus een boek (een echt, real life boek waarmee je iemand een dreun kan geven) dat GOED en begrijpelijk uitlegt hoe gtk2 werkt.

[wzzrd]

Mooi O'Reilly boekje over Gnome en GTK+ programmeren
Uitgegeven (volgens Amazon) in mei 2003, dus heel recent.
* wzzrd heeft zijn padvindersdaad weer verricht vandaag

[igmar]

Verwijderd schreef op 18 juni 2003 @ 22:12:
Dat ook

Onderbouwing ? Meestal zeggen mensen dit met weinig of geen C kennis.

[Verwijderd]

maar wat zou dan een oplossing zijn?
een extra afdeling binnen de communitie nast het programmeren, documenteren, presenteren?

ook nog opleiden?
dat mensen zich aanmelden voor leren programmeren in linux met C.
en dan via IRC oefeningetjes gaan doen ofzo.
en 1 keer in de maand een bug fixen uit een random open source programma.
als C oefening.

(klinkt niet verkeerd eigenlijk maar lijkt me niet haalbaar.)

offtopic:
[quote]igmar schreef op 19 June 2003 @ 15:11:
[...]

Onderbouwing ? Meestal zeggen mensen dit met weinig of geen C kennis.[/quote]

nee joh, je wilt inet eens dat iemand dat gaat onderbouwen dat leverd lange saaie discussies op over triviale dingen.
ik weet nog wel eens toen onze eigen bealzebub tegen nog iemand over programmeer standaarden tekeer ging.
daar wil je echt niet bij zijn geloof me.

hij heeft een hekel aan C, mooi genoteerd dat weten we, nemen we mee naar de volgende ronde.

(dit alles uiteraard onder het moto dat ik zelf een hekel heb aan Delphi and Java en dat ook totaal niet kan onderbouwen )

[kvaruni]

nja,
kijk, ik steun de open-source community enorm, maak mijn eigen werrk in open-source, gebruik enkel open-source.... maar ik vrees dat je mijn grootste probleem aangehaald hebt om mee te werken aan gnome: Je moet verdomd goed overweg kunnen met C... En zoals je kan zien is dit wel het hoofdprobleem.

Blijft bij mij te vraag hangen of het misschien niet zoveel beter zou zijn dat mensen eens ipv te werken aan glib of whatever eens zouden denken aan een C++ cursus. Toon hoe het moet, hoe onze code beter kan.... (jaja, ik lig met boek van C++ basis, maar basis en een GUI in elkaar knutselen..... nuja, je begrijpt wel )

Gewoon maar een idee natuurlijk, maar neem dit probleem toch wat meer aan vanaf de wortel.

[Verwijderd]

het is er al wel hoor.
gnome2 is gebaseerd op GTK 2.0 en GDK 2.0
van GTK2.0 is er al een erg uitgebrijde tuturial op de gtk.org

gdk dan niet (voor zover ik weet) maar ze gaan in de gtk2.0 tut ook in op gdk in korte gedeeltes.

over hoe ingewikkeld gnome is geschreven weet ik niet (source nooit gezien)
maar ik denk dat het eigenlijk nog wel mee valt, ik dacht eerst ook dat een programma als xmms er heel moeilijk uit zou zien. maar dat valt echt hardstikke mee.

en gui programmeren is gewoon regeltjes volgen die stap voor stap uitgelegd worden in de GTK2.0 tut.
[hierzo]

[ Voor 5% gewijzigd door Verwijderd op 19-06-2003 15:38 ]

[Heidistein]

wzzrd schreef op 19 June 2003 @ 14:47:
Mooi O'Reilly boekje over Gnome en GTK+ programmeren
Uitgegeven (volgens Amazon) in mei 2003, dus heel recent.
* wzzrd heeft zijn padvindersdaad weer verricht vandaag

Kan er alleen geen revieuws over gevonden.
Wel heb ik vernomen dat de tutorial toch wel aardig goed is. Alleen kan ik ABSOLUUT niet vanaf een beeldscherm zoveel lezen, en tis vakantie, dus kan ik niet op school 'ff' manual printen

Ik heb iig meer boeken gevonden, met revieuws, deze heeft me toch aangezet tot... dus...

[BezurK]

Heidistein schreef op 19 juni 2003 @ 16:27:
[...]


Kan er alleen geen revieuws over gevonden.
Wel heb ik vernomen dat de tutorial toch wel aardig goed is. Alleen kan ik ABSOLUUT niet vanaf een beeldscherm zoveel lezen, en tis vakantie, dus kan ik niet op school 'ff' manual printen

Ik heb iig meer boeken gevonden, met revieuws, deze heeft me toch aangezet tot... dus...

Ik heb toevallig een klein half jaar geleden voor 5.99 euro een boek over GTK+ gekocht bij De Slegte. Het boek heet "Applicaties ontwikkelen in Linux" en is geschreven door Eric Harlow en gepubliceerd/uitgegeven door Addison-Wesley. Ik moet toegeven, het is niet het meest fantastische boek qua inhoud (het is vrij chaotisch) maar het is absoluut dat kleine beetje geld waard! (het is zelfs een hardcover, kun je nagaan!)
Het boek telt overigens ruim 400 pagina's en gaat erg diep op de materie in

Just a side-note

[CyBeR]

kvaruni schreef op 19 juni 2003 @ 15:28:
nja,
kijk, ik steun de open-source community enorm, maak mijn eigen werrk in open-source, gebruik enkel open-source.... maar ik vrees dat je mijn grootste probleem aangehaald hebt om mee te werken aan gnome: Je moet verdomd goed overweg kunnen met C... En zoals je kan zien is dit wel het hoofdprobleem.

nogmaals, je hoeft niet per se met code te helpen. Er zijn heel veel andere dingen waar we ook nog mensen voor nodig hebben.
Tigert, Jimmac, en ik geloof drc doen ontzettend hun best icons en andere graphics uit te toveren, maar zover ik weet zijn dit de enige echte pixelpushers die we hebben. Als je creatief bent, met The GIMP overweg kan, en een beetje ok kan tekenen kunnen we in dat vlak ook hulp gebruiken.
Helpen op de mailinglists/irc is ook ok: er komen veel mensen op IRC langs (ik geef toe dat ik alleen op de GIMP mailing list zit) die soms vrij simpele vragen stellen. Echter is er niet altijd iemand die die vraag ziet, en kan beantwoorden.

Blijft bij mij te vraag hangen of het misschien niet zoveel beter zou zijn dat mensen eens ipv te werken aan glib of whatever eens zouden denken aan een C++ cursus. Toon hoe het moet, hoe onze code beter kan.... (jaja, ik lig met boek van C++ basis, maar basis en een GUI in elkaar knutselen..... nuja, je begrijpt wel )

Gewoon maar een idee natuurlijk, maar neem dit probleem toch wat meer aan vanaf de wortel.

GNOME (daar hebben we het nu even over geloof ik ) is geschreven in C, en met uitzondering van de C++ interfaces blijft dat ook zo. Wij houden van C. Geven in de meeste gevallen niets om C++. Weten dat C++ niet per definitie beter is dan C omdat er ++ achter staat en het nieuwer is

Toegegeven dat een boel code wat netter kan. In sommige projecten (met name die in anjuta of andere gui apps geschreven is geloof ik) zitten veel regels die ruim langer zijn dan 80 chars. Dit is kort gezegd kut voor de leesbaarheid van de code voor mensen die netjes in een terminal met vim werken. Grotere projecten (GIMP bijvoorbeeld) hebben ook een coding style, en rejecten patches die daar niet aan voldoen. Dat helpt, maar is niet alles. Vooral kleinere projecten waar maar een of soms twee personen aan werken hebben het probleem dat er wel eens twee coding styles door elkaar gebruikt worden (wordt vaak overigens in een later stadium wel gefixed).

Nu wijk ik erg af van wat ik in de eerste instantie wilde zeggen, maar ok

Punt is: helpen kan, en daar hoef je echt niet voor te kunnen programmeren (al is het wel meegenomen).

Om emt docs te helpen hoef je overigens ook niet altijd te kunnen coden. Je kunt ook de huidige documentatie proofreaden (typo's, slechte zinnen, enz.), of vertalen waar nodig. De meeste documentatie voor GNOME apps is in DocBook XML geschreven geloof ik, dus kennis van manpages is niet nodig.

Zucht. Als ik zoiets als dit schrijf wordt het meestal meer een soort rant

[Verwijderd]

Ik help via http://gnome-nl.sourceforge.net/ help ik mee aan het vertalen van GNOME. Een andere goede manier om te helpen is om bugs te reporten.
Ik gebruik GNOME onder Linux en Solaris. En onder Solaris is GNOME pas op versie 2.0 Onder Linux gebruik ik 2.2.₀

[ Voor 1% gewijzigd door Verwijderd op 19-06-2003 21:25 . Reden: ik zei toch .NET ]

[wzzrd]

* wzzrd rapporteert zich helemaal gek aan b00gs
Maar alleen als 'zaroo boogs found' natuurlijk
Misschien ga ik ook maar eens wat vertalen. Wellicht wel leuk.
Hoe kom ik daarbij?

[Verwijderd]

wzzrd schreef op 19 juni 2003 @ 20:51:

Misschien ga ik ook maar eens wat vertalen. Wellicht wel leuk.
Hoe kom ik daarbij?

Ik vertaal GKrellM. Ik ben begonnen door een mailtje te sturen naar de maintainer van GKrellM om te vragen of er al een nl vertaling was, die was er niet en toen ben ik het maar gaan doen.
Veel programma's hebben een "po" dir met vertalingen. Kijk daar is in. Als je geluk hebt staat er ook nog een readme. (btw. die po's worden door gnu gettext gemaakt)
En voor gnome-nl kan je gewoon een mailtje naar Valium sturen...(mail addr. staat op de site)

btw. zo ziet een .po er uit

[ Voor 9% gewijzigd door Verwijderd op 19-06-2003 21:22 ]

[Verwijderd]

Aangezien ik werkeloos ben (en dat voorlopig vrees te blijven) wil ik graag iets nuttigs te doen hebben. Ik loop al een hele tijd te denken om te helpen met coden in een open broncode project. Omdat ik pas na een kleine week KDE weer mijn geloof in---en overtuiging van superieuriteit van---Gnome heb hernieuwd, ligt het voor de hand om mee te helpen met mijn favoriete bureaubladomgeving. Ik denk dat ik maar eens zal beginnen met het installeren van Gnome 2.3. Daarna ga ik eens kijken hoe ik precies kan helpen. Hopelijk kan ik mijn gebrekkige C/C++ ervaring gecompenseerd met code-lust op een nuttige manier inzetten voor de mensheid.

[TheGhostInc]

De dood van de community?

Mijn reden is:
JAVA
eventueel aangevuld met wat PHP/ASP en scripting.

Doordat mensen amper meer C nodig hebben (op school leer je als HIO tegenwoordig JAVA), en steeds minder C++ is de belangstelling hiervoor minder.
Daarnaast is PHP/ASP al redelijk krachtig, waardoor veel mensen hier tijd in stoppen.

Ben zelf een redelijk ervaren C/C++ progger (druk bezig met elektro) en kan wel zeggen dat ik blij met mijn C kennis ben. (Hoewel ik ook de JAVA van de Hio heb gevolgd)

Maar dat terzijde, mijn reden om niet mee te doen aan een community is dat ik daar persoonlijk geen energie voor over heb. Hoewel ik wel zeker mijn steentje zou kunnen bijdragen aan wat projecten.

Je moet wel een drive hebben om iets te doen, bij mij is die drive verstoord door persoonlijke zaken, maar wat is de reden dat iemand aan Gnome zou *WILLEN* werken?

(Nu wil ik geen domme antwoorden, maar blijkbaar vinden veel mensen geen goede reden om het te doen, anders zouden meer mensen eraan werken... imo)

[ Voor 2% gewijzigd door TheGhostInc op 20-06-2003 03:28 . Reden: tis laat ]

[wzzrd]

Misschien is het ook wel logisch dat bedrijven als Sun en IBM een groot deel van de Linux ontwikkeling doen. Dat is nl. de enige manier voor hen om ergens nog een tegenwicht te bieden aan de moloch Microsoft. En er hoeft niet eens een speciale ingewikkelde onvereenkomst voor gesloten te worden: de GPL is uw vriend

United we stand, devided we fall, denk ik.

[BezurK]

TheGhostInc schreef op 20 June 2003 @ 03:26:

[..]

Je moet wel een drive hebben om iets te doen, bij mij is die drive verstoord door persoonlijke zaken, maar wat is de reden dat iemand aan Gnome zou *WILLEN* werken?

(Nu wil ik geen domme antwoorden, maar blijkbaar vinden veel mensen geen goede reden om het te doen, anders zouden meer mensen eraan werken... imo)

Nou,
• Weten dat je iets gebruikt waar ook jij aan mee geholpen hebt
• Zien en weten dat anderen iets gebruiken waar jij aan mee geholpen hebt
• Functies erin zien die jij er graag in wilde
• Erkenning
• Fun

[Verwijderd]

Wat ik ook heel vaak erg jammer vindt, als er een community is overleden en niet onder sourceforge wordt gehost.
Dat de source en de informatie in enkele gevallen helemaal verdwijnt van het internet doordat het vaak door niemand wordt onderhouden.
Dit ben ik vaak tegengekomen bij projecten om linux op een pda te porten. Daatmoet moest ik dingen zelf uitzoeken wat al uitgebreid is gedaan door andere ontwikkelaars en zelf stukke software schijven.

Dit is erg jammer dat er gewoon belangrijk informatie en stukke source gewoon verloren gaat

[ Voor 3% gewijzigd door Verwijderd op 20-06-2003 12:20 ]

[Heidistein]

BezurK schreef op 20 juni 2003 @ 10:44:
[...]

Nou,
• Weten dat je iets gebruikt waar ook jij aan mee geholpen hebt
• Zien en weten dat anderen iets gebruiken waar jij aan mee geholpen hebt
• Functies erin zien die jij er graag in wilde
• Erkenning
• Fun

• Iets voor op je CV
• Je helpt de economie: Koffie eet je rouw uit hep pak etc...

[bkor]

BezurK schreef over waarom je zou willen helpen aan Gnome:
Nou,
• Weten dat je iets gebruikt waar ook jij aan mee geholpen hebt
• Zien en weten dat anderen iets gebruiken waar jij aan mee geholpen hebt
• Functies erin zien die jij er graag in wilde
• Erkenning
• Fun

Bij mij:
• Iets terugdoen voor alles wat ik heb gekregen

De punten uit de quote ben ik het mee eens, maar dat zijn voor mij meer bijzaken.

Dat het met Gnome minder gaat, misschien wordt het tijd om actiever naar developers te zoeken. Zelf ben ik errug tevreden met Gnome 2.3.x. Er zijn een paar kleine irritaties, maar over het algemeen vind ik het fijn werken. Pas nudat ik dit topic zie, begrijp ik dat de nood voor nieuwe ontwikkelaars blijkbaar errug hoog is.
Het lieftst wil ik meeprogrammeren aan een programma. Jammergenoeg kan ik niet goed in C programmeren (C en alles eromheen) en het leren gaat ook langzaam. Vroeger heb ik meegeholpen bij andere projecten, vooral het triagen van Mozilla's Bugzilla, maar dat begint na een tijdje ook te vervelen.
Tot de tijd dat ik echt kan programmeren, probeer ik te helpen waar ik het kan. Bug rapporteren, uitzoeken van bugs waar ik zelf last van heb, helpen van Mandrake, etc.

Zodra ik goed zou kunnen programmeren en goed kan meehelpen, zou ik dat het liefst fulltime willen doen (denk niet dat ik ooit goed genoeg zal zijn, maarjah). Ik denk dat dit niet te vermijden is. Een kleine patch schrijven kan je altijd doen, maar het meehelpen aan gtk+/glib/atk/pango... het lijkt mij dat je dit niet een paar uurtjes in de week doet. Zo blijven de belangrijke ontwikkelaars bij de bedrijven zitten. Dit zie ik niet als een probleem, er moeten alleen meer verschillende bedrijven komen (!distributies) die meehelpen aan de ontwikkeling; zie mijn reden om mee te helpen.
[dreammode] Voorbeeld: In Duitsland gaan 14.000 in de overheid over op Linux. Dit zorgt voor leuke inkomsten bij Suse; zij kunnen meer ontwikkelaars inhuren voor kernel/KDE/etc. Leuk, maar ik hoop dat er ook een aantal mensen vanuit de overheid betaald worden om mee te helpen. Hierbij moeten ze helpen waar het betreffende bedrijf/overheid zelf mee te maken krijgen / ervaring mee hebben.
Wat de overheid uit mijn voorbeeld kan doen: usability (14.000 mensen die overstappen, errug veel informatie wat beter kan), verbeteren/ uitbreiden van de programma's die voor dat gedeelte van de overheid belangrijk zijn, maken van FOSS programma welke belangrijke functies vervullen (voor de overheid uit m'n voorbeeld), etc. [/dreammode]

[Verwijderd]

Laat ik ook eens een tegengeluid laten horen. .

http://advogato.org/person/thomasvs/diary.html?start=82

Geschreven door Thomas, en door Luis opgelezen als afsluiting van GU4DEC eergisteren. Gister nog met een stel Gnome-mensen Dublin bekeken, en dan snap je waarom sommige mensen lid van de community willen zijn.

Eerst even als reply op odysseus, jij zegt dat je dat tekort niet ziet, en dat je geen afname ziet. Ik zie ook geen afname. Maar met de toename van de complexiteit van Gnome en KDE (tel het aantal coderegels in KDE-1.0 en KDE-3.1 of Gnome-1.0 en Gnome-2.2 eens), zie ik geen gelijkwaardige toename in aantal programmeurs. En dat is zorgelijk, want elke coder wordt dus verantwoordelijk voor meer code. Daarnaast zeg je dat KDE geen tekort aan maintainers heeft, maar bedenk dat KDE enorm veel code per package in weinig packages heeft, waar Gnome juist weinig code per package maar veel packages heeft. KDE zou dus per package eigenlijk enkele maintainers, liefst per subdeel, moeten hebben. Net zoals GStreamer (voor Gnome-termen een gigantisch project) meerdere maintainers en verantwoordelijk heeft voor delen van de code - alleen kunnen we dat absoluut niet aan, veelsteveel werk.

Ik las ook ergens commentaar (van iemand anders) dat de code slecht gedocumenteerd is, maar bedenk dat dat ook een bug is. Het eerste wat ik doe bij code is het aantal comments vertienvoudigen (naar mijn persoonlijke mening bevat mijn code vrij veel commentaar en heeft de gemiddelde C file veel te weinig commentaar). Oftewel, als je een klein stukje code interessant vindt, dan kun je daar mee beginnen, voordat je je in de functionaliteit stort. Voor grotere projecten, zoals Nautilus, waarbij de structuur niet meteen duidelijk is, is vaak al globale documentatie aanwezig (bv. de GU4DEC paper van dit jaar over Nautilus).

Wat ik wel heb aangegeven aan Luis, is dat teveel projecten een matige tot nietbestaande roadmap en TODO list er op nahouden. Bugzilla wordt vaak gebruikt als TODO list (imo zou dit, waarschijnlijk via een bugzilla connectivity script, ook op de website moeten staan). Roadmaps (lange-termijn plannen) zijn bijna altijd afwezig. Maargoed, hoe dan ook, bugzilla is momenteel "de place to start", en dat vind ik eigenlijk al niet kunnen... Te beperkend, nieuwe developers lopen binnen via de website.

Hoe dan ook, het tekort aan developers is irritant, maar overkomelijk. Het tekort aan community (user-side!) is zorgelijker...

Ohja, laatste ding, na andere discussie met (again. ) Luis: andere mensen laten weten dat dit bestaat (via bv. het updaten van de desktop reviews hier @ GoT en die op de t.net frontpage gooien. ) is ook community werk, zelfs vragen beantwoorden op GoT is dat... . Gezien de drukte op GoT had het dus slechter kunnen gaan. . Maargoed, meer richting development toe mag het best wel eens groeien. .

[Verwijderd]

Ach ja, goed nieuws is geen nieuws, en als er iets slechts vermeld wordt begint iedereen zich zorgen te maken en mee te denken. misschien zijn er enkele projecten van de duizenden die door een enkel persoon voorgetrokken wordt (iets van 1%) vaak zijn die personen nadat ze opgehouden zijn nog wel aanspreekbaar. en dat sommige projecten bijna volledig door 1 bedrijf onder handen genomen wordt hoeft niet te betekenen dat er iets mis kan gaan. ik gebruik al 4 jaar de xosl bootloader http://www.xosl.org daar is grub niks bij. op de website staat dat de laatste versie van december 2000 is hij is dus letterlijk dood. als je naar de sourceforge page kijkt zie je dat er nog genoeg punten zijn die verbeterd kunnen worden. de mailinglist wordt nog evenveel gebruikt als 4 jaar terug, maar voornamelijk voor partitieproblemen, niet voor development.

[Valium]

Het gebrek aan interesse om te helpen in de community is denkik ook omdat die community-gedachte bewust is afgezwakt in de gnome 2 tijd. Gnome 1.4 was rommelig en "gezellig". Gnome 2 was veel strakker gecoordineerd en dat werd ervaren als afstandelijk en gesloten. Dat gnome wel degelijk een probleem heeft kun je o.a. merken aan de website die al ruim een jaar geleden vernieuwd had moeten worden en nu nog steeds niet klaar is. De oude is ook al niet al te best is.

Wel zijn een hoop mensen bereid om te helpen zodra je het probleem onder de aandacht brengt. Ik denk nu aan de hulp die gnome 2 kreeg via ditzelfde forum toen gnome2 bijna uit kwam en er dringend een vertaling nodig was. >KLIK<
Zie de sprong in de gele vertaling:

Het is een probleem van groeien van een project. De bekendheid om te helpen moet ook groeien (vandaar ook mijn signature hier en in m'n e-mail). Ik gok dat dat ook een reden was om deze discussie te beginnen?

Als mensen willen helpen met vertalen nodig ik ze iig uit om een kijkje te nemen op gnome-nl.sf.net. Ook is nu het moment aangebroken om de 2.3 (unstable) serie van gnome te testen en bugs te submitten. Er is dus genoeg te doen voor non-C-programmeurs.

[Verwijderd]

Bekendheid is inderdaad iets belangrijks. Wat jouw oude topic voor mij aangaf, was dat veel mensen wel willen helpen, maar niet weten hoezeer wij naar ze op zoek zijn. . Of ze weten niet waar te beginnen, whatever, maar uiteindelijk wil ik wel ernaartoe dat er nieuwe mensen komen helpen. Ik ben niet bang dat Gnome doodbloedt, ik ben wel bang dat we ernstige vertraging in bepaalde modules gaan oplopen als gevolg van het gebrek aan mensen (en dn met name programmeurs, maar ook op andere vlakken).

offtopic:
Overigens heb ik je in Dublin niet zien aankomen, jammer, ik had je daar wel verwacht. .

[Valium]

offtopic:
Mja, ik had er ook willen zijn. Zo'n grote bijeenkomst van GNOME. Maarja...

Ik kan het je nog sterker vertellen, ik zat op dat moment in Galway (andere kant Ierland), maar kon me niet losrukken van m'n verantwoordelijkheden daar. Volgend jaar beter?

edit:
Of nog beter...de eerstvolgende NOS-bijeenkomst. :-)

Zijn er nog concrete plannen uit de discussie op GU4DEC gekomen?Wordt er binnenkort weer over gesproken? Je zou bijvoorbeeld kunnen denken aan zoiets als wat sourceforge doet. Allemaal mensen die hun kennis aangeven en dan een soort van open source vraag-en-aanbod prikbord voor programmeurs.

[ Voor 7% gewijzigd door Valium op 21-06-2003 19:36 . Reden: NOS-bijeenkomst ]

[Verwijderd]

Luis had wel zo'n idee, ik geloof dat hij een soort roadmap+TODO list op gnome.org wilde plaatsen. De TODO list wordt dan per module dynamisch uit Bugzilla gehaald, is vrij makkelijk (pak alle open bug reports met query=ENHANCEMENT). De roadmap moet elke module apart aangeven, of als gnome algeheel. Verdere discussie zal wel op desktop-devel of gnome-love gaan... Ik volg alleen de eerste v/d twee.

En ik weet dat je in Ierland zat, ik heb Reinout en Timo gesproken. .

[Verwijderd]

ik ben van plan deze zomer C te leren (heb boek besteld van Kenningham en ritchie ofzo uit 1988) hehe, ns kijken of t een beetje lukt, en als mijn skillz beetje goed zijn ga ik zeker ook wel bijdragen aan de ontwikkeling van een aantal opensource projecten

[Verwijderd]

offtopic:
wat betekend die [disc] tag eigenlijk???

[Harm]

Verwijderd schreef op 21 June 2003 @ 23:50:

offtopic:
wat betekend die [disc] tag eigenlijk???

offtopic:
Disc == discussie

[BezurK]

bkor schreef op 20 June 2003 @ 14:38:
[...]

Even om het recht te zetten, ik had het over Open-Source projecten in het algemeen, en niet specifiek over GNOME
Overigens ben ik het _volledig_ met je eens over het "terug geven"-punt. Voor niets gaat de zon op zullen we maar zeggen. Zonder mensen zoals ons (en dan bedoel ik dus de mensen die ook daadwerkelijk iets terug geven) had het hele wereldje van OSS niet bestaan.

Valium schreef op 21 June 2003 @ 19:35:
Zijn er nog concrete plannen uit de discussie op GU4DEC gekomen?Wordt er binnenkort weer over gesproken? Je zou bijvoorbeeld kunnen denken aan zoiets als wat sourceforge doet. Allemaal mensen die hun kennis aangeven en dan een soort van open source vraag-en-aanbod prikbord voor programmeurs.

Kijk eens op Savannah, bedoel je zoiets?

offtopic:
Trouwens, wanneer is de volgende NOS-meeting? Ik vind dat ik er zo onderhand ook maar eens bij moet zijn, heb 2 meetings aan mijn neus voorbij zien gaan

[Verwijderd]

Een TODO list per module kun je samenstellen via deze bugzilla query (Gnome): http://bugzilla.gnome.org...last+time&form_name=query (deze is voor GStreamer, vervang GStreamer door iets anders om een ander product te zien).

Maak hier een mooi shell scriptje van en je hebt een TODO list voor product $1 (commandline optie), bijvoorbeeld:

code:

#!/bin/sh
 
# some variables
PRODUCT=$1
PAGE="http://bugzilla.gnome.org/buglist.cgi?product=$PRODUCT&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=enhancement&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=&short_desc_type=substring&long_desc=&long_desc_type=substring&bug_file_loc=&bug_file_loc_type=substring&status_whiteboard=&status_whiteboard_type=substring&keywords=&keywords_type=anywords&op_sys_details=&op_sys_details_type=substring&version_details=&version_details_type=substring&cmdtype=doit&newqueryname=&order=Reuse+same+sort+as+last+time&form_name=query"
TEMPFILE=$(mktemp /tmp/$0.XXXXXX)
 
# start download
wget -O $TEMPFILE "$PAGE"
 
# write HTML
HTML=$(mktemp /tmp/$0.XXXXXX)
grep show_bug.cgi $TEMPFILE > $HTML
NUMBUGS=$(cat $HTML | wc -l)
CURRENT=0
while [ $CURRENT -lt $NUMBUGS ]; do
        # we start by incrementing counter
        CURRENT=$(($CURRENT+1))
 
        # grab line
        LINE=$(head -n $CURRENT $HTML | tail -n 1)
 
        # format output to bug description + link to bugzilla
        BUGNUM=$(echo $LINE | cut -d">" -f4 | cut -d"<" -f1)
        DESCR=$(echo $LINE | cut -d">" -f21)
        echo "[url=http://bugzilla.gnome.org/show_bug.cgi?id=$BUGNUM]$DESCR[/url]"
        done
 
# clean up
rm -f $TEMPFILE $HTML

(ja kut, ik krijg die code niet goed in de layout... ).

Dan krijg je:

videocrop interface proposal
FEATUREREQUEST: encoding support for AIFF
repeat field for GstBuffer
GStreamer application development manual encourages incorrec
plugin/app metadata handling
[ENHANCEMENT] - Support Nullsoft Video
MPEG encoder doesn't support ID3 tags
gst-inspect should integrate better with the command line
FEATUREREQUEST: Would be great to have support for (nvidia)
mpegdemux doesn't support linear PCM streams
Feature Request: subtitles
support incremental gst-register/compprep updates
missing plugins should be automatically downloaded/installed
FEATUREREQUEST: TRM ID support
gnomevfssrc seekable property

. Dat zouden alle projecten moeten doen. .

[ Voor 6% gewijzigd door Verwijderd op 22-06-2003 10:39 ]

[bkor]

Beelzebubu: Als je de overbodige zooi van die URL weglaat, dan wordt ut al iets korter. In combinatie met \ en wat kleine opschoningen:

code:

#!/bin/sh
 
# some variables
PRODUCT=$1
PAGE="http://bugzilla.gnome.org/buglist.cgi?product=$PRODUCT"\
"&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&"\
"bug_status=REOPENED&bug_severity=enhancement"
 
wget -q --header="Cookie: COLUMNLIST=summaryfull" -O- "$PAGE" |\
grep 'show_bug.cgi?id=' | \
while read LINE; do
    # format output to bug description + link to bugzilla
    NR=$(echo $LINE | cut -d">" -f4 | cut -d"<" -f1)
    DESCR=$(echo $LINE | cut -d">" -f6)
    echo "[url=http://bugzilla.gnome.org/show_bug.cgi?id=$NR]$DESCR[/url]"
done

Past nu makkelijk binnen de layout


en over de community: * bkor heeft sinds kort ook op http://bugzilla.gnome.org/ en http://qa.mandrakesoft.com/ canconfirm en editbugs rechten. Bij Gnome heb ik de gnome-terminal bugs bekeken, maar het was best schoon (weinig te triagen). Mandrake is een zooitje; 'multiple submissions' zonder dat ze ooit als 'duplicate' zijn gemarkeerd, bugs die zijn opgelost zonder een 'fixed', bugmeldingen die totaal fout zijn (invalid), etc. Is nu eindelijk iets schoner.

[ Voor 19% gewijzigd door bkor op 26-06-2003 03:45 . Reden: past dus ook na de preview ]

[Apache]

Hmm, ik ben nu net afgestudeerd en zelf developer, het grootste probleem dat ik heb om mee te gaan werken is dat ik maar weinig van *nix development afweet, ik ken de grote lijnen en heb mede dankzij de hulp van Beelzebubu een heuse mini C++ server kunnen compileren met Automake en Autoconf en al die dingen waarvan de haren in m'n nek nu overeind gaan staan

K'heb ook nog nooit CVS gebruikt, dit terwijl ik gisteren nog 2 uur gespendeerd heb om CVS hier draaiende te krijgen => resultaat hoge bloeddruk en irritatie, maar goed, vanavond nog een keer proberen.

Ik heb C gehad op school, Java, e.d. daarom denk ik ook niet dat m'n programmeer ervaring een probleem zal stellen maar alles wat errond hangt. K'ga zeker volgende week, of zodra m'n dagelijkse leven weer een beetje genormaliseerd is kijken naar wat ik kan doen.

T'is trouwens niet dat er geen documentatie voor bvb die CVS beschikbaar is maar het feit dat niet alles meteen doet wat het zou moeten doen, gisteren met het creeëren van m'n eerste module al oneindige recursie veroorzaakt

[Bananenplant]

hmm, jammer dat ik rsi heb...

ik heb aldoor sterk het gevoel dat ik 'te dom' ben iets bij te kunnen dragen. en ik geloof ook dat ik C niet zo'n fijne taal vind... ik heb nu 2 jaar informatica gestudeerd en ik snap nog steeds niet echt hoe ik er iets fatsoenlijks mee zou kunnen maken.

maar kan iemand een beeld geven van de hierarchie in het gemiddelde open source-project? zoiets als "ik heb een lapje code nodig dat aan deze specs voldoet, test het op die en die manier" zou ik nog wel kunnen doen als ik even m'n best doe om wat beter C te leren... in datastructuren en algoritmen denken kan ik ook wel redelijk, maar de brug naar C-code is vanaf daar toch wel veel lastiger dan de brug naar Java of Haskell voor mijn gevoel.

ik heb trouwens die vertalingsfile bekeken, en ik heb het idee dat er nogal wat taalfouten uit verwijderd kunnen worden. veel "engelse ziekte" enzo... persoonlijk vind ik dat een professionele uitstraling niet ten goede komen ! misschien kan ik me zo nuttig maken...?

[Verwijderd]

StratoS_V2.0 schreef op 18 June 2003 @
ga maar eens zoeken naar het tarretje met de source van evolution.
het is te vinden, maar je bent zeker een half uur bezig met zoeken.

offtopic:
Misschien een goede tip: Evolution is bij Debian te halen, en daar kan je ook de originele tar vinden. Omdat Debian bijzonder veel software bevat kan je daar dus bijna altijd de originele software vinden. (En snel, want veel mirrors!)

[Verwijderd]

ucchan schreef op 26 juni 2003 @ 14:13:
ik heb aldoor sterk het gevoel dat ik 'te dom' ben iets bij te kunnen dragen. en ik geloof ook dat ik C niet zo'n fijne taal vind... ik heb nu 2 jaar informatica gestudeerd en ik snap nog steeds niet echt hoe ik er iets fatsoenlijks mee zou kunnen maken.

Informatica is de studie/theorie. Voor coden moet je de praktijk doen - coden dus. .

maar kan iemand een beeld geven van de hierarchie in het gemiddelde open source-project? zoiets als "ik heb een lapje code nodig dat aan deze specs voldoet, test het op die en die manier" zou ik nog wel kunnen doen als ik even m'n best doe om wat beter C te leren... in datastructuren en algoritmen denken kan ik ook wel redelijk, maar de brug naar C-code is vanaf daar toch wel veel lastiger dan de brug naar Java of Haskell voor mijn gevoel.

Ook dit is een vorm van ervaring: gewoon doen, dan leer je 't het beste.

C is exact 't zelfde als Java. Haskell zuigt. . /me heeft (vrijwillig) een aantal lessen haskell gevolgd en walgt er nu nog van. .

[Verwijderd]

ben het enorm eens met Beelzebubu,
volg al 4 jaar nu een IT school heb 1 jaar Java gehad en 2 jaar Delphi.
en ben nu een week met C++ bezig en ik kom al dingen tegen die ik op school nog nooit heb hoeven gebruiken. library's andere mensen hun API's de zooi linken, etc..

op school leerde ik dan iig enkel panelen slepen en knoppen slepen en aventoe een paar regeltjes code om ze aan elkaar te knopen. dan op F9 rossen en kijken wat het doet.
je leerde ook niet echt een taal maar meer de SDK interface die school had gekocht.

naja ik zit dan ook op een MBO, dus het verschil is meschien dat ze op hogere scholen wel wat serieus doen met programmeren.

[Verwijderd]

Ik denk dat je als beginnende developer (of geintereseerde) vaak tegen de muur oploopt omdat je eerst (heel) veel code moet doorlezen om uberhaupt iets te kunnen bijdragen aan het project qua code. Ondertussen zijn de mensen die er al aan werken al weer verder en moet je dus nog meer bijlezen en ik kan me voorstellen dat dat een reactie "heeft toch geen zin" of "te veel werk" als gevolg heeft.

[Verwijderd]

Maar logik, als je het zo bekijkt dan is elke vorm van samenwerking in welk verband dan ook altijd per definitie hopeloos...

[Verwijderd]

Eigelijk vind ik het behoorlijk logisch dat een opensource gebruiker iets terug doet voor de community. In het begin niet, dan is het meer nemen. Maar later leer je unieke dingen die niet iedereen weet en daarbij kun je anderen dan helpen. Op welke manier dat verschilt. Er zijn zo gruwelijk veel manieren om iets toe te voegen. Ik vind echter niet dat je de manier waarop mag opdringen. Ik denk dat dat bij de meesten uiteindelijk vanzelf komt. Je krijgt namelijk zoveel van de community ik kan me haast niet voorstellen dat je dan alleen nog maar kunt nemen.

Vertalen, databases met software-info up2date houden, (back)porten, software testen, howto's schrijven, coden, reviews schrijven, geld investeren/storten, (newbies) helpen met problemen, je eigen closed source software opensource releasen, mensen aansporen tot opensource software releasen, reclame maken/spread the word, laten zien welke opensource producten je gebruikt op bijv. homepage, (creatieve) resultaten laten zien die gemaakt zijn met opensource producten (coding maar ook WWW, Audio, Video e.a. grafische meuk), en dat alles afhankelijk van waar je interesses en kwaliteiten liggen. Vaak kun je echt wel het mooie met het aangename combineren.

Dus om nou te zeggen dat iedereen dit leest zich moet aanmelden op de mailinglist van een project. Beetje kortizichtig, er zijn natuurlijk veel meer manieren. Ik bijv. vind mail werkelijk zwaar klote om iemand te helpen. Geef mij maar IRC, veel interactiever, directer en leuker. En die keus heb ik gelukkig.

Toch is voor mij opensource software meer een middel dan een doel. Een middel om andere vrijheden op een vrije manier aan te bieden, zeg maar...