Community Over CodeThree +1's is what it's all about2015-03-27T10:55:21Zhttp://communityovercode.com/feed/atom/WordPressShanehttp://shane.curcuru.name/http://communityovercode.com/?p=3592015-03-27T10:55:21Z2015-03-27T10:55:21ZContinue reading →]]>The ASF recently held it’s Annual Member’s Meeting where all Members of the Foundation cast ballots in the annual election for the Board. We are lucky to have had a number of excellent candidates for the board as always.

The new board comprises:

Rich Bowen

Shane Curcuru

Bertrand Delacretaz

Jim Jagielski

Chris Mattmann

David Nalley

Brett Porter (chairman)

Sam Ruby

Greg Stein

I also keep a graphical history of the ASF board. The graphic there is a great way to see the slow but steady progress of electing new faces to the board over time. Thanks to all the active Members who voted in the elections!

As the ASF grows in projects, communities, and Members, we’re looking forward to continuing to support our now 165+ top level Apache projects going forward!

Note that a number of new Apache Member nominees were also elected; however we don’t share their names until they’ve all been contacted and have accepted the invitation. Stay tuned in a month for that announcement from @TheASF.

]]>0Shanehttp://shane.curcuru.name/http://communityovercode.com/?p=3532015-03-22T19:17:35Z2015-03-22T19:17:35ZContinue reading →]]>The ASF is holding it’s annual Member’s Meeting this week to elect a new board and a number of new Members to the ASF. I’m honored to have been nominated to stand for the board election, and I’m continuing my tradition of publiclyposting my vision for Apache.

We are lucky to have a large roster of excellent director candidates, so no matter how the election turns out we’ll have a stellar board. Given the wide variety of opinions in our candidates, I urge all Apache members to set aside the time this week to carefully consider all the board candidates, as well as all the great new Member nominees. Please vote – and if you’re not free this week, be sure to assign your proxy for the meeting attendance: I and several other Members are happy to proxy for you.

Please read on for my take on what’s important for the ASF’s future…

Shane Curcuru (curcuru) Director Position Statement 2014

V1.0 STATEMENT

If you believe that we need to significantly improve the scope and quality of services and support that Apache provides to our 200+ project communities, then I urge you to cast your first place vote for me. I want to: codify tribal knowledge; hire staff to help our volunteers; and be a director who will better tell our story to the world.

Codify Tribal & Community Knowledge

The ASF has grown past the point where relying on volunteers to effectively perform the many coordination, mentoring, project support, and Foundation operations is practical.

As a community we have amazing knowledge and experience locked up in our heads, our mailing lists, and scattered in hard-to-read documentation. It’s not fair to our project committers – and the new communities joining the Incubator every week – to continue to rely on various individual volunteers to provide the tribal knowledge of how and why the Apache Way works. We need to codify our core processes and why they are that way, and make it easy for any Member – or any project, or podling, or contributor – to understand them and implement them. We also shouldn’t be afraid to publish and recommend our many best practices to all our communities.

We need directors who will codify the operational models inside Apache so that we rely less on individual historical knowledge, and more on clear, documented, and easy-to-implement processes to provide services and assistance to Apache projects.

Engage Dedicated Staff To Help Our Volunteers

Even when we have clear and efficient processes that are easy for people to understand and use, we still struggle to effectively provide key services, and to provide Apache Way mentoring for all projects and podlings. We could greatly improve the level, amount, and professionalism of services the Foundation offers to projects by hiring dedicated staff[1]. This will provide a consistent and reliable backstop to our many volunteer Members who provide mentoring and operational work within the Foundation.

Our volunteer governance, and minimizing the rules for our projects will always be central to the ASF. Hiring staff for a position like Director of Operations or Community Mentor will greatly improve our volunteer’s ability to help our thousand of committers and project community members focus on what’s important to them: efficiently producing great software products for the public good.

I don’t want paid staff to ever replace what helpful volunteers actually do provide. But paid staff can assist in two crucial ways:

Improving the efficiency of volunteers doing mentoring and Foundation or project operations. Someone with paid time to focus on improving docs, providing interactive education, and to actively “mentoring the mentors” would both improve the experience for our volunteer mentors, and increase the value our project communities get from them.

