Right now we are looking for someone who can take over significant focus on Fedora, as well as provide skills in community consulting and strategy for other Red Hat efforts.

Myself, I’m looking for another rounded, senior-level person who can apply the open source way – thinking & doing – as well as help make practitioners out of other people. Just spread this word around – someone out there hasn’t thought her or his self in this role yet, but could be.

Looking at this role, it is an example of job skills and merit that can be learned and earned while working on open source projects. You may not be currently in the field of “community relations and management”, but you may already have all the skills needed to teach and do the open source way inside and outside of software projects.

And you certainly don’t need to have come up through the Fedora Project, but that can’t hurt. Historically, we do what anyone would do – hire the people we know are great at doing the job we want done. Your work in Fedora should reflect that. If you have other open source project experience, it’s out there. If you’ve been practicing the open source way correctly, you’ll be able to show us that experience using open content in public archives.

Check out the job posting. I’m not in control of the process, but I think the location could be flexible for the right person, so it’s worth considering even if you don’t want to move to Raleigh and be our voice-in-the-seat-at-Red-Hat-HQ.

If you are someone who I would recommend anyway – so I would be biased toward you in a selection process – I’d be more than happy to pass you into our resume system with a recommendation.

(Updated to fix my incorrect interpretation of the job requirements; having worked in the Fedora Project already is a written job requirement.)

Partner Technical Evangelist

Red Hat has large cachet with upstream, open source developers, and our relationship with mainstream, corporate developers is fair but scattered. Strong in the Java area, nice developer studio, but what’s the cohesive story? How do we interact as a whole with software vendor (ISV) partners and developers who work for our customers?

It seems likely that the above job will interact and work in those areas. In fact, the role is described as rather senior – perhaps someone with the right skills and personality could wrestle serious improvements to the Red Hat developer experience for customers and vendor partners? This role is inside of the ISV ecosystem team probably because of a need for evanglism to ISV developers as well as customer developers.

When I use the term corporate developer, I mean the person who builds and supports applications that run inside of enterprises and SMBs, written by the staff for the staff. These are folks who are looking for:

• Best practices for developing on top of  Red Hat Enterprise Linux (RHEL).
• How to package and deploy software the Red Hat way.
• Tutorials on how to use developer-focused tools in a Red Hat environment, from JBoss through Eclipse to Red Hat Enterprise Virtualization (RHEV).
• Forums to find answers and ask questions.
• 24×7 non-interactive support and solutions, so they can get their work done at their own pace.

You or anyone you know interested in this sort of work? Contact me or just apply yourself.

“What’s wrong with the actual Fedora lists?” Robyn asked me. “We’re just not being very true to our roots when we have a special list just for Red Hat folken.” There’s a very real risk that people will reckon the list receives priority by other Red Hatters (it might, that’s the point!) and is elitist (“Too good for our lists, eh?”)

I don’t disagree with those concerns, and here’s what I’m thinking for reasons and mitigation:

1. People inside of companies using software to get their work done may perceive external community lists as outlaw places, as unsafe (because some discussion might touch upon confidential materials, devolve to attack/defend, etc.), and – honestly – scary unknown territory. Speaking with colleagues for support (“Hey, Jo, how do you …?”) gives people the feeling that the responsiveness of the community is going to be proper to the situation – no one other than a Red Hatter can know how important it is for Foo Bar from Sales to get her presentation to work on her Fedora 15 laptop. (That, I believe, would be the perception by people of why to use an internal-only list; hard to battle that perception without first getting them in to a  common forum – albeit a private one – to hammer out the real issues.)
   • For example, I know folks who first had to be hand-held through using internal IRC, then they got their entire teams to use it, and after a number of years, were willing and interested in venturing in to the open community IRC. I am confident that final step happened only because the earlier ones came first – for some people, the long-time in non-public space is perhaps the only way they’ll make the transition.
