Hi Ludo, Thank for your notes on the FOSDEM talks. Would be great to have the slides presented and also I'm gonna link the presentations' pages because I guess they will show the recordings when the videos are gonna be made available: Coping with the proliferation of tools within your community https://fosdem.org/2013/schedule/event/coping_with_the_proliferation/ Combining Open Source ethics with private interests https://fosdem.org/2013/schedule/event/combining_open_source_ethics/
Our strength is our extensibility and making it more easy to create, collaborate and distribute extensions inside and with XWiki will be a great thing. Thanks, Caty On Mon, Feb 4, 2013 at 1:54 PM, Ludovic Dubost <ludo...@xwiki.com> wrote: > Hi, > > We were 9 xwikiers at FOSDEM this week-end and I wanted to take the > occasion to give some feedback on what I saw there. > > The Community Dev Room > ----------------------------------------- > > First XWikiers participated in the devroom co-organized by Sergiu: > "Community Development and Marketing". The great news is that the room was > full quite a big amount of the time. It was not a huge room but well placed > (in the "original" area of FOSDEM which is still quite active). I think it > shows more and more interest of people for this subjects which are less > usual at FOSDEM which is very technological. Kudos to Sergiu for > co-organizing this dev room. There was also a keynote from Kohsuke > Kawaguchi (creator of jenkins) on how the jenkins community was build which > was on a similar subject as the dev room (I'll give some feedback on the > talk below). > > Sergiu has a presentation about "how to cope with a proliferation of tools > in your community" which presented how XWiki can be used to be a portal to > all the contents of all the tools you have in your community (aka "the dev > flavor). The content of the talk was great but to my taste it was really > missing screenshots to show practically what happens. There was a mini demo > at the end but it was not enough to really make people realize how great > xwiki.org is :) But the idea of the presentation is great and if we can > spend a bit of time to not necessarly make the flavor, but publish the > different pieces of xwiki.org as extensions, including some simple macros > we are using (like how we integrate nabble). There was the 1M$ question of > if we can migrate existing wikis to which we could have answered a bit > better as we do have a few migrators for some specific wikis (Mediawiki, > dokuwiki) but nothing fully done and fully generic. This is another area > were we could spend some time making some specific migrators easier to use. > If there are any contributors that would like to help out improving and > publishing the migrators and "dev extensions" on extension.xwiki.org as > well as document how other communities could use our tools, it would be > very useful to help spread the XWiki work out there. Sergiu should publish > his slides and maybe somebody can improve them with screenshots. > > Vincent and myself had a "devil (business) and angel (open source)" > presentation on "Combining Open Source ethics with private interests". 20 > minutes was a bit short to cover this subject fully in details but it was > great to be able to share our experience on this. The room was quite full > when we did this presentation and there were a few questions which I > believe showed the interest of participants with this subject. Vincent will > publish the slides although it's not easy to follow without the additional > "talking". We should definitively try to do this again. > > MySQL and Security > ------------------------------ > > I attended a few MySQL presentations as well as some security > presentations. There seems to be some interesting improvements in InnoDB in > MySQL 5.5 and 5.6 (currently RC) and even MariaDB and Percona have some > work that improve InnoDB (with XTraDB). As we are planning to work on > performance we should look into testing how XWiki behaves on MySQL 5.1 to > 5.6 and compare the performance also with Postgres. In any case we should > follow what is happening in this area. On security there was a presentation > about OWASP ZAP ( > https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project) and attack > proxy to test the security of Web Applications. This is something to look > at for the Thomas D's coming work on security. > > Kohshuke presentation on Jenkins community > ------------------------------------------------------------------- > > On the "community" subject there was interesting presentations about "how > to cope with assholes in your community" and the presentation of Kohshuke. > To summarize very quickly while Kohshuke says part of the big reasons why > jenkins has been succesful is "good software" and "being there at the right > time" he would like to believe that the way the community is run and the > software is architectured has a lot to do with this success. Some important > items: > > - small core with apis, many extensions, extensions are "first-class > citizens" of jenkins > - very extensible > - very open to contribute an extension with almost automatic commit right > (with an IRC bot to get a rights) > > What we can learn for XWiki > ----------------------------------------- > > There are a few things to learn here for XWiki I believe: > > XWiki has a lot of what is said here, particularly the extensibility but we > could "finish" things a bit more with these learnings in mind. > XWiki is very extensible in many areas (but not all, like the old core). It > is very easy to publish an extension, particularly a XAR file on > extensions.xwiki.org and we have extension manager to install this > extension. However there are a few things we can do better: > > 1/ On the java side, contributing is still difficult. The core is still big > and not well defined. In the "platform" repository we have many different > things, including modules that are not vital to the XWiki core and that > could be maintained by contributors. Our development rules and > methodologies are very "strict" when it comes to the "platform", "commons" > or "rendering" and since many many things are published there it's not easy > to participate there. > > If we separated a bit the "real core" from the additional modules that > depend on the core apis but are not as critical to the core, and we move > the additional modules to an area with potentially less stricts rules of > development and where each developer can decide his own rules, maybe we > would greatly improve potential contributions. It's also a question of how > we "consider" the extensions and we publish information about them and > recognize them when they end up in the default install. More on this below. > > 2/ On the xar/scripting side, it's "almost" easy to publish something and > make it available thanks to EM but there are a few quirks that we need to > solve: > > - Exporting a XAR is not fully supported by the core (we need Admin Tools > and it's not enough documented). > - Committing your work is not easy which makes it more complicated to get > contributors to extend an existing extension. > > But the good news is that we are quite close: > > - AppWithinMinutes has an extension to publish an application on Extension > Repository > - SVN and GitHub app allow to commit XWiki pages > - Maven allows to build and release an XWiki app > - Admin Tools has ways to export multiple pages > - XEM code has an "Application Descriptor" which could be useful for not > AWM code > > If we bind all these together a bit more we can have a killer. Let's image > the following: > > 1/ In an admin area you go to "Extensions" and you have a button to "create > a local extension" and can add XWiki pages to your extension which would > add your pages to an "Extension descriptor" > 2/ AWM would automatically use this extension descriptor. > 3/ You would have a way to: > - ask for a git repository for your extension > - commit your extension from XWiki > - release your extension from XWiki and publish it on > extensions.xwiki.org > - allow another user to install this extension using EM and then decide > to fork it, modify it and commit the changes and create a pull request for > the changes > - finish the contribution loop > 4/ On extensions.xwiki.org you could see who the contributors are for the > extension and what they committed. > > Then you have an even more powerful way to contribute to XWiki, wether it > is an AWM application or just a snippet of code. > Aside from that we should make it a bit easier through documentation or > tools mainly) to publish java code as it is still slightly complicated to > make it easily installed using EM. > More important even would be to continue improving AWM to make it easier to > add Javascript, CSS or REST apis to an application but this is another > story for more complex applications. > > This is food for thoughts to allow XWiki to get more help from new > committers which is a great solution to help XWiki spread more. On the > spreading subject, I also think we should make more effort to publish some > "mashup" macros or snippets and publish them both on > extensions.xwiki.orgas well on the other projects extensions or > plugins pages. This would help > show how easy it is to integrate XWiki with other tools. > > I was quite happy with this year's FOSDEM. It's getting more and more > interesting. Open Source is alive and kicking. > We could push for happing a "Web Application Dev Room" (we tried to get a > "wiki one"), as there is not much on this subject. > There was a "web development" track but it was a bit empty. Maybe this is > an area to work on to get Wikis, CMS tools, Web and Javascript frameworks > presented. > > Ludovic > > > -- > Ludovic Dubost > Founder and CEO > Blog: http://blog.ludovic.org/ > XWiki: http://www.xwiki.com > Skype: ldubost GTalk: ldubost > _______________________________________________ > devs mailing list > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
