Entries tagged [works]

Tuesday March 05, 2019

Success at Apache: Growing with the ASF

by Phil Steitz

I got involved at the ASF in 2002, back in the wild and wooly Apache Jakarta days. In my day job, I was responsible for the team introducing Java technology at a large financial services company.

One of the first things we built was an MVC (model-view-controller) framework for Web applications. We were very proud of it and it worked great in production, but it was hard for us to keep ahead of the feature requests from the many development teams who were using it. One evening, someone said, "Hey, there is this Struts thing that is very similar to what we do and it has some of these things already." I went home and found my way to the Jakarta Web site and downloaded the latest source release.

One thing led to another and the next thing I knew I was asking questions on the struts user mailing list as we started playing with the software and seeing what it would take to convert our apps to use it. After a few months, I found myself answering questions on-list as well and I finally got up the nerve to submit my first patch, which was a documentation fix. At the time, the Apache Struts community was struggling to release version 1.0. I looked around to see what I could do to help and found my way to Apache Commons Pool and DBCP, which Struts was trying to use to replace its built-in connection pool. What I found there was some brilliant but inscrutable code hiding some nasty bugs that Struts needed fixed. At that time, I did not have the Java skills to solve the problems, but I resolved to come back when I did and I watched as others developed workarounds that enabled the Struts community to move forward. I found a welcoming community in Commons and some problems that I could help with. I did eventually make it back to Commons Pool and DBCP, serving as RM for quite a few releases.

During this same timeframe, my $dayjob career was advancing rapidly, thanks in no small part to my aggressive introduction of Open Source software and practices, which was uncommon at the time in financial services. We brought in some ASF committers and their companies to help us build a development pipeline and tooling that was ahead of its time. We applied the Contributor - Committer - PMC member concept to developing enterprise technology standards and strategy. We developed the concept of "earned authority" in technology decision-making, modeled after the idea of publicly earned merit at the ASF. My leadership approach was profoundly influenced by my experience at the ASF, and continues to be to this day. Not a day goes by at work when I do not push for more transparency, more eyeballs on code and more focus on community collaboration and genuine appreciation of diverse viewpoints. I am very grateful to the many ASF community members who have helped me develop as a leader.

Through the years I've met other Apache committers with similar experiences: welcoming projects, friendly communities and great opportunities for personal growth. I’m pleased to see how the ASF has grown and continued to evolve. Every day new contributors join us and new leaders regularly emerge to help guide our communities and the Foundation overall. We all benefit from our experience here and the Foundation becomes stronger as a result. 

Phil Steitz is Chairman of the Board of The Apache Software Foundation.  He has been an ASF committer since 2003 and a member since 2005.  He served for 4 years as Vice President, Apache Commons. Phil also currently serves as Chief Technology officer of Nextiva, a cloud-based business communications company. He has previously held C-level technology leadership positions at multiple software and financial services companies.

# # #

"Success at Apache" is a monthly blog series that focuses on the people and processes behind why the ASF "just works". https://blogs.apache.org/foundation/category/SuccessAtApache

Tuesday February 05, 2019

Success at Apache: For Love or Money: Volunteer vs. Professional Open Source

EDITOR'S NOTE: "Success at Apache" reflects diverse, personal experiences from our community members, with particular focus on the people and processes behind why the ASF "just works". The post below is the result of a discussion with the author that originated in early September 2018 and remained unpublished as its tone deviates from the general tenor of this series.Over the past few months, this topic has increased in visibility and relevance with the greater community, and we have made an exception in publishing due its timeliness and representation of the evolution of Open Source communities, both within and without Apache.

by Rich Bowen

A few weeks ago, a colleague asked me what I believed to be the biggest threat facing Open Source today. I answered that I think it's full-time Open Source developers, and the effect they have on part-time volunteer developers.