2. Desktop Linux users often get help from their local user groups, from special for-newbies-only mailing lists, and so forth. I would consider an internal fedora-users mailing list to be a similar, hand-holding gateway – ask questions here first, and if we can’t get an answer and need help from a Fedora list, either we’ll help you do that or ask for you.
3. If managers know their team members can ask questions on a private, confidential, internal list, they may be more likely to permit Fedora usage. Otherwise, there is little value in switching from the corporate standard build (CSB) of Red Hat Enterprise Linux (RHEL).
   • Sometimes people really do need the kind of software that can only be found in a latest Fedora. For example, I’ve heard from some of the big movie animation studios that while they run RHEL on their render farms, they may use Fedora on their desktops if a designer or developer needs what can only be found in a super-modern Linux distribution. Having support when you need, where you need it from, is a good thing.
   • Similarly, folks who aren’t paid to be available helping on external Fedora lists are in fact paid and empowered by Red Hat to help other Red Hatters. It would be great to get that help to happen out in the external lists, but maybe it just has to start somewhere else first.
4. Communities need private spaces, maybe this could be one?

I would make a goal of the list to be, help internal users to gain the confidence and competence to go the external community instead. The internal list could be a training community, and those who want to graduate go on to make other Fedora lists better with their experience and point of view.

For those of you who would love to see dozens or hundreds of Red Hat worker bees who run Fedora participating on the users@fedoraproject.org mailing list … this is the only way I can think of so far that might yield more of that.

Ultimately I’m asking all of you out here first because while I know other Red Hatters might like and use the idea, it is your perception that I can never adjust by just showing you the private archives to prove it’s a reasonable approach to take. If I’m going to ask you to take our word for yet-another-hallway-discussion-being-OK, I should at least ask you before I start the hallway discussion group.

I’m curious if your company or organization does something like this. What do you think of this idea? How could it be made better? How can I mitigate the risks more?

Comments are open.

Sustainable open source engineering refers to the process of supporting a collection of free/libre and open source software (FLOSS) over a very long period of time while following the open source way.  This means:

• Patches to the software collection must be pushed upstream where it makes sense; your engineers need to be the ones to know and make the call.  They are the ones who have to track and maintain the delta with the original upstream for many years.
• Provide a open mechanism for vendor partners and customers to collaborate on sustainability.
• Do all this in an open and transparent fashion.

Anything important not covered by this list?

Where a typical value of FLOSS is to allow for a small(er) investment as a contributor to yield a large(r) return as a user or vendor, sustainable FLOSS engineering turns this on its head.  The older the code base, the higher the cost to contribute.  Unless you happen to be already running the software because you are a customer or a vendor supporting that version, in which case the “obtain, install, understand” steps are already completed.  This is where the mechanism for collaboration comes to play.

Red Hat is the premier example of this.  While we get enormous value multipliers in resourcing current upstream projects and the Fedora Project, we commit enormous resources to sustaining Red Hat Enterprise Linux (RHEL) for seven years.  We’re so good at this practice that we routinely work with hardware and software vendors to train their engineers with our sustainable engineering teams.  If you have a big chunk of iron to support customers running RHEL on for seven years, you want your engineering teams to know how to collaborate on sustainable open source.

That should give you a hint of the example of other companies that practice this type of sustainable engineering.  Any large hardware (IHV) or software (ISV) vendor with products that customers run for more than a few years.  IBM and Hitachi, for example.

At this point I’ll note that fauxpen source/”open core”/dual-licensed-as-closed models are not good examples.  These are companies that are practicing business models that take some portion of their software source, usually an important part, and withhold it from being FLOSS.  Without a pure open source product chain, from R&D to sustainable-state, they are going to incur the costs of closed source development without the benefits of being at the center of a mechanism to collaborate with customers and partners.

What do you think are good examples of businesses practicing sustainable FLOSS engineering?

Do you have any interest in seeing Alfresco packaged for Fedora?  Having it in an EPEL repository for use in Red Hat Enterprise Linux v.5 (& v.4?) would be great …

Do you have any skill and experience at estimating how much work is involved in the packaging effort for Alfresco?

Recall that Fedora Release Engineering specifically recommends, 1.) get your package in JPackage.org, 2.) put it in Fedora, 3.) maintain it in both.  That’s the recommended way to prepare for the future, whatever it holds.

