Our applications are still free for anyone to download and install. This is important because of our desire to remain true to the idea that everyone on the net, regardless of income should have equal access to the basic technologies of websites. Providing software at no price also helped us continue to maintain and expand our market share.
Because our applications are open source, clients are welcome to download applications for free and follow the installation documentation in order to get them working. However, the fact that the software could be obtained at no cost, did not mean that we did not "sell" products.
Although we are proud of the user-friendliness of our documentation, clients often find that installation and customization might take some time, especially if they have limited programming experience. The fact of the matter is that Web Applications are not exactly the easiest things to implement. In the end, clients must ask themselves, "Do I want to spend my extra time learning to program or selling my products?
And that answer means a sale for us. Besides our license and contract products, like GNU, we also have developed a host of support services such as training, tech support, turnkey installations and custom app development.
Economic logic favors outsourcing Virtual enterprises can spring up overnight as networks of free agents come together for a single project. Costs and risks are distributed over an entire network Nothing could be more flexible - ready to turn on a dime, to grab any new opportunity.
Originally, the intent of the DevNet was humble. However, the evolution of the DevNet over the life of the company has been astounding. Originally, based upon what we knew about the market, we realized that once we seriously went forward with eXtropia, we would get far too many requests for custom app development and turnkey projects, in too rapid a succession, to possibly keep up with.
At the time eXtropia first opened it's doors, we received an average of seven requests for contracts per week. During the first quarter of eXtropia's life, that number scaled to 20 per week.
In the second quarter, we expect to see that scaling continue on its non-linear track. The Developers Network. The DevNet was our solution. At the outset, the DevNet worked like this. Developers were offered the chance via a web page advertisement to apply for positions in the network. As applications came in, we reviewed the qualifications of applicants, browsed code or reference sites, and initiated email chats with candidates to get a feel for their personalities in many cases of course, we already had known the applicants because they had been part of the eXtropia community for a long time.
If the applicant met our criteria, we would offer them a position in the DevNet. Our criteria for accepting applicants went as follows: The applicant must have an exceptional ability to code or customize web applications. The applicant must be a pleasure to work with in a distributed group programming environment. The applicant should be patient, dependable, considerate, careful, trusting, trustable, humble and not prone to jumping to conclusions or into flame wars.
The applicant must be serious about freelance web consulting. Preferably, the applicant should have his or her own freelance web programming company rather than doing web programming on the side. The applicants livelihood should depend on providing quality, full-time services to their clients. The applicant should introduce diversity into the group. For example, as the membership expands, applicants with supplementary skills should be chosen over equally skilled applicants with duplicate skills.
Also, a mix of races, genders, ages, and nationalities should be held as an ideal even if it means, for example, letting in an ace student with little real-world coding experience over someone with more experience but with duplicate lifestyles to other DevNet members.
If the developer accepted our invitation, they would pay a membership fee, and would then be accepted as a DevNet member. So what does a DevNet member get for their membership fee? Developers who joined the DevNet received a host of services such as training, free software and support, and easy access to us.
However, the primary benefit of DevNet membership focussed around a job referral system and a members-only discussion forum. Currently, DevNet members count on an average of 1 contract per week.
As we said, aside from the job referral program, developers had the opportunity to participate in three members-only online discussion forums. The forums included: The Jobs Forum: On this forum, new jobs are assigned to members, and members can comment on the progress of current contracts. The Tech Forum: On this forum, developers ask each other technical questions about projects, bug fixes, or just any old thing of interest.
In this forum, the developers can work together so that anyone can ask for free technology help from the network and get quick, reliable advice. The beauty of this is that members can rely on the core capabilities of other members. Why should one learn MSQL for example, when we have someone with that skill already in the group. Each member becomes a programmer with the skill set of the entire Network at their disposal.
And clients know that. Clients know that they are hiring more than a single developer but an entire network. We also harness the collective knowledge of the network through our tutorial series.
In short, every two to three weeks a developer is responsible for preparing a short online tutorial on some web-based technology for presentation to the DevNet membership. The developer is also responsible for answering follow-up questions.
Because we have capped our membership at 20 until the summer of , each developer only has to prepare one tutorial per year, but has the benefit of learning a new topic every few weeks. The Open Forum: On this forum, members discuss miscellaneous issues such as small business tax, freelance consultant pricing strategies, liability law, or just talk about their families, lives, and interests. However, no less important than the job referrals and discussion fora, were the less obvious benefits to members Members gained the opportunity to work with "the best" web developers on the web.
The Developer Network has a reputation. They are worth every penny" This reputation benefits everyone involved. As in real estate, if you get all the big names to setup shop on a strip of land, the value of everybody's investment goes up quickly.
The network also allows us to organize "commando programming" teams for "LARGE" corporate web site work that none of the developers could get or manage individually, but which pay a much greater amount of money. Further, projects can pop up anywhere in the US for now and we can be relatively sure that we will be able to find a DevNet member on the ground. Also web design firms can subcontract us out.
This is an important feature of the DevNet. Just as each developer creates a link in our private network, so does the network as a whole create a link on a greater network of web professionals. Many web design firms have chosen to work with us to expand their capabilities. They can focus on honing their design talents knowing that they can depend on us for outsourced backend development. Members also gain a sense of security and team which can be very important to someone who has struck out on their own into the world of self-employed-dom.
Further, members have the benefit of seeing the new technology first. To a large part, we rely on the DevNet members to be our first line of beta testers! DevNet members gladly provide beta testing services for free because they will be the ones called upon to customize and install new libraries and applications.
And because there is some competition out there, they have a special interest in getting to know the technology before anyone else does. Finally, DevNet members have an especially profound impact on the direction we take with our company and products. Through their comments and discussions, we glean many important insights into how to better design our products.
Though we are careful to be very sensitive to the outside world, because of their proximity, the voices of the DevNet members are always the loudest. What We Have Learned. As we write this study, we are approaching the end of the first quarter of the existence of eXtropia. However, though only a short time has passed, we have learned a great deal. Granted, we as an engineering-based management team have learned all sorts of things about sales, marketing, management, finance, and law.
Starting a software business has surprisingly little to do with creating software. However, more interestingly, we have learned a great deal about how to run our own brand of open source software.
Some of these things will be very useful to other companies in our situation. So to conclude this document, we would like to distill some of the knowledge we have gained. It is all about trust. Probably the most important lesson that we learned was that in a distributed network, like an open source community, or a decentralized network or developers, trust is central to all else.
Trust is essential because control is impossible. What do we mean by this? Well, the first thing to understand about networks is that they are anarchistic, decentralized, lawless, and shapeless creatures. In a true network, there is absolutely no central authority which dictates communal direction. There is no structural basis upon which to form consensus.
No laws, no leaders, no police force. As in the case of the Internet, order in a true network must emerge from nothing but the interaction of fully independent network nodes people or other networks in our case.
As the science of complexity shows, emergence of order from nothing is possible, but sometimes counter intuitive. Consider a beehive. The marvel is that more is different. To generate a colony organism from a bug organism requires only that the bugs be multiplied so that there are many, many more of them, and that they communicate with each other. At some stage the level of complexity reaches a point where new categories like 'colony' can emerge from simple categories like 'bug'.
Thus, there is nothing to be found in a beehive that is not submerged in a bee. And yet you can search a bee forever with cyclotron and fluoroscope, and you will never find the hive.
The hive comes about as a property of the system created by many bees in a network. The emergence of the hive from a jumble of bees is Extropy. Networks that work, like beehives, for all their lack of authority, are not at all chaotic. However, their order is self-emergent rather than dictated by law or force. I say networks "that work", because not all networks succeed.
Extropy is not at all guaranteed by collecting a horde of independent nodes and allowing them to communicate. It is true that extropy depends on the free flow of information and the uninhibited interaction between the nodes.
But it is also true that this in turn, depends on trust. Each node must be able to trust other nodes in the network or they will not interact or communicate. Nodes must be sure that every other node is working for the benefit of the whole by facilitating the network, and not simply leeching.
Of course, "working for the benefit of the whole" is not some simplistic stereotypical call for a Marxist utopia of self-negation. Nodes can trust each other and work for the greater good of the collective while at the same time pursuing their own self interest. This is because the network's collective strength can be leveraged by each node like when a developer doesn't have to learn MSQL.
In the post-industrial economy marked by hyper-speed, hyper-specialization, and hyper-customization, serving one's network is the smartest selfish strategy. Selfish actions, so long as they do not threaten the collective, are good and to be rewarded. After all, it is in the best interest of all the nodes to allow and to facilitate the growth of any other node in the network. As we said before, the value of any member's network membership increases as any other network member gains prestige.
It is only when network members are forced into a prisoner's dilemma that emergence of the network is threatened. The minute you cannot trust your back to the other network members is the minute the network stops generating a value greater than the sum of its parts.
That is, there is a right way to be selfish in a network and a wrong way. Network economies can be far more creative and lucrative than shortsighted selfishness-based models, but shortsighted nodes can certainly ruin the network by disrupting the ties of trust.
The trick in creating the self-emergent network is to structure it such that "good" selfish behavior and node interaction is supported and "bad" selfish behavior is punished. Trust in Job Assignment. This rule was made clear to us early on when we were figuring out how to assign jobs to the developers in the network. We thought, somewhat idealistically, that jobs would somehow emergently, magically distribute themselves to the right developers.
Members would decide amongst themselves who would do the job. Unfortunately, we did not get the desired results. No self-emergence occurred. Instead, this free-for-all style of job assignment turned out to undermine trust within the network. For one, different developers were online with greater frequency than others. Also, each developer had different personal style. Some were far more aggressive than others. This position has led some to claim that the GPL extends to proprietary code compiled with unmodified GPL code; and recently, creative new litigation models asserting the rights of licensees have been advanced by compliance trolls in Germany and the USA.
Once these risks are understood, companies are quick to appreciate the importance of a cohesive open source software strategy, coupled with a comprehensive compliance and risk mitigation program. However, few companies have an internal resource who understands the complexities of open source software issues.
The following case studies of actual client work illustrate the scope of our open source capabilities:. As is typical of an open source code scan across all industries developing software, thousands of instances of unmonitored open source software were discovered, including many instances of code with high security vulnerabilities according to the National Vulnerability Database.
An internal team at Fin Co was put together to remediate the situation. As internal legal resources were limited, Fin Co considered bringing in an external legal resource. Frank focused on critical topics such as trusted open source repositories, security issues caused by vulnerabilities in software code, and infringement risks related to non-compliance and the recent rise of compliance trolls.
Frank then guided Fin Co. With the support of an automated compliance program provided by a third party, Fin Co. Monitor your channels for particularly active end-users. Typically, if someone is spending a lot of time on your mailing list, IRC channel, or forums seeking answers to their questions, then it is likely they have a large stake in ensuring your project works in their environment. Many times, that means a production-level deployment, which is what you are seeking.
Monitor your channels for new end-users. If you see anyone new in your channels, check their domain name and use that to learn more about where they might be deploying your project. Introduce yourself. Reach out to these users. Find out why they are using your software, see if they need specific assistance, and if they do try to coordinate their getting in touch with the right person on your team to help them.
Along the way, you can learn more about the type of deployment they have personal or business. Invite them to participate. The invitation should include:. This last point is important. When a journalist writes an article about a person or company, they rarely—if ever—grant final review access to the article. This keeps the article from becoming little more than a positive public relations piece instead of a balanced piece of work.
For a case study, however, this kind of review is not a problem. Indeed, it can help assuage any nervousness the case study subject might have about discussing too much about their organization's infrastructure.
Once the invitation is accepted, be sure to follow up with the interview subject and work with them to arrange an interview time that is convenient to their schedule. They are doing you a great service by agreeing to participate, and they should be treated with courtesy.
When you schedule the interview, 30 minutes should be fine. Try, if you can, to schedule 30 minutes, but have space on the back end in case it goes long. Video chats are best, if it can be arranged. Skype, Google Hangouts, BlueJeans are all recommended. Phone calls also work well, though are more inclined for interruptions in the conversation. If you are a great note taker, then do that. But for most people, have a recording made of the conversation. Most smart phones have recording apps.
You're not looking for high fidelity, just something to go back and review quotes and important points in the conversation.
0コメント