The Apache Software Foundation Blog

Thursday April 02, 2020

Announcing New ASF Board of Directors

At The Apache Software Foundation (ASF) Members' Meeting held this week, the following individuals were elected to the ASF Board of Directors:

  • Shane Curcuru (re-elected Director)
  • Bertrand Delacretaz (former Director)
  • Roy Fielding (former Director)
  • Niclas Hedhman (new Director)
  • Justin Mclean (new Director)
  • Craig Russell (re-elected Director)
  • Sam Ruby (former Director)
  • Patricia Shanahan (new Director)
  • Sander Striker (former Director)

The ASF thanks Danny Angus, Rich Bowen, Ted Dunning, Dave Fisher, Myrle Krantz, Daniel Ruggeri, and Roman Shaposhnik for their service, and welcomes our new and returning directors.

An overview of the ASF's governance, along with the complete list of ASF Board of Directors, Executive Officers, and Project/Committee Vice Presidents, can be found at http://apache.org/foundation/ 

For more information on the Foundation's operations and structure, see http://apache.org/foundation/how-it-works.html#structure 

# # #

Tuesday March 31, 2020

Inside Infra: Chris Thistlethwaite

"Inside Infra" is a new interview series with members of the ASF Infrastructure team. The series opens with an interview with Chris Thistlethwaite, who shares his experience with Sally Khudairi, ASF VP Marketing & Publicity.




"I get very attached to the technology that I'm working with and the communities that I'm working with, so if a server goes down or a site's acting wonky, I take that very personally. That reflects on how I do my job.



Let’s start with you telling us your name --how is it pronounced?

It’s “Chris Thistle-wait” --I don’t correct people who say “thistle-th-wait”-- that’s also correct, but our branch of the family doesn’t pronounce the second “th”.

What’s your handle if people are trying to find you? I know you’re "christ" (pronounced "Chris T") on the internal ASF Slack channel.

Yeah --anything ASF-related is all under "christ".

Do people call you "Christ"?

They do! I first started in IT around Christmastime and was doing desktop support and office-type IT. When people started putting in tickets, and my username  was "christ" there, they were asking "why was Christ logging into my computer right now?" and it became a thing. When I was hired at the ASF I told Greg (Stein; ASF Infrastructure Administrator) about that story, he said "you gotta go with that for your Apache username."

When and how did you get involved with the ASF?


A long time ago I started getting into Linux and Open Source, and naturally progressed to httpd (Apache HTTP Server). Truth be told, that’s where it started and stopped, but I’ve always been interested in Open Source and working with projects and within communities. Three years ago I was looking for a new job and stumbled across the infra blog post for a job opening. I fired up an email, sent it off to VP infra and that’s how everything started. The ramp up of the job was diving deep into everything there is with the ASF and Open Source --which I am still diving. I don't think I found the bottom yet with the ASF.


How long have you been a member of the Infrastructure team?


This November will be my fourth year.


What are you responsible for in ASF Infrastructure?


Infrastructure has a whole bunch of different services that are used by both Apache projects as well as the Foundation itself: the Infrastructure team builds, monitors, supports, and keeps all those things running. Anything from Jenkins to mailing lists to Git, SVN repositories and on the back end of things we keep everything working for the Foundation itself within, say, SVN or mailing lists, keeping archives of those things, keeping your standard security and permissions set up and split out. Anyone you ask on the Infra team will say: "I do everything!" It's too hard to explain --it's quite possibly a little bit of everything that has anything to do with technology --as broad as it can possibly be.


So you really have to be a jack-of-all-trades. Do you have a specialty, or does everybody literally do everything?


Everyone on the team generally does everything --for the most part any one of us can jump into the role of anyone else on the team. Everyone has a deep knowledge of a particular or a handful of services that they’ll take care of --like, Gavin (McDonald; ASF Infrastructure team member) knows more about Jenkins and the buildbot and build services than most people on the team. At any one given point we’re on call and need to be able to fix something or take a look at something, so everyone needs to be versed enough in how to troubleshoot Jenkins. That can also be said for not just services that we offer, but also parts of technology, like MySQL or Postgres or our mail system or DNS: we do have actual physical hardware in some places, and we have VMs everywhere too, so sometimes we’re troubleshooting a bad backplane on a server or why a VM is acting the way it is. There's a very broad knowledge base that all of us have but there are specifics that some people know more about than others.


How does ASF Infrastructure differ from other organizations?


There are a lot of similarities but a ton of differences. A big part of how Infra is different is, to use a "Sally-ism": if you look at it on paper, it wouldn't work --I've heard you describe the ASF that way. If you explained the way things work at the Foundation to somebody, they would literally think that you're making it up and there's no way that it would possibly be working the way that it does. There's a lot of that with the Infrastructure team too: many people that I keep in contact with that I've worked with over the years, from my first job where we would buy servers, unbox them, rack them, wire them up, set them up, and run them from the office next door to us --I'd be impressed whenever I had 25 servers running in our little "data center" at that job, and now I talk to these guys about what we do at the ASF: we have 200 servers in 10+ different data centers that are vendor-agnostic and we make it all work. They ask: "how the heck do you do that?!" We just do --it's an interesting thing as to how it all works together because we solve problems that others have as well, but their problems are often centralized to one thing, or a data center that they control and own, or one cloud provider that they control and own, where they deal with a single vendor and possibly at most have to talk with the same vendor in two different geographical areas. We're having to deal with stuff with one cloud vendor that's a VM and other stuff on the other side of the world that's actual hardware in a co-location or data center running and the only thing that makes them the same is that they're on the Internet.


It's a good summation of the team too due to the fact that we’re all based out of worldwide locations, we’re not all in one spot doing something.


Describe your typical workday. Since you're all working on different things on such a huge scale, what's it like to be you?


"It's amazing" [laughs]. Everyone on the team generally has some project or projects that they are working on --long-running things for Infra. 


I'm currently working on rewriting a script for Apache ID creations. The process of putting your ICLA in, sending off to the Secretary, the Secretary says, "OK good," puts in all your data, and that gets put into a file in SVN ...currently, we have a script that we manually run that does a bunch of checks on the account and whatnot, and then creates it, sends off a welcome email, whatever. I'm rewriting that because it's an old script, it's in several different languages. It's actually six scripts that all run off of one script. Consolidating that into one, massive script, that's in a supported language for us, and then moving forward with it into something that we could potentially automate, versus me having to run a script manually a couple of times a day.


Fluxo (the ID/handle for Apache Infra team member Chris Lambertus) was working on some mail archive stuff in our mail servers. Gavin (Apache Infra team member Gavin McDonald) is working on some actual build stuff. Everyone has kind of "one-two punch" tasks that they work on during the day, and then the rest of the time is (Jira) tickets or staying on top of Slack, if people are asking questions in the Infra channel or in our team channel or something like that. The rest of it is bouncing around inside the ASF and checking things out, or finding out new projects to work on, or ways to improve such-and-such process. 


How many requests does Infra usually receive a day, in general?


Over the past three years, we've resolved an average of 6 Jira tickets a day, year-round. We've had 213 commits to puppet repositories in the last 30 days. We handle thousands of messages on our #asfinfra Slack channel, and have had 659 different email topics in the last year.


Dovetailing that, how do you keep your workload organized?


Everyone on the team does it their own personal way. I have a whiteboard and a Todoist list. We also have Jira to keep our actual tickets prioritized and running. We have a weekly team meeting/call and talk about things that are going on, and is the more social aspect of what we do week-to-week.


How do you get things done? You're juggling a lot of requests --what's the structure of the team? How do you prioritize when things are coming in? Is there a go-to person for certain things? If you're sharing everything, how do you balance it and who structures it? How does that work? 


To one end, the funnel to us starts with Greg and David (ASF Infrastructure Administrator Greg Stein and VP Infrastructure David Nalley). It's different from other places that I've worked, where I'm on a team of other systems administrator/engineering people, and we have a singular, customer-facing site. Someone says, "Hey, this should be blue instead of red," there's a ticket and we make the change and then it goes to the production.


There're many different ways to get a hold of the Infrastructure team. Everyone gets emails about Jira tickets and gets updated as soon as one of those comes in. If it's something that you know about --say, the Windows nodes that we handle-- those all fall into my wheelhouse because I'm the last one to work with Windows extensively. Everyone else knows how to work with them, but it makes more sense for me to pick it up in some cases. 


Most of the stuff in Jira are very "break-fix" kinds of things. A lot of the requests on Slack are too, for example: "DNS is busted," and we fix DNS. It's a very quick, conversational, "Let me go change that," or, "I'm going to go fix that real quick." Of course, some of the Jira tickets are very long-running, but the end result is they're fixing something that used to work. 


We were originally running git.apache.org, and Git WIP, so we hosted our own internal Git servers and we would read-only mirror those out to GitHub. Somewhere along the line, Humbedooh (the ID/handle for Apache Infrastructure team member Daniel Gruno) started writing out Gitbox or building Gitbox based on the need to have writable GitHub repositories. He built Gitbox and set up with the help of some other people on the team, got it going, and that became our replacement for git.apache.org. While we still host our own Git repositories, people are free to either write to ours or write to GitHub, and the changes are instantaneously mirrored between the two.


We had Git hosted at the ASF, and had GitHub as a read-only resource. The need arose to have rewrite on both sides: Humbedooh went and built out MATT (Merge All The Things), which does all of the sync between GitHub and our Git instance.


MATT started a while ago, and Humbedooh added on to that to do the rewrite to GitHub. Basically what all that does is once your Apache ID is created, or if you have one already, you go on ID.apache.org, you add your GitHub username in there and then MATT --there's another part of that called Grouper-- MATT and/or Grouper will run periodically, pull data from our LDAP system and say, "Oh, ChrisT at apache.org has ChrisT as his GitHub ID. I'll pull those down." It says, "ChrisT is in the Infrastructure group. Hey look, there's an Infrastructure group in GitHub. I'll give ChrisT write access to the GitHub project." In a nutshell, that's what that does.


There's a ton of other house cleaning things, if you get removed from the LDAP group ... we run LDAP and keep all this stuff straight. If you get removed from the Infrastructure group at LDAP then MATT/Grouper will go and say, "Oh, this person's not in this LDAP group but they do have access in GitHub. Let me pull that so that they don't have access to that any more." It does housekeeping of everything as well as additions to groups and that kind of thing. There's a ton of technical backend to that, and that's what Humbedooh's doing. 


At first when Git and GitHub were set up, it was fine: the ASF has to keep canonical everything about what goes into each project. You could only write to our Git repos. Then it was conveniently mirrored out to GitHub because there's a lot of tools that GitHub has that we didn't have or weren't prepared to set up. GitHub has a very familiar way of doing things for a lot of developers. Once GitHub Writable came along with Gitbox and the changes to MATT, that opened up a whole other world of tools for people on projects to use. If they wanted to use pull requests on GitHub, they could start using pull requests on GitHub to manage code. They could wire up their build systems to GitHub with Jenkins so that whenever a PR was submitted and got approved, it would kick off a build in Jenkins and go through unit tests and do all the lovely things that Jenkins does.


It was really an evolution of, "Here's the service that we have. Someone, somewhere, be it infrastructure or otherwise, once they have writable GitHub access, here we go." And here's the swath of things that that now opens up to projects inside the ASF that if they could come and set up a project with us, and then never, ever actually commit code to the ASF, it would always go to GitHub but still be safe and saved on our GitHub servers for ASF project reasons.


At the same point, we saw a need and said, "Let's build this out and go." Another funnel that comes into us is when we're on-call, something breaks and we ask, "Why do we do it this way? We should be doing it a different way." We then come up with a project to fix that or build it. It's a very interesting process of how work gets into the Infrastructure team.


It's been an interesting ride with that one.


There's always stuff that we're working and fixing and making better. For the most part, Gitbox as it is now is kind of in a state of "It's getting worked on". If there are bugs that need fixed, it gets fixed, but I don't know what the next feature request is on Gitbox. There's talk of other services ...like GitLab. If someone wanted to write code and put it in GitLab as opposed to  GitHub, then someone would need to come in and write the connector from Gitbox to GitLab. So it's possible. I don't know if that's necessarily an Infrastructure need as much as it is a volunteer need for infra. But it's a system that can be set up to any other Git service as long as someone goes in and writes that.


You brought up an interesting point here, which is volunteers. Do volunteers contribute to Infra also? 


We sometimes have volunteers, yes. We have a lot of people on the infra mailing lists that will bounce ideas back to us or they'll work on a ticket or put in a pull request.


Well, the need is not as critical because you have a paid team, versus Apache projects. 


Right. That's exactly true. There's a bit of a wall that we have to have because we work with Foundation data, which not everyone has access to. Granted, we're a non-profit, Open Source company and everything's out there to begin with, but usernames and passwords of databases and things that we have encrypted that the team has access to isn't necessarily something that you would want any volunteer to have access to.


How do you stay ahead of demand? This is a really interesting thing because part of it is you're saying, "Necessity is the mother of invention." You guys are doing stuff because you've got those binary, "break-fix" types of scenarios. In an ideal situation, do you even have enough runway to be able to optimize your processes? How do you have the opportunity to fix things and improve things as you're going along if you're firefighting pretty much all day long?


That's a really good question about just how our workflow is. In other companies that I've been in, there's the operations people that are doing the "break-fix", and then there's the development people that are doing "the next big thing". The break-fix folks are spinning the plates and keeping them spun without breaking, and that's a lot of firefighting. That's literally all that job is. Even when you're not firefighting, you're sitting around thinking about firefighting in a sense of, “when is this going to fall over again? If it does fall over, what can we do to fix it so it doesn't do that anymore?" And in the past, the break-fix guys, the firefighters, would end up saying, "Hey, there's this thing that needs fixed." And it would fall over the wall to the developers. They would develop the fix for it, and then it would go back into production and then the cycle continues. 


