OK, welcome everyone to our panel session, Apache Way for Business. I have with me a hand-picked group of four people who are not on the board at the moment. Unfortunately, we are clashing with the board meeting, but I'm hoping that between them we have a good mix of experience, different projects, different ages, different levels of having been or nearly been incubator PMC chair to tell us a little bit about involving businesses in the Apache Software Foundation, building businesses on top of it, things that have worked, things that maybe didn't work quite so well, and perhaps also some sort of warning signs for disincubating projects is going to need a bit more help before it's ready to graduate. So what I'd like to do is get a very brief introduction from all of our panel and then I'll kick off with some of the questions we've got. OK. Well, I'll start then. My name is Atodoma. I've been involved with Apache since 2004 or something and committed, became a committer at that year, and been involved with several projects, still involved with several projects. Nowadays, the last few years mostly as a mentor of potlinks in the incubator, seen some potlinks that graduate successfully, like Arivata or SXDB, currently mentor on NetBeans and Apache Streams. So it's my involvement right now. Hello, everyone. My name is Roman. I apologize for my voice because I'm recovering from a call, but hopefully you can hear me all right. So I've been involved in ASF since 2008, roughly mostly in big data Hadoop ecosystem. I actually used to be a VP of Apache Incubator, mentor on a few projects, so Spark I guess is the most famous one out of everything that I've mentored so far. And interestingly enough, this involvement in Apache from the business slash new projects perspectives actually was partially responsible for lending me my current job, which is at Pivotal, where I am director of open source, because Pivotal at the time wanted to have somebody familiar with open source to help them open source all of its data portfolio, and including legal side of it, developer education, sales, basically the whole end to end business strategy plus actual execution. So that was really unusual that something that I thought I was doing just for fun and for free would all of a sudden lend me a job. Like I'm expected to be hired as a committer on foo, but not as an incubator guy, so that's me. Cool, hi everyone. My name is Daniel Rajeri, and in the ASF I've been involved in the web server project. I guess since the mid 2000s became committer in 2010, just became member earlier this year. And I've hung around the community list quite a bit because we do love our community here, and then also sticking around with the incubator a bit. What's kind of neat, similar to what you're saying, I'm coming at it from a different angle. I'm actually in an industry where open source is kind of weird, so I'm one of our inner sourcing evangelists using that as a foothold to kind of move our own stuff that we're doing in-house into the public. So happy to talk with you guys about those things if you have such an interest. And I'm John Amon. I actually came to the incubator in 2011 as part of a new popling and have kind of stuck around since you probably know my name from the board reports and having to remind everyone to actually get their report out there so that we have something of substance. I'm with Tamiya and Juno and now Edgin and Ariotosca and probably a few other podlings that I can't think of off the top of my hat, trying to get them through the rest of the incubator and get them promoted to top level projects. And similar to what Roman and Daniel just talked about, I am also working on trying to get some internal software open sourced throughout my company to get them actually contributing back more and more to open source. Okay, so I've been going around the conference the last couple of days picking people's brains on what topics they'd like us to cover today. I'm going to try and have us tell a story, ticking off as many of those as possible. And please do grab the mic if you feel you have something to say on the topic or you've got something to contribute. So the first one that comes up, especially with newer companies coming into the ASF, they sort of come along and say, either what's all this about individuals or how do I get five of my staff to be committers on this project that I've just decided is really important? Can someone talk on the individuals and why that matters for the second question? I guess I can definitely take a stab at that. The reason I reached out for the mic is because I also happen to be an employee of Linux Foundation, which is a different way of doing open source collaborative projects. And with Linux Foundation, it is all about companies in a way, right? Because with Linux Foundation, developers, of course, do matter. But at the end of the day, it's companies agreeing on the governance and sort of the bylaws and how the project is structured and what it means to be a committer and what it means to be on a PMC if there is such a thing. And it's just a different way of governing. I mean, I'm not saying that one is better than the other. Actually, nowadays that I'm also an employee of Linux Foundation, it would be weird for me to say that one is better than the other. It's just that different, right? And explaining the difference is probably the first step that you go through when a new company comes and tries to open source something or, you know, suggest it to Apache, because it may very well be the case that Apache is not a good place for them. So like us asking this, you know, there is a certain presumption that, of course, the answer is no. Like, you know, we, of course, we should tell those companies that it's all about individuals and you cannot really just make committers willy-nilly. Well, you can just not with SF. So if, you know, GitHub works for you, great. If, you know, Linux Foundation works for you, great. It's just SF happens to be opinionated about very few things, but the ones that we are opinionated about, we are really strongly opinionated about. And what I find super useful is just getting it out there as quickly as possible, because the list is not big. You know, you can basically articulate that list within, you know, 15, 20 minutes and say, like, here's the stuff we will absolutely not budge on. Everything else is negotiable. So to me, that's kind of like, that's how you open the conversation. And then everything else flows, you know, from that set of non-negotiable principles. Yeah, I can fully agree on that. I think I can also give an other angle on that. My company, HIPAA, is really providing an open source product, which is Apache licensed and it's been so since, I think, 2005 already. So we've been kind of having a logical and natural tie in the way of thinking, the Apache way. And for us as a company to participate and contribute to the ASF is the natural thing to do because we rely on like 80, 90% of our code base is itself based on Apache projects. And we build our product on top of it, which is again Apache licensed. But so we rely heavily on the health and the durability of the underlying stack where we building our product upon. So contributing and participating in these projects is like fundamental thing for us to do so. It's just gardening and supporting our own underlying stack. And another thing in that is we rely on these Apache projects. We also contributing on a project of our own, which we started in the Apache foundation. But the point is not so much to get it in the open source or get it at Apache as such. It's more like the Apache way of sharing the projects, having multiple parties and people involved in that. So you get a diversity and that gives a longer lifeline and insurance that what you might wanna take out of that project is not necessarily the only way. And by having multiple people contributing on that from a diverse set of companies or individual participants on that, you actually build a stronger product with a much longer durability of that. So for us that's the natural thing to do and it's just gardening our own product foundation in the long run. Well, and then also one of the final things to point out as a 501C3, we cannot give any particular special benefit to any particular special entity such as a business. So it really is software as a public good. So if one company kinda owns the PMC of any particular project, that could put tax status at risk, right? And nobody wants to deal with that. Okay, relating to the individuals thing, one thing that we sometimes try and educate the companies with is that having your staff involved in an Apache project is a good thing for the staff member and makes them happier. Anyone wanna touch on some of the employee benefit type stuff from that? So I'll be one of the, yeah, I'll jump right into that because I have the mic, so. So I'll kinda tell my own story. I am absolutely floored that through my involvement in the project, I've met some really great people. I've been exposed to some really great ideas. My professional network, my personal network has grown quite a bit. So I mean, it's really obvious to say, oh, Daniel just joined this community. He's immersed in some of the most brilliant minds in the world, how could that not be a good thing, right? I mean, that's just seems so obvious to me, so. So I'll add to that and say it's really great to even see your own open source in use in your commercial products. It is, not everything is gonna be open source and I think we all understand that and the Apache license is focused on the fact that there is a difference between your commercial products, your open source products. And being able to leverage that, being able to draw both internal ideas and external ideas from the community to try to build the open source pieces makes it so that your notoriety is out there, your public recognition over what you're doing is something that's just coming up constantly, assuming that what you're working on is a great project that lots of people are using. And interestingly enough, what I also found very sort of compelling is when you explain to developers that ASF basically functions as a constitution, you know, if those developers from the corporation contribute to an ASF project, they have certain rights. Just like anybody who is subject to a constitution, you know, has a certain set of rights. And a lot of those rights actually help in dealing with what's typically known as managerial bullshit.   And not in a defined sense, not in like, well, this is bullshit. I'm not going to do this. But it's like, no, if we do this, we will get kicked out of incubator or ASF. I cannot do it not because I am, you know, just defying you. I cannot do it because it will jeopardize the project. And that works extremely well. Not a single company wants to be a poster child for the first project that got kicked out of ASF because they violated, you know, the constitution. So yeah, you know, when you explain it to developers, especially, you know, the ones that have been subject to the sort of closed source development, they're like, yeah, we want ASF. And, you know, that's how you get them going. Yeah, that's a good point. And I'd like to add in the, I mean, I fully agree, but it's kind of the negative, if you're not, for my company, it's actually beneficial to being an open source project. And actually our product is used by large organizations like Dutch government and governmental organizations, really find the fact that it's open source and backed by ASF or Apache licensed communities, a really strong point in trusting the company in contributing and honoring the quality of the product itself. So the fact that we have several committees within the company, who on an individual basis participate at ASF, kind of also showcases to our customers that the company truly is of good faith. And investing in that and doing the thing beyond just the commercial benefit of the company alone. So that's a major added value, I think, not just for the employee itself, but through him also to the company. Okay, so I was chatting last week with a company interested in getting involved in an Apache project. And they said, we've got some money and we've got a couple of developers and we really want this new feature adding to project name removed to avoid embarrassment. How do we do it? Like I tried ringing up the sponsorship team and said, hey, can I give you some money to add that feature? And they just said, no, what am I supposed to do? I've got money, I've got developers, help me. What do we say to those well-meaning but confused people who wanna help? Start off by reaching out to that community. We see a lot of males on ComDev and on Webmaster and incubator generalists saying, we wanna add this feature. It's great that you're trying to start at the top level, but you really need to focus on the actual project and talk to that project directly to figure out what can you do to contribute this back. It could be that they're used to doing things like Jira tickets with patches or they're used to doing GitHub pull requests. You have to reach out to that community first, figure out what works best for them. It's gonna be different project to project. No two, well, a lot of projects do operate the same way, but not every project operates with a consistent mantra of what it is they're doing. You seem really eager. Yeah, I actually love this question because it pops up all the time when I talk to companies as well. And I think the analogy I sort of finally settled on is this, I'm a big football fan, not American football, the real one. So whenever a company asks that question, it says though they're asking a question, we have this favorite team of ours, but it seems to be losing all the time. How can we help? What do we do to make it win? Like, do we go to FIFA and give FIFA some money? Well, I guess you could do that. It doesn't do you any good, but it actually gets you in trouble as we've found out recently, but it's just, it's not how it operates, right? Well, if you want to help, you actually find out like you reach out to the club, right? You know, you reached out to the team that is losing. And that team is typically operating as a club, right? And within that club, you can basically have all sorts of conversations. Maybe it's a different player that needs to be brought onto the team, right? Maybe it's somebody from a different club that the club just doesn't have money to, you know, buy from, you know, some other club. But if you donate some extra money, you know, that player can be bought. Now, does it guarantee that the team will win? Absolutely not. But at least you increase their chances. The same way it works with ASF, right? If you want your project to actually develop a feature, you reach out to the community and you can even pay people within or outside the community, you know, as contractors to develop that feature. Is it guaranteed that that feature will be developed for your specification? Absolutely not. But if you found the right people, at least they would give it the best try they could possibly give it. Yes, and then that feature should align with the community goals of the project itself. That's the first rule. So if you want something which is like completely opposite direction of what the community is going towards, you can throw it much money in at it if you want to, but it's not likely to succeed at all. So first of all, you need, you have two ways of doing it. Either you build up a strong story which will convince and bring interest from that community for the feature you wanna get realized, then it's more like an organic thing if you get people as interested in that feature. Typically, the community will pick it up. You might need to invest some time and effort in supporting people like from your own company, developers who start participating in the community, feeding a jury ticket or actually, well, in time, commit us on their own, but all in all, it's still the direction of the project and the community who will decide what the end result will be. So truly, if you want some feature delivered in a project, join the project, participate in the project, and align with the vision and the thoughts going on there. And if you want stuff changed, do a little bit more work and gradually grow into that community and see if you can make people within there interested in the direction you wanna go. That's the road to success in this case. And then a related question we sometimes get is, when this was my project before I go to the ASF, I could say we're gonna have 1.0 next Tuesday. Do I have any control? Do I have any way of trying to meet these things, especially since next week my CEO is standing up on stage and I can't really slip the release date of the conference? Yeah, what do we say to them about how they can? It's kind of the same question in my book. It's even more unlikely to succeed, if you could say next week something, unless you already have that whole community aligned and everybody's already focusing on getting this lift and still you have no guarantee. Because there are some rules to be applied, sanity checks, validation checks, and you're not as a company owning that process. There are typically a good diversity of different participants and they're all individuals. There's no one company owning that who have a say in that process. And if you get everybody convinced and working towards that goal, yes, you have a chance. But you already should be more or less part of the whole process to begin with, to even make a claim like that. And then still, it's not a claim. It's a kind of hope and suggestion and you can pull that off, but only if you're on the right track within the community itself. Actually, I guess I will not necessarily disagree with this viewpoint, just maybe offer an alternative one. Honestly, I'm a big believer in separating projects and products. So going back to your CEO question, the CEO can totally go on stage today, couple of hours from now, and say whatever he or she wants about the product that the company is producing. Because that is the brand that is fully controlled by the company. Now that product may be 90% based on the Apache project or even 99% based on the Apache project, but that's fine. It's still a separate brand. It's something that the company controls. Now, if the same statement needs to be applied to a project, well, obviously, of course, you're absolutely right. I mean, you just simply cannot do that, but that separation between products and projects, I think is very healthy. And the textbook example of why it could be a problem if you conflate the two, has recently been in the news with Docker, basically splitting out the whole mobby thing. And everybody was like, what's that mobby? And like, why is Docker now Docker? Everybody was confused because they actually conflated the two. So for a long time, Docker was product and project at the same time. Now project is called mobby, as it should have been a different name from the get go and the product is still Docker. So not confusing the two from the very early on helps build businesses. So one thing I'll add to that is having a release through any open source project is just like trying to drive an agile team to the delivery of their sprinkles. You can aim as best as you can to delivering, meeting every feature requirement, meeting every need that comes up, but at the end of the day, until it ships, it's not complete. So that CEO, it doesn't matter if they're trying to say, Apache, CouchDB is being released next week or my internal product based on CouchDB is being released next week. It's gonna be as up to the community as best as they can actually deliver that feature set to meet those goals. Well, and then I'll just repeat what you said is if you want to drive the community, join the community. If you wanna set some certain goals for the project, join the project, make the project feel like you're part of the project and not some vested commercial interests that's on the outside because that's a quick way to piss people off, right? So join the project, contribute, show that you bring value all the time and then when you have an itch to scratch, the community is much more likely to hear it. Can maybe give a small example on how we do this within a company. So our product heavily relies on Apache Jackrabbit which we have several committees participating that as well but our product is called HIPAA repository. So this is like our branded version of Jackrabbit with some added features on that. So we typically have our own release schedule in that. So while we would like to have our improvements or certain fixes to be released like just before we could release but we totally not dependent on that because what we maintain is our light fork of the Apache Jackrabbit. So we maintain a minimal set of patches and that grows and reduces over time. So independent of if those patches have been merged and accepted within Apache Jackrabbit or even accepted but not yet released we are independent of that release schedule. And as soon as we have like a final draw in the sand for our product, of course we do our best to keep our forked patches and get them upstream in the Apache Jackrabbit. And sometimes it takes a little bit more time, sometimes a little bit less time but you should never rely on that dependency. And that's just fine because that's the good thing of the Apache and the Apache license. We are totally free to brand it and have a fork of that and be independent of the whole process. So the forking thing is interesting because you sometimes get companies that are new to the ASF maybe on an existing project.  I can like take your toys and go home. Why would anyone ever contribute back? Can anyone kind of touch on what you need to say about why you maybe don't want to and why you maybe should? So this is a fundamental question I guess about open source not necessarily in the ASF but what would you not want to contribute back? Would probably be the things that are your secret sauce that this is the only way you can make business or reach your business goals or differentiate yourself from competitors. But on the flip side is if you're maintaining that special sauce that's on you to do forever and that's maintenance, that's work that you have to prepare for. The answer I usually give when folks are asking about open source is you should open source all of the things that everybody's got to do. If everybody's got to do it, there's no reason why you would want to keep it behind and own that maintenance and he's got to own the maintenance and he's got to own the maintenance. That's a shared playground. Let's just all be on the same playing field and then we can compete in places that are actually really cool and interesting. So that would basically be how I respond.  Okay, so on a related one, hopefully a happy question, would any of you like to share a big win you got for your company from a day job, not necessarily a current job, by contributing something back, getting a private fork squished back to upstream and back, tracking the community? I don't know if, well, I would say there's been several small wins and that's the cool part. I mean, participating on the web server project, as you can imagine, I run a lot of web servers at my day job and there were several things that the way we use it or the environment was a little peculiar. So we were able to contribute back some features that made things work a whole lot better for us and it also made the project itself better. So I would say it's a big win because it's a win for the community, it's a win for us and it was constant, right? There wasn't any one particular patches, a series of patches that we got a lot of benefit from. I actually would like to add to that from a different perspective, not necessarily a company perspective, but a customer. So we basically had a customer who had to maintain essentially a set of plugins into a product that had to be revved up when you rev up the product itself and they were actually, there was some portion of a contract dedicated to it and we explained to them that they can actually take that code and push it back into the main project. They're like, and then we don't have to maintain it anymore and we don't have to pay anybody and we're like, yeah, if community accepts your contribution, like you're set, like, awesome, let's do it. So we help them, you know, just coach them, you know, Jira's whatnot and now they don't have to pay anybody. Yeah, from a maybe different perspective, but I mean, our product is run by big companies with large cluster setups of our CMS product and sometimes they hit some clustering problem and locking problems, so we really had to go into their environment, fixing the problems and then figuring out it's actually something which should be fixed upstream. So more or less they paid us to fix the bug and we pushed it upstream. So actually they indirect, they were paying for sharing the improvement and the fixes for the whole community to really benefit from. So I can tell you, from my own experience, we fixed a number of security holes and performance issues in Apache user grid. This was a long time ago. We ran into a number of database constraint issues where there were just too many app servers trying to update the same rows in Cassandra and was causing really bad performance in our environment. We got to a point where 10 concurrent clients were able to cause these sorts of problems. We were able also run, provide input to security insights that we were seeing from private security scanning as well as just public intrusion detection that we were able to do to provide these security patches to the project so that we didn't have to maintain it and keep everyone secure who was using these projects. So it's not only us who are benefiting it but we're able to see others in the community be able to take these patches in and actually work with the software and know that at least these security holes that were identified are now fixed. So one thing that sometimes flares up with new projects is someone in marketing says something. Maybe FooCorp is the company behind Apache Hadoop. Maybe it's FooCorp have just released Foo and it upsets a lot of people. And if you're lucky enough to have Alan working for you and you've sat your marketers through the training set he's done, then maybe that wouldn't happen. But for projects that have come up and coming in and if you're mentoring them, how do you help the engineers help the rest of their company to change? Well, I think you just have to explain it in the terms that the marketing people can understand and they understand extremely well what it means to use a brand. Just like they understand that using a Mickey Mouse or a Disney song in a presentation would probably not be a good idea. Once you sort of explain it in those terms, they're like, oh, so you're telling me that the source code is free but the brand is not? And I'd be like, yeah, that's what it is. And then they actually get to be very reasonable because those are the terms that they're used to. I think a lot of times it happens because the assumption is that because the code is available under an extremely permissive license, the brand itself is also available under the same license which is just not the case. So I can add to that. I think it's also important when you're coming in as a podling, if you are using that name and that is somehow indicative of your company, that is not the name to give to the podling. The project that's actually powering it should be separate from your corporate entity. So that means that if your company is named Foo, you should not create a podling called Foo. You have to come up with a new name for that project that correctly describes what that project is doing that is independent of the corporate backing behind it. And keeping that separation is very important and actually helps in a lot of these situations. At the same time, there are cases where you do have to go and try to reach out directly to the marketing people there to get some of these press releases fixed. And that is an unfortunate thing to do, but there are cases where the engineers aren't gonna be comfortable enough having that conversation, but they may be willing to. I'm adding to that, I think everybody also should realize that one of the strengths of the Apache way is indeed the diversity. So if you as a company are backing a certain project or supporting it, if you try to taint that project, its brand, you might shy off some competitors and other people in the marketplace to actually contribute to that project because they don't wanna contribute to a project who's actually like claiming to be well controlled or steered by one of your competitors. So actually you're draining the lifeline of your project itself by doing so. Truly by keeping that separate, you're keeping the level playing field for everybody to participate, which in the long run guarantees you or gives you a more guarantee on the quality and the duration of the project.  It's literally letting blood run. Would someone like to channel in a shame and give a quick explanation of what not to do when one of these things happen? What would Shane do? No, yeah, don't go on Twitter. So I guess, first of all, all the potlinks and definitely TLPs, PMCs should be familiar with the branding guidelines that exist and are well documented. I mean, there are not too many things that are extremely well documented at the patch here. Branding guidelines are actually one of those things that are extremely well documented and not difficult to understand at all. So I encourage all of my potlinks to basically go and read them and just sort of internalize them. Now then, the explanation that I try to give them is they are not meant to be enforcement of those sort of guidelines. If push comes to shove, I mean, they're not meant to be the people sort of trading emails with the company lawyers, trying to explain to the company not to do something, but they're all meant to be in support of the guidelines that are documented, which means that if they see something that is off, at least they should send a note to the PMC's mailing list in private, if that's required to be in private, just saying, hey, I've noticed that this company is doing this, are you guys feeling that this is the right thing to do? What's everybody's stake? And I think as long as we can basically encourage people to keep track of what's going on around them and not become complacent, not saying that, well, all these companies do it, so if this company does it, it's fine, all of them do it. So just fight that complacency, try to bring issues back to the PMC's mailing list, and then these solutions are typically reasonable because a lot of times just a single email from a chair of the project back to the corporate email address, marketing at company name or some such would do the trick. I mean, the companies would actually just say, like, thank you, we didn't know, we fixed it, whatever it was. Sometimes they wouldn't respond, and then you would basically include it into the report that you're submitting to the board, or if it's significant enough of a violation, you may even flag it to the board sooner, then your next report, and then it's literally up to the board to help you deal with that, right? Again, they will tell you to do a certain set of things, but at the end of the day, if it really gets tough, the board will get involved, and ASF actually does have legal resources to even send cease and desit letters, if it comes to that. I haven't actually done it once, I haven't seen it done even once, but those legal resources exist. What I've seen on trademarks is that actually you should direct them to trademarks, and then Shane can handle it, and he can connect with the lawyer, so it's more of an officer's type thing than a board thing. Yeah, could be. Yeah, that I agree with. All I'm saying is, and maybe again, maybe that's just my inner mentor speaking, I like keeping board appraised of just about everything. And even if all we did is, we send the email to let's say trademarks.apache.org, even that has to go into the report, so that's all I'm saying. I also wanted to comment on this a little bit. One thing we've told our people internally and found is it's much better to get those, like if the marketer goes off the rails, it's much better to hear that internally than to get called out on the list. So you shouldn't actually feel bad about telling your own company, hey, that's not gonna work, because they'd rather hear it from you than from Apache officially. So that's at least something we tell our people is please be even more diligent in policing us than the outside. Yeah, I would agree with that. So first of all, we're just suggesting if somebody on a community sees something off, then indeed I would suggest the first direction is notifying the PMC, preferably private. So within the PMC, you likely will have one of the participants being an employer of the company in question. And so the natural path and the ideal path would be this is then resolved internally and doesn't need to escalate to public or trademark or stuff like that. So first of all, I think the PMC is the first line responsible entity to monitor and being aware and if need be escalate the problem. But anyone in the community, if you see something which you think this is odd, take the initiative to notify the PMC privately and then see how, and they probably will respond with you, so you will be aware, even if you're not on the PMC. And then it will take next steps after that. Typically it should, the most cases, it's just somebody misunderstanding the situation and it can be easily resolved in practice. If it hasn't gone wild on Twitter. Yes, so that's what I meant, don't do a private PMC email and not Twitter. Okay, well we've got a few minutes left. So would anyone like to pose a question to the panel? Any members like to chip in with anything? At the outset, there was mention about maybe talking about running businesses off of Apache software or trying to commercialize Apache software. And if you have any thoughts on things to do or not do to try to make that happen. So one area that I've seen be very successful with this is providing support and consulting opportunities on top of the Apache products. You're not violating anything about the brand. You're making it very clear that you can assist with the implementation, the delivery, the setup of these Apache products, while not violating anything about the core deliverables of those products. Hadoop would be a good example of this where you can actually go on site and help set up a 25,000 node cluster for someone. And that makes a lot of sense because that's not something you would expect from the project to do. At the same time, I would shy from saying I have a commercial distribution of Tomcat and that is what I'm shipping to you. Because that is a problem from both a branding and a naming standpoint. I was just gonna pass it to you. So I'll just maybe reiterate the unusual business that may exist, which has actually little to do with the existing Apache projects and everything to do with the future Apache projects. What I found is that a lot of traditional enterprise companies these days, they go through this phase in popular literature being referred as digital transformation. And as part of that, it's actually on them to redefine themselves, at least in large part, as software companies. And they at some point all realize that part of that redefinition includes having two-way relationship with open source communities. And there's actually a great deal of what you're doing, which is inner source, essentially internally changing the culture, the legal climate, just everything about the company to make them capable of that type of two-way streets relationship with open source communities. It is a boutique business, I would say, but it is one that is extremely well paid. So it's kind of like, you know, it's the bit that McKinsey cannot do for them. Let me put it this way. Yeah, just a small accent note. I mean, my company is like I already explained, like the product we deliver, which is also open source, it's like 89% based on Apache software. So how we say it, we really are standing on the shoulders of giants. And we do add value in our own adaption of these projects and added features on top of that. And we commercialize that. So, and then in our case, we actually do this on a support subscription base. But there's so much value in the Apache projects that anyone who cannot add value and make a product out of that, he's not on the right track because you need smart people. You need to have an edge. You need to have something your competitors are not having or not looking at. So you have a niche in the market, but there's so much added value where you can leverage Apache software for. There's, I see no reason why people can't build commercial business on top. And actually it's like one of the best foundations you could start with. Do we have any other Apache members in the room who want to have a quick comment on their business models? Willing to share? Okay, unfortunately we are out of time. I see the next speaker hovering at the back of the room. So thank you very much to our lovely panel. And thank you all for coming.


