Entries tagged [success]

Monday September 23, 2019

Success At Apache: "Mentor Your Mentor"

By Patricia Shanahan

After retiring, I wanted to continue programming but without the pressure and constraints of a job, so I started contributing to Apache. Open software development the Apache way is a great retirement hobby, offering social contacts, intellectual challenge, continuous learning, and the pleasant feeling of making a contribution.

I just got back from having a wonderful time at ApacheCon NA 2019 in Las Vegas. While there, I met relatively young people, and older people who had been involved in Apache for up to 20 years, but joining as a retiree seemed to be unusual. 

Encouraging retirees could benefit Apache in many ways. 

Often, a retiree has a range of experience and skills that take time to accumulate. I have worked, for several years each, on applications, operating systems, compilers, system performance, and architecture of servers with dozens of processors. People like me who were programming in the 1970's have experience surmounting memory limitations, a skill that may be useful again for Internet of Things projects. I can imagine several reasons for a lack of retiree recruits. The most basic is that the computing profession was relatively small when a 2019 retiree would have started their career. That is a good reason to develop ways of helping retirees join Apache, so we will benefit from increasing numbers over the next few decades.

Some retirees already have plans that will take all their time and energy, and have zero interest in another hobby. Among those who might choose Apache as a hobby, there are several possible blocks, such as just not thinking of it, lack of confidence in returning to doing after a period of managing, outdated skills, and skills that may have atrophied through disuse.

The concept behind "Mentor your Mentor" is that someone who is active in Apache should watch for opportunities to bring the idea of open source as a retirement hobby to the attention of a retiring colleague, even if the retiree has been their mentor, and no matter how senior the retiree.

If the retiree is interested, the Apache contributor can offer various forms of help and support such as:

• Introduction to how Apache operates
• Encouragement
• Help selecting a project
• Help identifying resources for technical learning and relearning

In summary, the Apache contributor would do for the retiree the things a good mentor would do for someone new to IT. 

If you are an Apache contributor reading this blog, ask yourself: who in your network has retired from the computing profession? Reach out to them! Apache projects are a great opportunity for retirees to reconnect with innovation in computing. If you are a retiree and do not have an Apache mentor, don't let that stop you. Begin at http://community.apache.org/newcomers/.


Patricia Shanahan worked from 1970 to 2002 in various programming and computer architecture roles for NCR, Celerity Computing, FPS, Cray Research, and Sun Microsystems. She then went to UCSD as a graduate student, receiving a PhD in computer science in 2009, after which she retired.

= = =

"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

Saturday September 21, 2019

Success at Apache: Why you'd want to become an Apache Committer

by Dmitriy Pavlov

All newbies in Open Source communities may sometimes think that they’ll never be able to become Committers. Many treat this role as a prestigious one, granted only for special feats, and after having written a ton of code. But not all things are so simple, and I hope my story will help you. 


Election as Apache Committer

My journey with The Apache Software Foundation began relatively recently, in 2015. I was working for Openway Group, and was enthusiastic about in-memory computing. I got to know about Apache Ignite at a local developers conference. I implemented the POC of a backend system based on Apache Ignite. I was so impressed with the clear API and documentation, and it was also very convenient that I could start prototyping without passing through the approval process. I suggested using the Apache product instead of a source-available solution. I met Konstantin Boudnik (cos), who helped me to understand the difference between Apache projects and source-available/closely-governed products.


Luckily for me, GridGain, the company that initially donated Ignite to the Apache Incubator, has a development center in my city (Saint Petersburg, Russia). I joined the GridGain team in 2017.


As part of my day job, I provide patches to the product. I actively joined the dev.list discussions (some fellows sometimes say “too actively”). I’ve created a number of wiki pages - ‘Apache Ignite-Under the hood’ to help developers understand product internals. Also, I developed ‘Direct IO’ plugin. I was elected as a Committer.

In 2018 I was concerned about reviews of patches from members of the community not affiliated with GridGain. Since I had a commit-bit now, I’ve started to review patches and ask others to review them, too. I don’t know for sure, but I suppose - these social achievements in the community development were a basis for me being elected as Project Management Committee (PMC) member. 


I asked several questions about The Apache Way on the Community Development (“ComDev”) dev list. I was very impressed by how friendly and welcoming they are. I very much like such a positive atmosphere, and feel it influences the success of Apache projects. Now I’ve also joined Apache Training (incubating) community as Committer and PPMC (Podling Project Management Committee) member.


Quite funny for a software developer with 17 years of experience… being elected as a Committer, that is to say, because of the social aspects and documentation. 


Who is a typical Committer and where does his or her strength lie?

When creating an Open Source product, we always let the users explore it in action -- as well as allow them to modify it and distribute modified copies. But when such modified copies are replicated in an unsupervised manner, we don’t get contributions into the main codebase and the project stalls. It’s here where we need exactly such a person – the Committer – someone who is authorized to merge user contributions into the project.


Why should you become a Committer?

First of all, being assigned to a Committer role is extremely motivating. The professional community acknowledges you and your work, and you clearly see the results of your work in action.


How different is that from some enterprise project -- where you have no idea why you must continually keep shuffling various XML fields?


The second pure advantage of being a Committer is an opportunity to connect with top professionals and also pull some cool ideas from Open Source into your own project. But, if you aren’t one of the top professionals, certainly don’t be afraid to join -- the community has various tasks for different folks.


Besides, being a Committer is a jewel in your CV --and even a greater plus for junior programmers, because at interviews you are often asked to show code samples. If you know an Open Source project well, a company supporting or using it will be happy to hire you. There are some people who will tell you that great positions are unreachable without first committing in Open Source.


There are some bonus goodies, too! For example, Apache Committers get an IntelliJ Idea Ultimate license for free (albeit with some limitations).


How do you become a Committer?

You should be committed to the project --it’s just that simple. Development, writing tests and documentation, and simply answering questions on lists are also good ways to start working towards committership.

Yeah, the contributions of QA engineers and technical writers in the community are valued no less than the developers’ contributions.

If you think there are no tasks for you on some project, you are wrong. Just join the community you are interested in and start working on its tasks. 

The Apache Software Foundation has this dedicated page that lists what contributions are needed.  

Committer — to be or not to be?

Committer activity is a good and useful endeavor, but one shouldn’t strive to become a committer per se. This status can be granted not only for code and it doesn’t justify your proficiency. 


Find a project you may be interested in: it will probably be a project whose software you already use. Dive into its code and say hi to the community; offer help, improve docs, complete a newbie ticket or answer to a user. You may just be surprised how welcoming and open folks are there.


Strive to gain the expertise (knowledge and experience) while researching the project, tweaking it and helping others to solve their problems, and, hopefully, enjoying collaborative development in an Open Source project.


Getting started at http://community.apache.org/ will help you on your way.


Dmitriy Pavlov is a Java developer enthusiastic about Open Source and in-memory computing. He is interested in system performance, information security, and cryptography. He created and donated utility for monitoring tests for Apache Ignite, and is a former Community Manager for Apache Ignite at GridGain. Dmitriy represents the Apache Ignite Project Management Committee (PMC) at local meetups in Russia. He runs workshops and training for Apache Ignite developers and users, and is a frequent speaker at meetups and conferences.

= = =

"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 06, 2019

"Success at Apache: The Path To Berlin"

by Isabel Drost-Fromm

"A decade ago" - according to common wisdom for software engineering that's the equivalent of the stone age: The only constant is change - and rapid change at that.

This blog post is going to tell an entirely different story: One about what persistence, patience and continuous engagement can accomplish. One about what can happen when people are working together.

It was over a decade ago, in 2008, when I met with people interested in the then-hyped Apache Hadoop project to create a quarterly meetup on everything data analytics, text mining, scalable data storage. That was when the (Apache) Hadoop Get Together Berlin took place at newthinking store - a co-working space and event location before that format itself was turned into a business model http://blog.isabel-drost.de/posts/scaling-user-groups336.html.

A year later it was clear that an ApacheCon EU was unlikely to happen in Europe. When Simon Willnauer, Jan Lehnardt and myself approached The Apache Software Foundation about holding the event in Berlin - the kind people at Apache who did have experience with ApacheCon successfully stopped us: Given the baggage around the event, the trademark implication, the expectation that all sorts of different people had as well as the pure http://blog.isabel-drost.de/posts/how-hard-can-it-be-organising-a-conference.html logistics of creating an event that's bigger than 100 people, that was a safe and likely wise decision.