To some extent, that's kind of where DevOps came from: if you merge the two of those together, then while you're firefighting you can also write the fix for the problem, and then you don't have to wait for the lag between the two. We don't have that split here. Everyone on the team is firefighting with one hand and typing out the solution with another. And a lot of the times our project work, like getting a new mail server spun up or my task to rewrite the workflow for new Apache ID creations, I've been working on that for a very long time because it will keep falling off ... it gets put on the backburner while we're like, "Hey, we found out that our TLP servers are getting hammered with downloads from apps and people trying to use them instead of the mirror servers." So, let's set up downloads.apache.org and we can funnel stuff over to that so that that server can get hammered and do whatever it needs to do so that our www. site and all the Apache Project websites stay up and running in a more reliable way.


What's the size of the teams that you were dealing with before that had a firefighting team and a dev team versus ASF infra?


The last "big" corporate job I had was ...six ops people that kept the site going, four database people, another eight technical operations-type people… all-told it was about thirty.


There were technically thirty firefighting people and we had a NOC (network operations center) that was literally people that only watched dashboards and watched for alerts. Whenever those go off, they’d call the firefighting people. The NOC was another 20 people. And then the development teams were ... twenty to fifty people.


What kind of consumer base were they accommodating? Does it match the volume that ASF has? Was it more of a direct, enterprise type of, "We have a customer that's paying, we have to respond to them" situation? Or is it different?


This was at a financial services company that transacted on their Website: completely different from the type of stuff we're dealing with here at the ASF. Volume-wise, they were much smaller, but it was much more ...visible, as their big times were at the start of market and end of market. After end-of-market came all the processing for the day to get done before markets started the next day. The site had to be up 100% of the time. We had SLAs of five minutes. If you got paged or something broke, you had to get the page and respond to it in a way of, "Hey, this is what's going on and these are the people that I need involved with it," all within five minutes of it going off. That was the way the management structure was. It was intense.


In scale, Apache probably does way more: they do way more traffic across all of our services in any given day. If someone doesn't get mail for a little bit, then they come and tell us or we get alerted of it by our systems, and we go and we fix it and we take care of it. But with the financial services group, people were losing money: dealing with people and money is just a very stressful situation for anyone working in technology because you have to get it right and it has to be done as fast as possible before someone's kids can’t go to college anymore. It was a completely different minefield to navigate.


The type of stress that's involved or the type of demand or the pressure is different, but you also have the responsibility with ASF that systems have to be up and running. I understand it's not mission critical if something goes down for more than five minutes, which is different in the financial sector, but do you feel that same type of pressure? Is it there or is it completely different for you? 


No. I think I do because we also have SLAs here: they're just not five minutes. We have structure around that and the way that we handle uptime and that kind of thing. I get very attached to the technology that I'm working with and the communities that I'm working with, so if a server goes down or a site's acting wonky, I take that very personally. That reflects on how I do my job. If a server's not working or if something's broken either because of me or something externally that's going on, I want to get that up and running as fast as possible because that's how I would expect anyone to work in a field that has ...any technology field, for that matter. And generally, that's the same attitude the rest of the team has as well.


How has ASF Infra changed over the years?


It's matured quite a bit. When I first started, it was Gavin, Fluxo, Humbedooh, Pono (former ASF Infrastructure team member Daniel Takamori), and me. There were five of us. The amount of stuff that we got done, I'm like, "Man, there's no way that five people can do this."


That's kind of what I'm pointing at. If you're a team of eight or five or twelve or whatever, compared to the other thing that you did with the other job that had maybe a core team of twenty, thirty --that in itself is insane.


We were five people, everything was very, "Here's the shiny thing we're working on," and then something else would come up and we'd have to jump on that. Then something else would come up and we'd have to jump on that. We were very ...I don't want to say we were stretched thin, but there wasn't necessarily ...time for improvement.


There was a lot of stuff we had still in physical hardware, and a couple of vendors that we no longer use. But things were moving more towards a configuration-based infrastructure with Puppet instead of one person building a machine, setting up all the configs themselves, installing everything and then letting it go off into the ether to run and do its job. We were moving everything towards Puppet to where you configure Puppet to configure the server. So then if the server breaks, or goes down or goes away or we need to move vendors or whatever, all you need to do is spin up a new server somewhere else, give it the Puppet config, it configures itself and then goes off into the ether to run and do whatever it needs to do.


That's great. More automation.


Right. We were automating a lot more stuff right when I first started. Over the course of the next year, the team kind of ebbed and flowed a little bit until we were eight in the last year. We started to get to the point of "where can we point the gun to next? What can we target next to get it taken care of and done?" That's where we started taking on more specific infra projects, for instance, mail. Our mail server has been around since the dawn of time, and it's virtualized so it moves servers every now and then, but the same base of it is quite old in technology standards.


Fluxo started moving this on to newer stuff and he got that going. We started taking care of projects that were not broken, but needed to be worked on. Instead of waiting for it to break, we're fixing and upgrading and moving down that path versus firefighting, break-fix, that kind of thing. We were moving more towards, "Hey, I see a problem. I have time. I'm going to take care of that and make that into a more serviceable system." 


Automation has helped quite a bit with that. I also think that just as the team grew, it just got to a point where I think tickets were getting responded to quicker, emails, chat was responded to quicker. And then we also could focus more on the tools that we use for the foundation. Like, HipChat was going away. We needed a new chat platform, so we chose Slack. And then we updated and moved everything over to Slack, and that's where we are with that. It started following into its own with workflows of like, "Oh, okay. How do we get this done? Let's go do that."


What areas are you experiencing your biggest growth? Is it a technical area? Like, "Hey, all of a sudden mail's out of control"? Or, "Hey, we need to satiate the demand for more virtual machines," or is it a geographic influence that's coming in in terms of draw? Where are you guys pointing all your guns to?


Currently we're trying to get more out to the projects and talk to people more often. Not that we didn't do that before, because ApacheCons and any Meetups that we had, Infra would always have a table. We were always accessible, but we were always passively accessible. We weren't really going out and talking to projects proactively to say, "Hey. What do you guys need from us? What are we doing with this?" So I think that's one part of it, that I think that we're moving towards a little bit. It's not at all technical, but more of a foundation broadening, community broadening thing that we're doing.


That's one part of it. The other thing that we're doing too is from a more technical or infrastructure standpoint, is we're really trying to get our arms around all of the services we provide, and then really take a look at those and say, how is this used inside the ASF? How is it used in the industry as a whole? Do we need to put more time and energy towards those things in order to make the offerings of the infrastructure team a little bit a more solid platform, kind of thing? Generally, that ... and on top of any other automation and that kind of stuff, I think that's really the two spots that I see infra growing in a lot in the next year-ish of just really boiling down our services to, "Hey, we've seen a lot of people using this. And a lot more projects are using this. It's not just a flash in the pan. We need to build out more infra around blah service, so let's really do that and make that a solid platform to use."


What do you think people would be surprised to know about ASF Infra? When you tell someone something about your job and they go, "Whoa, I had no idea" or, "That's crazy." What would people be surprised to know?


That Apache has an infrastructure team. [laughs]


Why are you saying that?


Because honestly, I don't think a lot of people know about the Infrastructure team. Those that do, have used us for something, not used us for something, have talked to us about something, and worked with us on something. Those that don't are like, "Oh, I didn't know the ASF paid people to be here," --that kind of thing. That's kind of the two reactions I've got from people. It's like, "Oh, that's cool. You work for the infrastructure team." Shrug. And then the other people are like, "Oh, sweet. Yeah, that's great. I know Gav. I've worked with him on blah, blah, blah." But that's not necessarily surprising. I mean, it is in a sort of way. 


When people ask, "What are you doing for work?" and you say you work for ASF, do people even know what that is? Do they know what you're doing? Do they care? Are they like, "Oh, okay. Whatever"?


There's literally three types of people that I've run into that ask, "Oh, what are you doing for work?" One person is the person that has no idea what the ASF is, not even the vaguest hint of Apache, and they're like, "Oh, okay. That's cool." There's that next person that does, and may or may not know about the ASF but knows of Apache, the Web server, or some other lineage of that.  They're like, "Oh, whoa. That's super cool. It's impressive.” That's wild. Then the third people ask "Why are ‘Indians’/Native Americans running software? That doesn't make any sense to me" and "Are you on a reserve?" I swear to God I've gotten that question before. I don't even know how to answer that. I'm like, "No, buddy."


Are these technologists or are these just guys off the street? Are they in the industry?


Guys off the street. I say Apache Software Foundation, and they're like "Apache" and "software" doesn’t make sense. Actually I've gotten mean tweets too whenever I've been tweeting about being at ApacheCon. Things like I'm "taking away" from Native Americans and whatever...


We also get that on Twitter, on the Foundation side: we get included in tweets about some kind of violation along the lines of, "Stand up for the ..." I get it. From time to time we also get sent these "How dare you?" letters, that sort of kind of thing. It's an interesting challenge, the whole issue of "why do Native Americans run this thing?" misinterpretation.


Let’s move on. What's your favorite part of your job?


The whole job is my favorite part of the job.


That's funny because everyone at Infra ... You know how people have bad days or may be grumpy or whatever, in general you guys seem to all like each other. You all have a great camaraderie. You all get along. You work really closely together. It's a very interesting thing to see from the outside. Is that true? Or are you just playing it up? Does it really work that way?


That's absolutely true. I've found that generally speaking, when you get a bunch of nerds together, they either really like each other and everything works or they really don't like each other and nothing gets done. The team is great, and it's like no other team I've ever worked with before. But it's very odd because you go through the interview process, and the interviews are interviews. I mean, you get to know people in interviews, but not really. Then you start working with people, and at some point you start getting below the surface. And at some point you get deep enough to where you find out whether or not ...how you gel with all these people. 


It's very odd that all of us have the same general sense of humor. We'll talk about food non-stop in the channel, and recipes and cooking, and different beers or different whatevers. It's nice to get to that point with a team that you're comfortable enough with everybody to ... like I said, I've been here three years and there is still so much that I don't know, both technical and non-technical, about the ASF. I ask very dumb questions in channel and say, "I have no idea why this is doing this this way," or, "Can someone else take a look?" or, "I don't know what I'm doing here." And never in the entire time I've been here, from the day one until now, has anyone ever chastised me for not knowing something or said anything about the way that I work or something like that. Well, at least not in channel. At least not publicly. 


Everyone's very supportive. It doesn't matter if you know everything there possibly is to know about one singular product or thing you're working on, or don't know anything about it. You can ask questions and really learn about why it was done the way it was done, or figure out how to fix a problem. No problem on the team. It's just like, "Okay, yeah. This is what you have to do." Or, "Here's a document. Read up on it." Or, "I don't know either." And then out of that comes an hour of conversation and then a document pops out, and then the next person that asks, we can say, "Here, go read the doc." Yeah. I mean, we're all very happy. Very happy.


Which is really good. Looking back when you first started, what was your biggest challenge when you came onto the team?


Oh man. I look back at that and I feel like the learning curve was ... It wasn't a curve. It was a wall. I've used Linux, I've used Ubuntu for a while and various other flavors of Debian and whatnot, so getting spun up on all of ...expanding my Linux knowledge was a big deal, expanding everything about the ASF and how it works. Which I'm still trying to figure out. If you know, send me something to read to figure out how that all works. I mean, I don't want to sound like I was completely out of my depth and I have no idea what I'm doing, but I feel like I was completely out of my depth and I had no idea what I was doing. 


There's a lot about the ASF that is just tribal knowledge, and there's a lot about Infra that's tribal knowledge. It's just no one has anything written down --"the server's been running under Jim's desk for the last 15 years in a basement that has battery backups and redundant Internet, so it's never gone down. But don't ever touch that server, because if it goes down, then all of our mail goes down" or whatever. There was a lot of figuring all that out for myself and digging around. Which is, frankly, one of the parts that I really enjoy, is just, "Hey, this thing broke. I've no idea what that thing is. I've no idea where it lives," and just diving in and trying to figure out what's going on with it and how it's built, and then the hair trigger that sets it off to crash and never work again. Yeah. That's an interesting question too.


What are you most proud of in your Infra career to date? You're talking about overcoming these challenges, I'm always curious just to see what people are like, "Yeah, I'm patting myself on the back for that one" or, "Ta-da. That's my ta-da moment."


I did lightning talks at ApacheCon Las Vegas and didn't get a phone call from you when I was done. [laughs]


I wasn't at lightning talks --what did you say? What would make me call you?


I didn't say it. We were on stage, and it's John (former ASF Infrastructure team member John Andrunas), Drew (ASF Infrastructure team member Drew Foulks), and I, and we figured we'd do lightning talks: "Hey, we're the new guys: ask us infrastructure questions." A week or two before ApacheCon, there was a massive outage at a particular vendor. It wasn't: "Oh, our server's down for a while," the server went down and then it was *gone*. It got erased from the vendor side. I can't remember what service it was. There was something that disappeared two weeks before Vegas and never came back. 


