Home

Hudson's real top page lives in https://hudson.dev.java.net/ and link to three pages in the Wiki

News

Do you blog about Hudson? Do you have any interesting URL to share with Hudson community? Check out our News Aggregator.

Hudson Helper for Android

Recently I launched Hudson Helper for iPhone and iPod Touch, enabling Continuous Integration fans to stay in touch with their projects. Android users can get in on the game now too, with Hudson Helper for Android.

Hudson Helper for Android

Hudson Helper for Android provides all of the same features as the iPhone version including support for multiple servers and authentication. New for this version are build controls: start and stop builds right from your phone. CI can be even more fun with shake-to-build and sound effects.

To get Hudson Helper for Android, search for 'Hudson Helper' in the Google Market on your Android device.

Growth of Hudson plugin ecosystem
A Hudson committer Seiji Sogabe put together a chart that shows the growth of the Hudson plugin ecosystem.
Xuggler Commercial Licensing

Hi folks,

(Hudson users probably want this post).

We’ve talked to quite a few folks since Friday, did some internal discussions, and have decided on our licensing approach. Here’s the summary:

Xuggle. Inc. will release a “Xuggler Professional Edition” by July 15th that allows developers to build products that link in Xuggler without having to release their own source code with the following pricing:

$800 per version you use, per organization, per operating system.

That’s it. So if you’re one developer deploying on Windows, you pay $800 to use the Xuggler 3.0, regardless of how many applications you sell. If you’re a thousand developer company deploying one hundred products linking Xuggler on Windows and Linux servers, we ask you pay $800 x 2 or $1,600, regardless if a billion people watch the videos you stream with Xuggler.

Before we go into details, we thought a summary of what we heard from you might help frame why we’re reached the decision we have:

  1. There are lots of companies out there that offer technology and APIs to aid in video transcoding1 with pricing that gets more expensive the more you deploy it. Prices seem to scale either per server (e.g. $5,995 per server per year and up) or per GB transcoded ($2/GB and down with volume)2. (Incidentally many of these companies seem to use FFmpeg under the covers3, and are charging people for the value FFmpeg provides, in addition to anything else they provide of their own.)
  2. Most of you started your development process looking at using FFmpeg directly because you didn’t want to pay someone for the “value add” you know FFmpeg provides for free.
  3. And you seem to like Xuggler because we’re easier to use than FFmpeg’s API, we integrate directly with Java, we provide a lot of testing, we continuously integrate with the latest FFmpeg while communicating changes between releases (somewhat) clearly, and we clearly know this complex technology space.

We could take the approach of charging per server, or per video processed, like everyone else, but that seems wrong. We think we do add a lot of value, especially in making it really easy to use FFmpeg, and we think it’s reasonable to charge for that value if you’re not giving code back. But we also think that it’s unfair to charge for the parts of the value that FFmpeg really provides — the converting of video and audio to raw data and back. That, in our opinion, would make us jackasses.

Ultimately our goal here is to have a sustainable project with happy developers using it. We changed to AGPL, as stated here, to make Xuggler sustainable by requiring users to either share their code with the world, or to help fund the project. As the second part of that strategy, we’re putting in place a (hopefully) sustainable licensing model, NOT a gouging licensing model. We think (and we hope you agree) that this approach is unique in the industry, and believe the model provides reasonable terms and pricing for the value Xuggler provides.