What they didn't achieve though was to stop us from running some event the following year: We at least wanted to give friends from the Big Data and search communities an excuse to make their employers pay for a trip to Berlin in summer: http://blog.isabel-drost.de/posts/my-highly-subjective-berlin-buzzwords-recap290.html. This was possible due to some lucky conditions we found ourselves in: Knowing conference organisers who were willing to share their know-how such as legal issues and boundaries with us Finding an event company (newthinking.de) that was supporting the idea.

Being employed by a company https://www.neofonie.de/ that saw value in sponsoring the event by allowing me to do so during my working hours.

While successful, part of the ASF community was still missing though. Fast forward several years to 2017, a new conference concept was born. Under the name of FOSS Backstage, we focus on the one topic that every project at Apache has to deal with: Governance, legal, security, economics https://blogs.apache.org/foundation/entry/success-at-apache-cookie-monster Issues that are not an Apache exclusive issue, but true for everyone - individuals as well as legal entities - involved in open source projects.

The only caveat: We had intentionally left all technical content out of scope for FOSS Backstage. For the data analytics crowd the event was conveniently co-located with Berlin Buzzwords. For the remaining content, Sharan Foga kindly volunteered for coordinating to run an Apache Roadshow alongside FOSS Backstage together with newthinking for two days after Berlin Buzzwords and in parallel to FOSS Backstage. With a name different than ApacheCon this left quite some room for experimenting beyond the traditional ApacheCon format.

Little over a year after that ApacheCon finally is on its way to the city of Berlin: With https://twitter.com/plainschwarz as event organisers, in collaboration with the Apache Software Foundation - with Myrle Krantz as event chair to coordinate between the ASF and the local event team.

In retrospect, the series of events was an interesting journey. There's a couple of lessons I've learned that carry over to open source software development - but also a few that are distinctly different.

1.Patches welcome - turn people that come with feature requests into active contributors

Instead of accepting feature requests from people, it helps to pull them in to submit their own patches: Early on there were requests for a barcamp, for a lightning talk session, for trainings. My response back then: Submit the idea through the CfP form, find someone to run it and we'll run it through the regular submission process adding it to the schedule if it fits.

For the trainings we went for a slightly different approach: Instead of directly offering them ourselves we reached out to established training providers suggesting to run with a co-location/ co-promotion approach.

For those that asked for free tickets we would turn them into helping hands - either on site, during setup or (in the first year) as local guides taking groups of up to twenty people out for dinner in a restaurant close by that they had selected.

For those that asked for more content on some specific topic we offered the option of organising a deep dive satellite event on Wednesday after the conference at one of the many companies willing to host these in Berlin.

In general we left a lot of room and freedom to those who wanted to get involved and add content to the event that they found missing.

2. Decisions are made by those doing the work

While feedback is important, there is a limit to what can feasibly be realised for any given conference budget. While we value feedback from anyone involved, the final decisions need to be taken by those actively contributing time to the event. As a result, that also means that not all feedback can always be taken into account - at least not right away, maybe at a later stage or in a different event, the consecutive year or just taken as an impulse to come up with new fresh ideas.

3. "It's done when it's done" is not an option