Images. Fingers tapping on a laptop. At a computer, a young man dons headphones. A man in a wheelchair moves through a lab. Braille labels on a keyboard. Words appear. Access. Universal design of computer labs.  Good education today requires access to technology. In planning a computer lab, universal design is crucial. That means thinking about every potential visitor's abilities and disabilities. Dan Comden. It's important to think about universal design early in the design process, if that's possible. The Americans with Disabilities Act makes it clear that equitable access is a requirement. Access Technology Consultant. Visitors to your lab may have obvious disabilities such as blindness, hearing impairments or mobility impairments. Or they might have disabilities that are not apparent, such as low vision or learning disabilities. As we look at all of the things that we're going to need for a lab, we need to consider everybody that's going to be using it, or everybody that's potentially going to be using it. Student access and computing. By planning ahead, you can make sure everyone has a positive experience in your lab. The first step is getting there. A woman in a wheelchair halts at steps. If they can't find the lab, they can't use the lab. Eliminate those external barriers. Consider these examples. Words appear. Parking areas with spaces for wheelchair users. Clear paths to the building with ramps if necessary. Building entrances at least 32 inches wide with thresholds no higher than one half inch. Ramps or elevators inside. Elevator controls marked in braille and accessible from a sitting position. Clear entrances and hallways with protruding obstacles removed. Wheelchair accessible restrooms near the lab with high visibility signs. Now for the lab itself. Look at the physical details for users. Remember that people with various abilities will be using the room. For example. Words appear. Large print, high contrast signs for those with visual impairments. Braille labels on computers for blind users. Wide clear aisles for wheelchair users. Damian Cremons. We really try to focus on making wide and open pathways from our access points particularly for Computer lab managers. Students that have physical disabilities. Student wheels to a low counter. Hi. Can I help you? Yes. We try to make sure that there's a lot of clearance on desk heights so that students can get underneath things and that there's generally kind of a large workspace. Words appear. Some adjustable tables with wheelchair accessible adjustment controls. Document holders for ease in reading printed material. Controls on computers, printers, scanners and other technology that can be reached from a seated position. Another thing to consider is the accessibility of your lab handouts or documents. Be prepared to provide lab documents in large print and Braille. Put them in an accessible format on your website. Internet access will make those documents available to all lab users including students who are blind and using speech output systems to read the text. Put it under the screen and you can change the size with the center knob. If you provide a magnifying system, a visitor with low vision can read your printed material. A large magnifying glass is a lower cost option. Design the documents themselves in a clear and consistent format. This is especially helpful to people with learning disabilities. Finally, be sure that printed materials are within easy reach from a variety of heights and that furniture doesn't block access. Once everything is in place, think about people actually using the computers. Plan on having adaptive technology available but don't worry about trying to anticipate every possible request. People mostly are interested in the adjustable table on our special keyboards and on Braille production. The main thing is to have the basics that most people are going to need. You don't have to have every little thing that's out there. Can you find the message area? Yeah, it's right here. It's important for staff to know about the basics and to be able to talk to the clients about what those basics are. And if a student is in need of a more involved accommodation then those staff need to know where to go to make those additional arrangements. Keep it simple at first adding new technology as requested. For people with visual impairments you might want to start with Words appear Large print key labels Software to enlarge screen images and large monitors Speech output systems Braille conversion software and embosser For people with mobility impairments you can provide Words appear A track ball Wrist and forearm rests An adjustable table For all users, but especially those with learning disabilities Grammar and spell checkers should be available. And finally, be sure that webpages and other electronic resources offered in your lab are designed to be accessible to people with a variety of disabilities. For example, provide text alternatives to graphic images. Cheryl Burgstahler Almost every unit on campus now has a website to document their services and provide electronic resources. And most of these people who are developing these websites don't have the expertise in how to make them accessible. And so in most cases it's useful for that person to work with the central computing organization staff to develop strategies for making an accessible website. The key to all of this is simply equal access. Everyone who needs to use your lab should be able to do so comfortably. As you plan services in your computing facility consider all of your potential users including those with disabilities. Make sure everyone feels welcome. Words appear Ask yourself if visitors can get to the facility, access lab information and other printed materials, and access equipment and software. A boy with headphones uses a computer in a lab. Make sure also that staff are trained to support people with disabilities and have a plan in place to respond to specific requests in a timely manner. With those key issues in mind you'll be able to make your lab accessible to everyone. Words appear To get started develop policies and procedures that assure access to lab facilities, computers and electronic resources for people with disabilities. Consider accessibility in the procurement process. Include students with disabilities in planning and evaluating lab products and services. In key lab documents include pictures that show lab users with diverse characteristics with respect to race, gender, age and disability. Also in lab documents state your commitment to universal access and include procedures for requesting disability related accommodations. Make signs with high contrast and large print. Make all information resources available in accessible formats. Have frequently requested assistive technology on hand and add products when students with disabilities request them. Train staff on accessible products in the lab, appropriate communication and procedures for addressing requests for accommodations. To help you in your plans there are many resources for locating and selecting assistive technology, for designing accessible web pages and for dealing with other lab accessibility issues. Describe by audio eyes. For more information about IT accessibility consult www.uw.edu.accessibility. The content of this presentation is based on work supported by the National Science Foundation under grant number 9800324. Any opinions, findings and conclusions or recommendations expressed are those of the authors and do not necessarily reflect the views of the National Science Foundation. Copyright 2015, University of Washington. Permission is granted to copy these materials for educational non-commercial purposes provided the source is acknowledged.