Skip to content

Boards and stuff

Note: The below may sound "self-serving" and kinda egotistical, and for that I'm sorry. This just seems the easiest way to get the message out there. 

For awhile now, I've been unable to accept any offers to join the board, or the technical or community advisory committee, of any foundations or start-ups/companies (as a volunteer, of course). This wasn't due to any conflicts, nor any lack of desire to participate, but rather a real recognition that I simply lacked the cycles to put into the effort to my own satisfaction. I take these positions, and especially the duties associated with them, extremely seriously; I don't accept them simply to "pad" my CV, but in order to make a real contribution... a real difference. And up to now, I simply have lacked the free time to do so. And this was kind of sad, and I was really sorry to not be able to accept, because some of those roles were incredibly cool.

With summer winding down, I'm happy to say that I've taken some time to better organize my free time, such that the above is no longer the case. So if someone like me would be an asset for your board, or a valuable resource to your technical/community advisory committee, ping me and let's see how I could help.

Constructive Criticism

My previous post (Why I won't be going to OSCON this year) generated a lot of twitter comments and a lot of private feedback, mostly agreeing with my points and one actually calling me "brave" for making such a post. I'm not so sure about the "brave" part, but I think I kind of made it obvious that the post was my own personal opinion as well as that shared by many others. It was a grieving  for the OSCON that was and a lament on what it has turned into.

One tweet however confused me. In it, I was told that my post wasn't "constructive". I really don't see how that was the case. It seemed to me kinda obvious on what suggestions I was making, but to make it crystal clear, and easy to grok, let's list them, shall we.

  1. The speakers are different:
    My complaint is that most speakers were not the actual developers behind the projects. The solution is obvious: have more developers as speakers. When someone is talking about the architecture behind some code, I want to hear about it from the person who designed it.

  2. The audience is different:
    Here I was lamenting the skew of the audience away from the technical and more towards the business/marketing point of view. By having parts of OSCON actually be concerned about the tech, the audience might just skew back to something more reasonable.

  3. The speakers are the same:
    This one is real easy. With a conference as large as OSCON, and with a conference that obviously gets a huge number of session and speaking proposals, the fact that a large portion of speakers are the same from year-to-year is either laziness or favoritism or fear-of-change. For a conference around open source, which is all about energy, enthusiasm, building community, creating opportunities and the need for change, that mindset is really counter to the core. Solution: Mix it up regarding the speakers.

  4. The cost is burdensome:
    Another easy one. Reduce the cost. Make it easier for students and the pure volunteer open source contributors to attend. Use some of the huge sponsorship funds to reduce ticket prices. Help foster the next generation of open source enthusiasts.

As someone mentioned, most people go to OSCON today for the "hallway track" and as a social excuse to meet up with old friends and colleges. These later years, that's why I went, as well as for the occasional worthwhile (IMO) session. And I agree that conferences are a social event, and should be. But when it becomes the sole or primary reason for a conference, then maybe that conference needs to be re-thought (At Apache, we had this some exact issue with ApacheCon, resulting in our changing producers and re-focusing on outreach and info for a larger audience).

In the first post I specifically said that it wasn't meant to dissuade anyone from attending OSCON. It was a listing of why I (and others) don't go, with a specific set of reasons behind that decision. That certainly sounds like constructive criticism to me, at least to anyone actually willing to listen.

Why I won't be going to OSCON this year.

OSCON is next week, but if you are looking for me, I won't be there.

The "why" behind that decision is kind of complicated, but it's a decision that has been brewing for quite awhile.

First of all, however, don't take this as some sort of post designed to convince you to not go; that is not my intention. It's just an explanation of why, at least for me and others, OSCON is no longer one of the "Must Attend" conferences of the Open Source world.

  1. The speakers are different:
    Back in the day, pretty much every speaker was one of the core developers behind the open source project they were talking about. This made OSCON a great opportunity to learn about the project from the experts: the people who actually wrote it, people who were intimately involved. Not so much anymore. More than likely, presentations will be made by "community managers" or marketing folks from companies leveraging the project. Ask them a technical question and the answer you'll get is "Give me your name and number and I'll have one of our developers get in touch with you."

  2. The audience is different:
    It seems to me that the vast majority of the audience aren't really developers, and if they are, they aren't there as developers. They are there to be seen or marketed by their companies ("Be sure to wear a company t-shirt!"), or they are there to hang out with their old buddies. Few are there to learn (mostly because the content is simplified) or hone their skills. There also aren't many people there who are interested in "learning what this whole open source thing is about" or even "what this open source project is about". No, it seems that most of the audience are marketing people, or people hoping to make business connections.

    Now don't get me wrong here. When I attend a conference and my employer is footing the bill, the least I can do is wear a company T-shirt and make sure that my employer gets the recognition and credit they deserve. Nothing bad or unacceptable about that. But when you are there only as a prop, well, something is amiss. And sure, I also understand how the success of open source is based on the acceptance of it by companies (heck, the whole idea of the term "open source" was to make it more palatable to corporate interests), so I have nothing against marketing and business alliances either. It's just that, at least for me, OSCON isn't the place for it, at least to the extreme that it is today. Unless you are in Marketing or Strategic Alliances, what does OSCON actually hold for you?

  3. The speakers are the same:
    Read through the list of speakers. Now compare it with last years list. Sweet Sassy Molassy that's a lot of repeats! In fact, there are a large number of names that you can be pretty much guaranteed to be speaking year after year. Really? It's become almost a joke submitting a talk; unless you are one of the blessed, your talk must be exceptional and direct and non controversial. The "usual group" can submit anything they want and it'll be selected; the unwashed masses? Good luck.

  4. The cost is burdensome:
    The reason why OSCON is mostly a business-related conference is because with the amount of money it costs to attend, it is really out-of-reach for "regular" people. The only way people can attend is if their company picks up the bill. Hardly a good way to build a grass-roots community.

So what conferences do I go to and enjoy? Well, there is ApacheCon, of course. But there are also POSSCON and All Things Open. These are great conferences because they have a true mix of speakers and attendees, where speakers are there to teach, and attendees are there to learn. More than OSCON, these conferences are, IMO, an accurate reflection of the open source ecosystem, as it is and as it should be; they embrace all aspects of the open source community.

So no, I won't be at OSCON this year. But if you do attend have fun and drink a pint for me.

Being the Old One

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?

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

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. 

Telaen 2.0 Status

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!

Open Source and Trademarks

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!

Open Source and Trademarks

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!

Starting on Telaen 2.x

After a somewhat long sabbatical, I'm energized about rebooting the Telaen Project.

Partly, this is due to jaguNET migrating to using Dovecot for both POP3 and IMAP, and the realization that an upgraded webmail system would be the perfect compliment. Now for sure, Telaen is a great PHP-based webmail system, and, in fact, has served (from what I can tell) as inspiration and source for numerous other webmail systems as well (such as T-Dah Webmail, for example), but I had let it lay fallow for quite awhile and, well, it's showing its age. And to be honest, except for some of the larger, and more complex and dependency-ridden offerings out there, it seems that no real PHP webmail packages are being actively developed.

So, I've gone ahead and create the telean_1.x branch and master on the git repo will be the source of Telaen 2.0 development. In no particular order, I plan the 2.0 version including the following:

  • Removal of PHP4 support and baselining PHP5.3 at a minimum.
  • Faster indexing by utilizing sqlite3 instead of PHP arrays
  • Better and more complete IMAP interaction
  • Better SPAM handling, especially related to auto-population of the Telaen internal SPAM folder (right now, if the user creates a real, IMAP SPAM folder, Telaen gets awfully confused)

In all cases, the design goals of keeping Telaen as simple and streamlined as possible, and avoiding as many dependencies as possible, will be kept and honored. In fact, the only dependency "added", that I can foresee at this time, is sqlite3 capability, which is default for PHP5.x anyway. However, I do plan on adding some hooks so that if people want to use MySQL or Postgres, they will be able to.

If interested, check out the Github page, and help develop the code, add features or wish lists, find and patch bugs, etc... 

Lack of civility

Over the last several weeks, much copy has been created over the lack of civility in various communities: Open Source, gaming, etc...

Now, I'm not a gamer, but I am a person seriously involved in the FOSS community, and I see some parallels between the issues involving all of these communities, and I have some thoughts and possible insights to share.

First of all, what I see is a significant lack of civility. Not only in what is being said, but also in how it is being said and, almost most unsettling of all, that if there is a way for someone's statements to be misconstrued in the most unattractive/unpopular/controversial fashion possible,  that's the way it will be seen (in other words: the other party doesn't receive the benefit of the doubt: you must prove that you are not an asshole; it's not assumed that you aren't).

Now certainly the anonymity of mailing lists, twitter, etc all help in that, but mostly, IMO at least, it's also due to people forgetting that there is a real live human being behind that Email address or twitter handle

The second issue I see is that there is no longer a desire to have a discussion or a conversation, per se, but rather it's a contest, a war, in which the sole desire is to win, and make the other side lose. In doing so, we don't listen, instead we are planning and plotting our response. And, because winning at all costs is important, the ends justifies the means. If we have to create strawmen, well, as long as we win (or, at least, they lose), that's OK. Of course, in matters that we have deep feelings and concerns for, it's hard to keep emotions out of it. After all, if someone calls my kids stupid, I will "fight" to ensure that no one walks away with the mistaken impression that somehow that position is correct, or right, or warranted. But very few things are really that personal, we just make them so.

Closely related to the strawmen method noted above, is that in most discussions other "baggage" (for lack of a better term) is brought in. This baggage is only remotely related to the discussion at hand, but it is a powerful, polarizing artifact, and serves to either focus the discussion on that issue or, most of the time, implies that being for one position implies being against another (which you would not agree to at all). For example, in a recent "discussion", I noted that "actions have consequences". Certainly this is something that we can all agree with, right? After all, our legal system is based on it, parents instill this concept to their children, religions are based on it, etc... But, that simple statement somehow implied that I was OK with "blaming the victim". So instead of simply seeing and understanding what I said, instead a position was forced upon me, a position that I would never take. And I had to prove that I was not a "victim blamer".

It is sad when activities which started off as, and are supposed to be, fun and enjoyable degrade into "contests" and battles in which people have to "expect" harassment, ridicule, threats, etc. All these technologies were supposed to bring us together, not provide ammunition and resources for dipwads  and psychopaths to destroy one's happiness and life. If you are involved in a community, it is your responsibility to make sure that poisonous people are not allowed. That's why I am so proud of the communities we've created at Apache, after all, our unofficial motto is Community Before Code. We aren't perfect, to be sure, but I think we have some insights that other communities could benefit from.