Conferences are slightly different from open source releases in that there are hard deadlines - in combination with a fixed budget coming in from attendees and sponsors and some hard features that cannot be postponed to the next release (unless you're organising a remote only conference, running without a venue is pretty much impossible.) That circumstance makes organisation slightly more prone to conflict than your average open source project: There's no cheap way to go down both paths and only at the very last minute decide which is better - or even offering both options.

4. Balancing public and private communication

At Apache we value public communication: Often having discussions in the open invites others to participate and shows where contributions are needed. When it comes to budget, ticket pricing, communication with sponsors, contracts including specific prices for venues this approach becomes a whole lot harder. Even though it helps to provide a dedicated mailing list for program committee members as well as interested attendees to get in touch.

It also helps to make some of the planning background public - either while discussions are ongoing, or at least after a conclusion has been reached: http://blog.isabel-drost.de/posts/berlin-buzzwords-scheduling-behind-the-scenes118.html (caveat: the algorithm has changed substantially since this was published, but the article did help answer a lot of questions.)

One downside to this mode of operation is that people who potentially could provide valuable insight or help out have no idea of what is going on. Another downside is that for the outside world it becomes invisible how large a team it takes to make the event successful. As a tiny fix for that we always tried to make the team involved publicly known.

5. Bringing people together

At Apache we have a tradition to work asynchronously - on archived, searchable, referenceable mailing lists. Without that way of working we wouldn't be able to build bridges across timezones, geographies, cultures and organisations. It wouldn't be possible to collaborate for people with wildly different time schedules. Despite all this hearing people speak when reading their texts makes it easier to understand their tone correctly. Despite all this there are topics that are best shared face to face only for deniability reasons. Despite all this, meeting someone in person who so far has been communicating only remotely with you can be a ton of fun. I hope that you will join that fun in October in Berlin: Looking forward to seeing you there!

Join us! ApacheCon Europe/Berlin 22-24 October 2019 https://aceu19.apachecon.com/

Isabel Drost-Fromm is a former 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. She is a member of the inaugural Open Source and Intellectual Property Advisory Group of the United Nations Technology Labs (UNTIL).

= = =

"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 April 01, 2019

Success At Apache: Positively impacting the world one contribution at a time

by Dinesh Joshi

My journey with Apache began in 1999 with Apache httpd and Apache Tomcat. Apache httpd was the de facto webserver at the time on Linux and Tomcat was the most well known Java Servlet container. LAMP (Linux, Apache httpd, MySQL, PHP) stack was a fantastic combination. From that point on, I have always been a Apache user, successively exploring technologies like Apache Commons, Apache Storm, Apache Hadoop, Apache HBase, and Apache Cassandra. It has been a very dependable OSS brand. Being interested in Distributed Systems and Databases, I began exploring OSS databases and came across Cassandra.

In early 2018, almost 19 years after I was first introduced to Apache projects, I began actively contributing to Apache Cassandra source. I have always been passionate about Cassandra and used it during my Masters at Georgia Tech. Its distributed, shared-nothing model is amazing. So when I did get the opportunity to contribute to the Cassandra codebase, I decided to make the most of it. Over the past year I have contributed over 25 patches as an author and reviewed over 30 patches. Collaborating with various contributors in the community, we successfully proposed the very first CIP (Cassandra Improvement Process), a Cassandra Sidecar. We, the community, are now busy building it. I have contributed some interesting changes to Cassandra so that it is more reliable and can scale better viz. Zero Copy streaming and Zstd Compressor which have been featured on the Apache Cassandra blog and at various international conferences. This has generated new interest in Cassandra.

I fully credit the Cassandra community with enabling a new contributor like me to make meaningful contributions. It is an incredibly passionate community, with a lot of questions, answers and knowledge dominating the project JIRA board and mailing lists. As a new contributor it was incredible to see a lot of community interest in what I was contributing. The Sidecar specifically generated a lot of discussion and debate within the community and ultimately we achieved consensus, the Apache Way! Zero Copy streaming is something that big players like Netflix, Uber, etc were interested in. Contributors from Netflix took the initiative in testing and benchmarking it and posting the results on Jira. Getting your work into an Open Source project is one thing but it is humbling to see your work being actively evaluated by some of the biggest industry names. It is even more fascinating to me how people can overcome organizational boundaries to collaborate on a project, and how ideas are accepted, debated and implemented as a community ultimately making it better for everyone in the world. Given my contributions to the Cassandra community, recently the PMC voted me in as a Committer which will help me bring in more contributions from the community as well as help mentor others to join in and contribute!

My goal with contributing to Cassandra was to give back to the community the knowledge & expertise that I have gained over the years building some of the most scalable systems in the world. I have found great mentors along the way who have helped me achieve that goal. It is incredible to see the impact we have on the world through Apache projects such as Apache Cassandra. 

Cassandra is used at some of the biggest organizations in the world for mission critical applications and changes like Zero Copy streaming (CASSANDRA-14556) or Zstd Compression (CASSANDRA-14482) will have a significant impact on many large businesses and more importantly people’s lives. Specifically Zero Copy Streaming in Cassandra allows the database to recover from a failed node several times faster than existing stable version of Cassandra. In addition, it also lowers the amount of resources that are required by the streaming process. Therefore, an organization running large installations of Cassandra can see a meaningful reduction in MTTR (Mean Time to Recovery) as well as reduce the spare server pool capacity that they need to maintain. This lowers the TCO (Total Cost of Ownership) for Cassandra. Zstd Compression is a new lossless compression scheme that offers better compression ratios over existing LZ4 Compression that is used within Cassandra with comparable compression speed. It can reduce storage needs by up to 40% depending on the characteristics of your dataset. Again, this not only reduces the expenses but also requires fewer servers to store data. As a result you are not only saving money but in a way saving the planet by using fewer servers.

I also believe that being a Open Source contributor is not just about code contributions. Contributions come in various forms and one of them is documentation. Seeing how Cassandra’s documentation is not updated, I proposed Cassandra for Google Season of Documentation to improve it. I also have been invited to talk about Cassandra at various conferences across Asia, Europe and North America. So far, in the past year, I have spoken about Cassandra at 9 conferences. It is great to engage with the user community at large which is very passionate and excited about Cassandra. This is one of the most important aspects of community contributions because you get to talk to your users first hand. It also generates interest in the project and is key to getting new contributors for your project.

In summary, this is impossible without having a great, supportive community which is the whole point of the ASF – to build great communities that foster collaboration making the world better one contribution at a time.

Dinesh Joshi is a Senior Software Engineer and a Committer on the Apache Cassandra project. He has a Masters in Computer Science (Distributed Systems & Databases) from Georgia Tech, Atlanta. In the past, Dinesh was a Principal Software Engineer at Yahoo building real time distributed systems for Yahoo’s Finance Web, iOS & Android apps. He is also an international speaker and regularly talks about Apache Cassandra and Databases. In his spare time, he volunteers as a mentor for Women Who Code.

# # #

"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 March 26, 2019

The Apache® Software Foundation Celebrates 20 Years of Community-led Development "The Apache Way"

[click for "ASF at 20" promo https://s.apache.org/ASF20]

World's largest Open Source foundation provides $20B+ worth of software for the public good at 100% no cost; Apache software used in every Internet-connected country on the planet.

Wakefield, MA —26 March 2019— The Apache Software Foundation (ASF), the all-volunteer developers, stewards, and incubators of more than 350 Open Source projects and initiatives, announced today its 20th Anniversary, celebrating "The Apache Way" of community-driven development as the key to its success.

The world's largest Open Source foundation is home to dozens of freely-available (no cost), enterprise-grade Apache projects that serve as the backbone for some of the most visible and widely used applications. The ubiquity of Apache software is undeniable, with Apache projects managing exabytes of data, executing teraflops of operations, and storing billions of objects in virtually every industry. Apache software is an integral part of nearly every end user computing device, from laptops to tablets to phones.

"What started before the term 'Open Source' was coined has now grown to support hundreds of projects, thousands of contributors and millions of users," said Phil Steitz, Chairman of The Apache Software Foundation. "The Apache Way has shown itself to be incredibly resilient in the wake of the many changes in software and technology over the last twenty years. As the business and technology ecosystems around our projects have grown, our community-based open development model has evolved but remained true to the core principles established in the early days of the Foundation. We remain committed to the simple idea that open, community-led development produces great software and when you make that software freely available with no restrictions on how it can be used or integrated, the communities that develop it get stronger. The resulting virtuous cycle has been profoundly impactful on the software industry as a whole and on those of us who have had the good fortune of volunteering here. When we celebrate fifty years, I am sure that we will say the same thing."

Software for the Public Good
In 1999, 21 founders, including original members of the Apache Group (creators of the Apache HTTP Server; the World's most popular Web server since 1996) formed The Apache Software Foundation to provide software for the public good. The ASF's flagship project, the Apache HTTP Server, continues development under the auspices of the ASF, and has grown to serve more than 80 million Websites worldwide.

"The most successful revolutions are those birthed by Passion and Necessity. What keeps them going are Communities," said ASF co-founder Jim Jagielski. "Congratulations to the ASF and to everyone who has had a hand, large and small, in making it into who and what we are today."


The Apache Way
The open, community-driven process behind the development of the Apache HTTP Server formed the model adopted by future Apache projects as well as emulated by other Open Source foundations. Dubbed "The Apache Way", the principles underlying the ASF embrace:

  • Earned Authority: all individuals are given the opportunity to participate, and their influence is based on publicly-earned merit – what they contribute to the community. Merit lies with the individual, does not expire, is not influenced by employment status or employer, and is non-transferable.

  • Community of Peers: participation at the ASF is done through individuals, not organizations. Its flat structure dictates that the Apache community is respectful of each other, roles are equal, votes hold equal weight, and contributors are doing so on a volunteer basis (even if paid to work on Apache code).

  • Open Communications: as a virtual organization, the ASF requires all communications be made online, via email. Most Apache lists are archived and publicly accessible to ensure asynchronous collaboration, as required by a globally-distributed community.

  • Consensus Decision Making: Apache Projects are auto-governing with a heavy slant towards driving consensus to maintain momentum and productivity. Whilst total consensus is not possible to establish at all times, holding a vote or other coordination may be required to help remove any blocks with binding decisions.

  • Responsible Oversight: the ASF governance model is based on trust and delegated oversight, with self-governing projects providing reports directly to the Board. Apache Committers help each other by making peer-reviewed commits, employing mandatory security measures, ensuring license compliance, and protecting the Apache brand and community at-large from abuse.


The ASF is strictly vendor neutral. No organization is able to gain special privileges or control a project's direction, irrespective of employing staff to work on Apache projects or sponsorship status.


The ASF Today
Behind the ASF is an all-volunteer community comprising 730 individual Members and 7,000 Committers stewarding 200M+ lines of code that benefit billions of users worldwide. 

Lauded as one of the industry's most influential communities, the ASF develops and incubates 350+ Open Source projects and initiatives that are made available to the public-at-large at 100% no cost. The ASF has become an invaluable resource for users and developers alike, drawing 35M page views per week across http://apache.org/ ; 9M+ source code downloads from Apache mirrors (excluding convenience binaries), and Web requests received from every Internet-connected country on the planet.

"Over the past two decades, few institutions have been as important for the advancement and growth of Open Source as The Apache Software Foundation," said Stephen O'Grady, Principal Analyst with RedMonk. "By providing a neutral environment for developers from diverse backgrounds to work together, the ASF has played a pivotal role in the history of Open Source, and appears poised to continue in this role for the next decade."


All-Volunteer Community
The membership-based, not-for-profit charitable organization ensures that Apache projects continue to exist beyond the participation of individual volunteers by building diverse communities that develop and support software.

At the ASF, all software development and project leadership is executed entirely by volunteers. The ASF Board and officers are all volunteers. The ASF does not pay for development: thousands of committed individuals help make a difference to the lives of billions of people by ensuring that Apache software remains accessible to all.

The Apache maxim "Community Over Code" underscores that a healthy community is far more important than good code. In the event that the code would dematerialize, a strong community could rewrite it; however, if a community is unhealthy, the code will eventually fail as well.

The merit-driven "Contributor-Committer-Member" approach is the central governing process across the Apache ecosystem. The core Apache Group of 21 individuals grew with developers who contributed code, patches, or documentation. Some of these contributors were subsequently granted "Committer" status by the Membership, and provided access to: 1) commit (write) directly to the code repository, 2) vote on community-related decisions, and 3) propose an active user for Committership. Those Committers who demonstrate merit in the Foundation's growth, evolution, and progress are nominated for ASF Membership by existing members.


Powered by Apache

"The most popular Open Source software is Apache..."
— DZone "What Open Source Software Do You Use?"

Apache software is used in every Internet-connected country on the planet. Apache projects serve as the backbone for some of the world’s most visible and widely used applications in Artificial Intelligence and Deep Learning, Big Data, build management, Cloud Computing, content management, DevOps, IoT and Edge computing, mobile, servers, and Web frameworks, among many other categories. Examples of the breadth of applications that are "Powered by Apache" include:

  • Panama Papers: library, search, and document management tools used in the 2.6TB Pulitzer Prize-winning investigation;

  • US Federal Aviation Administration: system-wide information management to enable every airplane take off and land in US airspace;

  • Netflix: data ingestion pipeline and stream processing 3 trillion events each day;

  • Uber: handling 1M writes per second for 99.99% availability to users and drivers;

  • Mobile app developers: unifying mobile application development across Blackberry, Android, Windows Mobile, Windows Phone, and iOS operating systems;

  • Facebook: processing requests at 300-petabyte data warehouse, connecting 2B+ active users;

  • NASA Jet Propulsion Laboratory: accessing content across multi-mission, multi-instrument science data systems;

  • Global Biodiversity Information Facility: managing 1B+ occurrence records for open access to data about all types of life on Earth;

  • European Space Agency: powering new mission control system and next-generation simulators infrastructure;

  • Adobe: powering I/O Runtime and the core of Experience Manager;

  • IBM Watson: advancing data intelligence and semantics capabilities to win first-ever "Man vs. Machine" competition on Jeopardy!

  • Boston Children's Hospital: linking phenotypic and genomic data for the Precision Link Biobank

  • Target.com: driving $1B+ in revenue through Big Data optimization;

  • AOL: ingesting 20TB+ of data per day;

  • Minecraft: bundling libraries to modify the second most popular video game of all time;

  • Novopay: serving as a transactional backbone to processes $80M+ each month;

  • Formula 1, Audi, and Daimler: streaming data in vehicles in real time; 

  • Twitter: processing and analyzing more than a Zettabyte of raw data through 200B+ tweets annually;

  • Pinterest: processing 800B+ daily events;

  • Amazon Music: tuning recommendations for 16M+ subscribers; 

  • NASA: powering Big Earth and Ocean Science data analytics; 