Why am I asking?  I’ll tell you …

Someone with a desire to see Alfresco packaged for their enterprise environment + willingness to invest resources has asked me about this effort.

The first thing I need to deliver is an estimate that lets them know if they should continue pursuing this route or pull back and do an ugly wrapper-package that doesn’t use system libraries and other horrenduous ugliness we don’t want them to suffer under.  You all know how it is …

This is a chance for a few dedicated folks to get together and produce a fine set of packages for a much-desired enterprise CMS.  If you are interested, leave a comment to this post, or contact me via the usual places.

What resonated most with me was the idea that my content may be licensed to remain open and accessible, but if the file system is not free and open, the writing and storage of that content is paramount to encoding it in a proprietary format.

This was the most compelling part of the discussion, the part that made me want to rip out proprietary hardware and file systems to replace it with anything more open.  The fact that my soup pot doesn’t usually include OpenSolaris, ZFS, etc. doesn’t matter to me.

Yes, I’m sure you can cook something similar right now with btfrfs and Fedora 11.  There is another angle to view, which is stability over time.  You want to be careful about putting your first-line storage on a development-quality file system.  With that idea … does it make sense to create a first-tier storage using Nexenta.org?  It is built from OpenSolaris, a robust, stable, enterprise-quality kernel plus ZFS, which has been deployed in the enterprise for a number of years? ZFS is also a few years older as a technology than btrfs.

Then use Fedora plus btrfs as second-tier.  The trick is, both work on commodity x86 hardware, so you can create a large first- and second-tier storage solution for a fraction of the cost of a propietary hardware and software blend.  That’s a bonus after freeing your content from a proprietary file system.

What if we had a tool that could take a proper Fedora RPM and build other targets such as ZIP files?  In the process, it would download and bundle the dependencies instead of relying upon system packages.

Why would we care?  Honestly, the only platform I care gets good packages is Fedora and friends.  If one of these ISVs customers is running Fedora, RHEL, or a RHEL clone such as CentOS, I want those customers to have a better RPM-based experience.  If those customers are running another OS, there is little I can do to help their experience, and we don’t have time to care.

But if I can make the ISVs lives easier, or at least no harder than before, that is a way we can help make Fedora-based distributions better.

Our argument that there it is a strategic investment to build good packages is falling on deaf ears.  The common viewpoint sounds like this: “Our customers are not demanding RPM packages, they don’t want to feel we are pushing a Linux-based solution of any kind, after all we’re Java and run anywhere, and have you looked at how hard it is to package Java apps for Fedora?”

From a business viewpoint, I understand.  Being able to convince them to re-engineer in the middle of the race is going to take a lot more understanding than I can give them in five minutes here and there.  So I got to thinking … if they ran Fedora or RHEL as a development, build, QA, and release engineering environment, but they could get an installer out the other side for any OS (ZIP, EXE, BIN, DEB, OpenSUSE RPM, Mandriva RPM) using some kind of magic ‘rpm2all’ tool, would that be compelling?

I know there is a lot more to it than I’ve described.  I bet the MinGW cross-compiler has something to do with it. They might still need to specify mapping details for the conversion or plug in a proprietary installer builder.

But just as an idea … what do you think?

In reading it, a number of inaccuracies and old school misconceptions leapt off the page at me (ouch!).  Unlike many modern online news and magazine outlets, there was no way to respond to the article, either in a comments section or to the author.  In the tradition of pundits everywhere, I’ll use my own bully pulpit to ask …

Have people not heard of Wikipedia?  Five minutes research there would have debunked most of the mistakes this author made.   The assumptions and tone made it sound as if he just asked a few people in the cubicles around him, “What’s the story with this Java stuff anyway?  What is open source?”  Unfortunately, the author, Eugene Bukoveczky, admirably free lances from Nova Scotia between bouts of wood chopping and bicycle riding (sounds like my kind of dude!), so he cannot blame his office mates.