Backstopping volunteers. We rely on the Incubator’s volunteer mentors to ensure that podlings have a healthy community before graduation – but we know that not all our mentors are stepping up to the level our podling communities deserve. Paid staff can step in as a reliable backup community mentor when our volunteers don’t come through.

We also need to continue to invest in our excellent infrastructure team to ensure we can comfortably and reliably provide the wide variety of services our projects ask for.

Tell Apache’s Story To The World

Despite our rapid growth, we still struggle to explain to new communities and the rest of the world who we are and what we stand for. We need directors who will actively represent the ASF by better telling our story to the world: to developers, to users, and to companies in the software ecosystem. While titles may not matter much inside Apache, to the world outside, titles are important. We need directors and officers to actively educate individual developers and companies alike on how Apache works and the benefits of contributing to our projects.

Effective and appropriate education (from explaining the Apache Way and how Apache projects work) means that more companies may invest in our project technologies and communities. Most importantly, when newcomers do contribute – developers, companies, and their employees – will respect our project brands and communities, and contribute in a productive way. Even today we still find many clueful people at other major open source groups or events who don’t understand, or misunderstand, what Apache is – and doesn’t that just drive you crazy?

What Shane Does At Apache

I’ve been a passionate and active committer at the ASF since 1999. My current focus is to improve our documentation and guidelines to make them useful for everyone in our communities. I’ve written or improved content across the apache.org website, explaining Apache governance, project independence, and plenty of other clarifications. I speak at ApacheCon, OSCON and elsewhere, and have worked on mentoring within many Apache projects, both on branding and community issues. As VP, Brand I’ve defined and implemented a trademark policy for third party use, and guidance for projects to best showcase and defend their brands. I was an active mentor for the OpenOffice podling. I also give Lightning Talks whenever someone will let me.

About Shane

Committer since November 1999, Member since 2002, VP Brand Management since 2009, past Director.

My employment at IBM in the HR division as an Applications Architect is wholly unrelated to Apache; all my work here is currently unpaid. I live in Massachusetts with my wife, young daughter, and 2 cats (soon: +2 Siamese kittens! Whee!).

I believe in Apache’s mission for the public good – my work here is how I give back to the world. I view directorships and officer positions at the ASF as important commitments, and will attend every board meeting if re-elected. I have attended every board meeting since June 2009 with two exceptions (one due to my father’s passing; the other was a special in-person meeting in CA when I wasn’t a director).

]]>0Shanehttp://shane.curcuru.name/http://communityovercode.com/?p=3472015-03-22T00:43:21Z2015-03-22T00:43:21ZContinue reading →]]>How much do you know about the Apache Software Foundation (ASF) and the many Apache projects we host? Did you know we’re holding our annual Members meeting to elect our board of directors and new Members in just a few days?

I’m often surprised by the variety of basic questions and misunderstandings I hear in the software world about how the ASF really works. We’ve written plenty of documentation about the Apache Way and our governance, but let’s try a different approach. I’d like to interview myself to try to explain some things.

So, Shane, what *is* Apache? I thought it was that web server?

The ASF is a non-profit, public charity, 501(c)3 membership corporation with the mission of producing software for the public good. The Apache HTTP Server project (to use it’s formal name) is a project community at the ASF that creates the httpd web server, which has powered more active websites than any other server since 2000.

The ASF is the corporation that provides legal, branding, press, fundraising, and infrastructure support, and proven community mentoring to the many Apache projects like the HTTP Server. Think of the ASF as a great big house, where we provide shelter for a lot of different families that write open source software.

Well how many Apache projects are there?

We have over 165 different projects, and about 40 podlings. These 200+ project communities create a wide variety of software products, including Apache Hadoop, Apache Lucene, Apache OpenOffice, Apache CloudStack, and many, many more.

You are almost certainly using multiple Apache products right now as you read this. You may not realize it, but much of the plumbing of the internet uses Apache software to keep servers organized and connected. Most browsers use various Apache products under the hood for a wide variety of utility functions. It is our project communities that actually create the software you’re using — the ASF just helps keep them organized.

How does the ASF organize all these projects?

The ASF provides all the infrastructure an open source project needs: websites, code repositories, mailing lists, bugtracking services, a crack infrastructure team. We also provide all the rest of the services that a project will want, like legal support, access to press releases or analyst contacts, and some fundraising support. The ASF also owns all Apache trademarks on behalf of our projects, to ensure they get the credit they deserve.

