Being the Old One

Posted by Jim Jagielski on Thursday, April 23. 2015 in ASF

This may come off as "sour grapes", or being defensive, but that's not that case. Instead, it's to show how, even now, when we should know better, technological decisions are sometimes still based on FUD or misinformation, and sometimes even due to "viral" marketing. Instead of making a choice based on "what is best for us", decisions are being made on "what is everybody else doing" or, even worse, "what's the new hotness." Sometimes, being the Old One ain't easy, since you are seen as past your prime.

Yeah, right.

Last week, I presented at ApacheCon NA 2015, and one of my sessions was "What's New In Apache httpd 2.4." The title itself was somewhat ironic, since 2.4 has been out for a coupla years already. But in the presentation, I address this up front: the reason why the talk was (and is) still needed is that people aren't even looking at httpd anymore. And they really should be.

Now don't get me wrong, this isn't about "market share" or anything as trivial as that. Although we want as many people to use Apache projects as possible, we are much more focused about creating quality software, and not so much about being a "leader" in that software space. And we are well aware that there are use cases where httpd is not applicable, or the best solution, and that's great too.

First of all, there is still this persistent claim that httpd is slow... of course, part of the question is "slow how?" If you are concerned about request/response time, then httpd allows you to optimize for that, and provides the Prefork MPM. Sure, this MPM is more heavyweight, but it also provides the lowest latency and fastest transaction times possible. If instead you are concerned about concurrency, then the Event MPM is for you. The Event MPM in 2.4 has performance equal to other performance-focused Web Servers, such as Apache Traffic Server and NGINX. Even so, whenever you hear people talk about httpd, the first thing they will say is that "Apache is slow, where-as 'foo' was built for speed."

There is also the claim that httpd is too feature-full (or bloated)... Well, I guess we could say "guilty as charged." One of the design goals of httpd is to be a performant, general web-server. So it includes lots of features that one would want, or need, at the web-server layer. So yes, it includes caching, and proxy capability, and in-line content filtering, and authentication/authorization, and TLS/SSL (frontend and reverse-proxy), and in-server language support, etc... But if you don't need any of these capabilities, you simply don't load the modules in; the module design allows you to pick and choose what capabilities you do, or don't want, which means that your httpd instance is specific to your needs. If you want a web-server with all the bells and whistles, great. But if you want just a barebones, fast reverse proxy, you can have that too. Of course, I won't go into the irony of httpd being "blasted" for being bloated, while the hotness-of-the-day is praised for adding features that httpd has had for years. *grin*

Finally, we get to the main point: That Apache httpd is old, after all, we just celebrated our 20th anniversary; httpd is "old and busted", Foo is "new hotness"(*). Well, again, guilty as charged. The Apache httpd project is old, but httpd itself isn't. It is designed for the needs of today's, and tomorrow's, web: Async/event-driven design (if required), dynamic reverse-proxying with advanced load-balancing (and end-to-end TLS/SSL support), run-time dynamic configuration, LUA support (module development and runtime), etc...

You know what else is old? Linux.

Makes you think, huh?

More...

Open Source Has Won The Battle; Let's Not Lose The War

Posted by Jim Jagielski on Friday, April 17. 2015 in Open Source

The below is an abstract for a talk...

Open Source Has Won The Battle; Let's Not Lose The War

20 years ago, a bunch of us got together and created Apache, and then 5 years later went ahead and created The Apache Software Foundation. The idea of Open Source back then was weird, and wild, and suspect. But due to the power and capability of the Apache Web Server, in combination with Linux, Open Source gained traction, acceptance and now ubiquity.

Looking around at the IT landscape nowadays, Open Source is found everywhere. Software is eating the world, and Open Source is the utensil of choice. Corporations once critical of Open Source, now embrace it; Open Source is now both strategic and mandatory. In many ways, one could assume that Open Source has won.

Well, maybe it has won, but it's just won the battle; the war is still there, and our success in winning the battle is threatening to cause our loss of the war. 

"It's on Github, so of course it's Open Source, right?" Wrong.

"It's got an OSI license, so nothing else is needed, right?" Wrong.

"There's nothing wrong with paid developers/contributors, right?" Well... maybe yes and maybe no.

"What is really the matter with pay-to-play Open Source foundations?"  Give me 30 minutes or so, and I'll tell you what the risks are.

There's an old saying that in Open Source, developers/contributors scratch their own itches. But what about today? Do they still? Can they still? And what is the ultimate harm if they can't. And as more and more Open Source gets funded, directly, by corporations, where does that leave the true volunteer contributor? And finally, who really has the ultimate control over a project's destiny?

This presentation will give a short history of the Open Source movement, and why the most critical forces behind its success in being an innovation engine may be at risk. 

More...

Telaen 2.0 Status

Posted by Jim Jagielski on Monday, January 19. 2015 in Programming

As noted in a previous blog post, I've started working on the 2.0 version of Telaen: a simple but powerful PHP-based Webmail system. Quite a bit has been changed, fixed and added under-the-covers, including baselining PHP 5.4, a more robust installation checker, and some significant performance increases.

However, as I was working to make the backend stuff as up-to-date as possible, it became increasingly obvious that Telaen's UI was extremely dated. It was functional, yes, but made very limited use of CSS, HTML5, Javascript, etc, all of which combine to affect the user experience. Luckily, a very good friend of mine, Mike Hill, has started work on a new UI for Telaen, making it not only more streamlined and attractive, but also much more functional as well.

