In a previous post, I shared the first part of my interview with Travis Oliphant, co-founder of Continuum Analytics, where I asked him what excites him about the future of tech and we discussed how much of that future comes down to people and culture. In this installment, Travis talks about how to balance enterprise and open source, as well as what it takes to build a community.
Can you talk about any challenges you’ve faced while balancing the enterprise and open source parts of your business?
They work beautifully together as long as you understand their roles. Yes, it can be difficult— mostly education-wise—there is misinformation and misunderstanding in multiple places. There are some people who are kind of very steeped in the wool of “all commercial enterprise is bad and nobody should pay anything for anything.” There are very extreme views like that. And so they take any effort to sell anything as an affront. Fortunately, it is a very small percentage of people who have that extreme view. In the Python community it is even smaller. The Python and R communities have largely built some antibodies against that kind of extreme reaction. These communities are much more enterprise-friendly as long as there is a lot of giving back to the community.
There is a fundamental gap of understanding in the minds of some. People who are just in their niche don’t realize that there are a bunch of people in the world with problems that they need solved. The market is this amazing concept where people can voluntarily pay for solutions to their problems. Do you want people to solve real problems and provide jobs for others? Then you want a market to exist. There can be a real misunderstanding of markets and how important the markets are to progress and peace.
A big reason for this blind-spot in the software world is the anemic nature of markets where you have deep proprietary software stacks where network effects have created significant lock-in. The creates the anti-pattern of siloization and feeling trapped by your vendor, which leads to a reactionary response that goes too far the other way and some believe they need to write everything themselves and shouldn’t pay a vendor for anything. Some believe that either it is open-source, you write it yourself, or you do nothing. Doing nothing means you don’t get your pain solved, which helps no one. Writing it yourself typically means you spend too much and don’t take advantage of the cost-savings available by sharing costs across a number of participants. Having everything be open-source may not work either because while many things will be produced as open-source, there will always be needs that are not interesting to the volunteer labor that is behind open-source. It is not economical for you as a person building tractors, making toothpaste, making loans, for you to build the entire software stack needed on top of open source.
Now, what open source has done is said, well, actually there is a fundamental layer that will be open and shared across everybody, and it will become public domain so to speak—something that anybody can use. Great. That’s fantastic. That has made the world a better place because it decreases the initiation cost. However, some people believe that is all that is necessary and then everybody builds from there. But the problem there is you still have that same shared-cost problem. What about the shared stuff in between—that open source hasn’t built yet, may never build—who pays for that? Does every company have to repay and pay the same thing over and over for that too? No. That’s not economical either.
This is the modern open source spender, basically. And it is an emergent concept that many people are getting and starting to show up. For us, Anaconda Enterprise is that thin layer on top of the Anaconda open source. The enterprise customer makes a lot of sense. As a company, open source is life blood. So you have just actually connected a meaningful commercial transaction with supporting open source. And whenever you can do that, you are guaranteeing a continuation of open source. So it is actually in the best interest of fixing the well-documented sustainability problem of open-source.
You hear people talk about it all the time—the sustainability of open source. It has been popular for people to complain about the fact that projects don’t get enough funding and what not. I know that. I live that. And I am a poster child of that. It’s one of the reasons that we started NumFOCUS and started Continuum. At the heart of both organizations is sustainability of open source, because it has been on my mind since I was a poor grad student with three kids and a mortgage writing what would become SciPy. Continuum makes things sustainable by having commercial transactions that are supported by open source with margins from that business going directly to support open source. People’s pain points and problems are solved with commercial software using open source, and therefore they pay money, and therefore you have a sustainable story that supports open source.
We have actually come up with a pretty good model of how that works and how we support open source. I’m pretty excited about that because it is definitely working. That general principle translates to practice in a bunch of different ways—from training, to custom solutions around open source, to grants, and then product. And they all contribute to helping promote open source.
The other part of what open source helps inform us on is that you have to stay abreast of it. It’s a changing dynamic and space. So a lot of times you are basically having to look out and see—and we don’t always do this perfectly but you look out and see where things are headed. To us, open source is not just about code being open, it is about building and maintaining community. Because if code is just open and free, then, okay, that might be useful but maybe it is not progressing. You are going to have to do work to get it where you need it to be, but if you can see activity and its trajectory is there, then you are kind of making educated guesses about where it is going to be and therefore where your contributions shouldn’t be trying to compete. That dance of prediction between open source communities and open source players is very interesting. And it is a subtle thing that is going on all the time that is actually a part of the dynamic of what technology gets created.
It is under appreciated, I think. When somebody does something and promotes something—an idea—it can cause other people not to do something. Just like vendors might do that, open source communities might do that as well. So it is why it is particularly important in my mind when a big innovation like Spark comes out and people start thinking this is everything—it has got some good innovations, but it is not everything. And that seems true of many other things. You want to make sure it doesn’t take the oxygen out of the room and people start to think oh we are done, when actually you just starting to ask the right questions.
We keep coming back to this idea of community. Clearly, you have been involved in many communities, both inside and outside of Continuum. Do you have any advice to offer—either in terms of leading a community, best ways to access it or how to get a pulse?
That’s a good question. Usually those questions have a different subtopic. In terms of leading a community, you have got to listen. Not everybody can do it, not everybody should do it. Because leading community—you have got to have enough interest and passion about what you are doing to connect with people. And recognize that the people who are a part of who you bring in—it is not just “hey I’m there and every user of this thing I’m building is equally weighted.” You actually start having to segment and look for ways to create a structured hierarchy of individuals.
Hierarchy may be the wrong word because it has implications—but it is what it is. You have the inner people who you are trying to get to contribute to the thing and build the thing and extend the knowledge. Rather than 1 to 100, you are trying to create 1 to 10, and then each of those 10—you are building a tree of relationships. Because that’s actually how real, sustainable community works. It becomes this highly interrelated connective tissue. It is not a single superstar with thousands of followers. That might work in rockstar world, but that comes and goes. It doesn’t sustain. What sustains communities are relationship networks. And so you have to recognize that and realize you are building those relationship networks with every transaction and interaction you have.
I know we all see the community tracks at conferences—leadership, how to make a community strong, how to communicate—it really does seem to be a central issue.
It is. And I think it will be for a long time because it is a central human issue. And what is interesting to me, and I don’t talk about this greatly because some people have an allergic reaction to religion, but it is exactly the same problem religions have been addressing for generations. You can go back and—even if you don’t believe in anything they have done—look at the practice of how these communities have organized and recognize it is exactly the same thing here, because it is about human interaction and how do you support each other and how do you get the right folks involved. You can study and you can have things that work and things that didn’t, and understand why.
What you have to do for community to work is get people who are passionate about the vision or the mission or the thing—the unifying elements. And to stay connected those people have to mix their activity and effort with it. So if you are trying to build a community, then you have got to be able to first have a compelling thing that matters to enough people. Second, start to engage with the people who will be your missionaries, your evangelists, your people who actually care enough to tell somebody else. The Tipping Point calls them Mavens—you have to focus your attention on educating those folks. For example, making sure you have enough developer documentation instead of just user documentation. That is an important practical aspect that is often not sufficiently appreciated.
Some of this has been accidental for me. Like just watching NumPy and SciPy explode when the documentation came out that detailed how things worked. Because you have user documentation and you have also have documentation of how things work, right? And how the documentation of how things work is critical to attract new developers—new people become part of the inner circles. You need both users and people to sustain those users by encouraging everybody working on things. It is just recognizing they are both there, and then you make progress. But it has got to start with concern and interest, and passion about the thing. There is nothing that has been created that didn’t start with somebody who really cared about it. It is not quite as simple as turn on the internet and this code magically flows. The cathedral and bazaar concept by Eric Raymond I think is still absolutely real but I have a different take on the two modes.
My re-telling of his story is is that any open source software starts with a cathedral—the creation of the thing. And then the bazaar is that everybody comes and builds their stuff around it. Successful open source always has to have a cathedral phase where there is a thing that gets built that is the right thing. And then it also has to enter the bazaar phase where tons of stuff gets added to it that’s easy to do. That’s how the new cathedral gets built, and this is just the cycle that continues. Cycles happen, but good software has a long life. Be aware that, with community building, you will pay for the mistakes of the community you built, early, for a long, long time.
That whole “strong foundation” aspect.
That’s right. But, how do you do that? One of the things about community is recognizing the importance of an organization to help you. I think that is one thing that is under appreciated sometimes, though it is starting to become more appreciated with the existence of organizations like the Apache Foundation, NumFOCUS, and the Software Freedom Conservancy. There are organizations now that can help with the tactical details and then can help you be part of something bigger.
I have one more thing that just occurred to me. It is important to understand what your rallying point is. So if you will forgive another religious connection, what’s your church meeting? What brings you together? Community to sustain has to have a rallying thing. Is it a conference? Is it a webinar? Is it just a very tight knit mailing group? What is the thing that rallies people and brings them together to share the good word and reignite the fire that drives the innovation?
Yeah, and helping to build off of each other and learn from each other and recreate that passion. Conferences are usually filling that role, and they are pretty effective at helping feel connected to a community to the point where participants feel like, hey, I’m part of this, and so I can give, and my contributions will be received. That is why it becomes very important for those conferences to be welcoming, receptive, encouraging. You can’t force all of that, but it doesn’t just magically happen, and people have to work hard to create the safe atmosphere where people can share.
PyData has been really fun to watch because we knew this was important so we did a lot of work up front to make sure that the conference started and happened the first four times. But then all of a sudden other people get involved and you welcome that, and then they become owners, and then they become part of it. Then the natural geography and boundaries give opportunities for people to have their local deep involvement and they become part of something critically important.
Not every community is going to be big enough to have that level of organization but you can certainly affiliate, and you can have sub chapters and groups and special birds of a feather inside a larger event. There is very large opportunity with that.
Local people put on the PyData conferences, right?
Local people put it on. I founded NumFOCUS months before I founded Continuum. And the first year of Continuum we spent some of our seed capital hiring an executive director for NumFOCUS, Leah Silen. Then we supported NumFOCUS as it got off its ground, to really rally a community around a set of disparate projects that each had their power and their little sub communities, but they needed a center voice. And that center voice needed to have community governance. I didn’t want to create a center voice that people perceived as Continuum. Maybe in some parallel universe that would work, right, where people weren’t so afraid of markets.
The observation for me was there already was community and it was disparate and it was spread and you can’t go and just take over that community. It doesn’t make any sense, and people will perceive any kind of attempt at that. But it needed to be rallied and connected. So to do that, it required pushing forward NumFOCUS and PyData, and sponsoring them and making it happen and paying for it until the local community recognizes it as theirs. Every PyData now is local—the organizing committee is local. There is still a center—NumFOCUS sponsors them and provides guidance, a template, provides approach, has people who will come. There are fulltime people at NumFOCUS that help make PyData happen. But they don’t happen unless there is a local organizing committee and local support.
I know that we had people go to PyData San Francisco and they were really impressed with the local aspect.
Yeah, it’s because the community is there. I knew there was this community that was nascent energy out there, but what surprised me was how much latent energy was there. It just needed a little bit of a spark—step into it folks, go do it. So that was exciting for me to see just how powerful and vibrant that community was and is.
Editor’s note: The above has been edited for length and clarity. In the next installment of this interview, we’ll talk about Travis’ next big project, and what he sees in the future of software development.