Most importantly, the Apache Membership and many of our 4,000+ Apache committers provide the community mentoring and support to keep our projects running smoothly, with an independent project governance. We have many passionate Members with amazing experience in making open souce projects work, and they volunteer to help keep our projects healthy and running strong.

But this is mentoring and guidance, not direction. The ASF does not direct the technical direction of our projects. We let the people doing the work — the project committers and Project Management Committees (PMCs) decide where the code should go.

So the projects direct themselves. But what is “independent project governance“? How do you enforce it?

A critical behavior for any Apache project is independent governance. That means that every project manages their code for the benefit of all users (the public good), and not just for some company or vendor. In particular, the ASF and Apache projects only recognize individuals as committers or Members — never companies.

We expect when committers are working within their Apache project, they are acting for the best interests of the project itself. But we also have checks and balances: all Apache projects report formally to the board of directors quarterly. The board reviews project health — are they acting indepenently, are they publishing software releases, are they voting in new committers. If the board sees behavior that does not show mature Apache project behavior, the board will work within that project community to help the project community correct itself. Many Apache Members also volunteer to mentor our projects in these cases. In extreme cases (very rare), where a project does not follow the Apache Way, the board will unilaterally make changes to correct their course.

Can you clarify who are the board, the Members, and how they relate to projects? Are Members part of all projects?

Imagine Apache as a condominium association with multiple condos together. The ASF as a corporation provides the building. Like some condo associations, we also define a few expected behaviors and appearances for all the condos we offer. We also offer bonus services, like help moving into your condo or fixing things up. Each Apache project lives in one of these condos. We’re happy for you, the project community, to live your own lifestyle within your condo and paint the inside whatever color you want, as long as your public behaviors when you’re here follow our community best practices.

Here, the Apache board is the board of the condo association. They set the core rules and guidelines for the building. The Membership are sort of the owners of the building — not that they can ever sell their shares or make a profit, but they are the only ones who can nominate and elect the board. The board appoints all the officers who set detailed policies and make all the operations of the building work, like trash pickup and elevator maintenance.

Every Apache project condo has at least one Apache Member involved with the community: the Incubator requires that every new project has a few Members interested in that community to help mentor it. But within each project condo, the code direction or decor choice is completely up to the whole project community to decide. Membership in Apache is not transitive to any project: Members need to be elected to your project to have a direct say in it.

The ASF offers a lot of services to projects. How does this all get paid for?

The ASF board approves an annual corporate budget of about one million dollars. Our primary income is from our formal Sponsorship program, where organizations can provide a regular annual donation. As a 501(c)3 charity, we also have many individual donors, and some authors donate royalties from their books about Apache software to the ASF.

Importantly, sponsorship of the ASF does not provide any influence over Apache operations nor the operations of any projects. The ASF’s mission is to serve the public good, and while we very much appreciate our generous sponsors, we do not serve them: we serve our project communities and software users.

Sponsors provide a variety of reasons why they sponsor the ASF, many of which relate to how we host so many different critical software product communities. As one sponsor said, “Apache builds the plumbing of the internet”. Some sponsors and donors simply want to give back to the ASF in appreciation for all the software we provide for free.

So the Sponsors can pay for Apache project development, interesting.

No! Sponsorship funds are purely undirected — we do not accept donations with ties or requirements. By policy, the ASF does not pay for core development on any Apache project. All our budget is used for the support services that allow our project communities to do their work — which is building Apache software.

Do any Apache committers get paid for their work?

Of course — but not by the ASF. Many committers are working on Apache projects on behalf of their employers, who may be software vendors providing support, hosting, or add on products for that Apache project. Some committers are independent consultants, trainers, authors, or the like, who make their own living from helping other people use Apache projects. And a lot of committer work is done simply because that person needs to fix a bug or add a feature that they need for themselves. With so many people using Apache software to run their businesses, most work is self-serving: building code that they need.

The ASF provides a vendor-neutral place where everyone who benefits from Apache software can collaborate to improve that software. The ASF does not have an agenda or direction — we rely on the people using our software to help improve it.

Well… how much do *you* get paid at Apache?

Nothing.

No, seriously — how much do you get paid for this?