It wasn't just us, though: tons of companies had this issue. So we're on stage answering questions, and someone asks where this service went: "What happened to XYZ?" And John has the mic and he goes, "You should probably go ask [vendor name]." At that point it was very widely published that the vendor"s response was like, "Whoops, someone tripped over the cord that powered the data center. And when it came back up, then deleted all of your VMs.” They totally acknowledged it and they didn't give refunds for it, so it was a little bit of a PR kerfuffle for them. The vendor is in the other room handing out buttons and stickers, and John was like, "Oh yeah, go ask the [vendor] guys what happened to your server. That's their fault," he said it jokingly but my jaw dropped. 


[laughs] No one told me this story. No one said anything. Someone's trying to protect you. I had no idea this happened ...oh my gosh.


Well, David Nalley was in the back of the room, and he's screaming with his hands cupped around his mouth, "Don't badmouth the vendor and the sponsors." I deflected and quickly moved onto something else. [laughs]


But yes, that's another good question that I haven't actually reflected on. Looking back and seeing where Infra was when I first started and where it is now, it was a very runnable and very good team then, and it's a very runnable and it's a very good team now. I feel like a lot of the work that I've done and a lot of the work that the team has done over the last three years has been getting from a spot of "everything's on fire, who's holding up what this weekend?" to things being stable and us nitpicking on whether or not something needs to be updated or not. That's huge. That's a big step from like starting a company and treading water to being profitable and having resources to do other things versus just keeping your employees paid. I mean, it's a big step for a company and it's a big step for Infrastructure.


I love your talking about how you guys are tightly-knit and all that. How would your co-workers describe you?


The other odd part about that too is being completely remote and not having day-to-day, face-to-face interactions with people. You get a very odd sense of people through text for a 24-hour period that you're online reading stuff. It's a different perspective than if I was in the office every day, working on something and interacting with people. Even though every day, except for the weekends, I'm online talking to these guys and doing stuff. How would they describe me? Dashingly good looking and ... I don't know. [laughs]


I know that Infra's "just Infra," right --you guys are all under the Infra umbrella. Do you have a title? When you got hired, what do they call you?


We're all systems administrators. The only person that actually has a title is Greg, and he's Infrastructure Administrator.


What are the biggest threats you face? For infra folks or systems administrators or infrastructure administrators even, what do you need to watch out for these days? What's big in the industry? Is everyone saying, "Oh, XYZ's coming"? In terms of your role in the job: is there something that you need to keep your eye on? Is there something that you would advise other people, "If you're in this job keep an eye out for blah, this is a new threat" or anything along those lines?


General scope stuff. 16 years ago, everything was hardware: you bought hardware and you had to physically put it somewhere. And virtual machines came along about the same time. People were starting to do virtual stuff to where you could have a physical machine and then multiple machines running on that, sharing resources. Then cloud and infrastructure as a service, and everything's been moving more and more towards that over the years.


Of course, there's still people that work in office IT, doing desk support stuff or office infrastructure type things.Those are still a majority of how things run at companies. As everything is moved more towards the cloud or hosted services, more systems administrators are becoming more like software engineers. And software engineers are becoming more like systems administrators. They're kind of melding into one, big group of people. Now of course, there are still people that only write software. But gone are the days where it used to be someone would write some code and say, "I need to deploy it and get it out to all these computers." They would write the code, they'd hand it off to a systems person. Systems would go and configure on whatever server to get it out to however many machines and hit the button and go. The software developer never really needed to know hardware specifics of the systems that it was going to run on. And the systems people never really needed to know what software packages this was getting put together. There's exceptions to that, but for the most part ... 


Over the years, it's fallen into a thing now where the software developer knows exactly what systems this is going to run on and how it's going to run there, so it's more efficient and things work better and they're releasing less buggy code based on the fact that they know they're closer to the hardware. And the systems people, they want to troubleshoot it more and work with it and fix problems because they're closer to the software and know more about its internal workings and how it's going to run on systems. Everything is getting more and more chunked down into, first it was VMs, then it's cloud, then it's containers with Docker and things like that, and it's going to get more virtualized down into that. Knowing about Docker orchestration and things like Kubernetes and Apache Mesos. The reality is other people run Kubernetes, people run Docker, people run everything. That's the interesting thing in terms of how they do it at ASF. We don't require folks to do just one thing.


In terms of where the industry's going ... everything's getting pushed down to "a developer can work in a container on a set of systems, write software for that and then deploy that to a machine themselves, never involving a systems engineer at all, and build a product using that." It's getting stuff out the door faster, and it's also keeping the unicorn of the industry a while to go ... even today, I developed this thing, it works on my machine. If I move it over to another computer, it stops working. Why? What's the problem with that? Containering or containers fix that problem. The container you run on my system runs the same way as it does on every system everywhere. It takes the "runs on my machine" thing out of the equation. 


What's your greatest piece of advice? What would you tell aspiring sysadmins?


Part of the ASF is the community behind it, and a giant part of that is what makes it work. I mean, you could say all of it. That's what makes everything work with this. Right when I first started the sysadmin kind of thing, I didn't get into Meetups and Linux Users Groups and any of that stuff. I didn't get into the network. I didn't go into the community that I had around me. And honestly, I don't know if that's because it didn't exist or because I didn't know about it or what, but now that I'm older and wiser, the community part of it is really ...there's a massive benefit to that. Aside from socialization, or networking and how to get a better job through networking, getting together with like-minded people and talking through your problems is an amazing tool to use. And I didn't do that enough when I was a sysadmin starting out, and looking back it's something that I sort of regret not doing, was really sharing knowledge with other people in the community and building a group of people that I could ping ideas off of, or help with other ideas, or share in the knowledge of, "Hey, this is what's going on in the industry" or, "Hey, I saw this at work the other day. How do we work around that?" or that kind of thing. It's much easier these days with social media: the never-ending amounts of social media. But it's a big, important part of my day-to-day now, that I wish I had 16 years ago.


That's powerful. OK, If you had a magic wand, what would you see happen with ASF infra?


If I had a magic wand, I'd update our mail server instantly or maybe magic wand a few other projects.


Wait. I know you're joking, but what is the problem with the mail server?


It's running on an older version FreeBSD that doesn't play well with our current tools. Some form of that server has been upgraded, patched, moved, migrated, etc for the last 20 years. We want to bring it up to more modern standards. Mail runs fine for the most part, but it's probably the most critical service we have at the ASF and we want to make sure everything continues to hum along. Because of that, it's a huge project that touches a ton of different parts of our infrastructure.


How big is it?


It's all of our email. Every email that goes through an apache.org address.


This is a huge project and Chris (Lambertus) has been working on it for a while --it's not a simple thing to fix. It's very, very complicated. We couldn’t do it without him.


Back to the magic wand thing: I'd wish for more wands. 


Chris is based in Pennsylvania on UTC -4. His favorite thing to eat during the workday is chicken ramen.


# # #

Sunday March 08, 2020

The Apache Software Foundation Statement on the COVID-19 Coronavirus Outbreak

As a global organization with contributors on every continent, safeguarding our community is our highest concern, especially during the public health emergency presented with the COVID-19 coronavirus outbreak.


The World Health Organization and US Centers for Disease Control continue to release updates: we are actively monitoring the situation as part of our commitment to helping protect individuals from contracting or spreading the virus. 


Effective immediately, The Apache Software Foundation (ASF) strongly recommends suspending all travel associated with official ASF business and events through May 2020, after which we will reassess the restriction period. This applies to official Apache Conferences*, including Apache Roadshows in Washington DC (25 March) and Chicago (18-19 May), as well as beneficiaries of the ASF Travel Assistance Committee.


Of course, exceptions need to be considered. We implore those who must travel to review the WHO's Travel Advice https://www.who.int/emergencies/diseases/novel-coronavirus-2019/travel-advice and the Centers for Disease Control and Prevention's comprehensive Information for Travel reports at https://www.cdc.gov/coronavirus/2019-ncov/travelers/index.html 


With email being the ASF's primary method of communication for more than two decades, we do not anticipate significant disruption to ASF operations or to Apache Projects and their communities. Where possible, those organizing in-person assemblies may wish to consider holding virtual events or postponing, as opposed to cancelling.


Many members of our community work remotely. Whilst working from home may not be possible for some, we urge everyone to practice caution and be proactive with frequent hand-washing, using hand sanitizer, covering coughs and sneezes, and handling food safely. We urge those who are at risk or feeling unwell to stay home and take care of themselves. As symptoms can take more than three weeks to appear in those affected, we commend those who encourage their friends, family, and coworkers to take proper precautions.


We will continue to monitor this rapidly changing situation, and endeavor to provide updates as early as possible.


*Please follow the Notice on Apache 2020 Conferences at https://s.apache.org/zgm8m for the latest updates on Apache events.


# # #

Thursday March 05, 2020

Notice on Apache 2020 Conferences

In light of the World Health Organization raising the threat level about the COVID-19 coronavirus outbreak, we have decided, after much consideration, to cancel the following events:

Note that the Apache Roadshow/Seattle, scheduled for 10-12 June 2020, has been postponed.

The safety of our event attendees, speakers, sponsors, and staff is of the utmost importance. We are committed to minimizing our global community’s potential health risk, exposure to border health inspections, and increased travel restrictions.

Event organizers will be in contact with delegates regarding further updates.

= = =

UPDATES --9 March: added Chicago Roadshow to cancellation list; added postponement notice for Seattle Roadshow.

For the latest developments, follow @ApacheCon on Twitter and ASF Events on LinkedIn.

Wednesday March 04, 2020

The Apache Software Foundation Operations Summary: November 2019 - January 2020

FOUNDATION OPERATIONS SUMMARY

Third Quarter, Fiscal Year 2020 (November 2019 - January 2020)

"The Foundation's unique approach has created many industry standards and will likely continue to do so for many more years. Apache projects are famous not just for great technology, but for their longevity and vendor-independence."
Doug Cutting, ASF Member and Chief Architect at Cloudera (ASF Platinum Sponsor)


> Conferences and 
Events http://apachecon.com/

During this period we held two major Apache events. Q3 was fairly quiet for Conferences. We did not hold any events during this period, but were busy with early planning happening for several upcoming events.

ApacheCon North America 2020 will be held in New Orleans in September https://www.apachecon.com/acna2020/

We will be holding several Apache Roadshows in the coming months:

Sponsorship opportunities and speaking opportunities are available for all of these events.

> Community Development http://community.apache.org/

One of the key themes this quarter was the discussion of how to encourage ASF participation locally by establishing Apache Local Communities (ALC). The ALC comprises local groups of Apache enthusiasts, called an 'ALC Chapter' that will be responsible for organising local Apache related events. To create the necessary oversight for these groups we have agreed a set of governance processes including how they are formed, roles and responsibilities, how events are to be organised and how to dissolve a group if it is no longer active.

We have received the requests to establish the ALC Chapters in Beijing, Warsaw and Budapest and these are currently under consideration. Our existing active ALC Chapter in Indore ran an event on Open Source and ASF Awareness for school students.

We have applied on behalf of the ASF to be a GSoC mentoring organisation for 2020 and are waiting for the response. In preparation we have setup a wiki page to collect GsoC ideas from our Apache project communities.

During January we prepared for participation in FOSDEM as we were once again allocated a booth at the event. Volunteers from many of our projects signed up to spend time on the booth or to make themselves available to talk to attendees. As usual Community Development co-ordinated the booth and managed the giveaways for the event.

As well as ApacheCon and the Apache Roadshows planned for 2020, we are continuing to actively support any third party events that we can.

Despite the holiday season our mailing list traffic has increased slightly this quarter.

> Committers and Contributions http://apache.org/licenses/contributor-agreements.html

Over the past quarter, 1,581 contributors committed 42,338 changes that amount to 14,073,594 lines of code across Apache projects. The top 5 contributors, in order, were: Tilman Hausherr (1,010 commits), Andrea Cosentino (788 commits), Mark Robert Miller (771 commits), Mark Thomas (681 commits), and Jean-Baptiste Onofré (616 commits).

All individuals who are granted write access to the Apache repositories must submit an Individual Contributor License Agreement (ICLA). Corporations that have assigned employees to work on Apache projects as part of an employment agreement may sign a Corporate CLA (CCLA) for contributing intellectual property via the corporation. Individuals or corporations donating a body of existing software or documentation to one of the Apache projects need to execute a formal Software Grant Agreement (SGA) with the ASF.

During Q3 FY2020, the ASF Secretary processed 187 ICLAs, 6 CCLAs, and 6 Software Grants. History of Apache committer growth can be seen at https://projects.apache.org/timelines.html

> Brand Management http://apache.org/foundation/marks/

Operations —the work of the Brand Management team falls broadly into one of four categories:

- providing advice to projects

- granting permission to use our marks

- trademark transfers and registrations

- addressing potential infringements of our marks

The volume of work this quarter has again increased significantly compared to the previous quarter. This has mostly been driven by starting work on a number of draft policies where we are looking to clarify policy around a number of uses of Apache marks.

The topics covered in the advice provided to projects this quarter included setting up an external package registry, podling naming, community managed sites, registration of marks, 'official' social media accounts, assignment of marks, name changes, event sponsorship and linking to external support services.

This quarter has seen requests to use Apache marks for marketing material, events, books, scientifc papers, Websites, t-shirts with nearly all requests being granted, subject to our Trademark Usage Policy. The few requests that are not granted often relate to using a derivtaive of our logos --something we do not permit.

This quarter a number of the event approval discussions resulted in changes to the proposed evenmst dates to avoid clashes with other planned ASF events.

Registrations —the registration of APACHE in the US completed this quarter.

A number of registrations came up for renewal this quarter. We review each renewal as it comes up and, as a result, opted not to renew some of those registrations. The remaining renewals are in now progress.

We also started a small number of new registrations this quarter.