Here’s a quick list of the inaccuracies, in the author’s own words, with the comments I would have put on his own article page if Investopedia (oh irony!) allowed them.

• ‘(S)o-called “open source” Linux software’ — When writers use the term “so-called” and then wrap the so-called term in quotes, it’s a way of double-insulating themselves from something that they don’t understand and fear will taint them by association.  Yeah, all that in the first sentence of the article.  FAIL by fear and lack of understandiing.
• “… Linux, a freebie operating system produced by legions of spare-time code junkies fueled by lashings of hot coffee, Red Bull, Jolt Cola or some other stimulant to tweak the creative juices” — We suppose at one time that was a semi-accurate description of Linux coding, but it’s been over fifteen years since actual Linux companies arose and began paying actual programmers actual money to do actually amazing work.  If you look at who actually contributes to the Linux kernel these days, you’ll see many familiar names that are i) public companies, and ii) doing quite well for some time.  Understanding that seems within the purview of an investment writer. Beyond that, most features of Linux that are crucial to success, from the file system to the graphical display, are coded by professionals doing real professional work … professionally.  Not sure about all the caffeine, but I can personally assure Eugene that I’ve met many developers, they are plenty creative to start with and caffeine is not what really drives them.  Finally, it’s a small point but an important one — Linux is not free-as-in-freebie, it is free-as-in-freedom.  The same kinds of freedoms that allow someone to call themselves an investment journalist without ever having to understand what they are writing about.  Again, all discoverable with reading a few Wikipedia articles.  FAIL by lack of clue and basic research skills.
  
• “Corporations get to profit from their efforts by giving away a cleaned-up package of this code, and making money from supplying service and maintenance contracts to their users.” — While the second half is roughly correct where it applies to just one or two open source business models, the first part is just silly.  Open source software companies are not typically freeloading on the backs of poor community members. Those corporations are contributing in the actual open source project, the code is already cleaned-up by the time it comes to QA efforts.  Any bug fixes from there go back to the upstream (rather, they should, if one follows an actual open source business model), so everyone gets the “cleaned-up … code”, not just the customers.  FAIL by misunderstanding what an open source business model actually is.
  
• “Linux has managed to capture about a 23% market share of the server market.” — Another assertion without reference or meaning.  Which server market?  Looking at the latest Netcraft count of just web servers, open source clearly dominates, with Linux a sizeable portion.  Animation studios, such as Pixar, Disney, and Dreamworks?  95% of their servers are Linux.  No “dominant” Microsoft servers there.  FAIL by assumption and misunderstanding generic data.
  
• “Sun has championed Java, the programming language preferred by most Linux users …” — While I’m sure “most Linux users” would disagree, and there is plenty of data to show what languages are preferred, that is not the true irony of this sentence.  The irony is, Java is the programming language preferred by enterprise and corporate developers who are not working on open source at all.  FAIL by misunderstanding enterprise market.
  
• “The move (Oracle acquiring Sun) has also being interpreted as the first step in a much needed consolidation process for the entire Linux market.”  Assertion without reference, and his inability to understand and analyze accurately makes this a very dubious statement.  “Much needed”? Says who?  FAIL by assumption.
  

Much failure all around.  I am now stupider for reading the article, and hope my own writing effort has raised my intelligence score back up a point or two.

• Support for how and why to invest resources in open source
• A cluebat about why your organization should participate in upstream projects

… then send them to Esplanade 302 for my 11:50 am session this Monday 01 June, the first day of CommunityOne.  I’ll be presenting ‘Participate or Die‘, which is my more aggressive talk that shows real numbers, reasons, and evident truths about why you must participate in open communities that matter to your person and business.  Or, well, die.

If you intend to still be in business in the next few years, now is the time to take the proper strategic view about your participation and contribution to open source projects.

This is Sun’s CommunityOne event that happens concurrently with JavaOne.  However, I’m aware that this is also Oracle’s house, and the last time I was at the Moscone Center when it was Oracle’s house our host did not treat us very nicely.  I expect better treatment this year, but just in case, I’ll be packing my Unfakeable Linux t-shirt.