Seriously: nothing. Zero. Zip. The ASF has never paid me for my work here, and my current dayjob is wholly unrelated to my Apache activities. I’m here purely as an unpaid volunteer.

How did you get to be at Apache? What drives you to do all this unpaid work?

I first started committing code to the newly formed Apache Xalan project shortly after the ASF was incorporated in November 1999. At that time, I was paid by Lotus/IBM, my employer, to contribute to the Xalan as part of my job. I also got to attend and speak at a few ApacheCons to try to promote our work on Xalan and Xerces.

Over time, my dayjob changed direction, and turned away from Apache, but I was still interested in how the ASF worked. At ApacheCon I had followed a friend into a conference planning meeting to see how it worked, and I walked out of the meeting with assigned tasks for the next ApacheCon. Once I started helping with events, I was hooked. In 2002 I was elected as a Member of the ASF, and got to see how the sausage was made from the inside. In 2004 my job changed to be wholly unrelated to any open source work, but I was already personally invested in the ASF and our many excellent communities.

I volunteer at Apache for several reasons:

This is how I give back to the world. I’m lucky enough to have a healthy family, nice home, and stable job. I volunteer my extra time to help make it easier for Apache project communities to build more free software for the public good.

I love the ASF and it’s people. I’ve met so many amazing people at ApacheCon and within our projects, and it feels like much of the Apache Membership is one big family. Sure, we fight plenty, but we also buy each other plenty of free beers and meals.
Helping open source communities get organized and keep their volunteers motivated is something I’m good at, and something I’d love to do more of if I could. Volunteering at Apache is a huge impact to my personal brand and my future job prospects.

Wow, that’s been a great interview Shane! How should we wrap this up?
It’s been a pleasure. Thinking about what motivates me, this is one of the things I love doing: explaining technology and communities to interested audiences. This is also great timing for this interview, because the ASF is having it’s annual corporate meeting where the Membership elects a new board.

We have a truly stellar list of director nominees this year: looking at the candidates the Membership has nominated shows just how talented and friendly all our candidates are, and how any of them would be a help to ensuring the smooth operations of the ASF in the year ahead.

Since I do have the microphone, I will make one short plug to note that I’m also running for a seat on the board. I’ll be posting my director nomination statement — a note detailing why I hope Members will vote for me — soon here on my open source blog, Community Over Code.

Good luck with the election Shane — it sounds like Apache is in good hands no matter who gets on the board.

Yup. While we still have a way to go to make it simple to understand Apache for newcomers, the ASF and our project communities are doing amazing work, and often having a lot of fun doing it. Apache plans to be around for the next 50 years providing a stable home for like-minded project communities of all sorts.

Thanks for the interview — this was great to talk to someone about this!

Shane volunteers as the Vice President of Brand Management for the ASF, although all content here is his own personal opinion. He is not normally an interviewer, but does sometimes play a trademark lawyer on the internet. He hopes you liked this article, which also appears on Medium, and will ask him any questions about Apache that you might have. He promises to stop writing in the third person now.

]]>0Shanehttp://shane.curcuru.name/http://communityovercode.com/?p=3442015-03-08T18:59:48Z2015-03-08T18:59:48ZContinue reading →]]>Open source has come a long way in the past 30 years and is entering the consciousness of most modern cultures. When thinking of open source projects, people categorize them several ways: governance structure, type of product platform, programming language, utility, technical details (language written in), industry sponsored or fully independent, and more.

But what truly defines any open source project, making it a unique entity different from all other open source projects? I would propose that there are three key elements of any open source project that frame, define, and differentiate that project from all others: the code, the community, and the brand.

The code

Code is king. Code is what makes a product do something, and that’s why open source projects exist in the first place: to build something useful. Technologists get excited about what the code does, and how it does what it does. Marketers get excited about how the product will solve their customers’ problems. Code is what most people are looking for when they’re searching for an open source project to use.

Sounds simple enough—so why don’t we define an open source project purely based on its code? As anyone who has worked in software development already knows, code is ever-changing and ephemeral. In the open source frontier, free from the traditional controls of corporate-led projects, “the code” can get very hard to follow: open source code is infinitely forkable. Once your code is checked in under an Open Source Initiative (OSI) license to a public repository, it is fully accessible to anyone and everyone to take—and modify—for their own purposes. Once another user forks the code from your project and makes a slight modification, it is no longer officially part of your original project.

