Seattle:Business Models for FOSS developers and providers

From Penguin Day
Jump to: navigation, search


- Idea of the session: ways that open-source can help people run a business and how people can come together around open-source software

What folks want to get out of the session

- how to build the real infrastructure we need to make open-source projects successful, including the documentation, etc needed - how to scale operations to meet increasing demand - how can we influence the foundation community (out of scope of this conversation) - exploring models for how an organization can support the actual development of tools - Looking at a distruted support model for an open-source product

General Notes

- how to make the model work when clients cannot afford to pay the entire bill for the services - a benefit of open-source licensing is that regardless of the contractual agreement of an individual project, ownership of the development belongs to the community (not to the vendor or the client solely). This can reduce the barriers and remove the isolation and duplication of effort in the ecology. - the downside to this, is that with increased value in the toolset market, that competition will increase for the service delivery which could affect the niche and therefore the livelihood of the consultant - does the value of writing a line of code in open-source development go to zero? If so, then I need to focus on business consulting or integration of code. (response: this has always been true) - the model is different for open-source: they do not spend money on licensing but rather on customization and implementation (this means less for the vendor, and more for the consultant) - Does this mean that its good to have a product that isn't fully developed or polished? Of course not, but where does the rubber meet the road? Response: the core functionality must be delivered but often the rest is modularized and available for customization - My view as an ED, is that I hear "I got Convio and it costs $xxx". Open source tools seem free, and often it is not clear that consulting and training is going to cost $xxx. If I knew all of this, it might affect my decision. - Often the costs over time are not always clear. If you are paying $xxx per month, you are not getting $xxx/month of value. The shift in moving to an open-source model is that you are actually paying for work that is being done (not work that was done already). - Convio or Kintera, you are paying for renting and are not getting any equity. With open-source, you are building equity - Support contracts are one avenue to explore, though it seems to not be congruent with the open-source model - How is the client having a business need, they hire you to meet that business need, and they write you a check, different in proprietary and opensource tools? (Response: the client doesn't need to know its open source, we say its open source because you are not locked into a vendor, your TCO may very well be less) - The TCO may not be different over time with propr. and open-source options, but ALL the expenditure can be focused on customizing to exactly what you want and more control over what you receive - You can have value-based pricing or bill hourly, but it may not be different depending on whether or not you are implementing opensource or propr. tools (response: but it is different, b/c the license fee is eliminated) - perhaps the question is: do we convince the foundation community to support opensource software in more real ways (this was decided to be out of the scope of this conversation) - How to build cross-functional teams that cover wide geographies? An example with Asterisk: everything that is involved with configuration can be done remotely, though you may need wiring and plugging, but in lots of cases I can work with a networking person who becomes my hands and ears and the capabilities are many. - In Civic Action, sometimes we need help to deliver to clients, and the nice thing is that we can reach into the Drupal community (a well-established community), though in less well established communities it is often very difficult to find competent assistance - We realized that we had to build infrastructure and change the compensation model to involve other folks in our team, the compensation model had to change to pay on delivery - We also changed to implement a retainer with our clients, we ask them to write us a check up-front. This is a quirk of open-source b/c we are delivering openly licensed s/w that folks can use at will. - Phil: I've never been burned by a client. Response: but you don't work for political campaigns - Another option is to use a third party account where the money resides until delivery is done and payment is required (escrow account) - There is some debate over what is software and what is service. Clients want something, they want the value delivered. - I work in proprietary s/w, and my clients are quite happy to pay support contracts or maintenance fees b/c they have value delivered. It would take an involved education campaign with my clients to get them to understand - Keeping code in escrow in the proprietary world is a way to address the issues surrounding "ownership" - In my view, I wouldn't tell my clients much of anything different based on whether I was using proprietary or opensource s/w - At Civic Actions, all processes are licensed under creative commons with attribution (questionnaires for clients, proposals, contracts, etc). We hope to get contractors using our tools to submit knowledge to the point where another developer could pick up their work more effectively using the openly licensed knowledge base. Another benefit of this is that when a client is in maintenance mode, engineers do not need to support them individually, but client managers (project managers) can support them and ANY engineer can be brought in when a problem arises. - One challenge: how to cover the costs of all the up-front work that has to be done until the proposal is written? - A collaborative development model can work really well, the challenge is putting together the cross-functional teams necessary - It sounds like the open-source space is starting to mature, the "lone wolves" are no longer the only folks in the space, and a more sophisticated model is emerging that involves more collaboration. It sounds like intermediaries are playing an increasingly important role to put the cross-functional teams together - Open source is often accused of having a lack of strategic knowledge, but this is changing - We can make an investment in training folks in opensource, there is less risk, b/c we may end up working with them on another contract or project - I see website development vs. desktop application development as different. The tools you use to build the client's websites are open, but the client's websites themselves are not. Response: actually, we make the templates available (example: mayoral elections in California and Utah - a customer paid $7500 for customization, another client was able to use it in 90 minutes at no cost, then we could focus on customizing for them - Include a fee for the cost of returning development into the community - Putting a plan together to support a module you are distributing (b/c its an insurance policy), which ensures it will be future version compatible - open soruce culture plays a role also - People typically go to the original developer to get customizations as they feel they will do better work, faster and cheaper

what folks want to get out of the session

- what are the infrastructure tools you need to have in place to work with (this was stopped short and digressed into a general conversation)

take aways/follow-ups

- ask the industry how they transitioned from being a proprietary, closed operation to an open operation and what the model looked like (a dip in income during the transition but an increase over time?) - Compensation structures - Building effective cross-functional teams by scaling up - Get a plan together for supporting a module you are distributing

other resources has been thinking about ourr business model and models for open source coopetition. I posted this "triolog" with Henri Poole and MIke Gifford my conversations with Mike and Phillip smith led to the Drupal Guild and more content on the drupal guild here