[FR] J’ai essayé pour vous: les Cast Codeurs Podcast August 18, 2009Posted by Sacha in Français, JBoss.
Il y a quelques mois, une bande d’irréductibles gaulois, Emmanuel Bernard, Antonio Goncalves, Guillaume Laforge et Vincent Massol créaient un nouveau podcast: Les Cast Codeurs. Description du concept:
Le concept du podcast Les Cast Codeurs est de discuter les nouvelles fraîches du monde Java en Français s’il vous plaît.
En général, le podcast contient les rubriques suivantes:
- discussion sur les nouvelles du monde Java avec vos hôtes habituels
- La sélection des outils de la semaine: un outil que l’on utilise au quotidien pour coder ou travailler
- Java, les mains dans le cambouis: une discussion détaillée sur un sujet peu connu des développeur
- l’interview: une interview d’un acteur Francophone (si possible) du monde Java
J’avais lu la nouvelle lors du lancement du podcast, mais n’étant pas un grand consommateur de ces contenus (je ne synchronize mon iPod que rarement – ce qui réduit considérablement leur intérêt), j’avais superbement ignoré la chose. La situation a changé récemment: désormais fashion victim et propriétaire d’un iPhone 3GS, je synchronise plus régulièrement mon téléphone et donc, peut bénéficier des Podcasts. Lors d’un long voyage en solitaire (retour de vacances), je me suis donc branché sur le podcast des Cast Codeurs et là, grande découverte, ce podcast est tout simplement superbe. Le ton est détendu mais les contenu sérieux, les avis balancés et les sujets variés. Bref, du tout bon.
Note plus personnelle, j’ai toujours perçu en Emmanuel Bernard un “A-player“, un jeune bourré de talent, plein de potentiel, avec une compréhension non seulement technique mais également une bonne intention du marché et, clairement, une envie d’apprendre. De surcoît, attitude que j’apprécie particulièrement, une faculté à se remettre en question et donc à être prêt à changer d’opinion si nécessaire (bref, il écoute, il ne fait pas que parler). Il ne lui manque que LA bonne opportunité et le résultat sera excellent. Bref, j’arrête la brosse à reluire pour vous dire qu’en tant que “présentateur” (on dit ça comme ça?) du podcast, il est fidèle à lui même: très bon. En effet, l’un des risques d’une telle position et de prendre trop de place, ne pas laisser suffisamment la parole à l’équipe et donc ne pas diriger les débats de manière ouverte. Que nenni ici.
Évidemment, comme toute nouvelle expérience, des améliorations verront probablement le jour. La durée des épisodes est très irrégulière, la quantité d’anglicismes est tout simplement effrayante (conseil: faites-le anglais si vous n’arrivez pas à passer sous la barrière des 50% d’anglicismes dans vos phrases initialement en noble langue Françoise) et la qualité sonore de certains intervenants pourrait être meilleure (quitte à enregistrer les voix en local et les resynchroniser lors du montage). Mais bon, ce côté “fais sur le coin de la table de la cuisine” a du charme
Bref, bravo à l’équipe et surtout, continuez!
JBoss World in Chicago: I will be there! August 16, 2009Posted by Sacha in IT, JBoss.
add a comment
Everything is is in the title I guess. It is only 2 weeks away, so don’t miss it!
It is the end of the Summer holidays, take this as an opportunity to learn about JBoss’s new products and product roadmaps, listen to customers and their migration stories and meet with the developers behind the JBoss products. This is a truly unique opportunity.
Furthermore, this will be the first time that Red Hat Summit and JBoss World will be collocated: consequently, with one pass you be able to attend two events!
See you there! Onward,
VMWare acquisition of SpringSource: thoughts. August 13, 2009Posted by Sacha in IT, JBoss.
How does WMWare’s acquisition of SpringSource impact the current IT landscape? Here are my thoughts…
The easiest question to answer is certainly: “does this deal make sense for SpringSource?” It certainly does, yes. If you look at SpringSource rumored numbers, they were in the low 20m, heavily biased towards non-recurring revenues (i.e. training and consulting). For that part of the business, a typical multiplier is in the 1x-2x range (and certainly not the ~20x we see here). Consequently, it is clear that SpringSource haven’t been acquired for their revenue*, especially when you compare them with VMWare revenues at a $1.8b run-rate.
Consequently, getting such a price tag could be explained only by two scenarios:
- A bidding war between multiple vendors, or
- VMware was in a hurry to close that transaction and the price “didn’t matter much”
I really don’t believe in the first option: I don’t see many other vendors willing to play with such big numbers these days, nor with the absolute need to acquire SpringSource.
However, I truly believe in the second option. Paul Maritz has been VMware’s CEO for exactly one year now. I imagine he has spent the first 9 months of his tenure at VMWare understanding the market, speaking with partners, competitors, customers and figure out a new strategy for VMWare. Being an ex-MSFT exec, it is very easy to guess that Paul Maritz felt like standing on quicksand with no OS and no middleware under his feet: it was in his DNA, he needed his Windows&.Net back in his new home.
I bet Paul’s team analyzed the possible alternatives and once he made up his mind for SpringSource he went after it with one top priority: timing (not money). On the other side of the table, I bet Rod Johnson wasn’t willing to sell for less than Marc Fleury did, probably some ego-related subtlety. I do not take it as a coincidence that VMWare bought SpringSource for the exact same amount JBoss was acquired by Red Hat (albeit Rob Bearden probably learned the JBoss lesson and got a cash-only deal – which is very sound given VMWare’s volatile stock).
Bottom line: this deal hugely makes sense for the SpringSource team since no IPO or revenue-based acquisition could have led to such a valuation (and the probability their TC Server could have generated any meaningful revenue in the next 3 years was very low).
*) this is not unique, we have other FOSS acquisitions get stratospheric multipliers with even lower revenues: Zimbra @ 350m and XenSource @ 500m for example.
This acquisition makes sense for SpringSource, but is the same true for VMWare?
“My theory”™ is that the market has been moving for several years towards a verticalization of a few key vendors. Translation: the market will be dominated by a few big vendors each owning a full stack, from server hardware to enterprise applications, welcome back in the 80’s.
Consequently, if you want to exist in that game, you need to own an operating system and a middleware layer. Problem: there are only very few solutions/vendors left if you want to get an OS and middleware layer, hence the M&A pressure on the market (BEAS and JAVA acquisitions are an example of this). And building your own OS or middleware layer is not really an option: this is not just about the merits of a technical implementation, this is about having an ecosystem and a big mindshare – this takes ages to build.
IMO, that is exactly what led to this acquisition. VMWare had to own a middleware solution and other options were too costly. SpringSource’s acquisition gives VMWare several quick-wins: a foot in the middleware game, a developer community, a recognized brand in middleware and, last but not least, a seat on the JCP.
Nevertheless, I see VMWare face several challenges:
- First, VMWare didn’t buy a middleware runtime, but just a wrapper. This doesn’t mean they cannot build one with enough time, talent and money, but that just isn’t there today. Yes, there is TC Server, but that is certainly not what the market is expecting in terms of a full fledge and robust middleware implementation – this is merely a cleaned-up Tomcat à la sauce OSGi with no pedigree and that hasn’t been tested in meaningful deployments. Again, this is not impossible, but will take time. Software is like good wine, it takes time to mature.
- VMWare has very low credentials in Open Source and actually has had some tense moments with the Linux teams. Furthermore, in the past I’ve met with people previously acquired by VMWare and the result was… let’s say… below average. I don’t blame them, acquisitions are a difficult art and fast growing companies are usually not the best organized to welcome newly acquired teams. Consequently, this might end up not being an easy ride for the SpringSource team, especially if VMware is not cautious with their FOSS DNA.
- VMWare has no OS (hence, no OS ecosystem) and no proper Java Virtual Machine nor any credentials in that area. This is a big hole in their stack and they will have to fill that gap fast. A solution to quickly obtain an OS ecosystem would be to acquire NOVL, especially with their currently low Enterprise Value (711m USD) -
Consequently, in order for VMWare to benefit from this acquisition, they’ll have to:
- Start (or continue) the development of a proper middleware runtime, hence invest solid money in SpringSource ranks,
- Respect SpringSource’s FOSS DNA,
- Build a proper OS+JVM foundation
That will require a very solid execution.
Back to my Verticalization theory now: I don’t think that VMWare will be one of the few companies owning such a stack, my bet is that they’ll end up being acquired once their OS story will be more solid.
What it means for Java and EE
This is basically good news for Java since another key IT vendor has joined the Java camp. But that is also very naïve: SpringSource always had a love-hate relationship with Java and the JCP. On one hand they have joined the JCP, have a seat on its Executive Committee and participate in several JSRs. But on the other hand, their business plan is based on Java+ EE+JCP bashing: their motto is that you have to use SpringSource products because what the JCP propose is so fundamentally flawed. While it is relatively easy for a small company to play that script, it is much more difficult for a big one. That’s where things will get interesting: will VMWare be a good Java citizen, standardize its technology and embrace common efforts or will they move away from EE and build their own Enterprise APIs?
What is at play here is not just Java and EE, but a much more strategic decision for them: what will their Enterprise API look like? What will VMWare’s Force.com or AppEngine be? My bet is that VMWare will want to create a one-way street towards their “virtualized-OS”, the real money maker (more on this below). For that to succeed, they’ll need:
- To implement the full EE spec (so that existing EE deployments can be moved easily onto their OS)
- To keep implementing proprietary API à la Spring to increase lock-in as developers start using them (and for this, they do not necessarily need to keep Spring Open Source, au contraire!)
Back to my verticalization theory: all big proprietary vendors will have an incentive to use the exact same strategy i.e. provide portability to migrate users off their current platforms and then proprietary APIs and services to lock them in. And, in 3-5 years, once the market share of the various vendors will have settle, we will face a strong increase in non-standardized/proprietary API in order to increase customer lock-in, hence reduce sales cost and increase ASP.
Hint: if you want to avoid that scenario it is your responsibility to only buy standardized technology and participate in standard bodies – don’t just leave standard bodies to software vendors!
What does it mean for Open Source?
VMWare know they are only going to make money if they can sell their entire platform (virtualization + OS + management + middleware ++). They didn’t buy SpringSource just to sell Spring or TC Server standalone: with almost a 2b USD revenue run-rate, selling 5k Spring subscription chips and training is not going to work. Consequently, Spring/TC (and any other runtime they could build) will be used solely to bring more customers to their overall solution.
My bet is that they will do the following:
- Keep most of Spring Open Source and keep developing it to maintain the developer mindshare
- Develop a proprietary runtime (where the cut between the FOSS library and the proprietary core will be part of long discussions IMO) fitting only on top of their core platform
The idea is to maintain the mindshare while making sure Spring runs “particularly well” (or, for some parts, only) on top of the VMWare platform. Consequently, I don’t think we are going to see big changes in the licensing scheme or in what is open source; the changes will be more subtle and will be at the interconnect between the API and their proprietary core.
What does it mean for the middleware market?
In the short and middle term, the market won’t change much. Spring (as a framework) was widely used on top of JBoss+WebLogic+Websphere before this acquisition and will this is not going to change anytime soon. SpringSource (as a company) didn’t have any business impact on the other middleware vendors (ORCL+IBM+RHT) and the VMWare acquisition is not going to change that overnight: VMWare sell mostly to the IT operations, not to the developers/architects, so this will be hard shift for them (ask your average VMWare salesguy to spell “middleware” properly, you’ll see what I mean).
In the longer run, the situation will depend on well VMWare executes. Not just with SpringSource, but their overall OS+JVM+runtime story. So let’s wait and see.
RHT now part of the S&P500 July 21, 2009Posted by Sacha in IT, JBoss.
While I am not a Wall Street specialist, I don’t expect that change to mean much factually. It will certainly bring more credentials to the company (which might be useful with some stratospheric CIOs) and will most probably increase the trading volume of the stock since it will now be part of index funds activity, but that’s pretty much it.
Now, from symbolic standpoint, that’s really an achievement, since it is the first time an Open Source company joins the ranks of this very popular index.
JBoss + Exo announcement July 19, 2009Posted by Sacha in JBoss.
(Disclaimer: I am truely excited by this announcement as this is one of the last business projet I had been working on whilst at RHT.)
Unlike many partnerships, this one is not “just” a business one (which would be perfectly find btw, I value those a lot). This alliance is multi-faceted and includes a deep community alliance since both companies will now work on a same and unique portal foundation (hence the same codebase, hosted at jboss.org). This is about recognizing each others strenghts and weaknesses and addressing them by cherry-picking the best pieces on both side.
When we first met with the Exo team (meeting took place earlier this year in Neuchâtel), we first agreed on high-level business principles to make sure an overall deal would be possible, but the remainder of the week was spent working on architectural and technical matters. None of the teams were willing to compromise on the quality of the “merged” architecture. To that end, I’d like to thank the excellent attitude of Thomas Heute, Julien Viet and Benajmin Mestrallet: at no point in time have I seen the tiring NIH syndrome (Not-Invented-Here) interfere in our discussions. The fact that Julien had an intimate knowledge of both architecture certainly helped.
10 days ago, I’ve met with both Thomas and Julien in the Fribourg Alps and I got confirmation that very active engineering work is underway.
So, let’s stay tuned to see further (and specific) announcements, but this is a great opportunity for those two companies with different but parallel strategies to focus on a common foundation.
BTW, will you be at JBoss World? I will
1 comment so far
Since I have been in the middleware field, I’ve been visiting lots of customers. And a very high percentage of them are using a very similar setup for their web deployments: an Apache httpd front-end acting as a long-balancer/failover for a cluster of tomcat-related instances (“-related” since it can be any flavor of a tomcat-engine, including JBoss AS).
But each time I met with any of those users, the problem is ALWAYS the same: which load-balancing module should I be running in httpd? mod_jk? mod_jk2? mod_proxy? which version? in which setup? For which OS? Truth is that picking up the right module isn’t exactly an easy choice: all had their own little issues, shortcomings and some releases would simply not work reliably on some OSes.
At JBoss, we had decided to fix the reliability issues by providing stable releases of those mod_xxx compiled on many different OSes. Still, this wasn’t fixing the fact that none of those modules provide enough features for a sophisticated load-balancing/failover setup. Consequently, about 1-2 years ago, we initiated a new project aiming at providing a clean next-gen solution: mod_cluster.
From the mod_cluster overview page:
mod_cluster is an httpd-based load balancer. Like mod_jk and mod_proxy, mod_cluster uses a communication channel to forward requests from httpd to one of a set of application server nodes. Unlike mod_jk and mod_proxy, mod_cluster leverages an additional connection between the application server nodes and httpd. The application server nodes use this connection to transmit server-side load balance factors and lifecycle events back to httpd via a custom set of HTTP methods, affectionately called the Mod-Cluster Management Protocol (MCMP). This additional feedback channel allows mod_cluster to offer a level of intelligence and granularity not found in other load balancing solutions.
The good news is that mod_cluster recently hit the 1.0GA milestone.
So, using Apache as a front-end to your JBoss or Tomcat worker nodes? Check-out mod_cluster, I bet this will quickly become part of your deployment.
So, what’s up JBoss? June 8, 2009Posted by Sacha in /dev/null, IT, JBoss.
1 comment so far
For the last 8 years, JavaOne has been an important time in the year. A lot of product activity would focus on this deadline. Except for this year actually: I realized JavaOne was over just 48h ago…Well, I had a good excuse as I was extensively working on a new framework. No worries, I am not working on a new ORM or web presentation layer, but helping a friend on some “real stuff”:
So, I did a quick check of the recent JBoss announcement and discovered the “JBoss Open Choice” tagline, which included several announcements.
The most important ones were about the split of the good old JBoss AS in three distinct cuts:
- Full EE profile (with IIOP, full JTS support, etc.)
- Web profile (similar to the future EE6 profile but applied to EE5)
- Simple Web server – this is really Apache httpd and Tomcat and a bunch of mod_xxx Apache modules but available for multiple OS – not only RHEL
Engineering wise, they are mostly cuts at the same codebase (which is great QE – and patch- wise – less cost) but from a business standpoint, it offers more flexibility to the user. You can see this as the first axis of a two-axis grid.
Then, on the second axis, Red Hat now supports a bunch of frameworks typically used in enterprise applications such as Struts and Spring.
As a result of these two axis, these frameworks are available à la carte on all of the runtime cuts. I like this a lot.
As a reaction to this announcement, Rod Johnson from SpringSource posted a lengthy reply explaining how RHT was reacting to SpringSource’s leadership… A few notes are in order:
- JBoss has had a flexible architecture allowing all kind of setup (from a simple embedded micro-kernel) to a full fledge certified EE5 application server since 2001 – so the “tc” architecture if anything is just 7 years late (tc was released last year)
- The various AS cuts are here to make customer work easier and provide various price tag – SS didn’t invent the notion of a “small server”, actually they can only be a “small server” since they lack the other pieces required to be anything else.
- “SpringSource leadership blablabla”… Yes, congratulations on the Open Source Spring framework, it now catches on the popularity of Struts, so RHT should definitively try to make money on it – still I fail to see how this translates in any particular SS’s leadership? Is that a revenue/booking metric? number of tc-server customers? Spring != SpringSource.
- Tomcat and its suburbs is what it is today thanks to the work of the Tomcat community, including the amazing work done in the last 6 years by people like Rémy Maucherat, Jean-Frédéric Clere and Mladen Turk – all RHT employees. It seems that SS is fast to hijack laurels.
Truth is that I just don’t think the market needs a new runtime – especially if it doesn’t add any meaningful feature:
So, is this a “reactive move”? Yeah, possibly, even though I would more accurately call it an “opportunistic move”. I am glad RHT is agile enough to lead in so many ways but yet, jump on side opportunities when they make sense. Not doing so would be a puerile and misplaced sense of pride: 4 or 5 years ago, if BEA had properly reacted to the JBoss threat, I am not sure JBoss would have become what it is today.
I am leaving Red Hat. Onward. March 29, 2009Posted by Sacha in JBoss.
From my first contribution to JBoss 2.x, to setting up JBoss EMEA operations throughout the RHT acquisition, these have been incredible times for me.
So, why am I leaving now? Well, JBoss is kicking and well alive. Sales are booming, the product pipeline is full and new talents are energizing our ranks. We are now 33 months after the acquisition of JBoss by Red Hat and it is fair to say it is a great success.
Where am I going next? First of all, I am not completely leaving Red Hat, I’ll remain available as an external advisor to Paul Cormier. But other than that, I don’t have any clear plans outside of spending the next 6 months actively doing nothing.
JBoss to join forces with Apache CXF March 26, 2009Posted by Sacha in JBoss.
Today, our Web Services stack, JBossWS 3.0, is actually a pretty sophisticated abstraction layer which can use either our own WS implementation (JBoss WS Native), Apache CXF or Metro – and this in a totally transparent way to the developer.
While this abstraction is a nice thing to have, we cannot spread our efforts thin on those three implementations. Consequently, we have decided to focus our future efforts on a single stack: JBossWS-CXF. This will make sure we maintain our competitive edge, rapidly support current and emerging Web Services standards and ensure we have proven interoperability. Obviously, much like in the past, we will also make fully certify this stack (EE5, etc.)
So, is this a problem if you are using JBoss Native WS today? No, certainly not: this will be a long term transition and our EAP and SOA-P customers will benefit from our commitment to and long-term support for the current JBoss Native WS stack – stability and long term commitment is part of the advantages you get when you become an JBoss Enterprise Middleware customer (vs. our community/.org projects).
Congratulations to the ASF for grooming such a great project.
EE6 Public Draft APPROVED February 26, 2009Posted by Sacha in JBoss.
Looking at the results gives some interesting information:
- The Apache Foundation voted NO, but didn’t do so based on the merits of the specs, but because of their long-standing issue with SUN wrt the SE 6 license. While I support Apache’s decision to vote NO to any SUN-led JSR until SUN gets their act together, we didn’t take such a strong stance and will only vote NO to any future SE JSR proposal (unless the ASF gets a satisfactory proposal from Sun obviously).
- SAP voted YES to the specification but commented that “[they] would like the Spec Lead to consider putting more emphasis on architectural rigor regarding a single consolidated and extensible component model to be used across the platform – right now there are three (EJB, JSF and JSR 299).” While I don’t think there are any problems with the current approach, I can see why SAP might want to dispatch things differently. The good thing is that SAP is part of all of those specs (EE, EJB, JSF, 299, etc.) so we are waiting for their specific advices.
- As always, I like to keep the fun for the end. SpringSource, the Switzerland of middleware, courageously voted NO… hum, no, they voted YES, hum, no… actually they voted ABSTAIN! SpringSource always had a hard time positioning itself wrt J2EE/EE. Consequently, this is no surprise that they opted for a non-risky position where i) they don’t vote NO to EE (not good for their karma), but ii) don’t back it either. It gives them the freedom to criticize the spec when they see fit. Opportunism at its best. Last but not least, they add this comment: “We would have preferred to see a dependency injection model for SE, as we proposed in 2007.” ?!? SpringSource never contacted us for a JSR DI specification, so I am not sure what “spec” they are referring to. Maybe some back-doors discussions with other vendors. In any case, if these were back-doors discussions, they should remain so and I find it strange to use it as a public comment to justify an ABSTAIN vote. In the land of privacy, you don’t become Switzerland overnight – and I know what I am speaking about…
Also, I’d like to officially thank our colleagues at Oracle, Google and IBM for their deep involvement between December 2008 and February 2009 to make sure JSR-299 fitted to their requirements. In just a few weeks, they’ve worked with no agenda other than solving problems. Thank you.
Mobicents 1.2 GA hits the tarmac February 16, 2009Posted by Sacha in JBoss.
add a comment
Since the last Beta, the Mobicents team has done an impressive job nailing the GA down. From the Release Notes:
This GA release includes the ‘all’ JBoss Application Server configuration, which hosts a cluster-enabled Mobicents Sip Servlets container. The Mobicents SIP load balancer is also included. Note that there are some limitations when clustering is enabled and clustering is only for the Sip Servlets container. For more information see http://www.mobicents.org/clustering.html. To demonstrate clustering and mid-call failover we have included a predeployed UAS example in the ‘all’ configuration called ‘simple-
Is it still possible for FOSS companies to raise VC capital? February 16, 2009Posted by Sacha in Finance, JBoss.
Good question, especially in those difficult times.
And it seems the answer is a victorious YES. Here is a short list of some of the 2009 rounds:
- LoopFuse raises 1.4m USD from True Ventures (congrats Roy and the gang);
- Black Duck raises 9.5m USD in a D-series (mix of capital and … debt! congrats ) and Tim Yeaton joins as a CEO (I know observe very closely what happens in the 2 weeks after Tim joins a company )
- Talend raises 12m USD in a C-series round (Frenchies leading a FOSS company – we know that it works )
Autogoal (as in “don’t speak too fast Jonathan”) February 9, 2009Posted by Sacha in IT, JBoss.
Just one year ago, on the 26th of February 2008, Jonathan Schwartz said:
Q:Turning to MySQL, how long do you think it will take before MySQL is fully integrated into Sun? We saw with Red Hat and its JBoss acquisition that this can be a slow, laborious process….
A: First, the personalities involved. Let’s just say that integrating Marten Mickos into a company might be easier than assimilating a few of the JBoss personalities. Marten is a joy to work with and will make this integration work.
AS 5.0.0: we are done. Next. December 5, 2008Posted by Sacha in JBoss.
We have been waiting for that day for a long time. Too long certainly. But here we are, the community version of JBoss.org AS 5.0 just got released.
Our foundations are now ready to absorb the changes the Java landscape will go through in the next 5 years. We have the strongest API-agnostic implementation of the core middleware services – our DNA (messaging, persistence, security, remoting, etc.). We have the most evolutive and flexible microcontainer on the market. Thanks to those two, we are able to morph our DNA to whatever API/programming model the market might move towards, and implement several of those simultaneously if needed. They are the (important) bells and whistles on top of our rock-solid and non-monolithic engine.
But make no mistake, we are not going to party long. JBoss AS 5.0.0 is just a start. We’ve already started working on the future:
- JBoss.org AS 5.x will be further refined to leverage all features of the MC. Some key services already fully leverage the MC today, but not all of them do.
- EAP 5.0, the only software actually supported by Red Hat in its commercial offering has already started its extensive productization and sanitization phases.
- In JBoss.org AS 5.0.0 you will find a new configuration: “web”. I think you’ll find it very similar to a web profile – more to come on this
Onto EE6 now, the refreshed JBoss will lead the pace. Onward,
Paris JUG, you rock! December 3, 2008Posted by Sacha in JBoss.
Tags: JBoss AS, JUG, Paris
Et donc hier se tint le JUG Paris auquel j’avais été cordialement invité. Après quelques petits problèmes techniques (une dizaine), la présentation pu commencer, devant environ 200 personnes selon les organisateurs, 180 selon la police.
Et quelle ferveur! La qualité de l’auditoire et des questions posées m’ont impressionnées. Bien que ce JUG soit très jeune, il rencontre d’ores et déjà des problèmes de croissance (taille de salle à disposition).
Lors de ma présentation, j’ai mentionné différents projets, j’ai pensé qu’il serait plus simple si je les référençais directement sur ce blog:
- JBoss Microcontainer:
- Homepage du projet
- Thincrust – pour la construction de virtual appliance
- Ruby on Rails
- JBoss Cache
- Certaines personnes m’ont également demandées comment rejoindre nos rangs, vous trouverez les positions ouvertes ici. Quant à nos développeurs cœurs, nous les recrutons exclusivement depuis nos projets Open Source, donc… Contribuez!
Si vous êtes intéressés par un quelconque de ces projets, n’hésitez par à rejoindre nos mailing lists ou, mieux encore, à rejoindre les autres développeurs et contribuer du code (surtout s’il s’agit d’additions mineures – c’est la meilleur façon de mettre le pied à l’étrier).
Par ailleurs, si vous connaissez une salle qui pourrait accueillir plus de 200 personnes, serait bon marché à louer (lire: gratuite), ouverte le soir et dans laquelle il est possible de proposer un buffet (apporté depuis l’extérieur), communiquez cette bonne nouvelle au comité du Paris JUG.
Encore merci au Paris JUG pour cette très conviviale soirée!