Infringements potential infringements are brought to our attention from both internal and external sources. The majority of infringements we see are accidental and our project communities are able to resolve these quickly and informally with occasional input from the Brand Management team. A small number of issues take longer to resolve. We made progress on some of these this quarter and hope that that progress will continue next quarter.

We continue to work to resolve the significant infringement mentioned in the last quarterly report. Along side that projects have resolved a number of minor issues during this quarter.

And finally…

The Brand Management team welcomes your comments and suggestions as well as any questions you might have. Please see https://www.apache.org/foundation/marks/contact for our contact details.

> Security http://apache.org/security/

We continued to work on handling incoming security issues, keeping projects reminded of their outstanding issues, allocation of CVE names, and other general oversight and advice.

For Q3 we tracked 94 new vulnerability reports across 46 projects. (Q3 last year for comparison was 88 reports). Those reports led to 37 published CVE vulnerabilities.

We published metrics for the whole of 2019 including discussion of high severity issues in a report https://s.apache.org/security2019 


> Privacy http://apache.org/foundation/policies/privacy.html

The board has rekindled the privacy effort. Currently we're working on three parallel tracks; developing a general policy from which we can derive day to day implementations and operating procedures, capturing/collecting the areas where we know we've historically dropped balls while also dealing with the day to day operational aspects (such as requests). The complexity is that we have on the one hand the purpose of the Apache Software Foundation; allowing a community to develop code for the common good. With all that that entails (such as having healthy, transparent and trust in the community). And on the other hands we have the rights and worries of both those in our community and our end users; whose privacy we would like to protect as well as we can. And the two can collide; e.g. for a software grant or things having to do with finance; we need to keep a fair amount of personally identifiable information on file. But at the same time - we want to protect the privacy of our community. Yet for the health of our community - a certain level of transparency is needed; as do some governance processes (e.g. those where developers approve a release as an official release of the foundation). For next two quarters the focus will likely shift to developing SoP's for day to day implementation (and automation) & hunting down where we have 'needless' data.


> Infrastructure http://apache.org/dev/infrastructure.html

This quarter has been relatively quiet for the Infrastructure team, given the holidays and New Year.

Our biggest highlight was hiring Andrew Wetmore as a Technical Writer and Editor, to bring his experience to our set of web pages, wiki content, and assorted documentation. For twenty years, the Foundation has organically written a large number of words. Andrew will corral this set of content into a coherent whole, with two goals in mind: to assist our development community with information about Infrastructure and its services, and to provide better guidance to users and new community members.

Continuing with a reflection of our history, we have decades of email archives. These have been provided on mail-archives.apache.org to the public. This quarter, we finally announced the decommission of our old archive system, in favor of the lists.apache.org service. The archive will be turned off some time during the next quarter, with redirects left in place to handle the myriad of links established over time.

For many years, the Foundation has been investing in CI/CD (Continuous Integration / Continuous Development). Primarily through our Jenkins installation, but also through integrations with third-party services. We have begun testing new Jenkins-based tooling to improve our management of clusters of nodes for assignment/use by our projects.

Our hope is this will help us continue to scale with the increasing demands of the Apache communities.

Fundraising is pleased to report another successful quarter of smooth operations. Renewals and business-as-usual work has been executed as planned. We've had a "typical" flow of new Sponsors and returning Sponsors with a few exciting Sponsor "upgrades" this quarter. This quarter we also completed our first targeted cash donation to an Apache project (Cordova).

We're pleased to also report further participation and "cross department" collaboration within The ASF. Fundraising support for Events has remained a focus this quarter as we ramp up for the several 2020 events. Additional focus is being placed on documentation, process, repeatability, and ensuring our Event Sponsors have a smooth experience all around. TAC and Fundraising are also collaborating more to encourage Event participation via Targeted Sponsorships -- more to come!

Process-wise, we continue improving the internals of the Fundraising mechanics to ensure smooth operation as well as improved documentation. We've recently adopted an improved procedure for meeting minutes and action items to further ensure nothing falls through the cracks.

Our planned outreach activities are all on track for Sponsors and we remain responsive to changes in organizational structures as our contacts enter and depart roles. We enjoyed meeting several of our Sponsors at COSCon in Shanghai in early November. Finally, we also updated our link policy for the "thanks page" to comply with popular webmaster recommendations by adding rel="sponsored" tags to new links and upon Sponsor renewals.

We are delighted to share the results of a very successful individual giving campaign that ran from late November through the end of calendar year 2019. The proceeds of the campaign were $14,240 in total which represents a 222% increase from previous years! The donations were comprised of 112 individual donations and 3 corporate gifts. We truly felt the love as some donations included heartfelt notes of thanks and encouragement for our mission.

Thank you to all our Sponsors --

  • PLATINUM: Amazon Web Services, Cloudera, Comcast, Facebook, Google, LeaseWeb, Microsoft, Pineapple Fund, Verizon Media, Tencent
  • GOLD: Anonymous, ARM, Bloomberg, Handshake, Huawei, IBM, Indeed, Union Investment, Workday
  • SILVER: Aetna, Alibaba Cloud Computing, Baidu, Budget Direct, Capital One, Cerner, Inspur, ODPi, Private Internet Access, Red Hat, Target
  • BRONZE: Airport Rentals, The Blog Starter, Bookmakers, Cash Store, Bestecasinobonussen.nl, CarGurus, Casino2k, Cloudsoft, The Economic Secretariat, Emerio, Footprints Recruiting, Gundry MD, HostChecka.com, Host Advice, HostingAdvice.com, Journal Review, LeoVegas Indian Online Casino, Mutuo Kredit AG, Online Holland Casino, ProPrivacy, PureVPN, RX-M, SCAMS.info, Site Builder Report, Start a Blog by Ryan Robinson, Talend, The Best VPN, Top10VPN, Twitter, Web Hosting Secret Revealed, Xplenty
  • TARGETED PLATINUM: CloudBees, DLA Piper, JetBrains, Microsoft, OSU Open Source Labs, Sonatype, Verizon Media
  • TARGETED GOLD: Atlassian, The CrytpoFund, Datadog, PhoenixNAP, Quenda
  • TARGETED SILVER: Amazon Web Services, HotWax Systems, Rackspace
  • TARGETED BRONZE: Bintray, Education Networks of America, Google, Hopsie, No-IP, PagerDuty, Peregrine Computer Consultants Corporation, Sonic.net, SURFnet, Virtru

To sponsor The Apache Software Foundation, visit http://apache.org/foundation/sponsorship.html . To make a one-time or monthly recurring donation, please visit https://donate.apache.org/

= = =

Report prepared by Sally Khudairi, Vice President Marketing & Publicity, with contributions by Rich Bowen, Vice President Conferences; Mark Cox, Vice President Security; Sharan Foga, Vice President Community Development; Myrle Krantz, Treasurer; David Nalley, Vice President Infrastructure; Tom Pappas, Vice President Finance; Daniel Ruggeri, Vice President Fundraising; Greg Stein, ASF Infrastructure Administrator; Mark Thomas, Vice President Brand Management; and Dirk-Willem van Gulik, Vice President Data Privacy.

For more information, subscribe to the announce@apache.org mailing list and visit http://www.apache.org/, the ASF Blog at http://blogs.apache.org/, the @TheASF on Twitter, and https://www.linkedin.com/company/the-apache-software-foundation.

(c) The Apache Software Foundation 2020.

# # #

Tuesday March 03, 2020

The Apache Software Foundation Announces Apache® Brooklyn(TM) v1.0

Advanced Open Source framework for modelling, monitoring, and managing applications used by global systems integrators, Cloud software and service providers, and major enterprises across financial services, supply chain management, and more.

Wakefield, MA —3 March 2020— The Apache Software Foundation (ASF), the all-volunteer developers, stewards, and incubators of more than 350 Open Source projects and initiatives, today announced Apache® BrooklynTM v1.0, the latest version of the Open Source framework for modelling, monitoring, and managing applications.

"I am excited to see the 1.0 release of Apache Brooklyn," said Geoff Macartney, Vice President of Apache Brooklyn. "This reflects the maturity and stability that Brooklyn has reached after nearly five years as a Top-Level Apache project."

Apache Brooklyn provides a single tool that includes a REST API and GUI for:

  • managing provisioning and application deployment;
  • monitoring an application’s health and metrics;
  • understanding the dependencies between components; and 
  • applying complex policies to manage the application.

Apache Brooklyn uses declarative YAML blueprints to describe an application and all its components. Blueprints can be treated as an integral part of the application, and as modular components that can be composed and reused in many ways. Brooklyn blueprints incorporate policies that actively manage a deployed application by reacting to sensor data such as application health or load, and take actions such as replacing nodes or growing a cluster. Brooklyn’s design is influenced by Autonomic computing and promise theory and implements the OASIS CAMP and TOSCA standards.

Apache Brooklyn 1.0 highlights include:

  • Support for public and private clouds, available out-of-the-box thanks to integrated Apache jclouds, as well as private infrastructure
  • A modern, user-friendly, web-based UI including the drag-and-drop Blueprint Composer
  • REST API and CLI tools, suitable for power users, automation and scripting
  • A stable blueprint language and API
  • “Batteries included” entities and policies covering clusters, auto-scaling, replacing unhealthy components, and more

"Apache Brooklyn has been in use for some time in production environments," said Richard Downer, Apache Brooklyn 1.0 release manager. "I’m delighted we can now announce our 1.0 release. Everyone should feel confident building on and deploying Apache Brooklyn 1.0 and know that the Brooklyn Project Management Committee has prioritised the long-term stability of Brooklyn."

Apache Brooklyn is in use by global systems integrators, providers of Cloud software and services, as well as mission-critical applications for major enterprises in financial services, supply chain management, and more.

"We are delighted to see Apache Brooklyn reach this milestone," said David Cairns, CTO for innovation at Fujitsu Digital Technology Services. "Apache Brooklyn powers Fujitsu AIOps solutions with policy-based autonomics to detect service deterioration or outage and can automatically re-locate Cloud applications and services from one cloud provider to another to elevate resilience and uptime." 

"Reaching v1.0 reflects the maturity of Apache Brooklyn and we appreciate the community’s effort," said Ross Gray, CEO at Cloudsoft. "Cloudsoft AMP is built on Apache Brooklyn and helps customers eliminate manual processes, cut effort by 75%, and reduce infrastructure spend by as much as 66%."

Apache Brooklyn blueprints for many well-known applications and tools, including ElasticSearch, clustered MySQL, and DNS management, as well as Apache projects such as Cassandra, CouchDB, Kafka, Solr, Storm, ZooKeeper and more, are all freely available under the Apache License v2. The Apache Brooklyn community warmly welcomes new code, testing, blueprints, documentation, presentations, and other contributions.

"Brooklyn is a powerful tool for unified modelling, deployment and lifetime management of applications," added Macartney. "This latest release is a great opportunity for a wider audience to try Brooklyn for themselves and find out how it can help them create and manage their applications, be it in the Cloud, on-premise, or in a hybrid environment. We look forward to growing our community as people discover all that Brooklyn can do."

Availability and Oversight
Apache Brooklyn software is released under the Apache License v2.0 and is overseen by a self-selected team of active contributors to the project. A Project Management Committee (PMC) guides the Project's day-to-day operations, including community development and product releases. For downloads, documentation, and ways to become involved with Apache Brooklyn, visit https://brooklyn.apache.org/ and https://twitter.com/ApacheBrooklyn

About The Apache Software Foundation (ASF)
Established in 1999, The Apache Software Foundation (ASF) is the world’s largest Open Source foundation, stewarding 200M+ lines of code and providing more than $20B+ worth of software to the public at 100% no cost. The ASF’s all-volunteer community grew from 21 original founders overseeing the Apache HTTP Server to 765 individual Members and 206 Project Management Committees who successfully lead 350+ Apache projects and initiatives in collaboration with 7,600 Committers through the ASF’s meritocratic process known as "The Apache Way". Apache software is integral to nearly every end user computing device, from laptops to tablets to mobile devices across enterprises and mission-critical applications. Apache projects power most of the Internet, manage exabytes of data, execute teraflops of operations, and store billions of objects in virtually every industry. The commercially-friendly and permissive Apache License v2 has become an industry standard within the Open Source world, helping launch billion dollar corporations and benefiting countless users worldwide. The ASF is a US 501(c)(3) not-for-profit charitable organization funded by individual donations and corporate sponsors including Aetna, Alibaba Cloud Computing, Anonymous, ARM, Baidu, Bloomberg, Budget Direct, Capital One, CarGurus, Cerner, Cloudera, Comcast, Facebook, Google, Handshake, Huawei, IBM, Indeed, Inspur, Leaseweb, Microsoft, ODPi, Pineapple Fund, Pivotal, Private Internet Access, Red Hat, Target, Tencent, Union Investment, Workday, and Verizon Media. For more information, visit http://apache.org/ and https://twitter.com/TheASF

© The Apache Software Foundation. "Apache", "Brooklyn", "Apache Brooklyn", "Cassandra", "Apache Cassandra", "CouchDB", "Apache CouchDB", "jclouds", "Apache jclouds", "Kafka", "Apache Kafka", "Solr", “Apache Solr", "Storm", “Apache Storm", "ZooKeeper", and "Apache ZooKeeper" are registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries. All other brands and trademarks are the property of their respective owners.

# # #

Thursday February 27, 2020

The Apache Software Foundation Announces 20th Anniversary of Apache® Subversion®

Community-led Version Control Software and Source Code Management Tool Available on Most Integration Servers, Integrated Development Environments, Issue Tracking Systems, and more. 