The community

If code is the “what” of a project, then the community is the “who” of the project—the people who make it all happen. The core community of a project includes anyone actively involved in moving the project forward, such as the engineers writing the code and the end users who provide feedback or request specific modifications. The overall community also includes people who don’t check code, but provide support such as governance/process oversight, public relations/marketing, training, or financial or employment support. The social norms, the etiquette, and the ethos of the community help to differentiate a project from all others.

While participation in an open source project may be part of some individuals’ paid employment (e.g. a corporate-employed software engineer assigned to work on an open source project for a certain percentage of her or his time), most open source community members participate voluntarily with no direct connection to their paycheck. So members tend to come and go as their interest or their other commitments wax and wane, or as their employer changes strategy. Like the code, the community is ever-changing.

Unlike a corporate software development project that can plan on having employees with certain skills available to assign to do specific work, the participation in an open source community is unpredictable and often beyond the control of the project. Personality conflicts arise and may result in highly skilled contributors leaving the community more readily than they would leave a paid employment. But the benefits of an open community can be seen in the enthusiasm and drive of many community members, and in the longevity of successful project communities, and in syncrhonicity and great work forward on the code.

The brand

Brand is how the world outside of an open source project learns about that project. When individuals or companies are deciding which project to use or to invest in, branding helps them differentiate projects that offer similar functionality. Of course they will consider other details, but it is much easier to think, “Do I want to support Hadoop, with the yellow elephant?” rather than “Do I want to support Cloudera’s CDH or the Hortonworks Data Platform, or the newly announced ODP?”

“The brand” includes many things: the official name of the project, a logo for the project or product, and even the appearance of the project’s website and your product’s UI. Some branding components in particular are legal trademarks: these typically include the official software product name and logo, although trademarks are strongest when used consistently.

Unlike code and community, a project’s brand is not ever-changing or ephemeral. A trademark cannot be forked without legal permission, and a project brand can stay consistent even when community membership fluctuates. In many ways, the brand and trademarks are the element of a project that can be most easily controlled and maintained. However, proper trademark usage can be overlooked—or underappreciated by the community inside of the project—as an important tool for defining a project’s unique character. Given that anyone can fork the code, and that community members come and go, a project’s brand and trademarks are crucial elements for maintaining a project’s longevity and independence, and to continue to draw in new project contributors.

How can we do a better job of getting at least a single “Apache Hadoop” into some of the many media stories about Hadoop these days? It’s great that all these vendors are making great technology and projects that power big data, but with all their success and fancy marketing campaigns, you’d think we could get just a tiny bit of credit in the popular press with the actual committers on the core Apache Hadoop project itself. Or any of the other Apache project technologies that these vendors, other software companies – and just about every other company too – rely on every day to help make their websites work.

Would it hurt marketers and journalists and bloggers to throw in just one extra “Apache” before talking about the many free Apache software products that help power more than half the internet?

The ASF and Apache projects give away a tremendous amount of technology every day under our permissive Apache license – always for free. All we ask is respect for our trademarks, and a little bit of credit for the many volunteer communities that build Apache software.

P.S. Apache projects love to get more code, documentation, testing, and other contributions too! And the ASF has a Sponsorship program.

But what we we really want is what every human wants: just a little love. Just an extra Apache here and there makes us feel better.

Thanks!

]]>0Shanehttp://shane.curcuru.name/http://communityovercode.com/?p=3342015-02-15T02:54:33Z2015-02-15T02:00:16ZContinue reading →]]>The contributors behind the awesome Groovy project are looking for a new home. It’s bad news that the project and some of its core contributors will no longer be sponsored (paid for) by Pivotal, but it’s great that the core contributors are organized and serious about moving their project to an existing Foundation.

You’ve already taken the most important step: choosing to join an existing Foundation. Although each option comes with some compromises or tradeoffs, I assure you any would be far superior to forming your own new non-profit corporation to be your legal home. Forming a new corporation is a lot of work, requiring a different energy and skill set than most developers have; this would significantly diminish the time that your contributors could spend actually focusing on the code. All three of the proposed options – Apache, Eclipse, and the Conservancy – have long and successful histories of providing all the things a Foundation can provide for open source projects: legal support, infrastructure, community and governance models, and a stable and well-branded place to call home.