Now I know, of course, that there are a number of other PHP webmail offerings out there, so some may be questioning the need for yet another. I can think of a few reasons:

  • Telaen is designed to have as few dependencies as possible; the goal is that any typical PHP setup will be able to run Telaen.
  • No external database is required.
  • Extensive support for both IMAP and POP; to be honest, most webmail systems don't support POP at all, or are extremely limited in their support.
  • Consistent functionality, no matter which IMAP/POP server is used; most webmail systems are simple "front ends" for IMAP servers, meaning the capability of the webmail system depends on what IMAP server is being used. Telaen puts that capability within the webmail system for a consistent feature set.
  • Fast caching
  • Designed to serve as both someone's primary Email client, as well as their supplemental client.
  • Lots of what you need/want, and none of what you don't: Telaen is as simple as it can be, but no more so.
  • A fast and secure upgrade path for all those people still using UebiMaiu
  • Open to ALL contributions!

The last point is important: we really want as many people as possible to use, contribute, drive and develop Telaen. It's a great project for someone just starting out as well as for more experienced developers. Or if your passion is documentation, we could definitely use your help! In fact, however you want to be involved, we want to welcome you to the project.

Our goal is to have a beta available sometime within a month's timeframe. Stay tuned!

More...

Open Source and Trademarks

Posted by Jim Jagielski on Tuesday, November 11. 2014 in Open Source

In any area of business and activity related to business, the idea behind, and protection of, trademarks is critical. But what some people don't understand is that in the Open Source/Free Software world, trademarks are, in many ways, the only real asset that a FOSS project has.

Think about this: in most normal areas of software development, the software itself (the code) is intellectual property. It is itself an asset, with value. But in an open source world, the code is free and open to all. "Having" the code isn't any sort of asset, since anyone can also have it as well; in fact, it is encouraged to share that code with as many people as possible. So whereas in other circumstances, the resulting work behind the effort of coding is an "asset", and, in many ways, the most valuable asset, with FOSS projects it is the least valuable.

So what is the main asset of a FOSS project?

The trademark. The brand and goodwill associated with that project. And for many projects, it's the only asset, and it's the main reason why people contributed to, and use, the code. For example, one significant reason why projects enter the Apache Software Foundation is that they want to leverage and benefit from the Apache brand. Being an Apache project automatically gives a project a sense of credibility, as well as a promise on how it will be governed and managed, and how code provenance will be done. It is a reputation obtained from years and years of doing things the right way; The Apache name means something. It has become a brand.

With this in mind, it should be somewhat obvious why FOSS projects walk that fine line between wanting (and needing) to protect their trademarks (and brand) yet, at the same time, allowing people to use those marks in as unrestricted ways as possible. On one hand, you want to use that brand to encourage even wider sharing and usage of the code, yet on the other hand, you must protect those marks from usage which would damage the brand, or confuse people. And so most FOSS projects or foundations create trademark policies that describe acceptable and unacceptable usage.

So I was shocked and extremely disappointed to hear that GNOME is having to battle Groupon over Groupon's unacceptable use of the GNOME mark. There are only 2 possible ways this could have come about:

  1. Those at Groupon tasked with this effort are so incompetent and clueless that they never heard of GNOME
  2. That Groupon is simply thumbing their noses at GNOME and, by extension, the entire FOSS community as well.

This is totally unacceptable, and is, IMO, an attack on all FOSS projects and foundations. When well-funded corporate entities, especially those who directly benefit from FOSS, go ahead and simply decide they can steam-roller over the FOSS community, it is time for all of us to take a stand. Help GNOME defend their mark!

More...

Open Source and Trademarks

Posted by Jim Jagielski on Tuesday, November 11. 2014 in Open Source

In any area of business and activity related to business, the idea behind, and protection of, trademarks is critical. But what some people don't understand is that in the Open Source/Free Software world, trademarks are, in many ways, the only real asset that a FOSS project has.

Think about this: in most normal areas of software development, the software itself (the code) is intellectual property. It is itself an asset, with value. But in an open source world, the code is free and open to all. "Having" the code isn't any sort of asset, since anyone can also have it as well; in fact, it is encouraged to share that code with as many people as possible. So whereas in other circumstances, the resulting work behind the effort of coding is an "asset", and, in many ways, the most valuable asset, with FOSS projects it is the least valuable.

So what is the main asset of a FOSS project?

The trademark. The brand and goodwill associated with that project. And for many projects, it's the only asset, and it's the main reason why people contributed to, and use, the code. For example, one significant reason why projects enter the Apache Software Foundation is that they want to leverage and benefit from the Apache brand. Being an Apache project automatically gives a project a sense of credibility, as well as a promise on how it will be governed and managed, and how code provenance will be done. It is a reputation obtained from years and years of doing things the right way; The Apache name means something. It has become a brand.

With this in mind, it should be somewhat obvious why FOSS projects walk that fine line between wanting (and needing) to protect their trademarks (and brand) yet, at the same time, allowing people to use those marks in as unrestricted ways as possible. On one hand, you want to use that brand to encourage even wider sharing and usage of the code, yet on the other hand, you must protect those marks from usage which would damage the brand, or confuse people. And so most FOSS projects or foundations create trademark policies that describe acceptable and unacceptable usage.

So I was shocked and extremely disappointed to hear that GNOME is having to battle Groupon over Groupon's unacceptable use of the GNOME mark. There are only 2 possible ways this could have come about:

  1. Those at Groupon tasked with this effort are so incompetent and clueless that they never heard of GNOME
  2. That Groupon is simply thumbing their noses at GNOME and, by extension, the entire FOSS community as well.

This is totally unacceptable, and is, IMO, an attack on all FOSS projects and foundations. When well-funded corporate entities, especially those who directly benefit from FOSS, go ahead and simply decide they can steam-roller over the FOSS community, it is time for all of us to take a stand. Help GNOME defend their mark!

More...

Page 52 of 55, totaling 273 entries

Quicksearch

Search for an entry in IMO:

Did not find what you were looking for? Post a comment for an entry or contact us via email!