Wakefield, MA —27 February 2020— The Apache Software Foundation (ASF), the all-volunteer developers, stewards, and incubators of more than 350 Open Source projects and initiatives, announced today the 20th Anniversary of Apache® Subversion®, the popular centralized software version control system.

Apache Subversion ("SVN") allows users to commit code, manage changes, and recover previous versions of all sorts of data across files and directories. Subversion is ideal for distributed teams who need to easily audit and act on modification logs and versioning history across projects. Subversion originated at CollabNet in 2000 as an effort to create an Open Source version-control system similar to the then-standard CVS (Concurrent Versions System) but with additional features and functionality. Subversion was submitted to the Apache Incubator In November 2009, and became an Apache Top-Level Project in February 2010.

"We are very proud of Subversion's long history, and remain committed to our mission statement," said Stefan Sperling, Vice President of Apache Subversion. "Subversion has moved well beyond its initial goal of creating a compelling replacement for CVS. In 2010 our mission statement was updated to ‘Enterprise-class centralized version control for the masses’.”

Over its 20-year history, Subversion has grown to become the most popular version control system on the market, and remains the leading centralized versioning and revision control software today. Millions of users worldwide depend on the collaboration-friendly system to easily access all files and historical data simultaneously without code conflicts or corruption. Subversion accommodates a wide variety of integrated development environments (IDEs), and is well-suited for large projects. 

Apache Subversion has been broadly adopted for mission-critical code distribution and collaboration workflow by Adobe Dreamweaver, Eclipse, Google, Halliburton, Microsoft Visual Studio, Python, Ruby, Skype, SourceForge, and WordPress, among many organizations and development communities. The ASF uses Apache Subversion in its own infrastructure, housing millions of lines of code in more than 1.8 Million commits across 300 Apache Top-Level Projects and sub-projects.

"One of the best decisions of my life was emailing up Karl (Fogel) to see if he was interested in moving the Open Source community beyond CVS," said Brian Behlendorf, co-founder of CollabNet and co-founder of The Apache Software Foundation. "Essential to Subversion's success was the core team of Karl, Ben (Collins-Sussman), and Mike (Pilato) working publicly, spending the difficult time on design docs and helping newbies up the learning curve, with the goal of building as a community what three people (even the best) alone could not do. 20 years later I'm not surprised to see it continuing to innovate, to add features, to fix bugs, and to push the envelope forward. Git still needs competition :) But it's also the best example, and essential example, for why community matters more than code. It's the Subversion community that made it successful, that made the code continuously better, that left no CVS user behind, and that did so with the technical precision and super-human decency all other projects should aspire to."

"Twenty years later, Subversion is no longer the upstart -- it is mature software, and still going strong," said Karl Fogel, original founding developer of Subversion, and Partner at Open Tech Strategies. "Subversion continues to be widely used, especially in enterprise settings, because of its reliability, the simplicity of its conceptual model, its ability to handle large files, and features like path-based access control and optional file-locking. In situations where Subversion's centralized model is the right tool for the job, it really shines: we use it for our entire internal corporate tree, for example, because the path-based authorization is crucial. To get some other viewpoints on where Subversion has come over 20 years, I took a walk through the main project's support forums and the forums of TortoiseSVN, the popular open source SVN client application for Windows. I was delighted by what I saw: a diversity of uses and users, fast and helpful responses, and a focus on practical needs. Starting two decades ago, Subversion helped bring version control beyond developers to a wider audience, and it continues to do that today."

"Today we've got a plethora of fast, reliable, and efficient version control systems, but twenty years ago we had exactly zero: CVS was the only widely used version control system and it still failed in unpredictable ways (including bitrot that was undetectable until you tried to check out old code)," said Brian Fitzpatrick, one of Subversion’s earlier developers. "Even though most people use Git today in the Open Source world, Subversion was the catalyst that allowed folks to move from CVS to Git and so many other modern day version control systems. While the core team wrote a great deal of Subversion's code, we also spent a great deal of time communicating outside of our office in Chicago in an effort to build a larger Subversion community--an effort that eventually paid off more than tenfold."

"When we gathered in my basement in early 2000, thinking about what paths Subversion should follow, none of us imagined what would be accomplished over the next twenty years," said Greg Stein, an early developer of Subversion, and former Vice President of Apache Subversion. "We focused on improving the experience of CVS users and administrators. We overshot our own expectations within just a few years, creating a system that millions have found worthy. From our humble beginnings, I couldn't be more proud of what the community has accomplished."

"Technology is at its best when it brings people together," said Matt Mullenweg, Founder and Lead Developer at the WordPress Foundation. "SVN has brought countless people together over the years and I wish it much continued success."

"Reliable and powerful version management is essential for our product development. Today, more than 100 of our employees regularly use Apache Subversion with several million lines of source code in our Subversion repository," said Roland Wagner, Head of Product Marketing at CODESYS Group. "Our success with Subversion convinced us to become the first company to develop a connected product for the area of industrial automation with the launch of CODESYS SVN. Many of the over 100,000 CODESYS users worldwide work with CODESYS SVN whichsignificantly simplifies the development of their industrial IEC 61131-3 application software, when realizing automation projects for factories and plants, mobile machines, buildings and energy systems. We thank and congratulate the Subversion community on its 20th anniversary!"

"After 20 years, Apache Subversion continues to deliver on our goal with a stable and portable version control system that powers software projects of all sizes being developed on any of the popular operating system platforms," added Sperling. "Apache Subversion repositories store valuable mission-critical assets of companies and organizations across the globe. Subversion remains an essential source code management tool for developers at every level --we welcome their participation on our lists and community."

Availability and Oversight
Apache Subversion software is released under the Apache License v2.0 and is overseen by a self-selected team of active contributors to the project. A Project Management Committee (PMC) guides the Project's day-to-day operations, including community development and product releases. For downloads, documentation, and ways to become involved with Apache Subversion, visit http://subversion.apache.org/

About The Apache Software Foundation (ASF)
Established in 1999, The Apache Software Foundation is the world’s largest Open Source foundation, stewarding 200M+ lines of code and providing more than $20B+ worth of software to the public at 100% no cost. The ASF’s all-volunteer community grew from 21 original founders overseeing the Apache HTTP Server to 765 individual Members and 206 Project Management Committees who successfully lead 350+ Apache projects and initiatives in collaboration with 7,200 Committers through the ASF’s meritocratic process known as "The Apache Way". Apache software is integral to nearly every end user computing device, from laptops to tablets to mobile devices across enterprises and mission-critical applications. Apache projects power most of the Internet, manage exabytes of data, execute teraflops of operations, and store billions of objects in virtually every industry. The commercially-friendly and permissive Apache License v2 has become an industry standard within the Open Source world, helping launch billion dollar corporations and benefiting countless users worldwide. The ASF is a US 501(c)(3) not-for-profit charitable organization funded by individual donations and corporate sponsors including Aetna, Alibaba Cloud Computing, Anonymous, ARM, Baidu, Bloomberg, Budget Direct, Capital One, CarGurus, Cerner, Cloudera, Comcast, Facebook, Google, Handshake, Huawei, IBM, Indeed, Inspur, Leaseweb, Microsoft, ODPi, Pineapple Fund, Pivotal, Private Internet Access, Red Hat, Target, Tencent, Union Investment, Workday, and Verizon Media. For more information, visit http://apache.org/ and https://twitter.com/TheASF

© The Apache Software Foundation. "Apache", "Subversion", "Apache Subversion", and "ApacheCon" are registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries. All other brands and trademarks are the property of their respective owners.

# # #

Friday January 31, 2020

Apache Software Foundation Security Report: 2019

Synopsis: This report explores the state of security across all Apache Software Foundation projects for the calendar year 2019. We review key metrics, specific vulnerabilities, and the most common ways users of ASF projects were affected by security issues.

Released: 31 January 2020

Author: Mark Cox, Vice President Security, The Apache Software Foundation

Background
The security committee of The Apache Software Foundation (ASF) oversee and co-ordinate the handling of vulnerabilities across all of the 300+ Apache projects.  Established in 2002 and comprising of all volunteers, we have a consistent process for how issues are handled, and this process includes how our projects must disclose security issues.

Anyone finding security issues in any Apache project can report them to security@apache.org where they are recorded and passed on to the relevant dedicated security teams or project management committees (PMC) to handle.  The security committee see all the issues reported across all the addresses and keep track of the issues throughout the vulnerability lifecycle.  

The security committee is responsible for ensuring that issues are dealt with properly and will actively remind projects of their outstanding issues and responsibilities.  As a board committee, we have the ability to take action including blocking their future releases or, worst case, archiving a project if such projects are unresponsive to handling their security issues.  This, along with the Apache Software License, are key parts of the ASF’s general oversight function around official releases, allowing the ASF to protect individual developers and giving users confidence to deploy and rely on ASF software.  

The oversight into all security reports, along with tools we have developed, gives us the ability to easily create statistics on the issues. 

Statistics for 2019
In 2019 our security addresses received in total over 18,000 emails. After spam filtering and thread grouping this comes to 620 non-spam threads.  Unfortunately many security reports do look like spam and so the security team are careful to review all messages to ensure real reports are not missed for long.



Diagram 1: Breakdown of ASF security email threads for calendar year 2019*

Diagram 1 gives the breakdown of those 620 threads.  138 threads (22%) were people confused by the Apache License.  As many projects use the Apache License, not just those under the ASF umbrella, users can get confused when they see the Apache License and they don't understand what it is.  This is most common for example on mobile phones where the licenses are displayed in the settings menu, usually due to the inclusion of software by Google released under the Apache License.

The next 162 of the 620 (26%) are email threads that are not spam but are also not reports of new vulnerabilities.  These are generally people asking support-type questions or how old vulnerabilities were dealt with.

That left 320 reports of new vulnerabilities in 2019, which spanned across 84 of the top level projects.  These 320 reports are a mix of both external reporters and internal; for example where a project has found an issue themselves and followed the ASF process to assign it a CVE name and address it.  Note that we don’t track the reporter affiliation, and ASF reporters often use non-ASF email addresses for reporting, so we can’t give a break down of internal vs external reports .

The next step is that the appropriate project triages the report to see if it's really an issue or not.  At this stage invalid reports, or things that are not actually vulnerabilities at all, get rejected back to the reporter.  Of the remaining issues that are accepted they are are assigned appropriate CVE names and eventually fixes are released.

As of January 1st 2020, 19 of those 320 reports were still under triage (i.e. the project had not yet determined if the report is accepted or rejected).  The process of triage and investigation varies in time depending on the project, availability of resources, and number of issues to be assessed.  As a general guideline we try to ensure projects have triaged issues within 90 days of the report.  The timeline for the fixing of issues depends on the schedules of the projects themselves and issues of lower severity are most often held to future pre-planned releases.  

The remaining closed 301 reports led to us assigning 122 CVE names.  Some vulnerability reports may include multiple issues, some reports are across multiple projects, and some reports are duplicates where the same issue is found by different reporters, so there isn't an exact one-to-one mapping of accepted reports to CVE names.  The Apache Security committee handle CVE name allocation and are a Mitre Candidate Naming Authority (CNA), so all requests for CVE names in any ASF project are routed through us, even if the reporter is unaware and contacts Mitre directly or goes public with an issue before contacting us. 

Noteworthy events
During 2019 there were a few events worth discussion; either because they were severe and high risk, they had readily available exploits, or otherwise due to media attention.   These included:

  • January 2019: Securonix published a report outlining an increase of attacks of Apache Hadoop instances that have not been configured with authentication.  Public exploits and a Metasploit module exist to perform remote code execution on unprotected Hadoop YARN systems.

  • April 2019: A flaw in Apache HTTP Server 2.4 (CVE-2019-0211).  A user who has access to write scripts on a web server could elevate those privileges to root.  A public exploit is available for this issue.

  • April 2019: A flaw in older versions of Apache Axis that parsed a file retrieved insecurely from an expired domain, allowing remote code execution (CVE-2019-0227).

  • June 2019: Jonathan Leitschuh contacted us after finding a number of Java build dependencies were being downloaded over insecure paths (i.e. HTTP rather than HTTPS).  We did not classify these as security vulnerabilities in themselves as exploiting them would require MITM attacks at build time.  We worked with ASF projects including those identified by the reporter to ensure that we use secure URLs.  Now, in 2020, a number of repositories are requiring secure URLs.

  • August 2019: The Black Duck Synopsys team reviewed older Struts releases and advisories and found some discrepancies in the reported affected versions.   The Struts team worked through their findings and issued corrections where needed.  This can be important if users are running older versions that they don't think are affected by an issue based on the advisories, but they actually are.  However, those same users are likely vulnerable to the other issues that have since been fixed and so we'd always recommend users upgrade to the latest version of Struts to ensure they have a version that contains fixes for all the published security issues.

  • August 2019: Netflix found a number of denial of service vulnerabilities affecting various HTTP/2 implementations. ASF projects containing HTTP/2 implementations were investigated and analysed the issues reported. Both Apache HTTP Server and Apache TrafficServer released updates to address denial of service issues that affected them.  Apache Tomcat also made performance improvements to HTTP/2 handling but the issues were not classed as denial of service.

  • September 2019: A RiskSense report highlighted vulnerabilities known to be used by Ransomware which included four in ASF projects.  The four vulnerabilities were all fixed in earlier years and all had updates and mitigations available before any ransomware took advantage of them.  Users should always ensure they pay attention to security updates in any ASF projects they use and prioritise updating for any remote or critical vulnerabilities. The four vulnerabilities were:

     -- CVE-2016-3088 in Apache ActiveMQ.  Targeted by XBash, this issue was trivial to exploit.  It was fixed in Active MQ 5.14.0 and mitigation was also available.

     -- CVE-2017-12615 in Apache Tomcat.  It is surprising to see this issue on the list as it affects a non-default and quite unlikely flaw.  However, it's an issue that is probed by Lucky (a variant of "Satan"), so if there is a server configured in this way it will get exposed. This issue only affected Windows platforms on non-default config, it was fixed in Tomcat 7.0.81, and mitigation is also available.  Note that Lucky will also do brute force attacks targeting weak passwords on  accessible Tomcat Web Admin consoles.

     -- CVE-2017-5638 in Apache Struts.  This issue is known to be exploited in the wild, however the first exploitation was discovered after the advisory and fix was published.  Used by Lucky (a variant of Satan).  It was fixed in Struts 2.3.32 and 2.5.10.1, and a mitigation is also available.

     -- CVE-2018-11776 in Apache Struts.  This issue is also used by Lucky.  It was fixed in Struts 2.3.35, 2.5.17, a possible mitigation is available but upgrading is advised.

  • Dec 2019: A flaw in Apache Olingo allowing XML External Entity (XXE) attacks (CVE-2019-17554).  This issue could be used, for example, to retrieve arbitrary files from a server.  A public exploit example exists for this issue.

  • A number of flaws in Apache Solr through the year that could allow remote code execution.  Public exploits exist for some of the issues as well as a Metasploit module.

  • The European Commission EU-FOSSA 2 project sponsored bug bounty programs for users finding security issues in both Apache Kafka and Apache Tomcat.  No issues were fixed in Apache Kafka.  Two issues were fixed in Apache Tomcat: CVE-2019-0232 (Important severity, affecting Windows platforms, public exploits including a Metasploit module are available) and CVE-2019-0221 (Low severity).   As well as running the bug bounties, EU-FOSSA 2 also sponsored a successful hackathon in June 2019.