Yawn…those things don’t sound particularly exciting, do they? In general, those aspects aren’t very exciting for most developers. But having a legal and stable home is critical if you want to manage your own project’s future, and not have it dictated by a single for-profit company. Or worse, slowly lose your way due to lack of contributors, and eventually, lack of users.

Talk To People

Clearly the Groovy core contributors have already considered a lot of the potential issues related to joining a Foundation, and have agreed on some basic requirements (which look great!). However, your community’s current understanding of how the three Foundations work appears to be mainly based on the available documentation from the Foundations, and not necessarily first-hand experience.

By far the most useful advice I can give is to have enough of your core contributors talk directly to some representatives of each Foundation (as some of you have already been doing). It’s likely that a number of your initial concerns won’t be as hard to deal with as you think, especially if you are clear and open in your communications with Foundation representatives. Make sure you have enough clear and direct information from the Foundation representatives – and your core contributors have time to truly discuss the input together – before making your final decision.

Who owns the Groovy Trademark?

In your planning, be sure not to overlook this essential issue. Who owns the GROOVY trademark? While it may seem obvious to developers and contributors, it may not be clear to the lawyers and marketing VPs of various companies who might be interested in using Groovy or contributing to the project in the future. Is Pivotal (and/or Codehaus, depending on who hosted the past software releases) willing to sign the trademarks over to your new legal home (once you choose one)? While open source code is infinitely forkable, trademarks aren’t. For example, the Apache License may be permissive regarding use of an individual project’s code, but explicitly does not license the project’s trademark(s). Likewise, most of your users know the language as “Groovy.” If Pivotal decided to keep the trademark (which seems unlikely, thankfully), you’d still be perfectly welcome to fork the code, but under a new name. Not Groovy. The apparent notoriety of the recent io.js fork notwithstanding, getting new contributors to a newly branded project is hard.

Who is your core Decision Making Community / Governance?

It’s great that your core contributors are thinking this through, defining the mission of the project community, and weighing the options carefully. This is a time where you’ll need to start developing a more detailed governance model; particularly the required members of the top decision making body. When your project is living without the direct umbrella of a company, you’ll need to have a specific list of the individual people who make governance decisions.

There is a clear difference between the Apache/Eclipse governance models and the Conservancy governance model. Conservancy essentially serves as a legal place to hang your project, with a hands-off approach that allows each project to develop their own self-governance models. Apache and Eclipse have detailed policies mandating how major decisions are made within a project (for example, inviting new committers or making formal software releases). In their models, a Project Management Committee (PMC) made up of individuals casts binding votes according to standard voting rules. Most decisions are still made by consensus of PMC members – probably how Groovy already operates. The details of voting rules really only come into play when the project team can’t reach a happy consensus, or when making formal software releases (in the later case, having clear votes by the policy ensures that the release is an act of the project, not of just an individual).

In addition to the project governance policies, Apache and Eclipse have an overarching board of directors to provide oversight that the core rules really are being followed consistently for every software release.

One slight difference between the Eclipse and Apache governance models is the role of the project leaders. Apache PMC members each have one vote, and all members of the PMC are peers. Technical direction is purely project-driven at both Apache and Eclipse; the board and officers never interfere with technical decisions. At Eclipse, there is a “Project Lead” role for each project, and that individual has greater influence over decision making. There are also Eclipse-wide Planning and Architecture Councils, which work to establish policies and processes for all projects, and the schedule for the annual Eclipse release train.

Infrastructure, Sources, History, And Tooling

Each of these areas requires attention, and I have some initial thoughts:

Infrastructure: If you like Conservancy, could you find another company (such as OSUOSL?) to provide the physical hosting for you?

Sources: While Apache requires the canonical repo to be on ASF hardware (to ensure the project is master of it’s own fate), there are plenty of ways to mirror to github or elsewhere.

History: If you really like Eclipse, then even if you did have to reset history, couldn’t you find some way to host a static version of the previous history somewhere for reference?

These are certainly issues that take effort, but it’s more important to ensure that the core people actually driving your community can find a stable home Foundation to settle in for the future.

Funding