So here’s the draft of licensing terms we’re going to use for the “Xuggler Professional” version we’ll release by July 15th (actual final legalese will follow in a few weeks):

  1. $800 per person or organization, and per operating system on which your product that links-in Xuggler Professional is deployed.
  2. The Xuggler Professional license will not force you to release your source code.
  3. Xuggle will deliver to Licensee either a copy of source for Xuggler Professional or Xuggler binaries (depending on OS):
  4. Licensee will have permission to use the source to create binaries using the Xuggle-provided build system, and to link the binaries into their product and redistribute those binaries in products they own that use Xuggler Professional.
  5. Licensee will have no permission to modify the Xuggler Professional source.
  6. Licensee will have no permission to distribute the Xuggler Professional source.
  7. Licensee will acquire a licence to use the version of Xuggler Professional that is current when license is acquired, or, at their option, to any new release of Xuggler Professional made within 30-days of purchase.
  8. Licensee will need to build and install your own version of FFmpeg to accompany the Xuggler Professional binaries. It’s up to you what version of FFmpeg you install, and whether it’s LGPL or GPL — in other words you get to choose whether you want libx264 support.
  9. As with all previous versions of Xuggler, the Xuggler Professional license and AGPL license will not include any license to use the different codecs implemented in FFmpeg. As with anyone using FFmpeg, you remain responsible for working with the correct licensing authorities to get licenses from them.
  10. The Xuggler Professional license will include no support (although the xuggler-users group will remain available), NO WARRANTY AND WE WILL ACCEPT NO LIABILITY. Basically it’s the same state you have with AGPL Xuggler 3.0 today, except we’ll impose no restriction on what you do with your source code.
  11. Lastly, for those who like to develop on one OS but deploy on another, you can use the AGPL licensed Xuggler for developing, since the AGPL restrictions on opening your source-code don’t apply when developing. You can develop with AGPL, see if you like Xuggler, and only when you decide to deploy buy a Xuggler Professional license. Of course, if you wanted to pay for each OS you develop on in addition to deploying, we’d think that’s a great way to show your support!

For that, we think you get a lot:

  • You can develop Java applications that decode and encode video much simpler than before Xuggler.
  • You get the advantages of all the new features in Xuggler 3.0.
  • You help fund continued Xuggler development, which means as we add features and fix bugs, you will have the opportunity to build even more cool stuff more easily.
  • You help us be able to apply our expertise in Xuggler, FFmpeg, libx264, libmp3lame, speex, Java, C++, x86 assembly, Swig, Valgrind, build systems, and testing frameworks to benefit you and the open-source community.
  • The licensing is simple to understand. An organization either has a license to integrate Xuggler Professional into the product they own or they don’t.
  • The pricing is simple to understand. Buy a particular version for an operating system, and integrate it in any product you own, and you don’t have to pay more even if you ship a million units or have a billion viewers.

We will also offer a paid support option; we’re interested in hearing from you on what you want on this, but our basic terms are below. Bear in mind that support will be much more expensive than the Xuggler Professional license — the only way we can support this type of licensing model above is if our actual support costs are either very low (i.e. we respond just to the list as we have time), or are paid for.

Standard Support Contract:

  • $8,000/yr for up to 3 named developers. $1,000/yr for each additional developer.
  • 1 Year term.
  • Licensee gets automatic license to any new versions, on any supported OS, of Xuggler Professional released during the term of support.
  • Bugs submitted by named developers will get priority handling by Xuggle.
  • Xuggler will make commercially-reasonable efforts to fix bugs proven by us or licensee to be in Xuggler code; Xuggle will not be responsible for bugs or issues in any Third-Party-Software that Xuggler relies on.
  • Separate (non-public) e-mail support.
  • Named developers may submit up to 25 combined incidents per year; $500/incident after that. An incident is a support question that is opened through the non-public e-mail support option. If an incident is resolved by fixing a bug in Xuggler, it will not count against the incident count.
  • Licensee may change names of named developers with written or e-mail notice.

It’s going to take us a while to rework our build system to do all this, set up the legal docs, and get the web-site redone for this, but we wanted people to know the plans and get feedback early. We’re targeting being done with all this by July 15th at the latest, and hopefully earlier. If you’re launching before then and are worried about our time-line, please contact us off list and we’ll see what we can do.

Finally, if you don’t want to pay, use the AGPL license and make the free software world better by also releasing your source code. Or if you don’t think we provide sufficient value for the price, and AGPL is not sufficient for your need, please use a different solution. Some of the available projects include ffmpeg-java and FOBS, although we are the only open-source java implementation that is continuously synced with the latest FFmpeg.

Thanks,

- Art & Robert (& Schrodinger)


  1. http://www.rhozet.com/, http://www.ripcode.com/, http://hdcloud.com/ http://www.encoding.com/ for starters
  2. Rhozet: http://www.rhozet.com/rhozet_priceList.pdf
    hdcloud list pricing is $2/GB:http://www.techcrunch.com/2009/04/14/hd-cloud-puts-video-formatting-in-the-cloud/
  3. http://roundup.ffmpeg.org/roundup/ffmpeg/issue484
    http://www.encoding.com/: notice how XML API options are almost 1-to-1 mapping to ffmpeg options
