Consider that Free and open source software models, as opposed to the traditional proprietary models, may afford end user organizations a direct line to getting the software that is most well-adapted to their specific needs and at a lower cost. If that tends to be the case, one should ask how it is that the groups providing Free and open source enterprise software model their businesses to support that notion.
TEC talked about business models with three organizations centered around Free and open source enterprise software. In the first part we talk with David E. Jones, project leader of the Open For Business (OFBiz) project (www.ofbiz.org). OFBiz is an e-commerce and enterprise automation (ERP, CRM, EAM, etc.) solution developed through open source methodologies. The second part focuses on a discussion with Edward L. Lilly, Jr., CEO of OpenMFG (www.openmfg.com), an ERP solution geared toward small and medium-sized manufacturers. While OpenMFG itself does not strictly fit the definition of Free or open source software, it is based on open source platforms such as Linux and the PostgreSQL database. Finally, we talk with Jorg Janke, founder and project leader of the Compiere (www.compiere.org) ERP and CRM solution. Compiere, like OFBiz, is an open source project. Compiere runs on a combination of open source and proprietary platforms.
This concludes Part One of a three-part series.
Part Two is based on a discussion with the CEO of OpenMFG, Edward L. Lilly, Jr. and Part Three is based on a discussion with the Compiere project leader, Jorg Janke.
Part One—OFBiz
The Open For Business (OFBiz) project began in May 2001, and project leaders, David Jones and Andy Zeneski, have based their consulting business around it for the last several years. OFBiz is licensed under the MIT Open Source license, which is approved by the Open Source Initiative (OSI) (www.opensource.org). The development, like many open source projects, centers around a core project with the leaders offering services based on that project. David describes it thus:
David Jones: One of the ideas behind the OFBiz group was to be a coordinator of the commercial players and others using Open For Business. The core of the whole thing is OFBiz, the open source project itself. . . . Andy and I run Undersun Consulting, which is mainly how we do business now. In general, the model with OFBiz is there is the open source project at the center, with all sorts of different users floating around it at different distances away from the project, depending on how involved they are with the project itself. Mostly, in dealing with the open source project we primarily deal with service providers or more technical end users so Undersun consulting . . . falls under a similar category, we're a service provider that works based on OFBiz. Andy and I as individuals also happen to be the people running the open source project, which is how it's organized.
TEC: An important concept benefiting open source projects is that the work completed for clients directly improves and extends the capabilities of the project as a whole. The expertise of the open source project leaders goes into their consulting, training, and implementation services, which makes their know-how a valuable commodity.
DJ: The main types of services that we provide are helping people to get going with OFBiz. If there is a specific project we'll often get involved with analysis, design, some custom implementation. We prefer to work with the actual end user, who may not have a technical team in house, then we'll partner with someone that can offer that technical team to them. A service provider on an on-going basis. That partner will then generally participate in some of the development and handle all of the deployment and then when necessary we will, very frequently train the partners and provide services to get them going.
TEC: Like any consulting firm, you can and do sometimes take on projects via OFBiz service providers but there are pitfalls in working through a provider. How can direct access to you, as project leader, bear an advantage for the client?
DJ: We work with a lot of people who say we are providing a service by acting as a management buffer between you and the client. That's a nice thought but it doesn't work that way in the real world because generally the people acting as a management buffer don't understand the software or the client's needs or the business processes—even when the business processes are standard and normal in the industry. So communicating with them and training the management people, trying to figure out what the client meant by what this management person is saying, those things take an incredible amount of time, often leading to miscommunication, which greatly increases risk.. . .
We have been through a few contracts like this, and one in particular comes to mind. We got in there to talk to the client directly, do some analysis with them, this was an e-commerce site, so going over every aspect of an e-commerce site. Everything from doing credit card processing, tax calculations, catalog organization, how searches would be done, how promotions would be done, all these sorts of things, integration with their systems. Going over all these things with them and finding out that the stuff we originally did [based on the partner's communication] was probably about 20 percent of what they actually needed. It was significantly different from what the client expected at first and also from what the partner that we were working with expected at first.
If I had known how much money they [the client] were paying it would be hard to recommend them [the partner] as a good option just because they [the partner] really had no OFBiz expertise. . . . It took them some time to ramp up, which ended up costing the client money too because of the delay for the deployment of the site. That's probably the number one risk we deal with. Problems with project management when we're not involved in it.
TEC: Do those difficulties not exist in a proprietary software environment? Or is it similar?
DJ: . . . with proprietary software it's almost more of a problem. It's a universal problem and doing things in an open source way is one solution, or a potential solution to that problem. Just because it's open source doesn't mean it solves that problem but it allows you to operate in certain ways that most commercial circumstances don't allow you to operate in.
TEC: How does the fact that you're operating as an open source project change the circumstances?
DJ: There are certain services that really do require some sort of a fairly significant company providing twenty-four hour support for a live site . . . But if you are looking for expertise around software and business process analysis, dealing with a specialist directly is generally far more successful than trying to go through someone else that is using that specialist as a resource.
TEC: You mentioned twenty-four hour support, that's something a business could set up around for example, OFBiz.
DJ: Exactly, we have actually started offering something like this, where we work directly with the client and manage the hosting through a partner on behalf of the client. This allows us to stay involved with the client and help them add new features over time and stay up-to-date with the open source project. A number of our clients have asked us about these sorts of services because they have had a hard time doing it themselves, or have had a hard time working with partners. We are still offering services helping people do hosting and long-term maintenance and support themselves, but in certain circumstances we are also now offering this to clients.
TEC: Free and open source projects can have many people contributing, how do you decide the significance or choose from the types of feedback you receive to change, add, or customize areas of the OFBiz project?
DJ: If we're going to make changes or additions for somebody, generally it will be a big contract, or something we're interested in doing. Their requests in the open source project could sit there forever unless we get a contract, someone is interested in doing it, or we want to move the project in a new direction that just happens to cover that. There are a lot of specific features that people ask for that we don't put any effort into. Sometimes they will contribute it to the project and other people that are interested in it will develop it possibly collaborating with the person that requested it and then contribute back to the project. In that way, the open source project especially over the last eight to ten months has really become a much more active community with more people contributing code, especially on the applications level. We had quite a few contributions on the framework level before. . . . If someone comes along with a need and they don't have any funding for it, it's basically throw it out to the community and see what sort of resource sharing can happen with common interests.
TEC: How do people find out about OFBiz. You mentioned you don't have much need for marketing or salespeople. Yet you said that within the last eight months, the project has been growing a fair amount—more companies are interested.
DJ: A lot of people will say, "I was looking for a specific piece of functionality and I was reading about in this forum, or at this site, or I was looking at this open source project and they mentioned OFBiz, so I looked at OFBiz." Then it basically flows out from there. A lot of people tend to come looking for very specific things, then find OFBiz as a more generic solution to their needs. That seems to be the more common path into the project.
TEC: What is it that helps garner interest in open source projects like OFBiz? Why do companies become interested in the software?
DJ: It's hard to say exactly what would be a lynchpin or a keystone type of thing that would really make or break the game. There are a lot of things that I think would significantly help open source projects. If people are considering developing their own software, software for internal use, or perhaps a product they sell to customers, they will be much more likely to take a look at OFBiz. There is a kind of inherent risk to an open source project that is run by a couple guys; the community is reasonably large . . . and the functionality, especially in certain areas, is pretty mature, but trusting it, even being willing to take a look at it, is not very common for a lot of companies. I think the trust factor is a big deal, and of course part of that is funding for the project, if there was more funding for the project that would help take care of the trust.
One of those ways would be to complete certain areas of the project that we haven't really been able to make much progress on through contract work, like the general ledger piece of the accounting system. That is something that I think if it was there, people would be much more interested in looking at the package as a whole and taking a risk on it. . . . For Andy and I in our consulting business, the more people using the open source project, the better chance we have of finding clients because people, if they have money for a project they are always interested in getting help for it. We get quite a few people along those lines. Sometimes we just help them a little bit and they go from there, sometimes we get significantly involved in the project.
TEC: To get the trust, you need to have certain types of functionality that are crucial, and the difficulty is funding development because you cannot always depend on the chance that specific customers will request the type of efforts you think are required for the overall project's good. It's a catch-22.
DJ: That particular part of this, being able to fund new efforts is a little bit tricky. Early on, our operating expenses were fairly low so we didn't need much income to be able to survive, it was a lot easier to spend time developing those features without having a steady income, but as time goes that's becoming more difficult. Right now Andy and I are the main ones that do the consulting but there are various other people that we outsource work to, especially people that have contributed to the project. We try to do quite a bit of outsourcing maybe half a dozen to a dozen people and we've had far and away the best success with those that have contributed significantly to the open source project.
TEC: A lot of what gets developed outside of specific contracts must come from some company's need. Can you say more about who these people, the contributors, are? Would you say they're usually working for companies using OFBiz or else have some related contract engagement?
DJ: Generally that's the case. Like any enterprise software, it's pretty complex and so, this is true of a lot of other types of open source software, even operating systems, a word processor, or a development environment, it takes a fair amount of time to learn about it and get used to it. We hear from a lot of people who are interested in contributing to it and they'll ask for CVS commit access or ask to be a developer on the project. We generally say that's great we'd love your help, let us know when you have something and never hear from them again. The people we do hear from are generally those that have some sort of paying project to work with. That not only gives them objectives and specific things they need to learn about but they also have enough money to survive while they're doing that.
TEC: Because a lot of the functionality that gets built into OFBiz is based on different groups' projects, how do you maintain continuity with the direction of OFBiz development? What do you do to make features coalesce into your plan for the future?
DJ: We try to coordinate or manage the project. . . . Like the manufacturing module in the project right now, we spent a fair amount of time . . . just communicating with the guys working on it; talking to them about design and how it ties in with the other pieces of the project that already exist; how the data model was designed for that part for manufacturing, for instance. They basically took it from there, and there's two groups working on the manufacturing piece now.
Part of the reason there is good continuity there is because they are working on a sponsored project. If people don't have financial support for doing things, it just doesn't make it very far. Especially if it's something that's very large and complicated and involves a lot of little intricacies. . . .
TEC: If you have a client that comes to you and says they've already implemented all these OFBiz modules and they've done their own modifications and now they want you to support them, how do you deal with that?
DJ: We will work with some clients like that. Generally we try to encourage people to . . . contribute whatever they can back, so that it goes into the open source project, is maintained by the community, and as other things are added we can coordinate what is there. All of that sort of thing, so that when those updates are there, our adoption tools are more efficient to use when we update the code. If they change the older code, sometimes it takes significant effort to redo that work. We encourage people to stay close to the open source project and keep up to date with it periodically. Of course, that's in some environments, totally impossible because they don't have the resources for it. In others it's difficult but very feasible, especially for large-scale live sites, they of course have to be very careful about what they pull from the open source project. . . . We usually recommend periodic integration and system testing before they go live with a new version.
TEC: Is that something you would provide as a paid service?
DJ: Yes, sometimes we do get involved with that. We will help out with a testing plan or more frequently helping them [clients] address certain issues that come up or work with them on strategies for organizing their code, so if they do have something they've customized that has been difficult to maintain or they're trying to update and it's difficult to maintain, then we'll work with them on making that easier. We do sometimes work with migrating databases to new versions of the software. Generally with that kind of stuff, we try to stay out of it, if someone needs help and has sufficient money, we'll get involved or recommend someone to help them out.
TEC: Are there certain levels of business that your solution is more suited for? Is it going to be better for a small or medium business with a small budget or a large enterprise—does it matter?
DJ: That's something where our understanding of how that may work has changed a lot over the years. The current [business] model that seems to work best is—I've always thought there was a line between what an open source package can provide and what really has to be offered as a commercial service or product. There are many areas that OFBiz can't touch as an open source project, but if there was a commercial entity offering a service or a packaged product that was based on OFBiz, they could offer a lot more for much less money because of that.
TEC: Can you offer an example?
DJ: Maybe I'll step back from that and offer a contrasting example. There are a number of companies that use OFBiz directly and these are typically companies that have technical expertise in-house or a trusted partner that has technical expertise that wants to use OFBiz. Those seem to be the most common scenarios. So some sort of technical expertise is required to use the OFBiz project, if you don't have it in your company you need to find someone to help you. That's generally the case with commercial software because the owner or management entity of the software generally provides those services as well, but that's not the case with an open source project and there's a little difficulty a lot of people see with how that's supposed to work.
A lot of companies really need some help getting into it. With the open source project as it stands right now, a lot of the companies are technical or have a technical staff and maintain their own custom version of OFBiz. There are few groups that are trying get going with derivative works or managing a product, derivative open source work, or open source extensions to the project. Creating derivative works that are based on an open source project, I think is an area that has huge market potential. Medium and larger sized businesses can afford to pay for custom development, they can afford and often want to pay for system integration. And getting these things coordinated with how they run their businesses, with how certain people do certain things, and all sorts of stuff that goes on in those businesses, but for smaller businesses and even a lot of medium-sized businesses that don't have any sort of core technology focus, they really can't operate in that way; they can't afford to, and it's not interesting to them. So creating software that is a derivative work basically addresses the need for that [the small and medium-sized business] community by providing them a commercial package that does what they need.
The great thing about open source based commercial derivative works is that you can pick a very particular target market and economically develop for that market. There may not be a massive revenue potential in that specific market but you can pick a small enough market, meet their needs very well, and tap that revenue stream sufficiently to make a profit over what it costs you to extend the open source project. If you were to develop everything from scratch, chances are that wouldn't happen. A lot of companies that do try to do it from scratch, do try to use generic tools that are on the market like Access or FoxPro. But they don't generally get to start with very much, they generally have to start from the ground up as far as the business logic and data structures and such go. So given a starting point like OFBiz. . . the goal of the current operating mode is basically to expand the open source project horizontally, to the point where we can then extend it or create the commercial derivative works to get into specific markets. It appears there's huge potential if the needs for these companies can be better addressed for a reasonable price then they'll be very willing to pay. They're already paying generally for a lot of software that doesn't very well meet their needs, it's very generic, very limited, not very flexible, even if they wanted to customize something that was critical to their business it would cost so much that it's not even worth considering, so we think there's huge potential for that with open source.
TEC: What would some of those top markets be from your viewpoint?
DJ: The easiest ones for us to look at right now are probably retail oriented. We could even do packages for specific types of retail stores. This is already done to some extent; we could fairly easily do a package for a clothing store or a shoe store or a more general merchandising store. Those are all fairly similar technically except there may be certain customizations or certain things that are inherent to those industries to get their books set up for the industry. You have special tools to manage their type of product, there is so much different product information that you need to manage, often that is incredibly complex, if you take a specific type of product that a retailer is selling then you can customize their needs.
Now a company like Wal-Mart sells such a wide variety of products that they might develop a bunch of special tools for specific types of products, but they don't really need a package that is sold like this. They have plenty to budget and this is what they do right now, they just develop their own stuff when they need it. For smaller businesses that's not an option. There are lots of things to be done in retail where things are generic but different businesses really do have different needs. You have companies that sell lots of small ticket items and you have companies that sell a few large ticket items and those companies need to keep good track of their customers, try and win repeat business, it's much more important for higher-ticket items to keep track of specific things people have purchased. You know, for providing support and so forth. The needs of different retailers can vary a lot. If you expand the retail industry to include the rental industry, that flows out even more. There are all sorts of things that people rent, from videos to trucks that have very different tracking needs. Basically if we can pick these niche industries that would be a sub-industry of the retail industry or manufacturing industry, then we can create solutions that do exactly what they need. There isn't a lot of hassle, it's not expensive to install and run, you get help with it pretty easily, eventually if you want to customize it for specific needs that are not necessarily common in their industry and some distinguishing business practices, then we can work with them to customize it or they have options of hundreds of other people in the open source community that can help with that as well.
TEC: Even if they go with other peoples' services that can still benefit you because eventually those changes can make it back into the project, right?
DJ: Right. That's the thing, if we were doing it of course, we'd take as much as was generic and put it in the open source project and then maybe just the custom user interfaces, certain custom business process supporting logic, would remain part of the commercial part of the software. Naturally, if we can offer the same functionality to our clients and have twice as much of it be in the open source project then it costs us half as much to do and decreasing cost is a great way to increase your profit margin.
A lot of the contracts we work on are e-commerce. That's our real bread and butter, and one of the reasons is that people are used to paying for custom development with e-commerce because there's so many specific little things they want to do.
SOURCE :http://www.technologyevaluation.com/research/articles/tec-talks-to-the-open-for-business-projectfree-and-open-source-software-business-modelspart-one-ofbiz-17490/
TEC talked about business models with three organizations centered around Free and open source enterprise software. In the first part we talk with David E. Jones, project leader of the Open For Business (OFBiz) project (www.ofbiz.org). OFBiz is an e-commerce and enterprise automation (ERP, CRM, EAM, etc.) solution developed through open source methodologies. The second part focuses on a discussion with Edward L. Lilly, Jr., CEO of OpenMFG (www.openmfg.com), an ERP solution geared toward small and medium-sized manufacturers. While OpenMFG itself does not strictly fit the definition of Free or open source software, it is based on open source platforms such as Linux and the PostgreSQL database. Finally, we talk with Jorg Janke, founder and project leader of the Compiere (www.compiere.org) ERP and CRM solution. Compiere, like OFBiz, is an open source project. Compiere runs on a combination of open source and proprietary platforms.
This concludes Part One of a three-part series.
Part Two is based on a discussion with the CEO of OpenMFG, Edward L. Lilly, Jr. and Part Three is based on a discussion with the Compiere project leader, Jorg Janke.
Part One—OFBiz
The Open For Business (OFBiz) project began in May 2001, and project leaders, David Jones and Andy Zeneski, have based their consulting business around it for the last several years. OFBiz is licensed under the MIT Open Source license, which is approved by the Open Source Initiative (OSI) (www.opensource.org). The development, like many open source projects, centers around a core project with the leaders offering services based on that project. David describes it thus:
David Jones: One of the ideas behind the OFBiz group was to be a coordinator of the commercial players and others using Open For Business. The core of the whole thing is OFBiz, the open source project itself. . . . Andy and I run Undersun Consulting, which is mainly how we do business now. In general, the model with OFBiz is there is the open source project at the center, with all sorts of different users floating around it at different distances away from the project, depending on how involved they are with the project itself. Mostly, in dealing with the open source project we primarily deal with service providers or more technical end users so Undersun consulting . . . falls under a similar category, we're a service provider that works based on OFBiz. Andy and I as individuals also happen to be the people running the open source project, which is how it's organized.
TEC: An important concept benefiting open source projects is that the work completed for clients directly improves and extends the capabilities of the project as a whole. The expertise of the open source project leaders goes into their consulting, training, and implementation services, which makes their know-how a valuable commodity.
DJ: The main types of services that we provide are helping people to get going with OFBiz. If there is a specific project we'll often get involved with analysis, design, some custom implementation. We prefer to work with the actual end user, who may not have a technical team in house, then we'll partner with someone that can offer that technical team to them. A service provider on an on-going basis. That partner will then generally participate in some of the development and handle all of the deployment and then when necessary we will, very frequently train the partners and provide services to get them going.
TEC: Like any consulting firm, you can and do sometimes take on projects via OFBiz service providers but there are pitfalls in working through a provider. How can direct access to you, as project leader, bear an advantage for the client?
DJ: We work with a lot of people who say we are providing a service by acting as a management buffer between you and the client. That's a nice thought but it doesn't work that way in the real world because generally the people acting as a management buffer don't understand the software or the client's needs or the business processes—even when the business processes are standard and normal in the industry. So communicating with them and training the management people, trying to figure out what the client meant by what this management person is saying, those things take an incredible amount of time, often leading to miscommunication, which greatly increases risk.. . .
We have been through a few contracts like this, and one in particular comes to mind. We got in there to talk to the client directly, do some analysis with them, this was an e-commerce site, so going over every aspect of an e-commerce site. Everything from doing credit card processing, tax calculations, catalog organization, how searches would be done, how promotions would be done, all these sorts of things, integration with their systems. Going over all these things with them and finding out that the stuff we originally did [based on the partner's communication] was probably about 20 percent of what they actually needed. It was significantly different from what the client expected at first and also from what the partner that we were working with expected at first.
If I had known how much money they [the client] were paying it would be hard to recommend them [the partner] as a good option just because they [the partner] really had no OFBiz expertise. . . . It took them some time to ramp up, which ended up costing the client money too because of the delay for the deployment of the site. That's probably the number one risk we deal with. Problems with project management when we're not involved in it.
TEC: Do those difficulties not exist in a proprietary software environment? Or is it similar?
DJ: . . . with proprietary software it's almost more of a problem. It's a universal problem and doing things in an open source way is one solution, or a potential solution to that problem. Just because it's open source doesn't mean it solves that problem but it allows you to operate in certain ways that most commercial circumstances don't allow you to operate in.
TEC: How does the fact that you're operating as an open source project change the circumstances?
DJ: There are certain services that really do require some sort of a fairly significant company providing twenty-four hour support for a live site . . . But if you are looking for expertise around software and business process analysis, dealing with a specialist directly is generally far more successful than trying to go through someone else that is using that specialist as a resource.
TEC: You mentioned twenty-four hour support, that's something a business could set up around for example, OFBiz.
DJ: Exactly, we have actually started offering something like this, where we work directly with the client and manage the hosting through a partner on behalf of the client. This allows us to stay involved with the client and help them add new features over time and stay up-to-date with the open source project. A number of our clients have asked us about these sorts of services because they have had a hard time doing it themselves, or have had a hard time working with partners. We are still offering services helping people do hosting and long-term maintenance and support themselves, but in certain circumstances we are also now offering this to clients.
TEC: Free and open source projects can have many people contributing, how do you decide the significance or choose from the types of feedback you receive to change, add, or customize areas of the OFBiz project?
DJ: If we're going to make changes or additions for somebody, generally it will be a big contract, or something we're interested in doing. Their requests in the open source project could sit there forever unless we get a contract, someone is interested in doing it, or we want to move the project in a new direction that just happens to cover that. There are a lot of specific features that people ask for that we don't put any effort into. Sometimes they will contribute it to the project and other people that are interested in it will develop it possibly collaborating with the person that requested it and then contribute back to the project. In that way, the open source project especially over the last eight to ten months has really become a much more active community with more people contributing code, especially on the applications level. We had quite a few contributions on the framework level before. . . . If someone comes along with a need and they don't have any funding for it, it's basically throw it out to the community and see what sort of resource sharing can happen with common interests.
TEC: How do people find out about OFBiz. You mentioned you don't have much need for marketing or salespeople. Yet you said that within the last eight months, the project has been growing a fair amount—more companies are interested.
DJ: A lot of people will say, "I was looking for a specific piece of functionality and I was reading about in this forum, or at this site, or I was looking at this open source project and they mentioned OFBiz, so I looked at OFBiz." Then it basically flows out from there. A lot of people tend to come looking for very specific things, then find OFBiz as a more generic solution to their needs. That seems to be the more common path into the project.
TEC: What is it that helps garner interest in open source projects like OFBiz? Why do companies become interested in the software?
DJ: It's hard to say exactly what would be a lynchpin or a keystone type of thing that would really make or break the game. There are a lot of things that I think would significantly help open source projects. If people are considering developing their own software, software for internal use, or perhaps a product they sell to customers, they will be much more likely to take a look at OFBiz. There is a kind of inherent risk to an open source project that is run by a couple guys; the community is reasonably large . . . and the functionality, especially in certain areas, is pretty mature, but trusting it, even being willing to take a look at it, is not very common for a lot of companies. I think the trust factor is a big deal, and of course part of that is funding for the project, if there was more funding for the project that would help take care of the trust.
One of those ways would be to complete certain areas of the project that we haven't really been able to make much progress on through contract work, like the general ledger piece of the accounting system. That is something that I think if it was there, people would be much more interested in looking at the package as a whole and taking a risk on it. . . . For Andy and I in our consulting business, the more people using the open source project, the better chance we have of finding clients because people, if they have money for a project they are always interested in getting help for it. We get quite a few people along those lines. Sometimes we just help them a little bit and they go from there, sometimes we get significantly involved in the project.
TEC: To get the trust, you need to have certain types of functionality that are crucial, and the difficulty is funding development because you cannot always depend on the chance that specific customers will request the type of efforts you think are required for the overall project's good. It's a catch-22.
DJ: That particular part of this, being able to fund new efforts is a little bit tricky. Early on, our operating expenses were fairly low so we didn't need much income to be able to survive, it was a lot easier to spend time developing those features without having a steady income, but as time goes that's becoming more difficult. Right now Andy and I are the main ones that do the consulting but there are various other people that we outsource work to, especially people that have contributed to the project. We try to do quite a bit of outsourcing maybe half a dozen to a dozen people and we've had far and away the best success with those that have contributed significantly to the open source project.
TEC: A lot of what gets developed outside of specific contracts must come from some company's need. Can you say more about who these people, the contributors, are? Would you say they're usually working for companies using OFBiz or else have some related contract engagement?
DJ: Generally that's the case. Like any enterprise software, it's pretty complex and so, this is true of a lot of other types of open source software, even operating systems, a word processor, or a development environment, it takes a fair amount of time to learn about it and get used to it. We hear from a lot of people who are interested in contributing to it and they'll ask for CVS commit access or ask to be a developer on the project. We generally say that's great we'd love your help, let us know when you have something and never hear from them again. The people we do hear from are generally those that have some sort of paying project to work with. That not only gives them objectives and specific things they need to learn about but they also have enough money to survive while they're doing that.
TEC: Because a lot of the functionality that gets built into OFBiz is based on different groups' projects, how do you maintain continuity with the direction of OFBiz development? What do you do to make features coalesce into your plan for the future?
DJ: We try to coordinate or manage the project. . . . Like the manufacturing module in the project right now, we spent a fair amount of time . . . just communicating with the guys working on it; talking to them about design and how it ties in with the other pieces of the project that already exist; how the data model was designed for that part for manufacturing, for instance. They basically took it from there, and there's two groups working on the manufacturing piece now.
Part of the reason there is good continuity there is because they are working on a sponsored project. If people don't have financial support for doing things, it just doesn't make it very far. Especially if it's something that's very large and complicated and involves a lot of little intricacies. . . .
TEC: If you have a client that comes to you and says they've already implemented all these OFBiz modules and they've done their own modifications and now they want you to support them, how do you deal with that?
DJ: We will work with some clients like that. Generally we try to encourage people to . . . contribute whatever they can back, so that it goes into the open source project, is maintained by the community, and as other things are added we can coordinate what is there. All of that sort of thing, so that when those updates are there, our adoption tools are more efficient to use when we update the code. If they change the older code, sometimes it takes significant effort to redo that work. We encourage people to stay close to the open source project and keep up to date with it periodically. Of course, that's in some environments, totally impossible because they don't have the resources for it. In others it's difficult but very feasible, especially for large-scale live sites, they of course have to be very careful about what they pull from the open source project. . . . We usually recommend periodic integration and system testing before they go live with a new version.
TEC: Is that something you would provide as a paid service?
DJ: Yes, sometimes we do get involved with that. We will help out with a testing plan or more frequently helping them [clients] address certain issues that come up or work with them on strategies for organizing their code, so if they do have something they've customized that has been difficult to maintain or they're trying to update and it's difficult to maintain, then we'll work with them on making that easier. We do sometimes work with migrating databases to new versions of the software. Generally with that kind of stuff, we try to stay out of it, if someone needs help and has sufficient money, we'll get involved or recommend someone to help them out.
TEC: Are there certain levels of business that your solution is more suited for? Is it going to be better for a small or medium business with a small budget or a large enterprise—does it matter?
DJ: That's something where our understanding of how that may work has changed a lot over the years. The current [business] model that seems to work best is—I've always thought there was a line between what an open source package can provide and what really has to be offered as a commercial service or product. There are many areas that OFBiz can't touch as an open source project, but if there was a commercial entity offering a service or a packaged product that was based on OFBiz, they could offer a lot more for much less money because of that.
TEC: Can you offer an example?
DJ: Maybe I'll step back from that and offer a contrasting example. There are a number of companies that use OFBiz directly and these are typically companies that have technical expertise in-house or a trusted partner that has technical expertise that wants to use OFBiz. Those seem to be the most common scenarios. So some sort of technical expertise is required to use the OFBiz project, if you don't have it in your company you need to find someone to help you. That's generally the case with commercial software because the owner or management entity of the software generally provides those services as well, but that's not the case with an open source project and there's a little difficulty a lot of people see with how that's supposed to work.
A lot of companies really need some help getting into it. With the open source project as it stands right now, a lot of the companies are technical or have a technical staff and maintain their own custom version of OFBiz. There are few groups that are trying get going with derivative works or managing a product, derivative open source work, or open source extensions to the project. Creating derivative works that are based on an open source project, I think is an area that has huge market potential. Medium and larger sized businesses can afford to pay for custom development, they can afford and often want to pay for system integration. And getting these things coordinated with how they run their businesses, with how certain people do certain things, and all sorts of stuff that goes on in those businesses, but for smaller businesses and even a lot of medium-sized businesses that don't have any sort of core technology focus, they really can't operate in that way; they can't afford to, and it's not interesting to them. So creating software that is a derivative work basically addresses the need for that [the small and medium-sized business] community by providing them a commercial package that does what they need.
The great thing about open source based commercial derivative works is that you can pick a very particular target market and economically develop for that market. There may not be a massive revenue potential in that specific market but you can pick a small enough market, meet their needs very well, and tap that revenue stream sufficiently to make a profit over what it costs you to extend the open source project. If you were to develop everything from scratch, chances are that wouldn't happen. A lot of companies that do try to do it from scratch, do try to use generic tools that are on the market like Access or FoxPro. But they don't generally get to start with very much, they generally have to start from the ground up as far as the business logic and data structures and such go. So given a starting point like OFBiz. . . the goal of the current operating mode is basically to expand the open source project horizontally, to the point where we can then extend it or create the commercial derivative works to get into specific markets. It appears there's huge potential if the needs for these companies can be better addressed for a reasonable price then they'll be very willing to pay. They're already paying generally for a lot of software that doesn't very well meet their needs, it's very generic, very limited, not very flexible, even if they wanted to customize something that was critical to their business it would cost so much that it's not even worth considering, so we think there's huge potential for that with open source.
TEC: What would some of those top markets be from your viewpoint?
DJ: The easiest ones for us to look at right now are probably retail oriented. We could even do packages for specific types of retail stores. This is already done to some extent; we could fairly easily do a package for a clothing store or a shoe store or a more general merchandising store. Those are all fairly similar technically except there may be certain customizations or certain things that are inherent to those industries to get their books set up for the industry. You have special tools to manage their type of product, there is so much different product information that you need to manage, often that is incredibly complex, if you take a specific type of product that a retailer is selling then you can customize their needs.
Now a company like Wal-Mart sells such a wide variety of products that they might develop a bunch of special tools for specific types of products, but they don't really need a package that is sold like this. They have plenty to budget and this is what they do right now, they just develop their own stuff when they need it. For smaller businesses that's not an option. There are lots of things to be done in retail where things are generic but different businesses really do have different needs. You have companies that sell lots of small ticket items and you have companies that sell a few large ticket items and those companies need to keep good track of their customers, try and win repeat business, it's much more important for higher-ticket items to keep track of specific things people have purchased. You know, for providing support and so forth. The needs of different retailers can vary a lot. If you expand the retail industry to include the rental industry, that flows out even more. There are all sorts of things that people rent, from videos to trucks that have very different tracking needs. Basically if we can pick these niche industries that would be a sub-industry of the retail industry or manufacturing industry, then we can create solutions that do exactly what they need. There isn't a lot of hassle, it's not expensive to install and run, you get help with it pretty easily, eventually if you want to customize it for specific needs that are not necessarily common in their industry and some distinguishing business practices, then we can work with them to customize it or they have options of hundreds of other people in the open source community that can help with that as well.
TEC: Even if they go with other peoples' services that can still benefit you because eventually those changes can make it back into the project, right?
DJ: Right. That's the thing, if we were doing it of course, we'd take as much as was generic and put it in the open source project and then maybe just the custom user interfaces, certain custom business process supporting logic, would remain part of the commercial part of the software. Naturally, if we can offer the same functionality to our clients and have twice as much of it be in the open source project then it costs us half as much to do and decreasing cost is a great way to increase your profit margin.
A lot of the contracts we work on are e-commerce. That's our real bread and butter, and one of the reasons is that people are used to paying for custom development with e-commerce because there's so many specific little things they want to do.
SOURCE :http://www.technologyevaluation.com/research/articles/tec-talks-to-the-open-for-business-projectfree-and-open-source-software-business-modelspart-one-ofbiz-17490/
No comments:
Post a Comment