Long ago (it actually hasn't been very long, it just seems that way sometimes) Open Source was developed primarily by part-time hobbyist developers, working on their evenings and weekends on things that they were passionate about. Sure, there were full-time developers, but they were in the minority. Those of us working a few hours on the weekends envied them greatly. We wished that we, too, could get paid to do the thing that we love.

Now, 20 years on, the overwhelming majority of Open Source development is done by full-timers, working 9-5 on Open Source software. And those who are working nights and weekends are often made to feel that they are less important than those that are putting in the long hours.

Most of the time, this is unintentional. The full-timers are not intentionally marginalizing the part-timers. It just happens as a result of the time that they're able to put into it.

Imagine, if you will, that you're an "evenings-and-weekends" contributor to a project. You have an idea to add a new feature, and you propose it on the mailing list, as per your project culture. And you start working on it, a couple of hours on Friday evening, and then a few more hours on Saturday morning before you have to mow the lawn and take your kids to gymnastics practice. Then there's the cross country meet, and next thing you know, it's Monday morning, and you're back at work.

All week you think about what you're going to do next weekend.

But, Friday evening comes, and you `git pull`, and, lo and behold, one of the full-timers has taken your starting point, turned it in a new direction, completed the feature, and there's been a new release of the project. All while you were punching the clock on your unrelated job.

This is great for the product, of course. It moves faster. Users get features faster. Releases come out faster.

But, meanwhile, you have been told pretty clearly that your contribution wasn't good enough. Or, at the very least, that it wasn't fast enough.

The Cost of Professionalism

And of course there are lots of other benefits, too. Open Source code, as a whole, is probably better than it used to be, because people have more time to focus. The features are more driven by actual use cases, since there's all sorts of customer feedback that goes into the road map. But the volunteerism that made Open Source work in the first place is getting slowly squelched.

This is happening daily across the Open Source world, and MOST of it is unintentional. People are just doing their jobs, after all.

We are also starting to see places where projects are actively shunning the part timers, because they are not pulling their weight. Indeed, in recent weeks I've been told this explicitly by a prominent developer on a project that I follow. He feels that the part timers are stealing his glory, because they have their names on the list of contributors, but they aren't keeping up with the volume of his contributions.

But, whether or not it is intentional, I worry about what this will do to the culture of open source as a whole. I do not in any way begrudge the full-timers their jobs. It's what I dreamed of for *years* when I was an evenings-and-weekends open source developer, and it's what I have now. I am *thrilled* to be paid to work full time in the Open Source world. But I worry that most new Open Source projects are completely corporate driven, and have none of the passion, the scratch-your-own-itch, and the personal drive with which Open Source began.

While most of the professional Open Source developers I have worked with in my years at Red Hat have been passionate and personally invested in the projects that they work on, there's a certain percentage of them for whom this is just a job. If they were reassigned to some other project tomorrow, they'd switch over with no remorse. And I see this more and more as the years go by. Open Source projects as passion is giving way to developers that are working on whatever their manager has assigned, and have no personal investment whatsoever.

This doesn't in any way mean that they are bad people. Work is honorable.

I just worry about what effect this will have, and what Open Source will look like 20 years from now.

Rich Bowen has been doing open source-y stuff since about 1995, and has been a member of the Apache Software Foundation since 2002. He currently serves on the ASF Board of Directors. By day, he's the CentOS Community Manager, working for Red Hat. Read Rich's earlier post, "Success at Apache: Wearing Small Hats".

# # #

"Success at Apache" is a monthly blog series that focuses on the people and processes behind why the ASF "just works". https://blogs.apache.org/foundation/category/SuccessAtApache

Tuesday January 15, 2019

Apache Software Foundation Gold Sponsor Profile: Bloomberg

with Kevin Fleming, Head of Open Source Community Engagement and Member of the CTO Office at Bloomberg

Kevin has spent more than 20 years in the technology industry. In 2004, he started a VOIP service provider company and chose Asterisk as his platform. 9 months later he was offered a position at Digium to work on Asterisk full-time. After seven years of developing and managing the Asterisk project, and helping to design and build the Asterisk SCF project, he moved on to Bloomberg LP, where he works with various teams to help produce and support Bloomberg's open software, used by its customers and partners to integrate with the Bloomberg Terminal. Follow @realkpfleming and @TechAtBloomberg on Twitter.

“ASF's very explicit statement that every participant

in a project is participating personally is really

a big differentiating factor to the other models.”

How did Bloomberg's work with Open Source begin?

Bloomberg has been a consumer of Open Source software for decades, but our involvement as a community collaborator and contributor began in earnest about seven years ago. That was a result of a company-wide decision to begin using Open Source tools in the development of our applications and infrastructure when possible, instead of commercial or proprietary tools.

Open Source tools are important to us because, when a tool’s source code is available, you have the flexibility to understand how it works, to modify it, and to support it by yourself, and you don’t have to rely on a vendor who might go away or whose priorities might change. That's not to say that there aren’t vendors who support their Open Source tools, because there are, but we're not locked into a channel model. Open Source tools give us control over our own destiny. If something becomes important enough to us, we can form an internal team to provide support and enhancements for that tool and the team can contribute those enhancements back to the Open Source community, if appropriate.

Why Apache? How is Bloomberg involved with the ASF, and for how long?

Bloomberg has been involved with the ASF for almost all of the seven years that we've been an active participant in the Open Source community. Apache is the home of dozens of Open Source projects that are fundamentally important to us. These tools support our data science workflows, data processing workflows, and web services, as well as other internal and external services that the company operates.

It's important to us that the organization providing a project's home is able to effectively support the project, and we want developers that work on projects in the Apache organization to focus on actually developing software, without having to spend time managing infrastructure (like bug trackers, source code repositories, and related tools). Contributors to Apache projects can focus on their own project because of the support from the foundation that these projects receive.

Why is support for foundations such as the ASF important? How does helping the ASF help Bloomberg?

Supporting organizations like the ASF is important to Bloomberg because of its governance model. Every participant in one of these Open Source projects has equal representation and footing, and developers are valued based on the merits of their contribution. Projects operating under a different governance model might not offer same type of participation for developers unless their company has made a significant financial contribution to the organization. Bloomberg participates in those types of organizations as well, but we strongly prefer those that allow everyone to participate. Not only can input come from a broader community, but also this allows contributors with a varied level of experience to participate in projects.

Contributors on these projects aren't only developers; they also include people with varied skills like documentation, project management, and marketing. Sometimes a project's decision-makers don’t write any code. While useful tools are developed within both governance models, the way an Apache project's roadmap is set, planned, and decided upon is what's important to us.

What sets the ASF apart from other software foundations or consortia?

The one really significant difference from other charitable foundations that we also support is the ASF's governance model. ASF's very explicit statement that every participant in a project is participating personally is really a big differentiating factor to the other models. 

What does 'The Apache Way' mean to Bloomberg? What makes 'The Apache Way' special?

As a result, meetings held to discuss the next major phase of an Apache project's development don't feel like any company has a representative group. ASF's policy states that you're there representing your own personal interests and not anyone else's. Even though I may know where everyone in the room works, it doesn’t matter and is not relevant. That doesn’t mean you can't say 'the company I work for uses this piece of software in a certain way,' and obviously the way you use the software will impact your opinion, but you don’t make suggestions because that’s what your company wants. Your decisions about a project should be influenced by what you think is best for the broader community. A contributor's entire currency is based on their contributions and how the community values their participation.

Do you have any guidelines for promoting innovation? There is no limit with Open Source: how do you stay focused?

We often have to consider different solutions because of changing business requirements, new types of systems to manage, or some other reason. We strongly encourage people to take a few steps back from their daily work of maintaining our systems to think about what the service may need to support in the future. We want to know if we're using the right tool, if we should use something else, or if we should improve an existing tool.

We strongly encourage people to consider that they're not just delivering a service today and that they don't want that service to be irrelevant to clients six months down the road. They need to build applications and provide databases and services that have the right functionality that meet our clients' present needs. But, you also have to choose solutions that can grow with you and that you can grow, and you have to be able to take technology in the direction you need it to go. You can do this with Open Source easier than you can with a commercial, off-the-shelf solution.

How does Apache fit into Bloomberg's long-term strategy/plans?

It's strategically important to us to ensure that the ASF continues to be a place where new, interesting, and exciting Open Source projects want to go to as their home. As these projects evolve beyond just a few people putting code up on GitHub, they can receive the benefits and support that ASF has to offer – this is a good thing for Bloomberg and the greater Open Source community.

Money is just one way to support the ASF. How else do you contribute? What recommendations do you have for others to participate?

We participate in helping the ASF decide how best to support organizations like us, and we look for ways to further help the ASF through regular conversations with them. We help spread the word about how Apache projects are run and why that's valuable and important – marketing and evangelizing is another way we contribute to the overall health of the community and the projects to which our developers contribute.

There are a few different models for how people can contribute to Apache projects. We have some employees who contribute outside of work, in their personal time. On the other end of the spectrum, we have staff that spend most of their day working on Open Source projects, including reviewing patches that aren't contributed by Bloomberg employees. These Open Source projects are important to Bloomberg, and this work ensures that the projects move forward. Of course we also have team members who contribute to projects as the need arises, which may mean that they contribute to a dozen (or more) projects in any given year.

We also host collaborative weekend sprints that are focused on a specific Open Source project or group of projects. Between 50 and 100 people attend these events with project leaders so they can learn how to become contributors to that specific project, and we provide the support system so they can participate. We ask people to break up into teams so they can, while working as part of a small group, tackle open items on the project's 'to do' list. The groups dive in and try to figure out how to solve each problem, and experts are available to help when people get stuck or to merge participants' PRs on the spot.

For some of those attending, this may be their initial contribution experience, and it's important that this experience is very collaborative, friendly, and productive. The goal of these events is to train people to be Open Source contributors. While the sprint might not be for an Apache project, some participants end up contributing to Apache projects in the future. Once someone becomes a contributor, they become more comfortable with the process and know what to expect, and they're able to translate that experience to subsequent projects.

How does it feel to be able to offer this level of support?

We're pleased to be able to participate and encourage more companies to sponsor the Apache Software Foundation. Everyone wins when everyone collaborates.

# # #

Sponsors of The Apache Software Foundation such as Bloomberg enable the all-volunteer ASF to ensure its 300+ community-driven software products remain available to billions of users around the world at no cost, and to incubate the next generation of Open Source innovations. For more information sponsorship and on ways to support the ASF, visit http://apache.org/foundation/contributing.html . 

Monday January 07, 2019

Success at Apache: Accidentally Finding Awesome

by Daniel Ruggeri

My involvement with the ASF started very simply. 

I was a server administrator who wanted to have a bug or two fixed and a feature or two added to the Apache HTTP Server (httpd). I spent some time learning the codebase a bit and submitted my first patch to the httpd dev list. I wasn't expecting much of a response, as my primary motivation was to avoid having to maintain the fixes locally, but I was willing to do it if I had to. Surprisingly enough, I got a quick response from "those developer folks" and was thanked for the contribution and given a bit of guidance on when it might hit the stable branch. Wow... cool: that was neat. 

Fast forward a few months and I found a few other bugs and even added a few features myself. Every time, "those folks" (who I certainly wasn't a part of because I just wasn't as brilliant) took the contribution and incorporated it into the code base or gave pointers on how to improve it. This was getting to be pretty cool, but I was convinced "they" were just happy for the free labor.

Around that time, I was hitting some serious career growth. Working with httpd so much at $dayjob, I got to the point where I knew the ins and outs of the proxy quite well. I was also challenged by a mentor to consider giving public talks. After mulling over it, I figured I'd give it a shot and since 98% of $dayjob revolved around the httpd proxy and cool things you could do with it, I submitted a talk to ApacheCon. Again, thinking "Maybe 'those folks' don't have a full schedule" and are seeking content.

Amazingly, "those folks" accepted the talk. I gave my first *real* public speech at ApacheCon. I remember it vividly: I was nervous as hell. I mean... could you believe it? The PRESIDENT/one of the founders of the ASF was in the audience. The guy that WROTE THE MANUAL AND BOOK about httpd was also sitting right there. Oh, by the way, the guy that WROTE THE BOOK about modules was across the aisle a few rows back. Not to mention the fact that I saw several name tags I recognized as 'heavy hitters' in the community. I couldn't believe it, but they actually took the time out of their day to hear what I had to say.

While I think the presentation was probably "OK" at best, I was still welcomed and even got to chat with "those folks" about the future of the project and where it might be taken. I also got to chat with folks from several other projects. I heard about this "Hadoop" thing from a newfound friend (didn't make much sense to me) and enjoyed some awesome meals with folks from other projects (I didn't even come close to understanding what they did, but wrote down the names for later research). I connected with a fellow server admin who had some cool ideas for httpd and spent some time brainstorming how to make our @dayjobs better. 

I learned so many things in that first year at ApacheCon. 

Not too long afterwards, I was invited to be a committer on the httpd project. This floored me because, for the first time, I realized that this wasn't about sucking up free patches from the outside world. I started to see that the project was interested in me being part of it.

So, off I went. I continued submitting ever-more-interesting patches here and there, going to ApacheCons and giving ever-more-refined versions of my proxy talk and spending ever-more-time with other folks in the community. I did this really cool "barcamp" thing where we talked about whatever we wanted and got to expand our minds. 

There was also something about making the terrible (wonderful?) mistake of buying the first round the last night of the ‘con once, too: shenanigans all around. 

After a while, I didn't feel like just an outsider trying to run a better server at $dayjob. I felt like I was part of this bigger thing that was going on. I was hanging out with people I genuinely consider friends as opposed to "those folks". I was loving it and I wanted to share it. So I did the unthinkable... in a moment of boldness or temporary insanity enhanced by a faulty governor that avoids embarrassment, I gave a completely ad-hoc lightning talk titled "I love this community." And at that point... the cat was out of the bag and I was effectively 'all in'.

The really cool thing is that I wasn't actively trying to join the community. Heck, I didn't even realize a community was there. Instead the community was actually pulling me toward it. I had no idea what the *depth* and *richness* of where things would go. I started as an outsider with zero expectation other than making my life a bit easier at work and stumbled upon one of the most rewarding things I've found outside of blood family.

... THIS is why I love this community and THIS is why I want to serve it. So, as it follows, this is where the pride comes from. With a family this welcoming, it makes it easy to become more involved. So… the only thought to leave you with is “How are YOU going to get move involved?”

Daniel Ruggeri is an Open Source evangelist and lover of tech. At work, he is responsible for setting the direction of the Web and Cloud space for Mastercard and he spends his time playing with infrastructure and the code that powers it both inside the firewall and outside. He is a member of The ASF and has contributed code to Open Source projects from simple pet projects to widely utilized servers. As a lover of Open Source, he even teaches courses about Open Source Software Development (and will share the curriculum with you!).

# # #

"Success at Apache" is a monthly blog series that focuses on the people and processes behind why the ASF "just works". https://blogs.apache.org/foundation/category/SuccessAtApache

Monday December 03, 2018

Success at Apache: Cookie Monster

by Isabel Drost-Fromm

As a researcher interested in machine learning, Web- and social graphs I joined the Nutch mailing lists back in 2005 when the project was still on SourceForge. I started tinkering with Nutch Writeables to store the data I needed for my analysis – something that today some may know as Hadoop Writeables – the Nutch wiki still has a link to the material that I could get published out of those experiments: https://wiki.apache.org/nutch/AcademicArticles

After leaving academia I remained on the Nutch and Lucene mailing lists - until one day I saw the idea of an "Apache Text" project mentioned: https://lists.apache.org/thread.html/ac22faddbef946b66d544e590fe1b2a54b60215c98cc38a2f995ee06@1176254016@%3Cdev.lucene.apache.org%3E ... I got in touch with Grant Ingersoll, over the course of half a year that vague idea was turned into a plan to have a scalable machine learning project at Apache: Scalable in terms of community, dataset size but also commercially friendly when it comes to licensing – Apache Mahout was created.

Some ideas turn into something with a life on its own. The story I'm going to tell has little to do with great technical or economic achievements that were made with software developed at The Apache Software Foundation. However it has a lot to do with the kind of cross community links that exist between projects at Apache. It also has a lot to do with the fact that there are people active in Apache projects for whom the project is more than merely a day job.

But let's start at the beginning: Little over a year ago, in April or May 2017 Stefan Rudnitzki, one of my then-new colleagues at Europace AG was showing me around the office – mentioning in particular that there's space for meetups of 100 up to 200 people. It was the year when it was unclear whether or not there would be an ApacheCon EU. The combination of those two pieces of information put  an interesting idea in our heads: Why not pull ASF interested people to Berlin and have them discuss cross-community, behind-the-scenes, OSS economics, decentralized project management, coordination of work without discretionary power topics?

In a first step we ran a rough version of the idea past a handful of friends at Apache – and received encouragement. The idea got bigger, new aspects were added and we thought "Let's get more specific!".

In a working backwards model the next thing that was written was a press release (in big, bold, red letters marked as "draft, imaginary, DO NOT PUBLISH!!!!!!!") describing a conference on all things open source behind the scenes. The format helped identify important open question marks – like: 

  • "We don't have a name for the event yet!"
  • "We need to decide on a date."
  • "We need to come up with a clearer list of topics to cover."
  • "What's our target audience?"
  • "If this is a full day event – what will we do about catering?"

What helped me personally was having learnt from Sally in her ASF media training what a real press release actually should look like. 

As for the name that was found missing in the initial press release draft:  After weeks of trying several approaches to come up with a catchy name, I went to pick up my child from kindergarten. What caught my eye was a poster announcing a beneficial concert to collect donations for better equipment and toys – an *a capella* concert: .oO(FOSS A Capella?) .oO(FOSS Backstage?)

The press release formatted version of the vision was first run by Europace – though people here are fairly regularly running after hours meetups, hosting an entire full-day conference is a slightly different scale. After the idea had been met with approval here, it was run by the Apache Community Development mailing list – which we used to keep current planning status transparent and public. 

With the idea out in the open it grew beyond something that can easily be run as a small side project. Years ago to create Berlin Buzzwords I had been working together with an event agency called newthinking communications GmbH. They were founded in 2003 by Andreas Gebhard and Markus Beckedahl in the spirit to create a network on the interface between digital technologies and society. Today, the focus lies in the organisation of events such as Berlin Buzzwords and FOSS Backstage as well as content management services (based on Drupal) for NGOs and political parties as well the conferences named above. So I got in touch with newthinking – and was delighted to receive "Sure, we are going to help out" as an answer. 

So, what about the cookies? One of the first offers I received after publishing that we were to run a FOSS Backstage full day Micro Summit in November 2017 was: "If you need support with providing cookies for the coffee break – I'm happy  to bake some, if there's no more than 40 attendees." Half jokingly I responded that I would add another 40 cookies, lest someone sends me a 3D model of an ASF feather cookie cutter. Lo and behold  the next thing I know is that someone sends me a model file for an ASF cookie cutter (which by now even made it to the then VP trademarks – who was interested in putting it to good use himself). Just a few weeks later I attended Open Source Summit in Prague. Guess what happened? Someone who knew I'd be there brought some printed cookie cutters with him from Australia.

In the meantime we had a one day / two tracks FOSS Backstage Micro Summit in November 2017 kindly hosted by Europace AG. I was able to talk several people into baking ASF cookies (including sugar coatings in the appropriate colours). In addition with the support of both, Newthinking communications GmbH, the ASF planners, and the ASF community development PMC an Apache Roadshow was co-located with the actual FOSS Backstage in June this year – a two day, multiple tracks event featuring Danese Cooper and Shane Coughlan for keynotes, a host of speakers with all sorts of relevant and inspiring stories to share, as well as fishbowl discussions on topics like Open Source monetization. One of the loveliest feedback we received: "This doesn't feel like an inaugural conference, given the professional organisation. You surely did manage to successfully invite people from a great variety of FOSS projects and foundations."

Having a press release draft ready was helpful when starting to drum up interest for the real event: With all details filled in, the "Draft/ Do not share"-warning removed it ended up getting sent to the press and published for real.

We started with a scope of all things FOSS economics, decentralised organisation, cross-cultural team-building, volunteer motivation, licensing and legal. In 2019 we want to align these aspects towards InnerSource, work collaboration principles and modern work models so that teams, companies and organisations can learn from the experiences we all make while working on Open Source projects. We are glad to have the event backed by newthinking GmbH next year again.

Isabel Drost-Fromm is (currently board-) member of the Apache Software Foundation, co-founder of Apache Mahout and mentored several incubating projects. Interested in all things search and text mining with a thorough background in open source project management and open collaboration she is working Europace AG as Open Source Strategist. True to the nature of people living in Berlin she loves having friends fly in for a brief visit –- as a result she co-founded and is still one the creative heads behind both, Berlin Buzzwords, a tech conference on all things search, scale and storage as well as FOSS Backstage, a conference on all things Free and Open Source behind the scenes and how it interrelates with business and InnerSource.

= = =

"Success at Apache" is a monthly blog series that focuses on the processes behind why the ASF "just works" https://blogs.apache.org/foundation/category/SuccessAtApache

Monday November 05, 2018

Success at Apache: Wearing Small Hats

by Rich Bowen

Within The Apache Software Foundation, many of us have different roles. I am a committer on the Apache httpd project, and also a PMC member on that project. I am the Vice President, Conferences. I am a board member. And I’m a member of the Foundation. I'm also an employee of Red Hat, and may, at times, be perceived to be speaking for my employer.

I am a father, husband, brother, son, employee, and so on. How I interact with my daughter is very different from how I interact with my manager. I use different language, wield different authority, and expect different results.

Ten years ago at ApacheCon in Oakland, Bertrand Delacretaz gave a talk about hats. We all laughed a lot. But he was making a serious point. At the Apache Software Foundation –indeed, in life– we all wear many different hats.

However, whereas it's pretty clear, in real life, whether I’m addressing my daughter or my manager, on Apache mailing lists it's seldom, if ever, clear which hat I'm wearing in any given situation.

I like to operate on the following principle when communicating in the Apache community: Wear the smallest hat possible for the situation, but assume that everyone is seeing the biggest hat possible.

So, what does that mean?

In the list above of my Apache hats (Committer, PMC Member, Foundation Member, V.P. Conferences, Director), there are various levels of authority. As a project committer, I can make code changes, but as a PMC member, I can reject other people’s changes. As a Foundation Member, I can express an opinion, but as a Director, I can state the official position of the Foundation.

The difficulty comes when, on a mailing list, I say something, intending it to be my personal opinion (i.e., Foundation Member hat) and someone reads it as the official position of the Foundation (i.e., Foundation Director hat).

Thus, in any given situation, I have an obligation to wield the smallest stick I possibly can, appropriate to the situation. Also, to clearly communicate how I am speaking, if there’s any chance of confusion, by saying things like "speaking as a member, and expressing my private opinion …", or "It is the opinion of the Board of Directors that …"  And, since there’s always a chance of confusion, due to many factors, it’s worthwhile to make this clarification almost every time, if you’re in a position where you do, in fact, wear multiple hats.

By wearing the smallest hat possible i.e., speaking with the voice with the least authority you allow other people to be free to express their own dissenting opinions without feeling that they have already been overruled. This is in line with our culture of providing a level playing field, where all voices are equal, and all opinions are weighed the same.

Rich Bowen has been doing open source-y stuff since about 1995, and has been a member of the Apache Software Foundation since 2002. He currently serves on the ASF Board of Directors. By day, he's the CentOS Community Manager, working for Red Hat.

= = =

"Success at Apache" is a monthly blog series that focuses on the processes behind why the ASF "just works" https://blogs.apache.org/foundation/category/SuccessAtApache

Monday October 01, 2018

Success at Apache: carrying forward the benefits

by Mikael Ståldal

Back in 2013, I worked as software developer and architect at a small IT company. We needed a logging framework for the Java based server platform we were developing. Initially, we tried to use the java.util.logging framework built in to the Java platform. But we soon realized that it was insufficient for our needs.

Looking for alternatives, I found Apache Log4j 1.2 and Logback 1.0. I was not very impressed with either of them, and a bit frustrated with the fragmentation of logging frameworks for Java.

Then I discovered Apache Log4j 2, which was still in beta, but looked promising and I decided to try it out. It worked well for us, and I decided to get involved to improve and contribute to it. I hoped that it once will become the standard logging framework for the Java platform.

We used Graylog to aggregate and analyze log events, and I developed a plugin for Log4j 2 to make it easier to integrate with Graylog. This plugin, GelfLayout, was contributed to the project and became part of Log4j 2. Then I got invited to be committer in the Log4j 2 project.

2015 I got a new job at another IT company. We also needed a Java based logging framework, and I introduced Log4j 2. We found the plugin I had developed at the previous job useful. Later, I developed another plugin for our needs, KafkaAppender, and contributed it to the project. Then I got invited to the Apache Logging PMC (as a committer September 2015, and later member of the Project Management Committee June 2016).

So, thanks to open source and the Apache Software Foundation, I was able to develop a software component when working for one employer, and then continue to use it at my next employer.

How can you do this yourself? Most likely you already use some open source software at work, and there are probably cases where it can be changed to fit your needs better. Make use of your right to make changes, and consider contribute them upstream if they constitute generic improvements. That will benefit the larger community by improving widespread software. It will also benefit the company you work for since they will get less maintenance burden when never versions are released. And finally it will benefit your future self when you work for another company using the same open source software. Read more about how to contribute to an Apache open source project here: http://apache.org/foundation/getinvolved.html

Mikael Ståldal works as software developer, developing mostly in Java and Scala. He has worked at various IT companies in Stockholm. Mikael is also committer and PMC member of the Apache Logging Services project.

= = =

"Success at Apache" is a monthly blog series that focuses on the processes behind why the ASF "just works" https://blogs.apache.org/foundation/category/SuccessAtApache

Wednesday September 05, 2018

Success at Apache — 赢在 Apache: If it helps others, all the better.

by Sally Khudairi, with contributions by Ignasi Barrera, Von Gosling, Luke Han, Kevin A. McGrail, and Anthony Shaw. Translations by Ted Liu and David Zhenwei Dong.

I became active in The Apache Software Foundation at its inception in 1999. I am responsible for elevating the ASF's visibility, and supporting the Foundation by counseling 350+ Apache projects and their communities in the areas of messaging, outreach, and engagement.

As a global, virtual, and diverse community, the ASF relies on countless Apache Members, Committers, and Contributors to help share our values and explain our processes with others. We have grown from a single project to hundreds of projects and communities https://projects.apache.org/committees.html?date through "The Apache Way": an inclusive process and judicious reinforcement of "Community Over Code". 

We launched the "Success at Apache" blog series following the Media & Analyst Training at ApacheCon Seville in 2016. I asked ASF Board Member and VP Brand Management Mark Thomas his opinion on what he thinks are some of the reasons that the ASF "just works". His immediate response was: "project independence". I asked if he'd put that in writing —in his own words— as our community members' personal experiences help others see The Apache Way through their unique perspectives. Shortly afterwards, we published "Project Independence" https://blogs.apache.org/foundation/entry/success_at_apache_project_independence and "Success at Apache" was born https://blogs.apache.org/foundation/feed/entries/atom?cat=SuccessAtApache

Whilst English is the ASF's official language, localization often helps foster understanding,  encourage adoption, and onboard new contributors more quickly. A while back, ASF Member Ted Liu told me that he and some of his coworkers had translated a handful of our "Success at Apache" blog posts into Mandarin Chinese. He asked if it would be useful to us.

Why yes, of course: new approaches to promote and propagate The Apache Way are always appreciated.

. . . 

赢在 Apache

- Meritocracy, by Kevin A. McGrail, Vice President of ASF Fundraising. Translation by David Zhenwei Dong.

- Lowering Barriers to Open Innovation, by Luke Han, Vice President of Apache Kylin. Translation by David Zhenwei Dong.

- Scratch Your Own Itch, by Ignasi Barrera, a member of the Apache jclouds PMC. Translation by Ted Liu.

- Contributing to Open Source Even with a High-pressure Job, by Anthony Shaw, contributor to over 20 Open Source projects, including Apache Libcloud. Translation by Ted Liu.

- Open Innovation from a Non-native English Country, by Von Gosling, original co-founder of Apache RocketMQ. Translation by Ted Liu.

. . .

Ted's action reflects one of our greatest successes at Apache: the mindset of "If this is helpful to me, that's good (= "scratch your own itch"). If it helps others, all the better." 

After all, we didn't become the world's largest Open Source foundation by not being helpful. There's always something needing to be done in an all-volunteer community: if you'd like to help the ASF, we will happily accept your assistance where possible. Plus, helping others feels pretty great.

Whether contributing code and writing documentation http://apache.org/foundation/getinvolved.html , mentoring community members http://community.apache.org/ , supporting the ASF through an individual donation or corporate sponsorship http://apache.org/foundation/contributing.html , or serving in myriad other ways https://helpwanted.apache.org/ , we thank you.

For an immersive, rewarding experience with dozens of Apache projects and hundreds of user and developer community members, consider joining us at ApacheCon in Montreal 24-27 September 2018 http://apachecon.com/ . This year's event is extra special, as we're celebrating the 20th Anniversary of ApacheCon —huzzah! All are welcome https://blogs.apache.org/comdev/entry/my-first-experience-of-apachecon

We look forward to seeing you there and sharing your Success at Apache.

Sally Khudairi is Vice President of Marketing & Publicity at The Apache Software Foundation (ASF) where, in 2002, she was elected its first female and non-technical Member. Over her 25-year career in the Web, Khudairi has been lauded as a dynamic communications strategist and expert in next-generation innovations, and has played an integral role in building campaigns for some of the industry’s most prominent standards and organizations. Prior to launching the ASF in 1999, Khudairi was deputy to Sir Tim Berners-Lee as Head of Communications at the World Wide Web Consortium (W3C), overseeing the launch of 17 specifications that include PNG, CSS, HTML4 and XML. She is Managing Director/Luxury & Technology Practice lead at HALO Worldwide and Founder/Chief Marketing Officer at OptDyn.

= = =

"Success at Apache" is a monthly blog series that focuses on the processes behind why the ASF "just works" https://blogs.apache.org/foundation/category/SuccessAtApache

Tuesday August 07, 2018

Success at Apache: the Apache Legal Shield - a pragmatic view

by Bertrand Delacretaz

I became active in the ASF in 2001 via Gianugo Rabellino -- he was the one who started the discussions with Apache Fop about me donating the jfor XLS-FO to RTF converter that I had developed earlier. It was already too late to uninvent RTF which is a terrible format, but I digress. I am currently a member of the Board of Directors of the ASF and have been doing a lot of thinking (and presentations) about what makes the ASF tick in terms of collaboration and Shared Neurons.

Section 12.1 of the Apache Bylaws https://www.apache.org/foundation/bylaws describes the legal protection that the Apache Software Foundation provides to our directors, officers and members.

I'm not a lawyer by far, however, and that language is a bit hard for me to parse, so I thought I'd try to clarify what this means for our contributors and learn more about it in the process.

If you go into detail there's certainly more to it but I think the items below are the absolute basics that every PMC member https://www.apache.org/foundation/how-it-works.html should understand in order to benefit from the legal shield that the Foundation provides.

What is a "Legal Shield" ?

An important goal of the Apache Bylaws and policies is to isolate our contributors from any legal action that might be taken against the Foundation, if they act as specified in those policies.

That's what we mean by "legal shield": a way for our individual volunters to be sheltered from legal suits directed at the Foundation's projects, as mentioned in our "How the ASF works" document https://www.apache.org/foundation/how-it-works.html .

Acts of the Foundation

The first thing is to make sure our software releases are "Acts of the Foundation" as opposed to something that people do in their own name. This is natural if we follow our release policy https://www.apache.org/legal/release-policy.html , which defines a simple release approval process for releasing source code that makes the project's PMC https://www.apache.org/foundation/how-it-works.html responsible for the release, as opposed to our individual contributors and release managers.

This means that if the released software is ever involved in legal action and someone has to testify or produce information as part of a subpoena, or worse, it's the Foundation which is in charge of that and not our individual contributors. These things happen from time to time, not very often but they can represent a lot of work and aggravation that none of us are looking for. The 2011 subpoena to Apache around Java and Android http://www.groklaw.net/articlebasic.php?story=20110509221136468 is just one example of that. Produce documents reflecting all communications between someone and Apache, how fun is that?

The goal of our release process is to make it very clear what an Apache Release is, and also clarify that anyone using our software in other ways, by getting it directly from our code repositories for example, does so at their own risk. If it's not an Apache Release we didn't give it to them, they grabbed it on their own initiative and have to accept the consequences of that.

The Rest is for Contributors

This leads to a second and related item: developer builds, which happen much more often than releases, often daily, and that people can easily download and use.

Those builds are meant for contributors to our projects, to use in development and testing as part of their contribution activities.

To avoid any confusion, it is important to clearly label them as such, and to draw a clear line between them and official Apache Releases. They should only be advertised in places where developers who are part of our communities (as opposed to the general public) can see them, and with suitable disclaimers.

In our world of continuous deployment and automated builds, the lines between what's a release and what's just tagged code that works for someone are often blurred. That's totally fine from a technical point of view, and often desirable when one wants to move fast, but we shouldn't forget about the possible legal implications ot distributing software.

Let's make sure we take advantage of the well-designed Apache Legal Shield that the Foundation provides to us, by strictly following our release policy and clearly specifying what is what in terms of downloadable software.

I never thought I'd write a blog post on a legal topic, so here's the FUN DISCLAIMER: As mentioned, I am not a lawyer by far, and the above should not be considered legal advice - just a pragmatic view that can hopefully help our contributors better understand the related issues. For legal advice, consult your own legal advisor! And if you're thirsty after reading all this, get a drink and give a toast to the ASF and its founders!

Many thanks to the fellow Apache members who provided feedback and additional ideas for this post.

. . . 

Bertrand Delacretaz works as a Principal Scientist with the Adobe Research team in Basel, Switzerland. He spends a good portion of his time advocating and implementing Open Development as a way to make geographically dispersed teams more efficient and more fun for his coworkers. Bertrand is also an active Member of the Apache Software Foundation, currently on his tenth term on the Foundation's Board of Directors (Fiscal Year 2018-2019).

= = =

"Success at Apache" is a monthly blog series that focuses on the processes behind why the ASF "just works" https://blogs.apache.org/foundation/category/SuccessAtApache

Monday July 09, 2018

Success at Apache: The Apache Way for Executives

by Alex Karasulu

I'm a long time member of the Apache Software Foundation and have been an executive officer of several corporations over the course of the past 20 years. I've co-founded several projects in the community and mentored several others.

The "Apache Way" has benefited several aspects of my life, however I never imagined it would help make me a better executive. Even non-technical executives, in organizations totally outside of the realm of technology, can benefit from the Zen of the Apache Way.

Life is hard when you're stupid

I was involved in a number of early dot com startups as an executive, however that was before my involvement with Apache and long before any exposure to the Apache Way. To this day, I remember how opportunistic decisions for short term gains, the lack of collaboration, openness and communication kept causing friction that made my job and ultimately my life much harder than it had to be.

Learning while on the job

Exposure to the philosophy began early even while lurking on mailing lists but picked up more while incubating the Apache Directory Project where I worked with others to grow an active community. Meanwhile, I was the Chief Technology Officer of a large financial services company called Alliance Capital Partners. It was 2002, and the first time I had to conduct myself as a C-Suite executive in an enterprise that was obviously not a technology company. Incidentally, the lack of hands-on coding got me working on a pet project that ultimately became the Apache Directory Server and Apache MINA. The project was medicine to keep me sane and technically up to date. Unbeknownst to me, this would save my career, not as a developer, but as an executive.

The Apache Way makes life easier

The most important and first lesson I learned from the Apache Community was to avoid short term gains that were unsustainable in the long term. This very important core principle derives in part from the concept of "community over code". It does not matter how much code you write, or how good your code is if you cannot get along, compromise, and communicate respectfully with your peers. The code does not write itself, its the community behind it that keeps the code alive. Involving only the most technically proficient contributors should never trump the need to build a sustainable community. I saw projects often suffer from self-centered yet skilled coders added as committers for short term gain at the detriment of a healthy sustainable community. So as a corollary to community over code, avoid short term gains that get in the way of the long term sustainability of an organization's culture. This has immense applications for any executive in both technical and non-technical fields.

While growing my new development organization in this financial services organization, I decided to avoid hiring people that seemed to be very skilled technically but lacked the desire or social skills to collaborate with others. Thanks to experiences at Apache, I could start telling them apart much better than I did before. Also, I was calmer and less anxious when hiring to fill gaps on the team. It was better not to have the resource than to introduce a bad apple onto the team. 

This was contrary to how I had operated earlier and started producing great results. The application of this basic principle lead to a solid team that worked better together than ever before in the past. They were able to leverage each others' skills thanks to collaboration to out perform any one skilled developer. This is all thanks to the concept of community over code where social skills, and collaboration were stressed more than technical skills. In the end, being kind, listening, and asking smart questions begets the kind of collaboration needed to build complex software. 

Not only did this help with developers, it also worked with teams that did not produce code like project managers under the CTO office. The rule is golden, and IMHO should be applied to any executive's decision making process regardless of the nature of the business or topic at hand.

Inner Source is the Apache Way

Executives drive the architecture and cultural direction of their organizations and the Apache Way provides a solid framework to create healthy foundations through open collaboration, communication and the availability of knowledge for everyone to participate.

Several very successful technology companies have adopted the Apache Way without really realizing they're doing so.  In 2000, Tim O'Reilly coined the term Inner Source https://en.wikipedia.org/wiki/Inner_source to apply Open Source principles to any organization. Tim was essentially talking about applying the Apache Way within organizations. The Apache Way has proven itself with companies like IBM, Google, Microsoft, SAP, PayPal and even financial institutions like Capital One which have adopted the Inner Source methodology which is one and the same.

Without going into the details, of which we the Apache Community are intimately aware (using it daily within our projects), I would like to stress how important the approach is for executives outside of Apache to understand. The Apache Way can save organizations from all out disaster, not to mention billions of dollars by impacting the quality of services and products they produce. Again this does not only apply to companies in technological sectors. Capital One a financial services company has also used Open Source methods for internal projects to be extremely successful https://www.oreilly.com/ideas/using-open-source-methods-for-internal-software-projects .


The Apache Way provides several benefits to executives aware of the approach. Executives can directly integrate the principles of the Apache Way into their own thinking to improve their potential for personal success. However the biggest value comes from the cultural framework it produces for the entire organization, however to leverage it in their organizations, executives must be aware of it. The Apache Way has personally helped me grow as an effective executive and it can help others as well. It also provides a compass for how to properly build effective organizations, not only technical ones.

Alex Karasulu is an entrepreneur with over 25 years of experience in the software industry and a recognized leader in the Open Source community. He is widely known as the original author of the Apache Directory Server, used by IBM both as the foundation of the Rational Directory Server and also integrated into the Websphere Application Server. Alex co-founded several Apache projects, including MINA, and Felix, among others, which, along with their communities, thrive independently past his day-to-day involvement in the projects. He is the founder of Safehaus, where he authored the first low-resource mobile OTP algorithms in Open Source with the OATH community that was later adopted by Google in their Authenticator product. In addition to IBM, Atlassian, Cisco, and Polycom are just a few of the many companies that sell commercial hardware and software solutions that bundle or embed software and products that Alex has created. Alex holds a BSc. in Computer Science and Physics from Columbia University. He is the founder and co-CEO of OptDyn.

= = =

"Success at Apache" is a monthly blog series that focuses on the processes behind why the ASF "just works" https://blogs.apache.org/foundation/category/SuccessAtApache

Monday June 04, 2018

Success at Apache: the Chance to Influence the World

by Weiwei Yang

I submitted my first patch to Apache Hadoop in 2015, a very simple bug fix with just a few lines of changes. However the feeling is still vivid to me when the patch was accepted, I felt great accomplishment. It was not about how big the change was, but rather because I knew even a small change would help a lot of people. This is the best thing I like about working in Open Source, the work I've done has the chance to influence the world. 

As of today, I have contributed nearly 200 patches to Apache Hadoop, over 20k lines of code. I still feel happy when the community accepts my patches. I believe that having such passion is an essential for an individual contributor to make the way to Apache. Unless your company paid you to work on Open Source, you must find yourself such accomplishment during the work, otherwise the commitment won't last. Like me, I spent over 3 years until I received commit privileges for Hadoop. In retrospect, it was a tough, challenging but fast growth journey. I am glad I did not give up and finally get where I am now.

If you are hired by a commercial company that sells products or services powered by Open Source software, then congratulations, you are on a shortcut to Apache. Such companies usually have a strong team working directly on Open Source projects and a lot of committers. Being a member of such organization, you will have more time working on the project, get faster feedback of your patches, opportunities to participate more discussions and much deeper involvement. Unfortunately, I was not working for such companies. Moreover, my native language is not English and I have a big timezone gap with the majority people from the community. That makes my path to Apache much more difficult. I believe there are many people, just like me at 3 years ago, who are willing to contribute but finding it hard to. In this post, I will share some tips how to work with the Apache community and how to grow up to a committer.

First, it's important that you know things that are public to everyone. Every Open Source project has its own tutorials introducing how to contribute, be sure you have read that before working on any patches. Those documents generally tell you how to contribute code in the "Apache" way, and how to collaborate with the community.

Second, don't mind fixing bugs. Actually I suggest to begin with fixing bugs. You may find bugs in your daily work, or somebody reported to the community. No matter if they are big or not, bugs must be fixed so that it's easier to get attention from the community. In an Open Source community, everyone volunteers to review some other ones' patches. So don't be upset if nobody gets to your patch quickly, try to soft ping committers around this area. But never push them for anything. And always be polite.

More involvement. There are many ways to get more involvement. First, if a community sets up a MeetUp once in a while, try to attend even you are remote or in an inconvenient local time. Such MeetUps can help you gather information of the development status, current community focus etc. It also helps others to get familiar with your face; second, try to participate in more discussions. This could be discussions on mailing lists, issue tracking systems or a Web conference that discusses a particular issue/design. In my opinion, this is the hardest part especially for contributors from overseas.

Be self-motivated and passionate. Nobody forces you to work on Open Source projects, you need to keep motivating yourself. Like I first mentioned in this post, there are more ways to be self-motivated than just feeling accomplished. Working in the community gives you the chance to work in a diverse environment, meet people from different companies and different countries; you can get as many chances as you want to solve difficult real problems, and improve your skills; you can build your reputation in the community which also helps your career development.

I truly hope my experiences would help people. Now I am working at Alibaba Group, and it gives me more reason to write this post. I see a lot of talented people around, they have solid skills, they have done and are doing a lot work to make Hadoop better. They are open to contributing back but are having various of difficulties to work with the community. I am committed to helping grow this community, and I do believe an open and diverse community will help the project thrive.  

Weiwei Yang is a Staff Engineer working at Alibaba Group. He has been working on Big Data area for over 8 years, most of time working on Apache Hadoop. He contributed to several Apache projects such as YARN, HDFS, MapReduce, Ambari and Slider, and an active Hadoop committer. At present, he is working in Alibaba’s data infrastructure team and is focusing on evolving Apache YARN to support mixed workloads, improve performance and cluster utilization. Prior to that, he worked in IBM for several years and won multiple Open Source contribution awards.

= = =

"Success at Apache" is a monthly blog series that focuses on the processes behind why the ASF "just works" https://blogs.apache.org/foundation/category/SuccessAtApache

# # #

Monday May 07, 2018

Success at Apache: Dip into the Apache Way

by Nick Couchman

Like other recent contributors to this blog, I am not a developer by trade. My day job is as a Linux Systems Engineer and team manager, and, truth be told, my programming skills are not something I would rely on to make a living. Despite these facts, I've found something beyond acceptance in being a part of the Apache Guacamole project: mentoring.

Most of my experience with The Apache Software Foundation (ASF) has been with retrieving the Apache Web Server (httpd) http://httpd.apache.org/ from the download page, and getting involved with the ASF was more accidental than anything else. I've brushed arms with the Guacamole project http://guacamole.apache.org/ at several times over the past decade. As a systems administrator/engineer, and one who prefers Linux to some of the commercial alternatives, I'm always happy to see software produced that is truly cross-platform, and, as many current trends are demonstrating, Web browser applications are the pinnacle of cross-platform applications. I used Guacamole in various applications in my place of employment, but always saw opportunities to improve it – add a feature here or there, make it more administrator or user friendly, etc.

After a recent job change, I found myself with a little more free time than I had previously had, and a desire to do something productive with that time. I started thinking about how I could give back to the Open Source community  I've long been a user of many software packages made freely-available to the world, and my appreciation for the developers and companies that produce and support these efforts had, for a while, made me want to do something to return the favor and give back to that community. I also needed to challenge myself and fill some of my free time, and growing my programming skills seemed like a good way to accomplish these goals.

When I settled on Guacamole, I found that it had entered into the Apache Incubator http://incubator.apache.org/ programming in an effort to get the project accepted by The Apache Software Foundation. I thought that was cool, but didn’t think much else of it at the time, and I knew little about the organization. The Incubator program helps potential ASF projects learn how to create a certain culture and community that encourages development and interaction.

This culture is created, in large part, by the Apache Way, a set of guiding principles and behaviors for projects within the ASF. One of the biggest keys to my success, thus far, in contributing to the Guacamole project is the concept of mentoring  not a behavior or principle officially outlined in Apache Way documents, but rather a byproduct of those principles. It seems that it is very human to be dismissive of people that don't measure up to our standard in some way or another, and my programming skills are, by far, the weakest of any of the current contributors to the Guacamole project. However, instead of ridicule or dismissal or discouragement, the other developers within the project have been accepting, helpful, and provided guidance.

And, as with any good education opportunity, they don't do this by giving me the answers or telling me how to do something, they do it by providing examples, references, and pointers that help me to think through the why and make my way to the how to write better code. The result? I still wouldn't rely on my programming skills for my day job, but I've come a long way in the 18 months that I've been a part of the project, and the code I write today is better than when I started.

Finally, this involvement actually makes me better at my day job. Not only does it give me a stronger appreciation for the effort that goes into writing the software that I use on a regular basis, but, more practically, it gives me a stronger set of skills for debugging problems and tracking down bugs that occur. I'm better able to locate the actual cause of problems, provide useful descriptions of those problems, and interact with the software engineers and developers in various places responsible for writing, improving, and supporting those applications.

At this point, my involvement with The Apache Software Foundation is limited to the Guacamole project, and will probably stay that way for the foreseeable future, but it's great to be involved with an organization and community that has a very diverse community of developers and projects, and know that, should I choose to add another challenge to my life, there are other projects out there that would welcome the involvement and would provide similarly positive experiences in helping me grow in my ability to give back to the open source community. If you're itching to dust off or learn some programming skills then I encourage you to look at the many available Apache Software Foundation projects available and jump into one of the communities. You'll almost certainly want to join one of the mailing lists for the project and your involvement can grow from there.

Nick Couchman is a Senior Linux Systems Engineer and Technical Team Lead for a major cosmetics conglomerate, and spends his days trying to convince everyone that they should run more Linux and less...other stuff.  He spends his evenings with his family and increasingly small amounts of free time contributing to the Apache Guacamole project, learning how to write C, Java, and JavaScript.

= = =

"Success at Apache" is a monthly blog series that focuses on the processes behind why the ASF "just works" https://blogs.apache.org/foundation/category/SuccessAtApache

# # # 

Tuesday April 10, 2018

Success at Apache: Am I there yet? A n00b's perspective

by Charles Givre

Let me start out by saying that I am not a developer. I do have a technical background, but I hadn't coded in Java for at least 10 years before I got involved in the Apache Drill project. One has to wonder how, as a non-developer, I ended up as a committer for the Drill project. In this blog post, I'd like to share with you how I came to be involved with the Drill project.

But first, why Drill?

I first heard about Drill at an industry conference several years ago. I was speaking with Dr. Ellen Friedman about some data issues we were having and she casually mentioned have I tried Drill? I had not heard of it at that point, so I did some research and it seemed as if Drill could solve a lot of problems that my clients were having. But then, I tried using it and kept getting stuck.  

If you aren't familiar with Apache Drill, Drill is an SQL engine which allows you to query any kind of self-describing data. After experimenting with Drill for a while, I was impressed enough to thing that the tool had major potential in security. One of the biggest problems that Drill solves is the need to Extract, Transform, Load (ETL) data into an analytic tool before actually doing analysis of that data. This ETL process adds no value to anything really, and costs large enterprises literally millions of dollars as well as adding unnecessary delays between the time data is ingested and when the data is actually available for analysis. In security applications, this delay directly translates into risk. The longer it takes to make your data available, the more time it will take to potentially find malicious activity and hence, more risk. Therefore, if you're able to query the data without having to do any kind of ETL or ingestion, you are lowering your risk as well as potentially saving millions of dollars.

Getting Involved

Unfortunately, when I started using Drill, I saw this potential, but I couldn't get it to work. My next step from here was to try to get assistance at my company. I pitched the ideas to my company leadership, but it proved very difficult to get the company to pull Java developers from revenue generating projects to work on this "pie-in-the-sky", unproven project. After spending several months on this, I got really frustrated and decided that I was going to try to do it myself, however, I really had no idea what I was doing. I hadn't coded in Java for at least 10 years at the time, and had zero experience with all the modern Java development tools such as Maven and Git. What I did have was persistence, so I started asking for help and decided that I was going to dive right in and start adding the functionality that I felt Drill needed to be useful in security applications. I started working on something that someone else started—the HTTPD format plugin for Drill. Most of the coding was done, but there was still enough there for me to get my hands dirty and start figuring things out.

What I learned

I still would not consider myself a developer, but after getting that particular item committed to the codebase, I learned a lot about how open source projects actually work as well as writing production quality code. Since then, I've tried to add at least one bit of new functionality to each Drill release. I would encourage anyone who is interested in contributing to an Open Source project at the Apache Software Foundation, to dive right in, and start. There are still a lot of ideas I have for Drill, and with time, I hope to have the time to see them through to implementation.

In conclusion, I'm fairly certain that my involvement with Drill and the Apache Software Foundation is really just beginning. I'm currently working on the O'Reilly book about Apache Drill with a fellow Drill committer. It is my hope that the book will spark additional interest in Apache Drill. Open Source software is at the heart of the ongoing data revolution which is dramatically expanding what is possible with data. I firmly believe that Apache Drill will have a role to play in this data revolution and I'm honored to have the opportunity to play a small role in developing Drill.

Charles Givre CISSP is a Lead Data Scientist at Deutsche Bank where he works in the Chief Information Security Office (CISO). Mr. Givre is an active data science instructor and regularly teaches classes about data science and security at various industry conferences, such as BlackHat. Mr. Givre is a committer for the Apache Drill project and together with Mr. Paul Rogers, is working on the forthcoming O’Reilly book about Apache Drill. He can be reached at cgivre(at)apache(dot)org.  

= = =

"Success at Apache" is a monthly blog series that focuses on the processes behind why the ASF "just works" https://blogs.apache.org/foundation/category/SuccessAtApache

# # #

Monday March 05, 2018

Success at Apache: Open Innovation from a Non-native English Country

by Von Gosling

When I saw the "Success at Apache" series, I thought about writing something about my, being from a non-native English country, Open Source experience these past few years. Last year, RocketMQ graduated from the Apache Incubator and became one of the Apache Top-Level Projects. As one of the original co-founders of RocketMQ, I was proud to see an Open Source community from Apache RocketMQ that has an ever-growing diversity. The Apache Software Foundation (ASF), one of the most famous and great technology brands, has thousands of companies’ software infrastructure based on their projects. This is proven from the worldwide download mirror activity in ASF statistics. As an early implementer/pioneer of Open Source in China, Apache HTTP Server, Apache Tomcat, Apache Struts 1.x, and Apache Maven are my favorite software stacks when I worked for building distributed and high-performance websites.

Last year, I wrote an article about the road to the Apache TLP, which is published in China’s InfoQ. Some people asked me how to be more ‘Apache’ and how to build a more diverse community. These are the questions that many people are concerned about. In this blog post, I will address how to be more collaborative around the world, especially in non-native English countries.

Open Communication
With more and more instant messaging apps coming up in Android and IOS world, the younger generation prefers to communicate using such way, which has spread to the daily coding life for the majority of people. But, it is not search engine friendly and in most cases it does not support multi-channel for multi-language. I have been involved in many such local technology groups, together we have discussed what went wrong, explored ideas about how to solve it, and come up with a good solution together. This method worked for all my past projects, but when we hope to be more involved in Open Source around the world, that method does not work well. I remember clearly when RocketMQ began to discuss the process for its proposal, some people complained about what we have to do in the local community. We learned much about from this discussion in the community, and thus, found an effective solution. Hence in the Apache RocketMQ community, we encourage users to ask the question using the user email list. In order to make the communication process effective, we answer the question in the same language of the question. With more and more committers coming from different countries, this solution will help to grow the more diverse community. But, as John Ament said in another "Success at Apache" post https://s.apache.org/x9Be --open communication isn't for everything. We also allow private communication between the users and us as some questions might not be proper to discuss publicly. But that isn't a part of the decision making process. Likewise, anytime we're talking about individuals in either a positive or negative way should be conducted on the private list for a project.

Easy ways to be involved in the community
This is another top concern in the Open Source world. Some people may not know that in China there are many local communities about Apache Projects, such as Apache HTTP Server, Apache Tomcat, Apache Spark, and Apache Hadoop. Such Projects have corresponding Chinese documentations. On the other hand, we try our best to improve the English documents. We consider the messages behind every document page. If one finds a minor or big native narrative polish, one could leave a message, or send feedback to our dev or user email list. Besides documentation, we also hold programming marathons in the community irregularly to get more involved with the community. We could find more users who have more interest, especially cross-domain technology in such campaigns. Recently, we open sourced more tasks in the Google Summer of Code. Students will develop Open Source software full-time for three months. We will provide mentoring and project ideas, and in return have the chance to get new code developed and --most importantly-- to identify and bring in new committers. It is another chance to let PMC members know how to improve and let more students get involved in the community easily.

In China, Internet giants like Alibaba are devoting themselves into Open Source projects hence according to my personal experience, it made sense to help more excellent Chinese projects to come into the Incubator. Right before the Lunar New Year, another famous project from China, Dubbo, started its Apache journey. I am glad to be a local mentor and hope to continue to share what we have learned. Thanks to the ASF, more and more Open Source projects will benefit our daily coding. That is a great appeal around the world’s Open Source field.

Von Gosling is a senior technology manager working at Alibaba Group. He has extensive industry software development experience, especially in distributed tech., reliable Web architecture and performance tuning. He holds many patents in the distributed system, recommendation etc. he has been a frequent speaker at Open Source and architect conferences worldwide including ApacheCon and QCon. He has been the lead for messaging at Alibaba as well as the Tenth and Sixteenth CJK OSS Award recipient. He is the original Apache RocketMQ co-founder and Linux OpenMessaging Standard Initiator.

= = =

"Success at Apache" is a monthly blog series that focuses on the processes behind why the ASF "just works". 1) Project Independence https://s.apache.org/CE0V 2) All Carrot and No Stick https://s.apache.org/ykoG 3) Asynchronous Decision Making https://s.apache.org/PMvk 4) Rule of the Makers https://s.apache.org/yFgQ 5) JFDI --the unconditional love of contributors https://s.apache.org/4pjM 6) Meritocracy and Me https://s.apache.org/tQQh 7) Learning to Build a Stronger Community https://s.apache.org/x9Be 8) Meritocracy. https://s.apache.org/DiEo 9) Lowering Barriers to Open Innovation https://s.apache.org/dAlg 10) Scratch your own itch. https://s.apache.org/Apah 11) What a Long Strange (and Great) Trip It's Been https://s.apache.org/gVuN 12) A Newbie's Narrative https://s.apache.org/A72H 13) Contributing to Open Source even with a high-pressure job https://s.apache.org/lM9O 14) Open Innovation from a Non-native English Country https://s.apache.org/lh61

