Steve: Developing on the Edge - The Fedora Tactic

Steve: Developing on the Edge

Thoughts on development, Web-services, technology and mountains.

24Sep
Wed2008

The Fedora Tactic

I'm looking at the new SpringSource pricing model, which is

The source is in public SCM.
Release updates are only built/shared with people who have an enterprise license once a point release is up.
The SCM tags used for specific builds will be kept secret to stop others rebuilding and redistributing it.

Rod says, "A model where one company or group develops open source and another makes money from it is destructive in the medium to long term."

Which irritates me. Because everything is part of an ecosystem. I love gedit, jedit, other IDEs. But I don't expect to have to build gedit from source just to view a patch. Similarly, Firefox. Never built it. Indeed, my home and work desktops are Ubuntu Linux: never built anything there either. People using OSS software without paying you are still users, and by using your product they don't use a competitors, they provide more testing and bugreps, and can perhaps be convinced to pay for support if they need their hand held. More accruate would be "a VC-funded business model has a hard time surviving in a world where the core product -software- is freely distributed. To operate a compatible business model, you need to provide extra incentives to switch to the paying version. This can include making the free version less stable and more bleeding edge".

I call this the 'The Fedora Tactic', from RedHat's technique of encouraging paying customers to switch to RedHat Enterprise Linux by making the OSS release less stable. Even there though, CentOS and others redistribute their official versions.

Bill Burke has something to say on the matter. That's Bill from JBoss. Jboss being part of RedHat. That came out with The Fedora Tactic in the first place.

Posted by steve at 13:46

Comments

new comment thread


	SpringHatreply to this thread On 24 September 2008 at 22: 03 Gavin commented: Not so much The Fedora Tactic, but thinking along those lines: http://fishdujour.typepad.com/blog/2008/09/springhat.html
	Bill Burkereply to this thread On 25 September 2008 at 13: 31 Bill Burke commented: I don't think you've got "The Fedora Tactic" right. Fedora, to me, is an "ever forward" approach. Kinda like TRUNK/HEAD development. Bleeding edge stuff. RHEL is like a maintenance branch. JBoss doesn't follow a pure RHEL/Fedora split. We still push community releases as much as we do the RHEL-like release that customers pay for, we just refuse to support community releases. On 25 September 2008 at 14: 51 Steve Loughran commented: Yes, but isn't that what Spring are saying: you want stable and tested, you pay. If you want SVN_HEAD, you can have that for free. Now, if you look at unfunded OSS development -say Apache Ant- we have a different ethos, one that says "SVN_HEAD is all there is". All bugreps are dealt with by asking "Does it exist in the latest release?" and then "Does it exist in SVN_HEAD". Only defects that exist in the head get worried about. Making people submit bug reports verifies the problem is still there, and sets them up for verifying the fix works. More subtly, it sets them up for fixing it. Because every developer with a defect is someone who needs a bug fixed, someone with the skill and motivation to do so... On 25 September 2008 at 20: 41 Ismael Juma commented: It's worth mentioning that even though Fedora releases have no "official" support from Red Hat, package updates are available for release n until release n + 2 is out. Fedora releases usually take 9 months, but I think the aim is to have 2 releases a year. So, we're talking a minimum of 12 months of package updates, but possibly 18. On 25 September 2008 at 20: 49 Bill Burke commented: @Steve: No, its not the same as Spring. Our community releases are stable and tested. We just won't commercially support them. On 25 September 2008 at 21: 33 Steve Loughran commented: OK, that's a good point that Fedora comes with updates, it's just got more bleeding edge packages. What is interesting about Fedora/RHEL is that products like VMWare won't support VMWare on Fedora, so those of us who swear by that product have to choose between RHEL, Ubuntu and SuSE; although I can run RHEL at work, I don't like inconsistencies between it and the home boxes so have jumped to Ubuntu, who of course have a fairly bleeding edge philosophy too, just one that VMWare seem happier with. I only make SmartFrog RPMs for RHEL though, and only test them on RHEL VMWare images. So again, even my own software doesn't officially support Fedora, (though unofficially, its less trouble than Vista) On 25 September 2008 at 22: 58 Ismael Juma commented: That decision from VMWare seems related to reducing the amount of distros supported to make it simpler for them, not necessarily based on how bleeding edge packages are. As you said, Ubuntu is fairly bleeding edge too and even on LTS releases (shipping a beta Firefox for example). It seems to me that they decided that there were 3 main distro "lines" worth supporting: - RHEL, Fedora, Centos, etc. - Ubuntu, Debian, etc. - SuSe, OpenSuSe, etc. It's not surprising which of the distros from each line was chosen. On 26 September 2008 at 09: 09 Steve Loughran commented: you are right that Ubuntu 8. was too leading edge; shipping betas of things like firefox doesn't make sense in terms of stable/compatible. Which is why I haven't upgraded to it at work. For VMWare, one of the real problems is testing. They need to make sure that USB, sound, graphics works with different host OS and different virtual OS images. That must be a significant workload, so testing against stable-ish releases is the only thing that is viable. And their (excellent) support team needs to be able to replicate the problem, so they need real images around to test on. The other reason for focusing on RHEL over Fedora is that VMWare is commercial, so you want to target people with money, hence RedHat. I just wish Adobe brought FrameMaker for Linux back; that is something I'd buy.