[Agile 2009] Hudson-related presentations
Going to Agile 2009? Cannot get enough Hudson? I have put together a list of sessions at the conference that will explicitly mention the best CI server eveeeer ;-): Java Power Tools - getting it all together by John Smart, Build and Test in the Cloud - CI and Cloud Provisioning for Agile Teams, by Darryl Bowler, Agile [...]
Hudson adoption in the Eclipse community survey
According to Eclipse community survey, Hudson is the most adopted CI tool.

slave-status

Releases

What's new in this Wiki?

 
Recently Updated
by Anonymous (01 Jul)
Grinder Plugin
by Anonymous (01 Jul)
Meet Hudson
by Tom Pijl (01 Jul)
Re: Building a maven2 project
by Gregory Boissinot (30 Jun)
CopyArchiver Plugin
by Gregory Boissinot (30 Jun)
File copyarchiver_with_flatten.png
by Troels Knak-Nielsen (30 Jun)
Configuring a Rails build
by Joe Stano (30 Jun)
Re: Parameterized Trigger Plugin
by Dominik Kapusta (30 Jun)
Re: JMeter Plugin
by David Green (29 Jun)
Hudson Helper for Android
by David Green (29 Jun)
File hh-blog1.png

Labels

  Edit Labels
(None)
  1. Jan 23, 2008

    Anonymous says:

    When can I expect the Tutorial for Writing javancss Hudson PlugIn to be continue...

    When can I expect the Tutorial for Writing javancss Hudson Plug-In to be continued?

  2. Aug 27, 2008

    manjit says:

    I have an issue with hudson when it tries to checkout source files for a project...

    I have an issue with hudson when it tries to checkout source files for a project from CVS. Let's say I've a project abc under xyz main directory. I need to check out abc directly, not as xyz/abc, using a tag TAG_1 in CVS. I am not able to do so. Is there any additional configurations we can do to achieve the same? One work around I've found is to have the files checked out using other third-party CVS tools and have hudson use these files for a build. But I guess, hudson should be able to manage all these by itself.

    Suggestions are warmly welcome.

    Thanks

  3. Feb 26

    Harish M says:

    How easy to invoke other tools like IPSl from Hudson? If not, is it easy from Hu...

    How easy to invoke other tools like IPSl from Hudson? If not, is it easy from Hudson to communicate with some port say X of some server? Data flow will be in the XML format or SPML?

     Any information regarding this would be appreciated.

    Thanks

  4. Mar 11

    thao pham says:

    Is there any way to get the compiler error\s\ written into the hudson build fail...

    Is there any way to get the compiler error[s] written into the hudson build failure email? i.e. can we have the console output include in the notify failure email?

  5. Jun 01

    Carolyn Teo says:

    Hi Hudson Users and Experts,\\ I have this issue that I have not been able to so...

    Hi Hudson Users and Experts,

    I have this issue that I have not been able to solve for some time.

    I have 2 jobs:

    - Both are normal Ant Jobs that pulls out of Subversion

    The issue here is:

    One of the jobs has a Customized Jumpstart in the repository and the Hudson Build will also build this jumpstart.

    However, everytime this Job builds, any subsequent builds that uses Jumpstart will start pointing to the customized Jumpstart in that particular build. This causes all other builds to fail because of the specific customized Jumpstart settings.

    Things Tried:

    - Setting Environment Variable JUMPSTART_HOME to point to Generic Jumpstart in Hudson (The Job using the customized Jumpstart will fail to build)

    - Pass in JUMPSTART_HOME as a variable to the jobs for the build. (Does not work)

    - Getting the build.xml to pick up the JUMPSTART_HOME variable from the system (Did not work unless Hudson Env Variable is set) 

    Seeking your Advice since there's not much documentation on this Item:  

    • Is there an issue with the build or is this a Hudson feature?
    • How do I keep the environment settings in each of these build separate even on the same Hudson Build Engine?

    Thanks!