Fundamentals¶

Structure¶

Whereas the goal of any publicly traded corporation is to ‘maximize shareholder value’ - make money - our goal is to ‘maximize open source code’. So we’ve decided to experiment with structures that prioritize that over making profit. Corporations have evolved to make money for all who hold an interest. A corporation’s instincts and motivations are to always seek out more growth to bring more shareholder value. With OpenGeo we are seeking to engineer an animal whose instincts are to do whatever is best for the code. Making money to support a team of developers is an effective way to further that, but because OpenGeo’s goal is not to grow or bring in value for shareholders, it may not always take the most profitable route.

Though many corporations are full of good people who believe in goals beyond the goal of making money, they can be subverted by the corporate structure they work for. Corporations would rather grow than achieve a mission. OpenGeo, on the other hand, puts its mission first. It evaluates growth against its mission; if it is best for the code, the OpenGeo might even dissolve itself. For example, it could replace itself with a cooperatively funded collection of independent developers.

OpenGeo’s current structure is a division of a 501c3 non-profit called OpenPlans.

OpenGeo has received generous angel investment from OpenPlans and its primary benefactor, Mark Gorton. But for the past few years the goal has been to become completely self-sustaining by competing in the market while simultaneously furthering the mission. In the next year or two OpenGeo will likely start to make more revenue than its costs. In a for profit structure this would go back to investors. In the current structure this money gets returned to OpenPlans, to sustain its more charitable operations, or to help it start new ventures like OpenGeo that further its overall goals.

At some point it may make sense to shift this structure, perhaps following Mozilla’s model of spinning out a corporation that is owned by a foundation. And/or becoming a B-corp. We don’t feel there is currently an ideal structure for what we are trying to do, and as the structure evolves we will always keep the goal of making open source software above that of making money.

Revenue¶

OpenGeo formed to bring about a transformation from a services company to a product company. (should make a history section, somewhere else). The ideal primary source of revenue is OpenGeo Suite Enterprise contracts, which at the core provide unlimited bug fixes and advice on stable software packages composed of the open source projects we support. These are a great alignment of incentives, as clients desire software they can rely upon, without having to worry if anything goes on. And with sufficient Enterprise contracts OpenGeo’s incentive becomes to make the best bug free software, so that we don’t have to spend our time fixing individual bugs. In a open source project supported by consulting and services there is almost a perverse incentive to make slightly buggy software, so that ones services are always in demand. With subscriptions at the core the incentive is to make the best software, get it as widely used as possible, and rely on organizations who would rather pay money to not have to worry and waste time.

The most successful open source companies have all relied on this strategy, so OpenGeo is just following in the footsteps of Red Hat, Spring Source, Xen, JBoss, MySQL and more.

OpenGeo’s focus on geospatial software is more niche, but our revenue desires aren’t nearly so ambitious. The reason for shifting to a product company is to have more control over the roadmap, and to be able to take risks to incubate new projects and products. With just doing services the roadmap is completely dictated by the clients. And it is very hard to get clients to fund much of the unglamorous work of Open Source, like community management, releases, and bug fixes. With support revenue this becomes something required by clients.

We will never entirely give up on services, and indeed in the transition to a full product company services are required. In the long term we hope to push most of the implementation and training work to our partners, with OpenGeo focusing on core software development, documentation, training material production, and bug fixing. In the short term there is not enough of an ecosystem that has the skills to do truly great implementations, so we continue to do services. Some developers will always do services, because it is really useful to stay in touch with how people are actually using the product. A number of the services OpenGeo currently does is also things that are directly on the core roadmap already. So service work will also be used as a type of funded research and development (R&D). OpenGeo will likely never have a huge R&D budget, but instead will rely on clients to fund things that are of future interest, since we look for market feedback in all we do. These clients will be more early adopter types, who can see what’s coming next, and we may prototype some pieces to point the way forward. But we’ll always do services for core development of our roadmap.

In time partners will also be resellers and provide first line support. But a percentage will always go back to the core, for the core software development and for the OpenGeo brand. OpenGeo will always provide the solid, reliable brand around the open source software, and will continue to invest in marketing and press to keep it strong.

Many faces¶

One of OpenGeo’s core value propositions is that we ease the interface between traditional organizations and open source communities. We willingly adopt several different faces, so that people and organizations can interact with us in the way they feel comfortable. While open source communities are making some of the best software in the world today it can be quite difficult for an organization that is used to purchasing software from proprietary companies to interact. This makes sense, as the primary mode of interaction in a community is as individuals. A company looking to buy software from an open source community is like showing up at a potluck thinking it’s a restaurant - both parties will just be very confused. Complaining about shoddy service won’t go over too well, and if you try to pay the potluck participants will tell you to go to go home and make something, or at least buy something at a store and bring it.