# # # 

Monday February 26, 2018

Success at Apache: Contributing to Open Source even with a high-pressure job

by Anthony Shaw

I believe in the mission of the ASF for many reasons, but the first is the reason why I got into open-source software- free and open access to knowledge.

Back when I was age 12 (1998), I started to learn to program in dBase 4. dBase 4 and the compiler Clipper were not cheap, especially for a $5-a-week paper-round. The box with the software was unwanted by a local company and it came with the manuals. We didn't have the internet at home yet so I was left to go by the manual, and what I could find from second-hand stores and office cleanout sales. For the next decade, I learnt to case based on what I could find, borrow and scavange until in 2002 when I got a copy of Linux and assembled a couple of machines from unwanted parts from the village computer store.

This is where I discovered free and open-source software and really started to build on my coding skills.

My goals were to learn and to share what I'd learnt that others could get to where they needed to go faster. It also helped that software skills were well sought-after in Europe so it set off me in a career in IT.

20 years after I learnt to code, I've moved out of software-engineering and into Learning and Development at Dimension Data for a 29,000 person technology company that operates in 49 countries across the world. My current roles involves about 3-months a year of travel (15 countries typically), managing a department of over 30 people spread across 4 countries and 4 timezones and delivering on large and complex initiatives with high-degrees of change and short deadlines.