Conclusion

Apache Software Foundation projects are highly diverse and independent.  They have different languages, communities, management, and security models.  However one of the things every project has in common is a consistent process for how reported security issues are handled.

The ASF Security Committee work closely with the project teams, communities, and reporters to ensure that issues get handled quickly and correctly.  This responsible oversight is a principle of The Apache Way and helps ensure Apache software is stable and can be trusted.

This report gave metrics for calendar year 2019 showing from the 18,000 emails received we triaged over 300 vulnerability reports leading to fixing just over 100 (CVE) issues.  If you have vulnerability information you would like to share with or comments on this report please contact us.

# # #

graphic created by http://sankeymatic.com/build/ using code :

Threads [138] License Confusion

Threads [162] Support Questions

Threads [320] Vulnerability Reports

Vulnerability Reports [19] Under Triage

Vulnerability Reports [301] Closed

Closed [122] CVE

1000x600

colour B source

Sunday December 15, 2019

The Apache Software Foundation Operations Summary: August - October 2019

FOUNDATION OPERATIONS SUMMARY

Second Quarter, Fiscal Year 2020 (August - October 2019)

"...a preeminent organization in the world of open source software... The ASF has always distinguished itself by maintaining a consistent mode of project governance and evolution, known as "The Apache Way"."
—Brian Proffitt, Senior Principal Community Architect, Red Hat Open Source Program Office (ASF Silver Sponsor)


> Conferences and 
Events: During this period we held two major Apache events.

In September we held ApacheCon North America in Las Vegas, Nevada, and celebrated the 20th anniversary of the ASF. We had around 725 attendees at the Flamingo Hotel. Event details may be found at https://www.apachecon.com/acna19/   Videos of the plenary sessions and other selected content may be found at https://www.youtube.com/watch?v=0CLDVMcyo1s&list=PLU2OcwpQkYCzWULP5C-C9eTF4DcbnYa2l and audio from selected other presentations is at http://feathercast.apache.org/   Photos from the event are at https://photos.apachecon.com/?/category/2

In October we held ApacheCon Europe in Berlin, Germany. We had around 300 in attendance at the Kulturbrauerei Berlin. Event details may be found at https://aceu19.apachecon.com/  Session videos may be found at https://www.youtube.com/watch?v=2EvCF4XKLso&list=PLU2OcwpQkYCxVGCGWtMxb9d27Z-pcoN9a  Photos from the event are at https://photos.apachecon.com/?/category/1

At the end of this period, we were in planning for our 2020 schedule of events. This will include:

  • Apache Roadshow Chicago (Proposed) - 2020-05-27 to 2020-05-30 Chicago, IL, USA
  • Apache Roadshow, Seattle - 2020-06-10 to 2020-06-13 Seattle, WA, USA
  • ApacheCon North America, New Orleans - 2020-09-28 to 2020-10-03 New Orleans, LA, USA
  • Apache Roadshow China (Proposed) - 2020-10-24 to 2020-10-26, (Location TBD)

(Please note that some of these events are still tentative.)

For sponsorship opportunities, please contact planners@apachecon.com

Upcoming events are listed at http://events.apache.org/ and may change as planning progresses.

> Community DevelopmentDuring this quarter a key theme was event participation.

In August our main focus was dealing with the requests for ordering project stickers for ApacheCon. For this special anniversary event we wanted to ensure that any many projects as possible would have stickers available on the ASF booth.

The main focus in September was to help provide support for Apachecon NA in Las Vegas. As usual we co-ordinated the Apache booth which was staffed by our community volunteers from various projects. They had the chance to speak to attendees, promote their project and hand out a range of giveaways. The ASF booth was also the central place where the Apache feather was on display for all attendees to sign. 

In October the feather was also taken to Berlin for ApacheCon EU and attendees were also invited to sign the feather. Once again we had a central and dynamic booth which became a meeting hub for attendees.

As part of bringing the Apache Way to new audiences, an Apache Day event was held in Indore, India during September. The aim was to give people an overview of the ASF, the Apache Way and also give some practical help in becoming a contributor.

Also this quarter we participated at CCOSS 19 in Guadalajara, Mexico. There was an Apache track with talks ranging from Getting Started to Governance and Open Source Licences. This was a great opportunity to connect with potential new contributors to open source.

We are still receiving requests to participate at events so need to put a plan in place for 2020.

> Committers and Contributions: Over the past quarter, 1,581 contributors committed 42,338 changes that amount to 14,073,594 lines of code across Apache projects. The top 5 contributors, in order, were: Tilman Hausherr (1,010 commits), Andrea Cosentino (788 commits), Mark Robert Miller (771 commits), Mark Thomas (681 commits), and Jean-Baptiste Onofré (616 commits).

All individuals who are granted write access to the Apache repositories must submit an Individual Contributor License Agreement (ICLA). Corporations that have assigned employees to work on Apache projects as part of an employment agreement may sign a Corporate CLA (CCLA) for contributing intellectual property via the corporation. Individuals or corporations donating a body of existing software or documentation to one of the Apache projects need to execute a formal Software Grant Agreement (SGA) with the ASF.

During Q2 FY2020, the ASF Secretary processed 210 ICLAs, 7 CCLAs, and 14 Software Grants. History of Apache committer growth can be seen at https://projects.apache.org/timelines.html

> Brand Management: Operations — The work of the Brand Management team falls broadly into one of three categories:

  • trademark transfers and registrations
  • granting permission to use our marks
  • addressing potential infringements of our marks

The volume of work this quarter has been roughly double that of the previous quarter. The increase has been mostly in the areas of requests to use our marks and queries regarding potential infringements. The increase in volme has been manageable, largely due to the tracking system we have put in place.

This quarter has seen requests to use Apache marks for user groups, events, merchandise, publications and training courses with nearly all requests being granted, subject to our Trademark Usage Policy. There have been a few cases this quarter of requests being made for marks that the ASF does not own which we have redirected to the correct owners.

Registrations — A number of registrations came up for renewal this quarter. We review each renewal as it comes up and, as a result, opted not to renew some of those registrations. The remaining renewals are in now progress.

Some registrations, particularly those outside the US, tend to be more complex. This quarter some of our registrations in China have continued to require additional work to help them progress.

Infringements — Potential infringements are brought to our attention from both internal and external sources. The majority of infringements we see are accidental and our project communities are able to resolve these quickly and informally with occasional input from the Brand Management team. A small number of issues take longer to resolve. We made progress on some of these this quarter and hope that that progress will continue next quarter.

We received multiple reports of a significant infringement this quarter and are in contact with the company concerned to remedy the situation. We hope to have this resolved in the next quarter.

And finally…

The Brand Management team  welcomes your comments and suggestions as well as any questions you might have. Please see https://www.apache.org/foundation/marks/contact for our contact details.

> Infrastructure: The datacenter fast-exit mentioned last quarter was completed, as an all-hands shift. That went very well, and our services have been relocated. That sudden move really helped us to double-check our configuration management (Puppet-based) and to reallocate services to better-cost providers, to stretch our Infrastructure dollar.

For a short while in August, we experienced some email issues that created a perfect storm with one of our primary providers. That has been resolved, with a new mail queue monitoring system and alerting, helping to improve our ongoing level of uptime and service.

September was our 20th Anniversary ApacheCon North America, held in Las Vegas, Nevada. The entire team traveled to Vegas to meet with each other and with the community. It was a great opportunity to put faces to new names, to see some old faces, and to get a bit of work and team bonding accomplished.

We also launched our new ".asf.yaml" service for out projects to self-service many aspects of their GitHub presence, and workflow for publishing project websites. More features for the projects, and less tickets for the team. This has been working well, and we continue to improve upon its capabilities. One of the Apache community members provided several features through some Pull Requests -- it is always great to see someone in the community helping out the thousands of others who form Apache.

One of our final initiatives in the quarter, was a revamp of how we map projects' Apache Subversion repositories over to GitHub. We upgraded the server, improved the mapping system, and pruned out numerous unused projects (eg. they had switched to git). We also improved the resiliency of our GitHub-based webhooks by using message queues for repeatability, and to hold messages while we upgrade the primary server. We've seen improvements in stability and ordering, already.

> Financial Statement:


> Fundraising: Fundraising work continues smoothly with very few non-BAU/business-as-usual details to share. "No news is good news", as they say!

We are pleased to report that the online form and digital agreement signature procedures announced last quarter are working well and keeping busywork to a minimum.

We once again thank all of our wonderful ApacheCon sponsors that showed up in force at ApacheCon NA and ApacheCon EU and were glad to enjoy some in-person time with both Event and Foundation sponsors.

A targeted sponsorship for D&I was received and processed per our BAU procedure. This was the first exercise of the procedure and worked well. We also continued conversations with a targeted sponsor for a project as well as explored the possibility of a crypto token donation.

= = =

Thank you to all our Sponsors --

  • PLATINUM: Amazon Web Services, Cloudera, Comcast, Facebook, Google, LeaseWeb, Microsoft, Pineapple Fund, Verizon Media, Tencent
  • GOLD: Anonymous, ARM, Bloomberg, Handshake, Huawei, IBM, Indeed, Union Investment, Workday
  • SILVER: Aetna, Alibaba Cloud Computing, Baidu, Budget Direct, Capital One, Cerner, Inspur, ODPi, Private Internet Access, Red Hat, Target
  • BRONZE: Airport Rentals, The Blog Starter, Bookmakers, Cash Store, Bestecasinobonussen.nl, CarGurus, Casino2k, Cloudsoft, The Economic Secretariat, Emerio, Footprints Recruiting, Gundry MD, HostChecka.com, Host Advice, HostingAdvice.com, Journal Review, LeoVegas Indian Online Casino,  Mutuo Kredit AG, Online Holland Casino, ProPrivacy, PureVPN, RX-M, SCAMS.info, Site Builder Report, Start a Blog by Ryan Robinson, Talend, The Best VPN, Top10VPN, Twitter, Web Hosting Secret Revealed
  • TARGETED PLATINUM: CloudBees, DLA Piper, JetBrains, Microsoft, OSU Open Source Labs, Sonatype, Verizon Media
  • TARGETED GOLD: Atlassian, The CrytpoFund, Datadog, PhoenixNAP, Quenda
  • TARGETED SILVER: Amazon Web Services, HotWax Systems, Rackspace
  • TARGETED BRONZE: Bintray, Education Networks of America, Google, Hopsie, No-IP, PagerDuty, Peregrine Computer Consultants Corporation, Sonic.net, SURFnet, Virtru

To sponsor The Apache Software Foundation, visit http://apache.org/foundation/sponsorship.html . To make a one-time or monthly recurring donation, please visit https://donate.apache.org/

# # #

Report prepared by Sally Khudairi, Vice President Marketing & Publicity, with contributions by Rich Bowen, Vice President Conferences; Sharan Foga, Vice President Community Development; Mark Thomas, Vice President Brand Management; David Nalley, Vice President Infrastructure; Greg Stein, ASF Infrastructure Administrator; Tom Pappas, Vice President Finance; and Daniel Ruggeri, Vice President Fundraising.

For more information, subscribe to the announce@apache.org mailing list and visit http://www.apache.org/, the ASF Blog at http://blogs.apache.org/, the @TheASF on Twitter, and https://www.linkedin.com/company/the-apache-software-foundation.

(c) The Apache Software Foundation 2019.

Thursday December 05, 2019

Launch of the 2020 ASF Community Survey

This week, we are excited to launch the 2020 ASF Community Survey, with which we will gather scientific data that allows us to understand our community better, both in its demographic composition, and also in collaboration styles and preferences. We want to find areas where we can continue to do great work and others where we need to provide more support so that our projects can keep growing healthy and diverse. This joint effort was long overdue: our last survey of this kind was implemented in 2016 [1], which means that all the information we currently have about our communities is outdated. 