And, from Accumulo to Zipkin (incubating), more than six dozen Apache projects form the foundation of the $166B Big Data ecosystem.

Apache software is overseen by a self-selected team of active contributors to the project. A Project Management Committee (PMC) guides the Project's day-to-day operations, including community development and product releases.


The Code
Over the past two decades, 1,058,321,099 lines of Apache code were committed over 3,022,836 commits. The ASF codebase is conservatively valued at least $20B, using the COCOMO 2 model. All Apache software is released under the Apache License v2.0.


"If It Didn't Happen On-list...It Didn't Happen"
Since the ASF's founding, 351,067 authors sent 19,587,835 emails on 8,529,590 topics across 1,131 mailing lists.

Apache Incubator
The Apache Incubator is the entry path for projects and codebases wishing to become part of the efforts at The Apache Software Foundation. All code donations from external organizations and existing external projects enter through the Incubator to: 1) ensure all donations are in accordance with the ASF legal standards; and 2) develop new communities that adhere to our guiding principles. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects.

Since the ASF's founding, 199 projects have successfully graduated from the Apache Incubator. Today, 52 projects are in development, applying The Apache Way to innovations in annotation, Artificial Intelligence, Big Data, cryptography, data science, development environments, Edge and IoT, email; JavaEE, libraries,  Machine Learning, serverless computing, and many more categories.

"Wow, is it 20 years already? Congratulations to the ASF! I've always been a big believer and advocate of Open Source, but when we founded the ASF 20 years ago I certainly didn't expect *this* level of growth and success," said ASF co-founder Lars Eilebrecht. "I'm very proud that the ASF - despite many challenges - has remained true to its core values and the Apache Way of Open Source development. The ASF has had a very big and positive impact on the overall IT industry, and I'm certain that the industry and the Internet would look very different today without the ASF's involvement in the rise of Open Source!"

Apache License v2.0

"Apache-style licensing may yield more adoption and money."
— Matt Asay, c|net

The commercially-friendly and permissive Apache License v2.0 has become an Open Source industry standard. Its popularity has led to the rise in corporate contribution in Open Source, and is behind the launch of dozens of billion dollar companies, and is facilitating the adoption of some of the world's fastest-growing Open Source projects.

"I'd like to congratulate the Apache Software Foundation for growing and demonstrating a working model for open source development that has stood the test of time," said ASF co-founder Randy Terbush. "I am forever grateful for the opportunities that my participation in the ASF gave me and I am very proud of what the group has become."  


ApacheCon
Pre-dating the ASF, ApacheCon is the official global conference series of The Apache Software Foundation. Heralding "Tomorrow's Technology Today" since 1998, participants learn about Open Source development "The Apache Way", independent of business interests, corporate biases, or sales pitches. ApacheCon presents dynamic, community-driven content and innovation insight through hands-on sessions, keynotes, real-world case studies, trainings, hackathons, BarCamps, and more. The ASF is holding four events in 2019: 
  • Apache Roadshow/Washington DC 25, March 2019
  • Apache Roadshow/Chicago, 13-14 May 2019
  • ApacheCon North America/Las Vegas, 9-12 September 2019
  • ApacheCon Europe/Berlin, 22-24 October 2019
For more information and to register, visit http://apachecon.com/ and ApacheCon video.

"My Apache journey started in the Apache HTTP core development team in 1995, fixing security issues and continues today as VP of Security," said ASF co-founder Mark Cox. "In the years between, Apache has inextricably intertwined my professional career and my personal life. I'm proud to be part of the ASF as we move past 20 years and look forward to a celebration (hopefully with cake) at ApacheCon in September."

"Happy Birthday, Apache Group!" echoed ASF co-founder Bill Stoddard.

Support Apache
As a United States private, 501(c)(3) not-for-profit charitable organization, the ASF relies on charitable donations to advance the future of open development. The ASF is sustained by through tax-deductible contributions from generous corporations, foundations, and individuals, whose contributions help offset day-to-day operating expenses that include bandwidth, connectivity, servers, hardware, legal counsel, accounting services, trademark protection, public relations, marketing, and related support staff. Less than 10% is spent on overhead.

The Apache Software Foundation plans to continue to innovate "The Apache Way" with new Open Source projects and communities for years to come. Donations to the ASF help keep Apache software available to everyone.

- "From our first contributions to The Apache Software Foundation in 2006 until today, the ASF has been teaching us and everyone how to do community driven Open Source. We thank the ASF, their communities and all who have been involved! Congratulations on 20 years of volunteer-led service, and the many accomplishments with code and community. We look forward to collaborating on the next 20." –Adrian Cockcroft, VP Cloud Strategy at AWS

- "The Apache Software Foundation and OSI both turned 20 recently. As two of the founding organizations of the Open Source community, they are fundamental to its growth and success. The Apache Way ensures all participants have equal representation and footing, and developers are valued based on their contributions' merits. Bloomberg developers first got involved as Open Source community collaborators and contributors seven years ago, and we've been involved with – and a sponsor of – the ASF almost this entire time, as it’s the home of dozens of projects that are incredibly important to us." –Kevin Fleming, Head of Open Source Community Engagement and Member of the CTO Office at Bloomberg

- "Congratulations to The Apache Software Foundation on 20 years of ground-breaking software development and Open Source community leadership. The ASF has provided value to Cerner for more than 15 years through innovative projects and rich communities. We can count on the ASF to be the source of high-quality, foundational software and to provide a collaborative community that makes it easy for our engineers to grow." –Nathan Beyer, VP & Chief Engineer at Cerner, and ASF Member

- "The Apache Software Foundation provides a fertile home for software communities. The Foundation’s unique approach has created many industry standards and will likely continue to do so for many more years. Apache projects are famous not just for great technology, but for their longevity and vendor-independence. Cloudera looks forward to continuing to collaborate with others at Apache for decades to come." –Doug Cutting, Chief Architect at Cloudera

- "Datadog is a proud sponsor of The Apache Software Foundation. What an amazing journey it's been, from a small group of developers working on httpd to a foundation that stewards some truly amazing Open Source projects. As a consumer and contributor to many of those projects, it's difficult to understate the impact they've had; not only on us but on the software industry as a whole. Congratulations on 20 years!" –Jeremy Garcia, Director of Technical Community and Open Source at Datadog

- "After twenty years of practicing Open Source law, I appreciate how critical The Apache Software Foundation has been to the success of the OSS ecosystem. I am honored to work with the Foundation and its members." –Mark Radcliffe, Partner at DLA Piper 

- "We look forward to another 20 years of Open Source software with The Apache Software Foundation! We were excited to be one of the first corporate members in 2005, and even more excited to select the Apache license for Android in 2008. There's very few organizations that have shown the persistent dedication to Open Source the way that the ASF has and we're proud to be a part of it as a sponsor and to have so many of our engineers contributing to Apache projects." –Chris DiBona, Director of Open Source at Google

- "From an auspicious launch with the Apache HTTP Server to over 350 projects today, Apache continues to drive innovation in the industry and IBM is proud to have supported its founding. With dozens new projects coming to the ASF each year, from Artificial Intelligence to Deep Learning, Big Data, Cloud Computing, DevOps, IoT and Edge Computing, Mobile, Servers, and Web Frameworks, The Apache Software Foundation is an anchor for world-changing Open Source projects. We look forward to continued contributions and collaboration for many years to come." –Todd Moore, Vice President of Open Technology and Developer Advocacy at IBM

- "It's an honor and a privilege to help Apache, an organization so deeply ingrained in the history and growth of the Internet, fundraise online. Congratulations on 20 years, and cheers to the next 20!" –Alex Morse, CEO at Hopsie