For those potentially losing their Pivotal jobs, this is a key question, and one that’s certainly not easy, either on a personal level, or on a project and community level. Be sure you’re all clear on how and why you’re making decisions related to funding. For the Groovy community, this transition is clearly much more than a group of dedicated people doing this as their paid job, who are hoping to find new jobs together; you have built a coherent community that must find a long-term home for your project.

For the overall project, this is an exciting opportunity. With a full community, including both individuals as well as companies (contributing through the actions of their employees), you can have a long-term independent project. Right now, managed within the Pivotal framework, Groovy is at the mercy of Pivotal’s internal business decisions. To succeed as an independent project, you need to have a foundation to own the brand and provide (at least minimal) governance, and you need to draw enough interest from software companies so that they’ll either contribute work, or be interested in hiring your contributors.

Here also your three Foundation choices are very different. Conservancy will provide you with a 501C3 fundraising structure through which you can raise money to pay your contributors to develop code, but there may be limits to how much active fundraising support they can realistically give to you. Eclipse, as a 501C6, has a more corporate-focused funding model. They also seem likely to have more staff to help connect the core project contributors to companies potentially interested in funding more development. Apache is a 501C3, but the governance does not allow direct funding of project development by for-profit companies. Work on Apache projects is either performed by independents, or by employees of various companies; projects that don’t attract any company-sponsored contributors tend to stagnate; however for projects that stay relevant, it results in longer lived and strongly independent projects.

Good luck!

Whichever Foundation you choose, I wish you the best of luck. Open source has come a long way in the past twenty years. Licenses are well understood, and business and individuals everywhere frequently rely on open source projects for everyday things. And now with the long-term success of Apache, Eclipse, Conservancy, and many other non-profit open source Foundations, we are starting to have a decent understanding of some of the great governance and project management models we’ve developed.

This post also appears on Medium. Thanks to @mmilinkov for minor updates re: Eclipse.

]]>1Shanehttp://shane.curcuru.name/http://communityovercode.com/?p=3302014-12-02T19:50:24Z2014-12-02T19:50:24ZContinue reading →]]>As our intrepid conference master and ASF’s EVP Rich Bowen Notes in the Margin,
we recently held a spectacular 24th ApacheCon at the beautiful
Corinthia Hotel in Budapest, Hungary – followed by the CloudStackCollab
conference focused on the fast-growing Apache CloudStack project.

Rich, LinuxFoundation production staff, and an array of Apache volunteers put
together a great set of talks with some very focused
tracks on specific days – both for technology as well as for community
and business interests around Apache projects. As Rich notes: if your are an
Apache committer and want to speak, or see your project represented at
the next ApacheCon US April 13-17th, 2015, in Austin, Texas then sign up to help organize!

Unfortunately we don’t have video for talks this year. That means that folks
who couldn’t attend are missing out on an inspiring keynote from this year’s
conference: David Nalley talking about the Value Of The ASF. This is one
of those talks where the slides don’t make sense without hearing about it.
David came up with various figures representing the “value” of the code that
all Apache projects provide – and they’re massive numbers. More importantly,
the larger value of the ASF is the proven Apache Way of organizing
large-scale, long-lived collaborative activities between heterogeneous
groups of individuals – and making it work in a way that allows companies to
invest their resources (employee time and sponsorship) without impinging on
the independent governance of Apache projects.

Matching our inspiring talks was the friendliness of the
staff at the beautiful Corinthia Hotel Budapest, along with the beauty, history,
and warmth of the city of Budapest and the people of Hungary. A week alone
is not enough to see the sights of the city, and it’s no where near long
enough to enjoy all the wonderful food and drink there! Here’s hoping that we’ll
be able to come back next year!

]]>0Shanehttp://shane.curcuru.name/http://communityovercode.com/?p=3252014-10-02T11:02:33Z2014-10-02T11:02:33Z CODE, and I’m looking for feedback on how to expand … Continue reading →]]>So, it was short, but an important message that I don’t think many open source project participants are really thinking through yet. So, it was all about how BRAND > CODE, and I’m looking for feedback on how to expand this, so, into a much bigger and better talk.

So, you have to understand: yes, watching the video is so painful. I’m not usually that so-so. It was a combination of nerves (bigger stage than expected), jetlag, E_NOTENOUGH_PREPTIME, and the fact that my cell phone had just taken a dip in the water a few hours earlier.

]]>0Shanehttp://shane.curcuru.name/http://communityovercode.com/?p=3182014-05-29T17:43:30Z2014-05-29T17:43:30ZContinue reading →]]>The ASF recently held it’s Annual Member’s Meeting where all Members of the Foundation cast ballots in the annual election for the Board. We are lucky to have had a number of excellent candidates for the board as always.