In 2016 I made a choice after getting promoted into my current role that I would continue to contribute to the open-source projects I'd worked on for years. But I set myself 3 rules;

1. I would not take away from time with my family
2. I would not interfere with my work commitments
3. I would look after my health

My open-source contributions

For the past 4 years I've made around 1,000-2,000 contributions annually. These have consisted of bug fixes, submissions, and to around 50 projects.

The largest contributions I've made have been to Apache Libcloud, a multi-cloud abstraction library written in Python. Initially this was driven by a work commitment to contribute an integration with the cloud API we'd designed, but I soon realised the power of the library. Going back to my original goal of free and open access to knowledge, I'd seen an alarming trend in the computing world. Proprietary APIs were driving what is known in the industry as "stickiness" or to be frank, lock-in.

Cloud lock-in means that anyone without access to a reliable network, money or willing to sign up to these contracts is being pushed out of advances in technology. I know developers that are students, in remote areas such as rural Australia, Asia and Africa, or those who simply have little money.

Apache Libcloud's design means that you can design applications which can be deployed to OSS platforms like Apache CloudStack and OpenStack.

After finishing the work driver around 100 hours developing a container abstraction layer for Apache Libcloud that meant that developers could write automation for OSS platforms like Kubernetes using the same API as you would with a public cloud provider.