To make things really clear, though, I’ll be appearing in one of my favorite t-shirts, the VA Linux Systems one that says, “Open source. It’s the difference between trust and antitrust.” (Close-up of shirt back and what it looks like on a smart thinker.)

From Wednesday 08 April to Friday 10 April, I was in fabulous and mildly-rainy San Francisco to attend the Linux Foundation Collaboration Summit. I hadn’t spent that much time in Japan Town, it was cool to walk through the streets and catch bits of a Japanese-in-San Francisco history walking tour signs. The hotels and conference site were all within a few blocks of each other.

The summit was a meshing of multiple mini-conferences, including an embedded Linux summit.  This brought a wide range of Linux-related developers to one location and gave them reasons to intermingle.  The first day I was there (Wednesday) was a middle-of-the-summit day for some, and a chance for all to pause and take part in general interest topics in the main hall.  These included a final three-way discussion with Jim Zemlin of the Linux Foundation, Ian Murdock of Sun, and Sam Ramji of Microsoft, titled, “Why Can’t We All Just Get Along?”

As usual, I ran in to old friends (e.g. Elena Zannoni, still Queen of GCC tools, and Pete Graner, still one of the best engineering managers you’ll ever know) and made new ones (e.g. Jeff Osier-Mixon, who was there pimping Montavista’s new embedded linux community, Meld.)   Jeff and I talked for a long while about community affairs, and ‘best community practices’  was a theme for my time spent there.  I got the down-low invite to the Community Leadership Summit, since announced.

One role the Linux Foundation has been filling better in the last few years is being a catalyst between Linux developers, especially kernel, embedded, etc. and the companies that employ the contributors or deeply rely upon the contributions. I overheard a few embedded Linux developers saying that the Ottawa Linux Symposium (OLS) was down their list this year and got cut with travel budget considerations. That doesn’t mean OLS is not relevant, but that it has some competition in meaningful Linux developer conferences.  This is more a recognition that there is a gap to be filled here, one that a foundation traditionally fills as a neutral entity between otherwise competing interests, and the Linux Foundation is filling that gap.  This creates a gravity that can draw in or away from independent efforts.

Since simply networking with other free software folken isn’t enough, I was also  there to talk on a panel about measuring community contributions, which I covered in another article.  I also signed up to do what I could to help Tim Waugh prevent tragedies at the OpenPrinting Summit, a task which I and Tim largely failed at.

The OpenPrinting group met to work on improving printing in Linux with the typically laudable goal of “just work.”  They have come to a solution they feel is a good interim step toward an undefined future.  They are going ahead with plans to provide an automagic way of downloading and using proprietary printer drivers from within the printing dialogs.  This situation is analaguous to providing a way to access proprietary multimedia codecs, which Fedora tried to solve with CodecBuddy, one of the greyer parts of the project’s history.  I felt that mistake was made and lesson well (l)earned.

This automagic tool gives the printer manufacturers a way out instead of doing the right thing, that is, working on opening printer drivers or at least opening their standards so equivalent free drivers can be implemented.  I was just lurking in person while Tim was on the conference call, but I had to interrupt the meeting to make sure all there understood.  Their plan to write an application with the sole purpose to download and use/install proprietary code was not going to have an easy time passing Fedora package review.  In the end, the only thing it can deliver in Fedora are free drivers, and those are or should be packaged and already in the distro.

Even if the tool does make its way to Fedora, it still may not make it in to the next version of Red Hat Enterprise Linux, and even if there, the printing companies are still likely to negotiate individually with Red Hat to get proprietary drivers available in RHEL.  Nobody there seemed to have a problem with this.

I did not walk away feeling the state of printing in Linux was improved with this situation, although I’m sure millions of users will disagree with me.  Don’t those users realize this is a bandage over the situation that is made this way because of the printing manufacturers?  A bandage does not heal a wound or remove an infection.  Instead of a holistic solution that treats the whole body, we have a festering wound that is going to require surgery one day.

Based on our rapt expressions, I reckon James Bottomly was saying something smart and insightful.