- "Congratulations on ASF's 20th Anniversary! The mission of ASF is to provide software for the public good. Modern technology development is based on extensive collaboration. Our goal is to build the open ICT solution for global customers through collaboration with ecosystem partners. In the spirit of The Apache Way, Huawei actively participated in the ASF, contributed two, now Top-Level, projects: Apache CarbonData and Apache ServiceComb. We appreciate the community culture of ASF, and we thank ASF for making a healthy Open Source software ecosystem a reality." –Evan Xiao, VP of Strategy and Industry Development at Huawei Technologies

- "Leaseweb has been using Apache/ASF projects for a multitude of products and services over the last 20 years. The ASF is responsible for a mindboggling amount of Open Source projects that truly make up the fabric of the Internet. For Leaseweb, the ASF is in the core of many of our Cloud and Hosting platforms. Apart from helping out with our Platinum Sponsorship, Leaseweb would like to thank all developers and other volunteers in ASF and ASF projects for continuing to build software that makes the Internet what it is today. We’re looking forward to another 20 years of innovation, code, and community – and proud to be a small part of that." –Robert van der Meulen, Global Product Strategy Lead at Leaseweb

- "Twenty years ago the ASF's vendor neutral model of Open Source software development was central to the commercialization of the World Wide Web and has continued to accelerate innovation across the IT industry since then. At Microsoft we are committed to ensuring that Azure is the best cloud platform for our partners and customers. A key aspect of delivering on this goal is to contribute to the success of Open Source projects. The ASF's emphasis on vendor neutrality, is key to the success of many Open Source components used by both Microsoft and our partners. Happy Birthday to The Apache Software Foundation." –John Gossman, Lead Architect of Microsoft Azure 

- "The Apache Software Foundation has provided stewardship for much of the modern Internet, from the Apache Web Server itself to cutting edge infrastructure and data science technologies such as Kafka and Hadoop. No-IP is built on Open Source software. It is important for us to support Open Source projects and the Apache Foundation has made it easy to give back. We look forward to the Foundation's future work and wise guidance and we are proud to be associated with it." –Dan Durrer, CEO and Owner of No-IP

- "PCCC.com joins the world in celebrating 20 years of Open Source Software from The Apache Software Foundation. Happy Birthday!" –Kevin A. McGrail, CEO Emeritus of Peregrine Computer Consultants Corporation

- "More than being Open Source, Apache values transparency and openness with their users, something PureVPN staunchly believes in, advocates, and follows. Supporting Apache gives us the opportunity to align ourselves with an amazing team of people that makes a difference in the lives of individuals on a daily basis." –Uzair Gadit, CEO at PureVPN

- "The Apache Software Foundation has been a great help in pushing the Open Source agenda to a wide range of individuals, communities, and vendors over the years. Their approach to meritocracy and community-driven development has helped to shape some world class Open Source projects which have gone on to help drive some world-class products and businesses. Keep it up and here's to the next 20 years!" –Mark Little, VP Engineering and CTO JBoss Middleware at Red Hat

- "Tencent Cloud is proud to be the first platinum sponsor of The Apache Software Foundation from China. In years of supporting with Open Source communities, we found Apache is one of the best places to drive great innovations for industry of AI, Big Data, Cloud Computing, DevOps, Edge Computing, IoT, etc. We would like to thank ASF for its outstanding contributions to Open Source world, and celebrate its 20th Anniversary of Open Source collaboration. Tencent Cloud will stand together with ASF and looks forward to long term contributions and collaborations." –Huixing Wang, Vice President of Tencent Cloud

- "The Apache Software Foundation is among the brightest beacons in the global Open Source movement. HotWax is proud to recognize the ASF for harnessing transparency and meritocracy to generate some of the highest quality and most widely used code in the world, for decades now! Happy 20th -- we are honored to be a part of the community." –Mike Bates, CEO, HotWax Systems

- "Contributing to The Apache Software Foundation projects continues to be part of our engineering strategy." –Gil Yehuda, Senior Director of Open Source at Verizon Media

 == RESOURCES FOR EDITORS ==

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

# # # 

Success at Apache: What You Need to Know

EDITOR'S NOTE: I came across the author's original post, "An Introduction to Apache Software — What you need to know", dated 3 February 2017, and was interested in finding away to share with the greater Apache community. The author's enthusiasm was palpable, and earnestly intended to help educate others. With the ASF celebrating its 20th Anniversary this year, it's easy for many of us to simply rely on tribal knowledge, not realizing that navigation to definitive guides aren't intuitive to newcomers. Those of us who have been here for a while "just know", partially because we were creating it as we went along. Below is an updated version of the original post, amended through the guidance of three long-standing ASF Members. And that's the point of it all at the end of the day: at Apache, we help each other as it contributes to our collective success, and this writeup will help others find their Success at Apache. 

by Maximilian Michels

Before you started reading this post, you have already been using Apache software. The Apache web server (Apache HTTP Server) serves about every second web page on the WWW, including this website. One could say, Apache software runs the WWW. But it doesnt stop there. Apache is more than a web server. Apache software also runs on mobile devices. Apache software is part of enterprise and banking software. Apache software is literally everywhere in today's software world.

Apache has become a powerful brand and a philosophy of software development which remains unmatched in the world of open-source. Although the Apache® trademark is a known term even among the less tech-savvy people, many people struggle to define what Apache software really is about, and what role it plays for today's software development and businesses.

In the last years I've learned a lot about Apache through my work on Apache Flink and Apache Beam with dataArtisans, as a freelancer/consultant, and as a volunteer. In this post I want to give an overview of the Apache Software Foundation and its history. Moreover, I want to show how the "Apache way" of software development has shaped the open-source software development as it is today.

The History of the Foundation

The Apache Software Foundation (ASF) was founded in 1999 by a group of open-source enthusiasts who saw the need to create a legal entity to institutionalize their work. Among the first projects was the famous web server called Apache HTTP, which is also simply referred to as "Apache web server". At that time, the Apache web server was already quite mature. In fact, not only did the Apache web server give the foundation its name but it became the role model for the "Apache way" of open and collaborative software development. To see how that took place, we have to go back a bit further in time.

A Web Server goes a long way

As early as 1994, Rob McCool at the National Center for Supercomputing Applications (NCSA) in Illinois created a simple web server which served pages using one of the early versions of today's HTTP protocol. Web servers were not ubiquitous like they are today. In these days, the Web was still in its early days and there was only one web browser developed at CERN where the WWW was invented only shortly before. Rob's web server was adopted quite fruitfully throughout the web due to its extensible nature. When its source code spread, web page administrators around the world developed extensions for the web server and helped to fix errors. When Rob left the NCSA in late 1994, he also left a void because there was nobody left to maintain the web server along with its extensions. Quickly it became apparent that the group of existing users and developers needed to join forces to be able to maintain NCSA HTTP.

At the beginning of 1995, the Apache Group was formed to coordinate the development of the NCSA HTTP web server. This led to the first release of the Apache web server in April 1995. During the same time, development at NCSA started picking off again and the two teams were in vivid exchange about future ideas to improve the web server. However, the Apache Group was able to develop its version of the web server much faster because of their structure which encouraged worldwide collaboration. At the end of the year, the Apache server had its architecture redone to be modular and it executed much faster.

One year later, at the beginning of 1996, the Apache web server already succeeded the popularity of the NCSA HTTP which had been the most popular web server on the Internet until then. Apache 1.0 finally was released on Dec 1, 1995. The web server continued to thrive and is still the most widely used web browser as of this writing.

The Rise of the Foundation

The team effort that led to the development and adoption of the Apache web server was a huge success. The Apache project kept receiving feedback and code changes (also called patches) from people all over the world. Could this be the development model for future software? More and more projects started to organize their groups similarly to the Apache group. As the number of project grew, financial interests arose and potential legal issues threatened the existence of the Apache group. Out of this need, the Apache Software Foundation (ASF) was incorporated as a US 501(c)(3) non-profit organization in June 1999. In the US, the 501(c)(3) is a legal entity specifically designed for non-profit charitable organizations. This is in contrast to other for-profit open-source software organizations or even US 501(c)(6) non-profit organizations which do not require to be charitable.

After the ASF was incorporated, new projects could easily leverage the foundation's services. Over the next year, every few months a new project entered the ASF. The first projects after Apache HTTP Server were Apache mod_perl (March 2000), Apache tcl (July 2000), and Apache Portable Runtime (December 2000). After a short break in 2001 which was used to come up with a programmatic approach to onboard new projects via an incubator, the ASF has seen very consistent growth of up to 12 projects (2012) each year.

The ASF became a framework for open-source software development which, in its entirety, remains unmatched by other forms of open-source software development. The secret of ASF's success is its unique approach to scaling its operations, in which the foundation does not try to exercise control over its projects. Instead, it focuses on providing volunteers with the infrastructure and a minimal set of rules to manage their projects. The projects itself remain almost autonomous.