For this new version of the survey, we have hired Bitergia to design it, a company expert in analysing open source communities and other types of software development teams. They have experience in this type of surveys and research in open source communities. Among other studies, their previous work includes an analysis in gender diversity in technical contributions for OpenStack [2]. The 2020 ASF Community Survey is the first part of a two-stage research. The second part consists of interviews with people who have contributed to the ASF, in order to assess their experience. We'll share more on this second part of the project soon. 

This survey and research are part of the ASF efforts to build a more equitable, inclusive and diverse community. They are run by the Vice Presidency of Diversity and Inclusion, a team formed last May. We'll share a broader update about this group in January.

If you have an apache.org email address you will receive an email by Thursday, Dec 5 at 3PM PST, with a link to the survey. Please take 15 minutes to complete it. If you didn't receive the email or you do not have an apache.org email address, please use this link to complete the survey: 

https://communitysurvey.limequery.org/454363

We are looking to hear from everyone in our community: from users and contributors, to committers and PMCs. Everyone's voice matters. 

Find more information about the 2020 ASF Community Survey on its page on Confluence [3], including the privacy policy governing this initiative. If you are part of our community, either as a user, contributor, or both, your participation is paramount to the success of this project! Please consider filling out the survey, and share this blog on social media, send it to your fellow Apache contributors. As individuals form the Apache community, your opinion matters: we need to hear your voice.

Links

[1] https://cwiki.apache.org/confluence/display/COMDEV/ASF+Committer+Diversity+Survey+-+2016
[2] https://blog.bitergia.com/tag/openstack/
[3] https://cwiki.apache.org/confluence/display/EDI/Launch+Plan+-+The+2020+ASF+Community+Survey

# # #

Wednesday December 04, 2019

The ApacheⓇ Software Foundation Welcomes CloudBees as its Newest Targeted Sponsor at the Platinum Level

Donation of Continuous Delivery Software Services Helps Support Apache Infrastructure, Projects, and Communities

Wakefield, MA, and DevOps World/Jenkins World Lisbon, Portugal —4 December 2019— The Apache® Software Foundation (ASF), the all-volunteer developers, stewards, and incubators of more than 350 Open Source projects and initiatives, announced today that CloudBees has become an ASF Targeted Sponsor at the Platinum level.

"We are pleased to welcome CloudBees as a Targeted Platinum Sponsor," said ASF Vice President Fundraising Daniel Ruggeri. "ASF Sponsors help offset our day-to-day operating expenses, from Accounting to Infrastructure to Legal to Marketing and more. Targeted Sponsorship provides contributions aimed at activities and programs that support specific ASF operations as well as designated Apache projects and their communities. Among the many benefits towards Apache Infrastructure, Targeted donations include development/collaboration tools, co-location space, cloud services, monitoring systems and more. We are excited to add continuous delivery software services to the list, courtesy of CloudBees."

"CloudBees is a strong advocate of Open Source. As major contributors to many Open Source projects, including Jenkins and Jenkins X, we see the value organizations derive from using Open Source every day," said Sacha Labourey, CEO and co-founder, CloudBees. "Our contribution to The Apache Software Foundation will enable it to continue its mission to develop Open Source projects and support the use of Open Source all over the world. We are proud to be a targeted sponsor."

The ASF Infrastructure Team keeps the Foundation's global services running 24x7x365 at near 100% uptime at less than US$5,000 per project. Performance statistics that reflect 7M+ weekly checks and project mail volume across 2,059 lists are available at http://status.apache.org/

"Every day, billions of users of Apache projects benefit from the many services provided by ASF Infrastructure," added Ruggeri. "Our sponsors' generosity helps bolster the support provided to more than 350 Apache projects and their communities. We look forward to expanding the Targeted Sponsorship program to meet the growing demand for Apache projects that build upon our mission of providing software for the public good."

CloudBees joins the following Targeted Sponsors:
  • Platinum —DLA Piper, JetBrains, Microsoft, OSU Open Source Labs, Sonatype, and Verizon Media;

  • Gold —Atlassian, The CrytpoFund, Datadog, PhoenixNAP, and Quenda;

  • Silver —Amazon Web Services, Hotwax Systems, and Rackspace; and

  • Bronze —Bintray, Education Networks of America, Google, Hopsie, No-IP, PagerDuty, Peregrine Computer Consultants Corporation, Sonic.net, SURFnet, and Virtru.

To become an ASF Sponsor, please visit http://apache.org/foundation/sponsorship.html

About CloudBees
CloudBees is powering the continuous economy by offering the world’s first end-to-end continuous software delivery management system (SDM). For millions of developers and product teams driving innovation for businesses large or small, SDM builds on continuous integration (CI) and continuous delivery (CD) to enable all functions and teams within and around the software delivery organization to best work together to amplify value creation. CloudBees is the CI, CD and application release orchestration (ARO) powerhouse, built on the commercial success of its products as well as its open source leadership. CloudBees is the largest contributor to Jenkins and Jenkins X, and a founding member of the Continuous Delivery Foundation (CDF). From startups with full-stack developers practicing NoOps to large Fortune 100 companies, CloudBees enables all software-driven organizations to intelligently deploy the right capabilities at the right time. 

Over 3,500 of the world's best-known brands and over 50% of the Fortune 500 depend on CloudBees because of its ability to work across any cloud, in any development environment and to balance corporate governance and control with developer flexibility and freedom. CloudBees is home to the world’s leading DevOps experts, helping thousands of companies harness the power of "continuous everything" and putting them on the fastest path from great idea, to great software, to great business value. 

Backed by Matrix Partners, Lightspeed Venture Partners, Verizon Ventures, Delta-v Capital, Golub Capital and Unusual Ventures, CloudBees was founded in 2010 by former JBoss CTO Sacha Labourey and an elite team of continuous integration, continuous delivery and DevOps professionals. Follow CloudBees on Twitter, Facebook and LinkedIn.

About The Apache Software Foundation (ASF)
Established in 1999, the all-volunteer Foundation oversees more than 350 leading Open Source projects, including Apache HTTP Server —the world's most popular Web server software. Through the ASF's meritocratic process known as "The Apache Way," more than 760 individual Members and 7,400 Committers across six continents successfully collaborate to develop freely available enterprise-grade software, benefiting millions of users worldwide: thousands of software solutions are distributed under the Apache License; and the community actively participates in ASF mailing lists, mentoring initiatives, and ApacheCon, the Foundation's official user conference, trainings, and expo. The ASF is a US 501(c)(3) charitable organization, funded by individual donations and corporate sponsors including Aetna, Anonymous, ARM, Bloomberg, Budget Direct, Capital One, Cerner, Cloudera, Comcast, Facebook, Google, Huawei, IBM, Indeed, Inspur, LeaseWeb, Microsoft, Oath, ODPi, Pineapple Fund, Pivotal, Private Internet Access, Red Hat, Target, and Union Investment. For more information, visit http://www.apache.org/ and https://twitter.com/TheASF

© The Apache Software Foundation. "Apache", "Apache HTTP Server", and "ApacheCon" are registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries. All other brands and trademarks are the property of their respective owners.

# # #

MEDIA CONTACTS:

Sally Khudairi
Vice President
The Apache Software Foundation
+1 617 921 8656
press@apache.org

Sydney Holmquist 
PAN Communications 
+1 407 734 7327
cloudbees@pancomm.com

Wednesday November 27, 2019

Support Apache: Individual Giving and Corporate Gifts Campaigns

Your support helps The Apache Software Foundation —the world's largest Open Source foundation— to continue to provide $20B+ worth of software for the public good at 100% no cost.

As the US Thanksgiving holidays are upon us, our end-of-year Individual Giving and Corporate Gifts campaigns have begun. Your support of The Apache Software Foundation helps ensure 350+ Apache projects and initiatives remain accessible to all, absolutely free of charge.

Support from donors enables the all-volunteer, vendor-neutral ASF ensure its community-driven projects are freely available to billions of users, to steward, develop, and advance the next generation of Open Source innovations "The Apache Way", and nuture diverse communities around the globe.

This Tuesday, 3 December, is Giving Tuesday —the global fundraising movement that launched the second largest giving day of the year. When you donate to the ASF on Giving Tuesday itself, you can be a part of something even bigger: in 2018 more than $400M was raised for hundreds of organizations worldwide.

Whether you donate on Giving Tuesday or as part of your year-end contributions, giving to the ASF is easy: 

Individual Donations

  • One-Time or Monthly Recurring Donations: visit https://donate.apache.org/ to make a donation using a debit or credit card, ACH electronic transfer, or PayPal. You'll receive a receipt for your tax-deductible* contribution via email.

  • Purchasing Programs: those of you who shop from Amazon can start your retail journey at https://smile.amazon.com/ so a portion of your qualifying purchases will be donated to the ASF.

  • Additional Options: to mail us a check, donate cryptocurrency, or explore other contribution options, please visit http://apache.org/foundation/contributing.html

Corporate Gifts

  • One-time or Recurring Donations: some organizations contribute to the ASF in the form of a cash donation --whether it's a one-time gift or recurring monthly made at https://donate.apache.org/ Those wishing to contribute cryptocurrency and other donation options are welcome to visit http://apache.org/foundation/contributing.html for details.

  • Corporate Sponsorship: those seeking to become a Sponsor using a credit card, ACH transfer, or PayPal may easily do so at https://donate.apache.org/ . We invite interested parties to review our Sponsorship program at http://apache.org/foundation/sponsorship.html

  • Corporate Giving Programs: your gift to the ASF as part of an annual corporate giving program helps bolster the ASF’s mission. Companies such as Bloomberg Philanthropies, IBM, Microsoft, and many others' matching gift programs offer tax benefits, and provide their employees the ability to boost their support of a diverse set of nonprofit organizations. Contact us at fundraising(at)apache(dot)org to get started.

  • Corporate Matching Gifts: if you have a matching gift program, your contribution to the ASF can be generously increased. Matching gift programs augment corporate contributions and help further support the ASF. Contact us at fundraising(at)apache(dot)org for more information.

  • Third-Party Fundraising Platforms: the ASF is an official charity in the Benevity Causes Portal as part of numerous corporate giving initiatives, such as the Microsoft Tech Talent for Good volunteer program, among others. For more information, visit https://www.benevity.com/


The Apache Software Foundation is an all-volunteer community. The ASF does not pay for code development or contributions by its Board of Directors, Executive Officers, 765 Individual ASF Members, 205 Apache Project Management Committees, 7,500+ Committers, and countless contributors. 

Your tax-deductible* contribution to the ASF helps offset day-to-day operating expenses that include critical Infrastructure services (75%), plus Marketing and Publicity, Trademarks and Brand Management, Legal Affairs, Accounting, Operational support, and more. Less than 10% is spent on overhead. 

The ASF's diverse accomplishments are highlighted in the Annual Report for the 2019 Fiscal Year. Many of these successes were made possible by contributions made by organizations and individuals such as yourself.

Thank you for supporting the greater Apache community.

* For those based in the US, donations are 100% tax deductible to the full extent of the law. As regulation varies, we encourage you to consult a qualified advisor experienced with your local tax law pertaining to donations. 

The ASF is a US 501(c)(3) not-for-profit charitable organization, whose tax identification number is 47-0825376. More information about non-profits and related issues can be found at the Internet Nonprofit Center

 The ASF is recognized by Charity Navigator and cited with the Gold Seal of Transparency by GuideStar.

# # #

Tuesday November 26, 2019

The Apache Software Foundation Objects to the For-Profit Sale of the .org Registry

Non-profit organizations like The Apache Software Foundation serve the public good in many ways. It is critical to our mission and to the mission of many other non-profits, that we be able to reliably disseminate information via the Internet. This principle of enabling the open exchange of information to and among those we serve lies at the heart of what we do at The Apache Software Foundation. Indeed it lies at the heart of a free society.

It is for that reason that we object to the sale of the .org registry to a for-profit company. A private, for-profit registry is unlikely to protect the interests of non-profit foundations and organizations on the Internet the way a non-profit can.

We call on ICANN to stop the sale of the Public Interest Registry to Ethos Capital, and ensure that the .org registry remains in the hands of a body capable of governing neutrally and with sensitivity to the issues that are unique to the non-profit business sector.


Background information

# # # 

Wednesday November 13, 2019

The Apache Software Foundation Operations Summary: May - July 2019

FOUNDATION OPERATIONS SUMMARY

First Quarter, Fiscal Year 2020 (May - July 2019)

"We are excited to support The Apache Software Foundation, championing an organization that is delivering software for public good. Apache's software is core to much of the Internet and is used by many of our customers and community."
Zaheda Bhorat, Head of Open Source Strategy, Amazon Web Services (ASF Platinum Sponsor and Targeted Silver Sponsor)

> Conferences and Events: During Q1, we did not hold any official Apache events.

We were actively planning for the following upcoming events: ApacheCon North America in September, and ApacheCon Europe in October.

Upcoming events are always listed at events.apache.org and sponsorship opportunities are available for all upcoming events. Contact planners@apachecon.com with any questions.

> Community DevelopmentThroughout this quarter a lot of work has been done in helping support the preparations for ApacheCon NA and EU. With a 3 day Community track planned for ApacheCon NA and a 2 day Community track planned for ApacheCon EU, we helped co-ordinate and manage the CFP submissions to select the content for the tracks.  