As the ASF grows in projects, communities, and Members, we’re looking forward to continuing to support our now 151 top level Apache projects going forward!

]]>0Shanehttp://shane.curcuru.name/http://communityovercode.com/?p=3152014-05-22T19:30:18Z2014-05-22T19:30:18ZContinue reading →]]>The ASF is holding it’s Annual Member’s Meeting next week, where the Membership elects a new board of directors along with other matters, like voting in new Member candidates. Director candidates write position statements about what their objectives for being a director are in preparation for the Apache board election process. One of the biggest issues for the smooth functioning of the ASF as a home for healthy projects is better explaining how Apache works – so here is my Director Position Statement. You can also read my statement last year and the previous year.

Shane Curcuru (curcuru) Director Position Statement 2014

v1.0 statement

Over the past couple of years, the ASF has grown to a point where we can no longer efficiently continue to govern, manage, and execute the various operational aspects of the Foundation in support of our nearly 200 project & podling communities with only unpaid volunteers. We need a board that can maintain our fiercely vendor-neutral governance while also expanding and improving the services that we offer to all Apache projects, and this will require finding ways to increase our paid staff [1].

While the volunteer membership has been amazing throughout our history in helping with governance, mentoring, incubation, and all other aspects of operations, we simply don’t have enough members with time reliably available to provide this level of operational support. With 150+ separate Apache top level projects – each with its own technology, individual community history, and sometimes urgent pace of development — the overall cohesion that marked the earlier years of the Apache organization has been jeopardized. It’s clear from recent requests and issues that we are not providing the level of support – infra, brand/press, fundraising, and community mentoring – that many of our projects expect and require.

With the growth in key project technologies that affect the larger world, we also have a corresponding higher level of expectations from stakeholders outside of the ASF volunteer community. Our sponsors – when we do talk to them about their sponsorships – want us to be more visible in the open source space and show more support to our projects. The many vendors whose employees work on our projects similarly want to be more involved with donations, servers, events, or branding efforts around our projects. Ensuring that this external energy is focused on the Apache project in ways that maintain an independent project governance is critical to the success of both our projects and to the ASF itself.

We need to provide a better API between individual project communities and our service providers (infra, press, brand, legal, fundraising) at the Foundation level. We need to ensure that projects are aware of the services we can provide to support their operations, and make it simple for them to utilize those services. Clear expectations should be set for the level of services that the ASF will provide, as well as governance assistance for those projects that will continue to use external service providers (eg, various marketing@ efforts and many projects’ externally run build/CI/test farms).

To meet the current services needs, and to support increased quality in our governance and operations, the ASF will need to increase our number of paid staff [1]. We need motivated, experienced, and trusted individuals who have the paid time to address the ever-expanding needs of the Foundation, and who can dedicate themselves and their time at a level that is not possible for an unpaid volunteer.

It is also essential that we scale our management and oversight ability of these services and of staff without losing our soul: without compromising our historically independent and volunteer board and governance structures. I don’t know exactly what this path will be: that will be for the next board to decide. But I do believe we are underserving many of the projects at Apache today, and we have no end in sight of new podlings hoping to join us.

If you also believe we need to better provide for the many Apache project communities that trust us to be their home, I hope you’ll cast your first vote for me. Thanks!

About Shane

Committer since November 1999, Member since 2002, VP Brand Management since 2009.

I am employed by IBM in the HR division as an Applications Architect. My employment and income have been unrelated to my work at the ASF for many years, and I will always clearly separate volunteer work from employer-funded work.

My involvement in the ASF is driven by a belief in, and a love of, the ASF, and is not influenced by politics or finances. I live in Massachusetts with my wife, young daughter, and 2 cats. I view directorships and officer positions at the ASF as serious commitments.

I will attend every board meeting if re-elected.

[1] NOTE: How we pay for staff is equally important: at this point in the ASF’s history, I imagine either independent contractors as infra operates currently, or using the services of our new accounting firm Virtual, Inc. for some sort of co-employment arrangement, to reduce risk to the ASF.