Apache Governance - How does the foundation work?

There are about 200 independent projects running under the Apache umbrella. The question may arise, how does the foundation govern its projects? First of all, the ASF is an organization that is run almost entirely by volunteers. In the early days, many of the volunteers were developers which did not like to spend much time with administrative things (who does?), so the organization is structured in a way that requires little central control but favors autonomy of the projects which run under its umbrella.

Per-Project Entities

For every project (e.g. Apache HTTP, Apache Hadoop, Apache Commons, Apache Flink, Apache Beam, etc.), there are a Project Management Committee (PMC), Committers, Contributors, and Users.

Project Management Committee (PMC)

The PMC manages a project's community and decides over its development direction. Its most rudimentary and traditional role is to approve releases for a project. In that sense it has a similar function as the original Apache Group which led the development of Apache HTTP Server. When a new project graduates from the Incubator (covered later), the foundation's central instance, the Board, approves the initial PMC which is selected from the PPMC (Podling PMC) formed during incubation. Each PMC elects one PMC member as the PMC Chair which represents the project and writes quarterly reports to the ASF Board. The Chair needs to be approved by the Board.

Through a project's lifetime new PMC members can be elected by the existing PMC. Note that each new PMC member needs to be approved by the Board but this approval is merely formal and there are few instances that a new PMC member is not approved. PMC members do not need the formal permission of the foundation to elect new Committers. PMC members themselves are also Committers. Let's learn about Committers next.

Committers

Committers can modify the code base of the project but they can't make decisions regarding the governance of the project. They are trusted by the PMC to work in the interest of the project. When they contribute changes, they commit (thus, the name) these changes to the project. Committers don't only change code but they can also update documentation, write blog posts on the project's website, or give talks at conferences. Committers are selected from the users of the project; more about this process in the Meritocracy section.

Users and Contributors

Users are as important as the developers because they try out the project’s software, report bugs, and request new features. The term is a slightly confusing because, in the Apache world, most users tend to be developers themselves. They are users in the sense that they are using an Apache project for their own work; usually they are not actively developing the Apache software they are using. However, they may also provide patches to the Committers. Users who contribute to a project are called Contributors. Contributors may eventually become Committers.

In the image, the per-project entities are represented as circles. They exist for every project. Note that the user group circle is not depicted in full size because big projects tend to have much more Users than Committers and PMC members.

Foundation-Wide Entities

The ASF does not work without some central services. Here are the most important entities:

Apache Members

Apache members represent the heart of the foundation. They have been referred to as the "shareholders of the ASF" because they are deeply invested in the ASF (not in the financial sense). A prerequisite to becoming a member is to be active in at least one project. To become a member, you have to show interest in the foundation and try to promote its values. The ASF holds membership meetings which are usually held annually. At membership meetings new members can be proposed and subsequently elected. Elected members receive an invitation which they can choose to accept within 30 days. Becoming a member it not merely a recognition for supporting the ASF, but it also grants the right to elect the Board.

The Board of Directors (Board)

The Board takes care of the overall government of the foundation. In particular, it is concerned with legal and financial matters like brand and licensing issues, fundraising, and financial planning. The board is elected by the Apache members annually and is also composed of Apache members. The current board can be viewed here. Note that there is only one central Board for the entire foundation but Board members can be PMC members in different projects.

Officers of the corporation

The Officers of the corporation are the executive part of the administration. They execute the decisions of the board and take care of everyday business. Most of the officers are implicitly officers by being the PMC chair of a project. Additionally, there are dedicated officers for central work of the foundation, e.g. fundraising, marketing, accounting, data privacy, etc.

Infrastructure (INFRA)

The support and administration team (INFRA) is the team that runs the Apache infrastructure and provides tools and support for developers. INFRA is the only team at Apache which consists of contractors which are paid for their work. Their work includes running the apache.org web site and the mailing lists which are Apache’s main way of communication. Over time, various other tools and services were created to assist the projects. The main tools available which are used by almost all projects are:

  • Web space for the project's websites.
  • Mailing lists, for discussing the roadmap of the project, exchanging ideas, or reporting bugs (unwanted software behavior). Typically the mailing lists are divided into a developer and a user mailing list.
  • Bug trackers, which help developers to keep track of new features or bugs.
  • Version control, which helps developers to keep track of the code changes.
  • Build servers, which help to integrate/test new code or changes to existing code.

The Incubator

Founded in 2002, the Incubator is a project at the ASF dedicated to forming (bootstrapping) new Apache projects. The process is the following: People (volunteers, enthusiasts, or company employees) make a proposal to the Incubator. The proposal contains the project name, the list of initial PPMC (Podling PMC) members, and the motivation and goals for the new project. Once the IPMC (Incubator PMC) has discussed the proposal, it holds a vote to decide if the project enters the incubation phase. In the incubation phase, projects carry "incubating" in their names, e.g. "Apache Flink (incubating)"; this is dropped only once they graduate. To graduate, a project has to show that it is mature enough. The Community Development project at the ASF has created a catalogue of criteria called the Maturity Model. It requires having an active community, quality of code, and being legally compliant. Formally, the project needs to prove it fulfils the criteria to the Incubator IPMC which is comprised of Apache members. All existing work donated in the course of entering the incubator and all future work inside the project has to be licensed to the ASF under the Apache License. This ensures that development remains in the open-source according to the Apache philosophy. More about incubation on the official website.

Meritocracy - How are decisions made?

The Apache Software Foundation uses the term "meritocracy" to describe how it governs itself. Going back to the ancient Greeks, meritocracy was a political system to put those into power which proved that they were motivated, put effort into their work, and were able to help a project. The core of this philosophy can be found throughout history from ancient China to medieval Europe and is still present in many of today’s cultures in the sense that effort, increased responsibility, and service to a part of society ought to pay off in terms of power of decision, social status, or money.

Meritocracy in the Apache Software Foundation denotes that people who either work in the interest of the foundation or a project get promoted. Users who submit patches may be offered Committer status. Comitters who are drive a project, may gain PMC status. PMC members active across projects and taking part in the foundation's work may earn the Member status.

Decision-making within the foundation and projects are typically performed using Consensus. Consensus can be "lazy" which implies that even a few people can drive a discussion and make decisions for the entire community as long as nobody objects. The discussions have to be held in public on the mailing list. For instance, if a Committer decides to introduce a new feature X, she may do so by proposing the feature on the mailing list. If nobody objects, she can go ahead and develop the feature. If lazy consensus does not work because an argument cannot be settled, a majority based vote can be started.

Meritocracy and "lazy" Consensus are the core principles for governance within the Apache Software Foundation. Meritocracy ensures that new people can join those already in power. "Lazy" Consensus creates the opportunity to split up decision-making among the group such that it doesn't always require the action of all members of the community.

The Apache License - A license for the world of open-source


With the incorporation of the foundation in 1999, a license had to be created to prevent conflicts with the intellectual property contributed by others to the ASF. Originally, the license was meant to be used exclusively by the ASF but it quickly became one of the most widely used software licenses for all kinds of open-source software development.

The Apache license is very permissive in the sense that source code modifications are not required to be open-sourced (made publicly available) even when the source code is distributed or sold to other entities. This is in contrast to “Copyleft” licenses like the GNU Public License (GPL) which, upon redistribution, requires public attribution and publication of changes made to the original source code. The Apache license was first derived from the BSD license which is similarly permissive. The reason for this was that the Apache HTTP Server was originally licensed under the BSD license.

The current version of the Apache License is 2.0, released in January 2004. The changes made since the initial release are only minor but they set the prerequisite for its prevalence. At first, the license was only available to Apache projects. Due to the success of the Apache model, people also wanted to use the license outside the foundation. This was made possible in version 2.0. Also, the new version made it possible to combine GPL code with Apache licensed code. In this case, the resulting product would have to be licensed under the GPL to be compatible with the GPL license. Another change for version 2.0 was to make inclusion of the license in non Apache licensed projects easier and require explicit patent grants for patent-relevant parts.

Apache Today

The ASF today is not the small group that it used to be back in 1999. At the time of this writing, the Apache Software Foundation hosts 51 podlings in the Incubator and 199 top-level committees (PMCs). This amounts to almost 300 projects (latest statistics). Note that, a PMC may decide to host multiple projects if necessary. For instance, the Apache Commons PMC has split up the different parts of the Apache Commons library into separate projects (e.g. CLI, Email, Daemon, etc.). 50 of the 300 projects have been retired and are now part of Apache Attic, the project which hosts all retired projects. The above graph is taken from https://projects.apache.org.

