Does an OSS project’s language need to be “cool?”

We are in the process of starting up a new open source project. I think we have a pretty cool idea and as soon as we can get our collaborative infrastructure set up we’ll be opening it up to community. We are prepared to do most of the development if necessary but a key measure of success for us with this project is community building. We are starting this project up on behalf of our DoD customer and both we and our customer believe that the project should be a demonstration of the power of community. Plus, we just think there will lots of cool things it will be used for if it is open source, and it might be a nice demonstration of government OSS as public good.

So… with that as context, last week we spent a few days kicking off the project and thinking through some key architectural issues, a development roadmap, and the like. In the process of discussing architecture it became clear that, assuming we wrote the service in Java, OSGi would make a really good framework for building it. If we weren’t doing an open source project, we’d be done thinking about it. We’d be moving forward on our first few sprints of work (at least) coding in Java in an OSGi framework. But…

…it is an open source project, and we care a lot about early and significant community involvement. So, how to consider the impact of language / framework selection on community? Does Java and OSGi make this too “enterprise integration” in feel and potentially distance us “spiritually” from important potential contributors?

In some of our other open source projects, JBI ESB components that are firmly in the “enterprise integration” world, this wouldn’t be an issue. Developers in that world would be comfortable in enterprise Java and would probably be eager to incorporate OSGi into the mix. But what we have in mind is not really in the “enterprise integration” space (at least not in my mind). In my view this project will appeal much more to the constituents of “web”, “VoIP”, and “collaboration” worlds. Outside the DoD, I think the community for a project like this is likely to be more “Web 2.0 Summit” or “BarCamp” than “Gartner Enterprise Integration” – though I can imagine at least a little bit of “Office 2.0” or “Enterprise 2.0” zeitgeist mixed in.

So, other than a bunch of gut feel BS, how much does language selection influence audience and community? That is the question we are wrestling with.


  1. Joshua Hoover - September 11, 2007 @ 10:23 pm

    I think I understand your hesitation. I’m curious what the alternatives would be. Knowing a bit about the project already, I’m guessing Java is the safe bet all the way around. While other languages may be “hipper”, it sounds like the core to this new project is going to be the server. Maybe I’ve got that all wrong. As long as you have a REST API you should satisfy the needs of those using other languages, especially the dynamic/scripting bunch.

  2. Kit Plummer - September 12, 2007 @ 10:16 am

    That’s the thinking Josh. RESTful interfaces to the “world” and most likely a language-specific API (maybe multi-language) for the server-side stuff.

    But, what Jim is really addressing is a different perspective on the question. Rather than taking an app/requirements-first approach, let’s start with the communities and which would be most likely to provide the necessary lift and sustainability to our project. It is kinda cool to think about that way.

    I think it is somewhere in between with the community becoming a key functional requirement.

  3. Richard S. Hall - September 12, 2007 @ 10:44 am

    Funny that people now associate OSGi technology with “enterprise integration” since it has only recently been used in this area. OSGi technology has been available since 2000 supporting the creating of highly dynamic, extensible Java applications. The enterprise work has only become a focus in the last year. Funny how perceptions change. 🙂

    Sorry that I don’t have input on your choice of language. I would lean toward Java personally, but it definitely isn’t “hip” any more. If the project is into “VoIP”, it seems like SIP Communicator has a healthy community and it is Java and OSGi based.

  4. Joshua Hoover - September 12, 2007 @ 12:58 pm


    Right. What will be most acceptable/attractive to the community? I think that Java is probably the right answer for that as well. My thinking is that your most active community is going to be around what people can do with the REST API, ala the development around what Google, Yahoo!, Amazon, Ebay, and all those trendy Web 2.0 startups provide in their APIs. 🙂

  5. Srinivas Chennamaraja - September 19, 2007 @ 9:53 am

    I just came across your blog through GIGLite. To answer your question, (without knowing much into what you guys are doing), Java Still is the Language du jour for building web 2.o and/or RIA applications at least on the server side.
    If you look at the client side technology (whether it be Adobe Flex/AIR, or Ajax), Java is the serve side Language of Choice for them.
    just my $0.02.

    Srinivas Chennamaraja
    Akira Technologies, Inc.
    Technology-Innovation-Value Driver

  6. Jim S - September 19, 2007 @ 12:10 pm

    @ all – thanks for the comments. Just an update… looks like we are going to go with Java / OSGi for the server side. The technology seems like the right choice and we have the right competencies on the team.

    By the way, wasn’t making a judgement of any language’s “coolness” – I just thought it was interesting that there was this new dimension. If your “product” is as much community as it is software, a new set of choices seem to matter…

  7. Kit Plummer - September 19, 2007 @ 12:17 pm

    Interestingly enough…I don’t think the language is the key here. Frameworks, in general, are where its at. Of course, the framework will pull you to a specific language (Spring-Java, RoR-Ruby, etc.). The neat thing is that there are some very good options and formal Foundations out there to support it.

    Richard, I’m not so sure it is that OSGi is getting play in an “integration” capacity – as much as it is that OSGi has simply addressed some of the general Java problems (modules, version, classpath, etc.)

    The integration and enterprise aspects are a byproduct of a good thing getting exposure in large-scale software-specific projects (Eclipse, WebSphere, etc.).

    But, nonetheless, the discussion in the ServiceMix camp (Spring) is that OSGi and JBI are an extremely powerful combination. The linking of these kinds of frameworks/specs will be what drive OSGi in to the true Enterprise and not just server-side.

  8. johnheil - October 1, 2007 @ 8:51 am

    It’s probably too late but this article has some pretty good tips for language selection:

Leave a Reply

Your email address will not be published / Required fields are marked *