You can think of OpenGeo as a little stand set up by potluckers right outside of the potluck. If you want to just eat all the great food at the potluck they’ll take your money, set your table, dress up as waiters, bus boys and hosts, and serve you course after course. Behind the scenes they’ll cook some more for the potluck so there’s enough for all to eat. They can also dispense with the table service, but still contribute to the potluck on your behalf, so that everyone else is psyched that you came and sat at the table. Or they’ll just help you cook your own dish, giving you advice on where to place it, how the line works, when to get seconds, where to place your dirty dishes, and when it’s your turn to help out with the cleaning. If you already know how it all works, but just don’t have the time to cook they’ll make your dish for you. And they’re always excited for people who show up and already know how potlucks work, since it just leads to more awesome courses for everyone (including the people who want to go to the restaurant).

The equivalents of these modes of interaction are mirrored in how OpenGeo actually works.

• The most public face of OpenGeo is the full service one. Organizations can interact with OpenGeo just like they do with proprietary software companies. There is a professional website, prompt response to inquiries, items to buy, salespeople to help you through the process, legal contracts holding the company accountable for anything going wrong, support staff, training, stable release schedule, consultants to customize the software, local partners and extensive documentation. The software also is easy to purchase, as OpenGeo is on a variety of contract vehicles, like the GSA and several state specific ones, and is also able to sell through partners in other countries.
• OpenGeo can be funded to directly develop features that go in to the open source codebase. Instead of having to hire one’s own developers OpenGeo can be contracted to deliver an enhancement, going through the whole community process to ensure that it gets in to the Open Source baseline. Since our developers work with the code and community every day they can usually deliver much faster than anyone else.
• Those who want to get involved with the community can use OpenGeo to help introduce them. OpenGeo can consult on how to join, how to write code that will get accepted by the community process, what good contributions might be, etc. OpenGeo can mentor and train people to become core open source contributors, if that’s important for their organization.
• Many people who are already great community members often use OpenGeo for help on its core areas of expertise. Many of them already contribute to the software, code or documentation and help on lists. But to meet their clients or needs they will leverage OpenGeo as an extra cook in their kitchen to ensure that the result is of the highest quality.
• OpenGeo is on the lists every week, encouraging more contributors, helping with review of patches, doing releases, and in general helping build and expand great communities. All the work funded by clients goes right back in to these communities, and OpenGeo does its best to be seen as a great contributor. But at this level it’s really about individual contributors, people who work for OpenGeo and are able to contribute the work done while paid by OpenGeo clients to all.

So the primary reason for OpenGeo’s current public existence is really to provide a face to risk averse organizations to have the same experience they do with proprietary software. To help those who want to tap in to the amazing results of open source software, but need a well known way to interact.

Our long term dream would be for the need for that alternate face to drop away. The ideal would be that every organization contributes up front, each according to their ability. Open Source software is really a cooperative, and if there were a direct mechanism for passionate developers to always get paid for useful software then there’d be no need for marketing and sales and branding. But this is obviously far from the world we live in. And we accept that the vast majority of users never contribute anything. Thankfully the costs are relatively low, and there are organizations who have real needs that involve contracting OpenGeo and its core developers in some way.

So in the long term OpenGeo’s public face could drop away, though it’d likely still exist as a cooperative to help contract developers. But in the meantime OpenGeo provides a sort of asynchronous cooperative - the organizations who contract OpenGeo are pooling their money at the time that’s convenient to them, for a result that all benefit from. To compete effectively in the market it’s quite important to have all the trappings of a proprietary company, so OpenGeo will continue to invest in marketing, sales, contract vehicles and a great reputation that can be relied upon. And meanwhile we strive to be the best community members we can, even if that could enable a company that puts OpenGeo out of business - for it to succeed in the long term it must continue to make the software better, which is our long term goal anyways.

Quality¶

Key to OpenGeo’s success is a relentless focus on quality. Instead of chasing competitors, attempting to implement more features that we can market and sell, we work towards an ideal version of our software. A system so flexible, user friendly, and powerful that it is the natural choice for anything geospatial related. We’ve still got a long ways to go, but right now we believe we have a foundation that is more solid than anything else out there. As we grow we will dedicate developers to just continually refining and improving that foundation.

Our costs are often high due to our focus on quality. We rarely take any shortcuts when developing - we make sure that code is pushed to the lowest library level and written in the most flexible way. The only time we will code things in a less than ideal way is to prototype a concept, to make a demo of what is possible, and then we come back and build it right when we have a chance. We also employ a full time interaction designer, to ensure our user experience isn’t just an afterthought.

This focus on quality is essential to our success, since the premium that top quality affords allows us to put appropriate time in to building great open source software. The first thing that is most always cut in companies working around open source is contributions to the baseline, so we’d have to do the same if we were working in a cut rate manner. Our clients know that we will always deliver high quality code faster than anyone else, so they continue to work with us. They know that their system will be one that is supported by a wide open source community, not some custom thing that only their paid consultants will understand.

The business model for Enterprise contracts depends on having the highest quality product. The path that all open source companies have followed to success is to have technology that blows away the competition. This is relatively easy because open source is a superior development methodology. But it must be higher quality at every level, to achieve ubiquity. Once ubiquity is achieved you can count on a small percentage of organizations being risk averse and valuing their time very highly. It is thus a no brainer for them to pay the experts to support their system. But the key to getting there is to get the software used everywhere, and the only way to do that is to build the best software possible.