Apache Conferences

The Apache Software Foundation regularly organizes conferences around the world called ApacheCon. These conferences are dedicated to the Apache community or certain topics like Big Data or IoT. It is a place to meet community members and learn about the latest ideas and trends within the global Apache community. Apart from the official conferences, there are conferences on Apache software organized by companies or external organization, e.g. Strata, FlinkForward, Kafka Summit, Spark Summit.

Here's a list of some projects that I came across in the past. I grouped them into categories for a better overview. I realize you might not know a lot of the projects but maybe this list can be the starting point to discover more about these Apache projects :)

Big Data

  • Hadoop
  • Flink
  • Spark
  • Beam
  • Samza
  • Storm
  • NiFi
  • Kafka
  • Flume
  • Tez
  • Zeppelin

Cloud

  • Mesos
  • CloudStack
  • Libcloud

Machine Learning

  • Mahout
  • SAMOA

Office

  • OpenOffice

Database

  • CouchDB
  • HBase
  • Zookeeper
  • Derby
  • Cassandra

Query Tools / APIs

  • Hive
  • Pig
  • Drill
  • Crunch
  • Ignite
  • Solr
  • Lucene

Programming Languages

  • Groovy

Distributions

  • Bigtop
  • Ambari

Libraries

  • Commons
  • Avro
  • Thrift
  • ActiveMQ
  • Parquet

Developer Tools

  • Ant
  • Maven
  • Ivy
  • Subversion

Web Servers

  • HTTP (the one!)
  • Tomcat

Web Frameworks

  • Cocoon
  • Struts
  • Sling

Apache - A Successful Open-Source Development Model

My first attempt to learn more about Apache goes back several years. I was using the Apache License while working on Scalaris at Zuse Institute Berlin. I realized that the license was somehow connected to the Apache Software Foundation but I didn't really understand the depth of this relationship until I started working on Apache Flink with dataArtisans. Besides the official homepage of the foundation, relatively little information was available on the Internet about the foundation and its projects. In hindsight, the best source of information was to read the email archives, get to know other people at the ASF, and become a volunteer myself :)

When I originally wrote this post I couldn’t find an introductory guide to the ASF. So I decided to do a bit of research myself and tried to write down what I had learned working on Apache projects. I hope that I could provide an overview of the ASF and show you how significant the foundation has been for the open-source software development.

Thank you

Thank you for reading this article. Feel free to write me an email if I got something wrong or you would like to comment on anything.

Thank you Roman Shaposhnik, Shane Curcuru, Dave Fisher, and Sally Khudairi for your comments which were very helpful to revise this post for the 20th anniversary of the ASF.

Sources

 # # #

"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 March 19, 2019

The Apache Way to Sustainable Open Source Success

As Open Source software continues to grow in importance, it seems appropriate to reflect upon the ongoing success of The Apache Software Foundation (ASF) as it approaches its 20th anniversary. The Apache Way of community-driven development continues to gain momentum despite the compounding challenges of building software in the greater Open Source ecosystem.

This approach, The Apache Way, was defined over 24 years ago by the original Apache Group, prior to the establishment of the Foundation. It has led to our success as a foundation and we believe it has been fundamental to the triumph of Open Source as a whole.

While The Apache Way has been refined over the years, it remains true to the original goals of transparent, community-driven collaboration in a vendor-neutral environment that is accessible to all.

The Apache Way defines Open Source in terms of both a legal and a social framework for collaboration. It helps others understand what makes Open Source powerful and how participants are expected to behave. In this post we will examine The Apache Way in the context of the Foundation's mission:

"The mission of the Apache Software Foundation (ASF) is to provide software for the public good. We do this by providing services and support for many like-minded software project communities consisting of individuals who choose to participate in ASF activities." 

Let's dissect this mission statement. 

"Provide Software for the Public Good"

Key points in this section: 

  • We produce software that is non-excludable and non-rivalrous

  • Use of the software in any context does not reduce its availability to others

  • Users and contributors have no committed responsibility to the foundation, our projects or our communities

  • Use of a license that conforms to the Open Source Definition is necessary but not sufficient to deliver on our mission 

Investopedia defines a public good as "a product that one individual can consume without reducing its availability to another individual, and from which no one is excluded." On the surface, this is a good definition for our use of the term. However, there is a nuance in our use. Our mission is not to produce "public goods" but to "provide software for the public good". 

To understand why this is important, one needs to think about what motivates the ASF to produce software that is a public good.

Open Source software can be digitally copied and reused in an unlimited number of ways. Every user can modify it for their specific needs. They can combine it with other software. They can design innovative new products and services using it and can make a living from the proceeds. This is all possible without impacting other people's use of the software. As such, the ASF produces software that can be used for the public good in many different ways.

To allow us to deliver on this part of the mission, it is critical that we adopt a license that uses the law to protect the software curated here at the Foundation. For us that license is the Apache License, Version 2. In addition, we adopt an inbound licensing policy that defines which licenses are allowable on software reused within Apache projects. This policy can be summarized as: 

  • The license must meet the Open Source Definition (OSD).

  • The license, as applied in practice, must not impose significant restrictions beyond those imposed by the Apache License 2.0.

This means that you can be assured that software curated by projects within The Apache Software Foundation is both a public good and for the public good. You can use Apache software for any purpose and you have no responsibility to the Foundation or the project to contribute back (though as addressed in the next section, it is often in your interests to do so). 

It is important to recognize that there are software projects out there that adopt our license but do not adopt our inbound licensing policy. Such projects may bring restrictions that are not covered by our license; therefore, it is important to carefully examine the licensing policies of these projects. Using the Apache License alone may not provide you with the same options a Foundation project provides. 

Apache projects are successful, in large part, because of our diligence with respect to clearly-defined licensing policies. Such diligence makes it much easier for downstream users to understand what they can and cannot do with Apache software. The Apache License is deliberately permissive to ensure that everyone has an opportunity to participate in Open Source within the ASF or elsewhere. Modifications of our license are allowed, but modified licenses are neither the Apache License nor affiliated with or endorsed by The Apache Software Foundation. No modified license can be represented as such. Modified licenses that use the Apache name are strictly disallowed, as they are both confusing to users and undermine the Apache brand.

While we recognize that there are many ways to license software, whether Open Source or otherwise, we assert that only projects that use both our license (unmodified) and our inbound licensing policy truly follow and adhere to The Apache Way. 

While an OSD-approved license and associated policies are necessary for successful Open Source production, they are not sufficient. They provide a legal framework for the production of Open Source, but they do not provide a social framework, which brings us to the second sentence of our mission:

"The mission of the Apache Software Foundation is to provide software for the public good. We do this by providing services and support for many like-minded software project communities of individuals who choose to contribute to Apache projects."

"Like-Minded Software Project Communities of Individuals"

Key points in this section: 

  • The Apache Way provides a governance model designed to create a social framework for collaboration

  • The Apache Software Foundation develops communities, and those communities develop software

  • ASF project communities develop and reuse software components that in turn may be reused in products

  • Users of ASF software often build products and services using our software components

  • Our model, and others like it, have produced some of the largest and longest-lived Open Source projects that have literally revolutionized the industry 


There is a lot packed into these few words. It is an understanding of these words that makes the difference between software that is under an Open Source license and software that reaches sustainability through The Apache Way. These words underscore the fact that the Foundation does not directly produce software. That's right, The Apache Software Foundation, with upwards of $8Bn of software code, does not directly produce software. Rather than focus on software, we focus on the creation of and support of collaborative communities; the software is an intentional by-product. 

Our like-minded project communities come together because they share common problems that can be addressed in software. As the saying goes, "a problem shared is a problem halved". By bringing together individuals with their unique ideas and skills, we break down barriers to collaboration. 

The Apache Way is carefully crafted to create a social structure for collaboration, which complements the legal framework discussed above. Where the legal framework ensures an equal right to use the software, The Apache Way ensures an equal ability to contribute to the software. This is critically important to the long term sustainability of Open Source software projects. This social structure for collaboration is missing from many non-Apache projects, yet a robust social structure is invariably a key component in long-term successful projects outside of the ASF.

The Apache Way is fully inclusive, open, transparent and consensus-based. It promotes vendor neutrality to prevent undue influence (or control) from a single company. It ensures that any individual with a valuable contribution is empowered, and it seeks to assure that a project remains sustainable despite inevitable changes in community membership over time.