This was all whilst managing family time, work commitment and my health.

These are my 3 tips for maintaining contributions with a high-pressure job:

1. Pick a project that you care about

This is the most important, something that just sparks your curiosity is good fun, but long term interest often dwindles. I've been victim of "ooh shiny thing" many times in the past, but as my career has taken off, I've had to develop the discipline to stop myself from writing my own scripting language, or building an automated sprinkler system from scratch. I stop and remind myself that I might have the time this second, but what about next week and next month? Stop and prioritise.

Prioritise projects that mean something to you.

The 2 OSS projects I commit the most to are Apache Libcloud and SaltStack. I believe in Apache Libcloud's mission of giving open-access to cloud platforms. My SaltStack contributions have been focused around cloud abstraction, networking API abstraction and other fixes and utilities that make it easier for developers and end-users.

The difference between picking something shiny and something you believe in is that long-term you commit more and you find it easier to jump in and help when you can. But how do you find the time?

2. Choosing your tasks wisely and making time

I get asked this question all the time, "how do you find the time". When I try and convince people to contribute to OSS the response is always about time.

Get rid of the things that don't add value

If you can afford to, hire help to give you back time in your week. Not only does open-source help with your skills and knowledge, but it increases your value to a potential employer. Hiring someone to blow the leaves, or help with the chores once a week doesn't need to cost a lot, but if you work out how much value you can get back from that time it often makes sense.