In early 2018, we setup a Redbubble store as an easy way for any of our ASF projects to order their own branded items such as t-shirts and mugs etc. In preparation for ApacheCon, many of our projects have asked for their logos to be added to the store so they can purchase a range of merchandise and promote their projects visually.

As a regular GSoC mentor organisation, we have been invited to participate at the Mentor Summit in Germany. Two of our existing GSoC mentors have been chosen to attend.

Following on from the discussions last quarter on ways to drive better diversity and inclusion, a separate mailing list has been established that will focus on discussing, defining and co-ordinating strategies to improve diversity and inclusion across the foundation.

We are continuing to investigate opportunities for smaller Apache Roadshows in 2020 including the possibility of one in India. We have also been invited to participate with an Apache track in CCOSS 2019 in Mexico.

Mailing list traffic has decreased this quarter probably due to the holiday season.

> Committers and Contributions: Over the past quarter, 1,646 contributors committed 44,068 changes that amount to 17,190,978 lines of code across Apache projects. The top 5 contributors, in order, were: Andrea Cosentino (921 commits), Duo Zhang (906 commits), Claus Ibsen (748 commits), Jean-Baptiste Onofré (722 commits), and Mark Thomas (664 commits).

All individuals who are granted write access to the Apache repositories must submit an Individual Contributor License Agreement (ICLA). Corporations that have assigned employees to work on Apache projects as part of an employment agreement may sign a Corporate CLA (CCLA) for contributing intellectual property via the corporation. Individuals or corporations donating a body of existing software or documentation to one of the Apache projects need to execute a formal Software Grant Agreement (SGA) with the ASF. 

During Q1 FY2020, the ASF Secretary processed 188 ICLAs, 11 CCLAs, and 14 Software Grants. History of Apache committer growth can be seen at https://projects.apache.org/timelines.html

> Brand Management: Operations — The work of the Brand Management team falls broadly into one of three categories:

  • trademark transfers and registrations
  • granting permission to use our marks
  • addressing potential infringements of our marks

The volume of work has remained steady this quarter. Registrations and transfers are lengthy processes but the tracking system we have put in place remains up to the task.

This quarter has seen the usual collection of requests to use Apache marks for user groups, events, merchandise and publications with nearly all requests being granted, subject to our Trademark Usage Policy. Use of our marks for events is now dependent on the event having an acceptable anti-harassment policy.

Registrations — A number of registrations came up for renewal this quarter. We review each renewal as it comes up and, as a result, opted not to some of those registrations. The remaining renewals are in now progress. Some registrations, particularly those outside the US, tend to be more complex. This quarter some of our registrations in China have required additional work to help them progress.

Infringements — Potential infringements are brought to our attention from both internal and external sources. The majority of infringements we see are accidental and our project communities are able to resolve these quickly and informally with occasional input from the Brand Management team. A small number of issues take longer to resolve. We made progress on some of these this quarter and hope that that progress will continue next quarter.

It was pleasing to see a number of PMCs successfully address potential infringements independently this quarter. As the ASF continues to grow, having PMCs that can operate more independently in this area helps the overall Brand Management capability scale to match the ASF's growth.

And finally…

The Brand Management team welcomes your comments and suggestions as well as any questions you might have. Please see https://www.apache.org/foundation/marks/contact for our contact details.


> Infrastructure:
 Infrastructure has had an interesting quarter, combining a regular workload of upgrades, ticket handling, and project support, then needing to change gears for July to perform a full datacenter move to lower our costs.

We spent a significant amount of time upgrading and improving our systems. The backup system was simplified in FY19Q3, and we took another pass at it this quarter to expand storage space and improve the tooling via the open source backuppc system. Numerous upgrades of services, such as Jira and Jenkins, were performed to keep us secure and up to date.

One of the newer services we are testing is the use of a "Content Delivery Network" (CDN) for our projects' websites. A few projects are participating in a trial, and we will roll out wider usage later this year, after successful trials.

Lastly, we have started a concerted effort to expand and diversify our CI/CD capacity. The continued growth of projects at the Foundation, and modern development trends towards CI/CD, have combined to create an ever-increasing demand for resources. We are increasing our system capacity, tracking projects' usage, and looking towards new types of systems and providers.

> Financial Statement:



> Fundraising: Fundraising continues to carry on smoothly. New sponsors are successfully onboarding and renewals are occurring without incident. In this quarter, we renewed and onboarded several sponsors smoothly. We also spent the quarter continuing our work on consolidating existing sponsorship agreements into our formalized foundation offerings. This helps to limit one-off processing and to keep operations as efficient as possible.

We formalized a number of our event sponsorship/support activities into ongoing processes that are safe, repeatable, and comply with industry best-practices as we continue support of ApacheCon and our Roadshows.

Another significant step for Fundraising this quarter was the introduction of form-based onboarding which helps keep data clean and helps enable further automation for the road ahead!

We are delighted to report more than $10,000 in individual giving was donated to The ASF in addition to our foundation sponsors. Thank you, deeply, for your support!

= = = 

Thank you to all our Sponsors --

  • PLATINUM: Amazon Web Services, Cloudera, Comcast, Facebook, Google, LeaseWeb, Microsoft, Pineapple Fund, Verizon Media, Tencent
  • GOLD: Anonymous, ARM, Bloomberg, Handshake, Huawei, IBM, Indeed, Union Investment, Workday
  • SILVER: Aetna, Alibaba Cloud Computing, Baidu, Budget Direct, Capital One, Cerner, Inspur, ODPi, Private Internet Access, Red Hat, Target
  • BRONZE: Airport Rentals, The Blog Starter, Bookmakers, Cash Store, Bestecasinobonussen.nl, CarGurus, Casino2k, Cloudsoft, The Economic Secretariat, Emerio, Footprints Recruiting, Gundry MD, HostChecka.com, Host Advice, HostingAdvice.com, Journal Review, LeoVegas Indian Online Casino,  Mutuo Kredit AG, Online Holland Casino, ProPrivacy, PureVPN, RX-M, SCAMS.info, Site Builder Report, Start a Blog by Ryan Robinson, Talend, The Best VPN, Top10VPN, Twitter, Web Hosting Secret Revealed
  • TARGETED PLATINUM: CloudBees, DLA Piper, JetBrains, Microsoft, OSU Open Source Labs, Sonatype, Verizon Media
  • TARGETED GOLD: Atlassian, The CrytpoFund, Datadog, PhoenixNAP, Quenda
  • TARGETED SILVER: Amazon Web Services, HotWax Systems, Rackspace
  • TARGETED BRONZE: Bintray, Education Networks of America, Google, Hopsie, No-IP, PagerDuty, Peregrine Computer Consultants Corporation, Sonic.net, SURFnet, Virtru

To sponsor The Apache Software Foundation, visit http://apache.org/foundation/sponsorship.html . To make a one-time or monthly recurring donation, please visit https://donate.apache.org/

# # #

Report prepared by Sally Khudairi, Vice President Marketing & Publicity, with contributions by Rich Bowen, Vice President Conferences; Sharan Foga, Vice President Community Development; Mark Thomas, Vice President Brand Management; Greg Stein, ASF Infrastructure Administrator; Tom Pappas, Vice President Finance; and Daniel Ruggeri, Vice President Fundraising.

For more information, subscribe to the announce@apache.org mailing list and visit http://www.apache.org/, the ASF Blog at http://blogs.apache.org/, the @TheASF on Twitter, and https://www.linkedin.com/company/the-apache-software-foundation.

(c) The Apache Software Foundation 2019.

Monday November 04, 2019

The Apache Software Foundation Announces Apache® SINGA™ as a Top-Level Project

Open Source machine learning library in use at Citigroup, NetEase, and Singapore General Hospital, among others.

Wakefield, MA —4 November 2019— The Apache Software Foundation (ASF), the all-volunteer developers, stewards, and incubators of more than 350 Open Source projects and initiatives, announced today Apache® SINGA™ as a Top-Level Project (TLP).

Apache SINGA is an Open Source distributed, scalable machine learning library. The project was originally developed in 2014 at the National University of Singapore, and was submitted to the Apache Incubator in March 2015.

"We are excited that SINGA has graduated from the Apache Incubator," said Wei Wang, Vice President of Apache SINGA and Assistant Professor at the National University of Singapore. "The SINGA project started at the National University of Singapore, in collaboration with Zhejiang University, focusing on scalable distributed deep learning. In addition to scalability, during the incubation process, built multiple versions to improve the project’s usability and efficiency. Incubating SINGA at the ASF brought opportunities to collaborate, grew our community, standardize the development process, and more."

Apache SINGA is a distributed machine learning library that facilitates the training of large-scale machine learning (especially deep learning) models over a cluster of machines. Various optimizations on efficiency, memory, communication and synchronization are implemented to speed it up and scale it out. Currently, the Apache SINGA project is working on SINGA-lite for deep learning on edge devices with 5G, and SINGA-easy for making AI usable by domain experts (without deep AI background).

Apache SINGA is in use at organizations such as Carnegie Technologies, CBRE, Citigroup, JurongHealth Hospital, National University of Singapore, National University Hospital, NetEase, Noblis, Shentilium Technologies, Singapore General Hospital, Tan Tock Seng Hospital, YZBigData, and others. Apache SINGA is used across applications in banking, education, finance, healthcare, real estate, software development, and other categories.

"So glad to see the first Apache project focusing on distributed deep learning become a Top-Level Project," said Beng Chin Ooi, Distinguished Professor of National University of Singapore who initialized the SINGA project, and a member of the Apache SINGA Project Management Committee. "It is essential to scale deep learning via distributed computing as the deep learning models are typically large and trained over big datasets, which may take hundreds of days using a single GPU."

"I am glad to witness the graduation of Apache SINGA as a TLP," said Gang Chen, Professor and Dean of Zhejiang University and Dean of ZJU-NetEase research lab. "We will continue to contribute to the development and use it for industry applications such as smart fabric printing, e-commerce recommendation and smart cities."

"Apache SINGA has a flexible distributed training framework," said Sheng Wang, Research Scientist at the DAMO Academy of Alibaba and a member of the Apache SINGA Project Management Committee. "SINGA can implement multiple popular distributed training strategies, including synchronous and asynchronous training. It achieved excellent scalability in comparison with other deep learning platforms."

"Apache SINGA has been applied to support many different healthcare applications at MZH Technologies," said Zhongle Xie, CTO of Hangzhou MZH Technologies and a member of the Apache SINGA Project Management Committee. "The performance of disease diagnoses based on X-Ray images could even pass the radiologists. We also built a food recognition app using SINGA to help patients monitor their food intake and log the nutrition automatically."

"We are working with cardiologists in Fuwai Hospital, Beijing, China, to develop a machine learning/deep learning cardiovascular disease prediction model, using cardiovascular risk factors and other indirect factors such as diet and exercise," said MZH Technologies co-founder and Beijing Institute of Technology Professor, Meihui Zhang. "We are also using Apache SINGA for data cleaning and integration."

"Besides scalability, SINGA team is continuously improving the library by adding new features to make it easier to use," said Moaz Reyad, Postdoctoral Researcher at Université Grenoble Alpes, and a member of the Apache SINGA Project Management Committee. "For example, SINGA has a sub-component called SINGA-auto (original name is Rafiki), which provides AutoML features like automatic hyper-parameter tuning."

"We would like to thank all our mentors for guiding the project and all contributors for helping on this project from incubation to graduation," added Wang. "Deep learning and other AI technologies are changing the world from many aspects. We welcome newcomers to join our community to make contributions to this exciting field!"

Availability and Oversight
Apache SINGA software is released under the Apache License v2.0 and is overseen by a self-selected team of active contributors to the project. A Project Management Committee (PMC) guides the Project's day-to-day operations, including community development and product releases. For downloads, documentation, and ways to become involved with Apache SINGA, visit http://singa.apache.org/ and https://twitter.com/ApacheSINGA

About the Apache Incubator
The Apache Incubator is the entry path for projects and codebases wishing to become part of the efforts at The Apache Software Foundation. All code donations from external organizations and existing external projects enter the ASF through the Incubator to: 1) ensure all donations are in accordance with the ASF legal standards; and 2) develop new communities that adhere to our guiding principles. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF. For more information, visit http://incubator.apache.org/

About The Apache Software Foundation (ASF)
Established in 1999, the all-volunteer Foundation oversees more than 350 leading Open Source projects, including Apache HTTP Server --the world's most popular Web server software. Through the ASF's meritocratic process known as "The Apache Way," more than 730 individual Members and 7,000 Committers across six continents successfully collaborate to develop freely available enterprise-grade software, benefiting millions of users worldwide: thousands of software solutions are distributed under the Apache License; and the community actively participates in ASF mailing lists, mentoring initiatives, and ApacheCon, the Foundation's official user conference, trainings, and expo. The ASF is a US 501(c)(3) charitable organization, funded by individual donations and corporate sponsors including Aetna, Alibaba Cloud Computing, Anonymous, ARM, Baidu, Bloomberg, Budget Direct, Capital One, Cerner, Cloudera, Comcast, Facebook, Google, Handshake, Hortonworks, Huawei, IBM, Indeed, Inspur, Leaseweb, Microsoft, ODPi, Pineapple Fund, Pivotal, Private Internet Access, Red Hat, Target, Tencent, Union Investment, Workday, and Verizon Media. For more information, visit http://apache.org/ and https://twitter.com/TheASF

© The Apache Software Foundation. "Apache", "SINGA", "Apache SINGA", and "ApacheCon" are registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries. All other brands and trademarks are the property of their respective owners.
# # #

Calendar

Search

Hot Blogs (today's hits)

Tag Cloud

Categories

Feeds

Links

Navigation