Apache projects typically produce software components that can be combined with other software (of any license) in different ways to solve different problems. This provides plenty of opportunity for participants to collaborate within a given software project independent of their relationship outside the Foundation. This is very different from the idea of licensing your product as a whole under an Open Source license. Our model offers more opportunities for reuse which, in turn, increase the pool of individuals likely to contribute to the project.

In addition, our merit-based system seeks to ensure that as people come and go, for whatever reason, there is always someone to take their place. As a result, some ubiquitous Apache projects have existed for over 20 years and helped commercialize the World Wide Web; while dozens of newer projects have defined industry segments such as Big Data and IoT (Internet of Things). 

A core tenet of The Apache Way is "Community Over Code", which encapsulates our deep belief that a healthy community is a far higher priority than good code. A strong community can always rectify a problem with the code, whereas an unhealthy community will likely struggle to maintain a codebase in a sustainable manner. Healthy communities ensure the Foundation has the stability to thrive for the next 20 years and beyond. Apache projects do not have the problem of scaling that others, who focus only on the legal frameworks of Open Source, suffer from. If you look around at projects that have grown up alongside the Apache projects, you will see a similar focus on scaling the governance model. This is no accident. 

Why this is Important

Software is a critical part of any modern economy. It touches every part of every life in the developed world, and is increasingly transforming everyday life, from womb to grave, everywhere.

At The Apache Software Foundation, we believe that every developer has their personal motivations for building software. We celebrate their right to choose when and how they build their software, including their right to use a non-open license. 

We will not dictate what is best for developers or for the software industry.

We care about the provision of software that enables our users, our contributors, and the general public to decide what is best for them.

We welcome you to use our software and contribute to our projects -- or not. It's up to you. 

We ask that you leave commercial interests at the door.

Countless organizations are proving that their team members who collaborate in a vendor-neutral environment often apply Open Innovation processes (such as The Apache Way) to their work. This helps create internal efficiencies and lays the groundwork for new external opportunities that may provide additional added benefits.

Bringing only your intention of contributing what best serves the greater Apache community reinforces trust in the people and projects behind the Apache brand, and helps us realize our mission of providing software for the public good. 

We learn together and work together to deliver the best software we can. 

Apache software is available for all.

The freedom to choose is what makes the Foundation and Apache projects so strong.

Summary

The software industry has changed and continues to change. The ways software is delivered to end users have changed. Some of the leaders in our industry have retired and new leaders have emerged. But some things have not changed. Our model of collaborative software development, through a combination of a licensing and social framework, remains one of the most successful models of software production.

Increasing the number of users, even those who do not contribute to code, should be seen as a benefit, not a problem, in Open Source. More users present an opportunity. At Apache, more users means more success since they are our future contributors.

As a US 501(c)(3) public charitable organization, The Apache Software Foundation helps individuals and organizations understand how Open Source at scale works in a highly competitive market. For more than two decades our focus has not been on producing software, but rather mentoring communities who produce software. The Apache Way advances sustainable Open Source communities: everything we do is Open Source so all kinds of users can benefit from our experience. Apache is for everyone.

# # #

Monday March 18, 2019

Apache Software Foundation Platinum Sponsor Profile: Leaseweb

with Robert van der Meulen, Global Product Strategy Lead at Leaseweb


Robert is Global Product Strategy Lead at Leaseweb. Fascinated by technology, Robert studied computer sciences, and after his studies, he delved into the then relatively young and rapidly developing internet technology. He soon understood that the internet would be at the center of almost everything we do and wanted to be part of it. Robert is passionate about using technology to improve people's lives. He contributed to the Debian project as a developer later introduced Apache CloudStack in Leaseweb and has been active in the open source community for quite some time. During his 9 years at Leaseweb, he worked hard to make sure digital transformation, from how we communicate to how we do business, is part of the company mission. Follow @Leaseweb on Twitter.


"Many Apache projects are being built by – mostly – volunteers and motivated individuals, and the world can use, change and develop all of those. It's important to support the people that make this possible."


How did Leaseweb's work with Open Source begin?

There's a long history of open source within Leaseweb. When you do large-scale hosting, open source operating systems, tools, and applications are always pretty much part of your product – and working on open source projects brings mutual benefits. This can mean running a mirror for your customers and "the outside world", fixing and reporting bugs, or helping with actual features or changes to "products" you use. As our services portfolio grew, we started using and contributing to more open source projects, especially when Cloud was becoming a bigger part of the portfolio – bringing the need for more middleware and (platform) management.

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

If you count the Apache HTTP Server predating the ASF, we've probably been using ASF software in one way or another for as long as we exist – which is incidentally pretty close to the ASF (we celebrated our 20th anniversary about 2 years ago). Our contributions and use of ASF projects grew significantly when Apache CloudStack became part of the portfolio. CloudStack being open source and managed by the ASF after cloud.com and Citrix adventures gave us a nudge to start using it more. I'd say CloudStack is a significant part of our Cloud portfolio right now – we run large deployments all over the world, often supporting critical customer applications.

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

Support for foundations such as the ASF is important because those foundations are important :-) . Any big open source project at some point needs the infrastructure to continue to run – and it's great if a project can rely on an organization like the ASF for that infrastructure so the focus can be on making the project great. Open source projects can grow and be more successful if they can more easily deal with governance, financials and administration, as well as tangible infrastructure and tools. Helping an organization like the ASF helps the ASF projects all over, which has an impact on the software we use as part of our products.

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

The simple distinguishing factor is the size of the ASF. There's a vast number of projects which are part of the ASF, and most of those are significant in the free software "portfolio". Many of those components and projects are used in a less visible way, being part of the hard-core infrastructure of the Internet – but without them, many tools and devices we use would not be able to function. What I like about the ASF, is that it embodies the open source spirit by valuing consensus and being an enabler for the projects that are part of the Foundation. 

What does "The Apache Way" mean to Leaseweb? What makes The Apache Way special?

There's overlap between The Apache Way and the values we try to stick to in Leaseweb. 

Important ones are Merit, Open and Consensus – in part due to our backgrounds. We value facts, deeply dislike assumptions, and like to make decisions based on proper motivation and data. Growth makes people happy and gives great results, so we like people to do more of what they're good at – and to get even better at it. This also means being open to new opinions and ideas – executing on them because they make sense, not because where they come from. I think those values are recognizable in many open source communities as well as in The Apache Way.

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

Open source projects are often tools for us or part of a product offering or service – which means we'd look at what tools fit best to get to where we want to be. Innovation is more a natural part of that, as we need it to continue to offer the right services to our markets. It's pretty much impossible to do that without constantly innovating and adding new features and products. Focus is a more difficult one; a large part of that focus is driven by our target markets and customers, so listening to that market and those customers to figure out what they want is super important. That information, along with keeping a close eye on market trends, gives us direction and focus from a product and services perspective. From a more technical angle, great engineers are always looking for ways to make their systems and services better :-) . Lots of input (and obviously the execution!) comes from the product teams – either by constant optimization and small changes, or by bigger business cases or ideas that can be executed. 

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

A number of our leading Cloud products are based on Apache software. We use Apache CloudStack for various private cloud and VPS offerings, and those platforms are continually growing and evolving – and we keep adding more with most of the new locations we open. Along with the CloudStack platforms, hosting environments obviously have many deployments using Apache web servers. Within our technical teams we consume lots of different Apache projects and actively contribute to a number of them (we have a dedicated CloudStack team that includes one of the Apache CloudStack PMC members). Every software solution has its limits, and obviously this goes for CloudStack too – but also we're happy we can change or help change the things that could be better. 

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

An important part of the ASF support is the platform we provide; it's obvious that The Apache Software Foundation would run their infrastructure on Apache CloudStack, but I'm happy the Leaseweb team and infrastructure is delivering and maintaining that particular CloudStack setup. There's a sense of pride; the people building the software are trusting our services to do part of that on. Next to that, it proves to me we provide a set of services and products we can be proud of and one that fits the requirements of a bunch of pretty hardcore Cloud developers.

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

It feels great! It's important to, if you have the opportunity, give something back. Many Apache projects are being built by – mostly – volunteers and motivated individuals, and the world can use, change and develop all of those. It's important to support the people that make this possible.

Are there any other thoughts on the experience of being a large-scale donor that you would like to share? What else do we need to know?

Not much. I personally really enjoy seeing what happens with the support we provide – what projects it makes possible, what things it makes more easy or better. Tangible insight in the results is a big motivator as well as a proof point. 

# # #

Sponsors of The Apache Software Foundation such as Leaseweb 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 . 

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

Calendar

Search

Hot Blogs (today's hits)

Tag Cloud

Categories

Feeds

Links

Navigation