Another thing I've been strict about is binge-watching TV series and gaming. Playing 100-hours of the latest game might be fun, but I find developing more rewarding in the medium-to-long term. Find ways to unwind that don't consume so much time, like meditation, exercise, or reading.

But, if you do need to put your feet up and watch some TV for a few hours, don't feel guilty about it. 

Work smart, not hard

When I do sit down to contribute something, it'll have been carefully planned and thought through what I'm going to do, what I'm going to test and how I'm going to structure it. I try and complete tasks quickly, with foresight and a goal. Once I've completed this 1 module, with tests, I'll submit my contribution. Don't try and refactor the whole project over a weekend. Keep it simple.

But we all know sometimes the best plans go out the window. If you find yourself going down one of those rabbit holes, where you can't get something to compile or you can't debug one of those zombie bugs we love so much as developers.

Stop yourself.

You can easily sit until 3am banging your head against the wall trying to figure it out. This was my advice when I used to manage development teams. If you get stuck, take a break, ask for help and if that still doesn't work, move onto something else. 

Sometimes I pause working on a task if I can't figure it out. Pause for an hour, a week, or even a whole year. When you have one of those "aha" moments, you go back in and finish the job.

It saves time, it delivers better software and it's a good skill to have as a developer.

Find time

A contribution comes down to 3 things:

1. An idea
2. An understanding
3. A "change", like a fix, feature, test, code-review, documentation etc.

The ideas come to me through reading, listening to users or looking at bug submissions. I do this as and when I have a spare minute. This is normally on my lunch break, when I'm waiting for someone or something. 

The time for understanding I get by listening to podcasts and talking to people at conferences. I get a few hours a week in the car and I spend time doing some chores. During that time I always have headphones on to listen the newest Python podcast or OSS update.

The time to sit down and write, code, or test comes for me on the plane (where I'm writing this blog post!). Last year I did enough miles in the air to fly around the world 8 times, most of that time was spent coding, relaxing or sleeping. Aside from that, time spent in airport lounges, on the train or waiting for people I'll whip out my laptop. Any plane that has Wi-Fi I can push changes, else the minute we land I'll have a laptop open and running git push.

Weekend-time is off limits unless I'm travelling or I'm alone. That's rule 1 -- do not take away from time with the family.

3. Managing your workload and avoiding burnout

There are 2 components to this, managing your work commitment and managing your contributions. You need to do both to succeed. 

It's ok to stop and take a break. There is always a pull-request to merge, a bug to inspect, and an email from an end-user. If you need to take a break for a while, talk to the team, ask for help and be frank. We're all in the same boat, contribution is optional. 

So many times I see people contribution feeling like they have a complete obligation to test and fix bugs at 2am 
and then go to work at 8am. This is normally because they care about the project, they care about quality and they care about their reputation but sometimes you need to step back.

A strong project community will step up and help. If you know that work is going to be tough for the next few months, tell the team and set yourself a limit. Wind back for a bit until things calm down. 

Managing work commitments is tough, because there are often financial consequences (or at least a perception of them).

After 7 hours, you're not really adding value. I used to have a lounge-chair next to my desk and now I have a hammock as I work from home. After a few hours of solid concentration I'll happily go and sit down and do nothing for an hour. Your brain needs a break, sure you'll get the odd "working hard" jab from a passer by but I'm working smarter not harder. Once I'm refreshed I'll finish the next task about 30-40% quicker, to a better level of quality and insight. On the occasion I've done 12-14 hour work days, my brain is shutting down to conserve energy and your critical thinking is the first thing to switch off. Followed by logical thinking, this is where you make mistakes and deliver work that is less than a quality you'd normally expect.

I live close to the beach so my time out is going for a swim in the ocean or spending a bit of time with my family. As a manager I also see a responsibility to make it clear that it's encouraged to step back and recharge. Just in our chat-channel to say that I'll be offline for a couple of hours as I'm going to the beach mid-afternoon. I don't feel guilty about it and I hope they do the same.

Learn how to say no and don't feel guilty about it. When I coach people on this I ask, "who asked you to do this? Was no an option? What value is there in delivering this? What is consequence of not doing it? Who else could do it?"

Everyone wants to be helpful and indispensible, but your reliability is just as important to your reputation and what you deliver. 


Look after your health, be smart with your time and contribute for a cause.

Anthony Shaw is the Group Director of Innovation and Talent Development at Dimension Data, an NTT company. Anthony is an open-source advocate, member of the Apache Software Foundation and Python Software Foundation and active contributor to over 20 open-source projects including Apache Libcloud and SaltStack. At Dimension Data, Anthony is driving digital transformation for Dimension Data’s global clients across 50 countries and 30,000 employees. Key initiatives are software skills, automation, DevOps and Cloud. Anthony is based in Sydney, Australia and blogs about skills, software and automation to 170,000 readers annually.

= = =

"Success at Apache" is a monthly blog series that focuses on the processes behind why the ASF "just works". 1) Project Independence https://s.apache.org/CE0V 2) All Carrot and No Stick https://s.apache.org/ykoG 3) Asynchronous Decision Making https://s.apache.org/PMvk 4) Rule of the Makers https://s.apache.org/yFgQ 5) JFDI --the unconditional love of contributors https://s.apache.org/4pjM 6) Meritocracy and Me https://s.apache.org/tQQh 7) Learning to Build a Stronger Community https://s.apache.org/x9Be 8) Meritocracy. https://s.apache.org/DiEo 9) Lowering Barriers to Open Innovation https://s.apache.org/dAlg 10) Scratch your own itch. https://s.apache.org/Apah 11) What a Long Strange (and Great) Trip It's Been https://s.apache.org/gVuN 12) A Newbie's Narrative https://s.apache.org/A72H 13) Contributing to Open Source even with a high-pressure job https://s.apache.org/lM9O

# # # 



Hot Blogs (today's hits)

Tag Cloud