text:
tag:blogger.com,1999:blog-58168422057277216942014-10-06T22:33:12.369-07:00Open Source Business and Open For BusinessOpen Source Business IS Open For BusinessDavid Joneshttps://firstname.lastname@example.com:blogger.com,1999:blog-5816842205727721694.post-39011213156443043452014-09-23T21:13:00.001-07:002014-09-23T21:56:36.660-07:00Making Apps with Moqui - Book Now AvailableMy latest book is now available on Amazon.com:

http://www.amazon.com/Making-Apps-Moqui-Enterprise-Applications/dp/0692267050/

Making Apps with Moqui is the official documentation for Moqui Framework and includes a comprehensive summary of Mantle Business Artifacts. Starting with basic concepts and a tutorial to try things rights away, it builds to complete examples of end-to-end business processes including procure to pay, order to cash, and work plan to cash.

 The framework topics cover data and service tier tools, user and system interfaces, security, and performance. With dozens of diagrams and screen shots, and thousands of lines of code and configuration examples, this book gives you ideas of what you can do with Moqui Framework and shows you how too. This includes things as simple as defining your data model with entities to more advanced things like building hierarchical data documents based on entity data and feeding them to other systems or indexing and searching the documents through simple configuration.

 Learn how to easily build remote and local services that handle validation, security, transaction management, and much more. Build screens quickly with a wide variety of dynamic widgets and forms styled any way you wish, or even define your own widgets to use consistently across your applications. Handle large scale and milt-tenant systems. Track your application use and performance. Implicitly handle multiple languages, currencies and other localization details. Control access to resources across all tiers through flexible authc and authz configuration.

Written by the founder of Moqui and Mantle, and an enterprise application architect with 15 years of open source and commercial experience, this book provides the most accurate and useful information available for building modern enterprise applications with some of the best open source tools and technologies.

NOTE: this book is also available for free download from http://www.moqui.org.

David Joneshttps://firstname.lastname@example.com:blogger.com,1999:blog-5816842205727721694.post-45591695998563373412014-06-19T10:02:00.000-07:002014-06-19T10:02:27.981-07:00Why I Work Without Pay on Free Software: Flow and Autotelic Creative Work
An Unexpected Experience of Flow

It was a hot day and I was sweaty from walking off the tension of a meeting that hadn't gone well. My thoughts at the beginning of the walk were scattered and disorganized, running through random details of the troubled project I had recently stepped up to manage. The effort to evaluate the project was bringing in more bad news every day. Complex issues and insufficient support for off-shore developers caused compounding delays in delivery. The project was expensive and critical to the future success and value of the organization. Pressure was high. By the end of the walk I remembered that none of these were new or unique problems, and I knew a few possible ways to address each one. I was still new in the position so while pressure overall was high I still had some time to get the project on a better course.

Feeling more calm I sat down to review the messages that had come in through the night and check on the status of the few dozen highest priority tasks. My mind jumped all over as I scanned through messages and tasks to get an idea of what was stuck and needed to be clarified and delegated. I felt stressed and scattered as I worked to wrap my head around it all. For so many of the blocked tasks I felt frustrated with no obvious answer of who to delegate them to. With so many of the issues no obvious solution came to mind.

Eventually I had scanned through all of them and sat back to consider the most important priorities of the project. I started to feel more relaxed and saw the big picture made up of all these little parts. I suddenly knew which stuck task to address first, just who to delegate it to, and what to write about how to approach the task. That done I jumped to the next task that a solution came to mind for, then to a message where a good answer to the question suddenly became clear.

Some time later I looked at the clock on my laptop and was surprised to see that almost two hours had passed. I didn't remember hearing any of the noise in the busy office, even though I was in an open cubicle. I had been interrupted a few times by people stopping by, but even those conversations seemed to fit in fine with what I was working on, and a couple even allowed me to address email messages in person instead of by written reply. I felt content and satisfied, even happy. I was no longer focused and the answers were no longer flowing, but it was okay. My mind felt somewhat empty. I sat for a moment and spaced out, and it felt nice.

As I got up to see who was interested in heading out for lunch I realized I had just experienced a deep flow. I was surprised because the conditions for it were so different from the quiet, focused, unpaid free software development work where I usually experience flow. This wasn't development work breaking down details of a single well defined goal, and not even a type of work that I particularly enjoy. It wasn't something I chose to do for its own sake, just something that had to be done. Still, the goal of the effort was clear as was the general purpose that the goal fit into. It wasn't a purpose I cared about deeply for its own sake, it was a paid effort, but the purpose was clear and I was part of making it happen. There wasn't a single task to focus on, and I didn't get to choose the tasks, but I did have flexibility over the order in which to handle the tasks. I also had control over how to handle each one, and at this point had a good enough knowledge of the project and the team so that along with general experience the challenge at hand was fairly level with my ability.

Not only did I get through far more in the morning than I had anticipated, and had felt stress about not staying on top of, but my tense and frustrating morning had turned into a pleasant and fulfilling experience. I was full of energy, ready to enjoy a lunch with colleagues, and well prepared to get through the many hours of planned meetings and moving along important objectives that remained in the day. I marveled at the power of flow. I mused over the wide variety of work that could be autotelic, that could be enjoyable and rewarding on its own enough to be intrinsically motivating and not just as part of a bigger external purpose or for extrinsic motivations.

My Free Software Based Career

In 2001 I started The Open For Business Project, now Apache OFBiz, a suite of ERP, CRM, and eCommerce applications (http://ofbiz.apache.org). Between then and 2010 I worked around 8,000 hours on it without pay. I then started a series of new free software projects that are a redesign and fresh implementation of a scope similar to OFBiz: Moqui Framework, Mantle Business Artifacts, and various other projects based on them (http://www.moqui.org). I have worked around 2,500 hours without pay on these projects, and anticipate thousands more.

Why would any sane person do such a thing? Setting aside the question of sanity, what about the whole issue of earning income for personal needs, family obligations and funding ventures? On top of all that I am a normal person with a wide variety of interests that require time and money such as off-grid living, exploring the wilderness on foot and motorcycle, constant reading and learning, meditation and mindful living, health and fitness, and even a little romance here and there.

When I started OFBiz my main motivation was to create something that filled a need I had seen in the two failed startups I had just worked for, and do so in a way that I could build a long-term career on it. Building commercial software does not qualify because if you part ways or the company goes under you can no longer effectively leverage the software you worked on in future contracts or business ventures. It is great to be paid to build something, but even better to build something that you can continue to use and improve no matter where you are working, or if you are working (for money).

These free software projects have been a great foundation for a career in enterprise software consulting. I have worked for some of the largest companies in the world, for fascinating and innovative startups, and everything in between. I have experienced business and culture many corners of North and Central America, Europe, and Asia. I have enjoyed a high level of independence and a good amount of work coming in through the free software projects, so I never really had to market myself in other ways. I get to work on the design and development of software that I am good at and enjoy, and not so much on the marketing and sales that I am neither good at nor enjoy very much, and yet still work as an independent consultant or in various incarnations of consulting organizations that I have tried over the years.

While these extrinsic motivators are great they are more of a side-effect and what it all comes down to is drive, to intrinsic motivation. This is not just something that drives me to work the long hours necessary for large and complex software projects, but is something that makes the work rewarding for its own sake. It is a powerful thing to experience the flow and satisfaction that comes from the combination of autonomy (of time, task, and team), challenge that often goes just beyond my existing skill and knowledge, and fulfillment in pursuing a greater purpose. These three are key to experiencing flow in creative efforts.

Doing creative work in a state of flow is both rewarding (pleasurable and satisfying) and nearly always results in effective, efficient work with excellent results. Working on free software projects benefits from a natural sense of purpose, frequent satisfying challenges, and a high level of autonomy. The experience of flow on free software or other more autonomous creative work carries over into day to day necessary work as well. People learn to get into flow and leverage it for improved results and satisfaction. This is one of the reasons why organizations allowing 20% time to work on whatever employees want see greater innovation and productivity overall.

So why do I work on free software? It is a foundation for a career, but more importantly it is something that I can tap frequently for the experience of flow. On the income side of things, it is easier to get into flow doing paid work based on the free software projects that I work on and in the ever growing set of business contexts that I am familiar with. This carries over into paid work and makes it easier for me to get into flow on those efforts. I pursue flow in other experiences like riding a motorcycle in the wilderness, adjusting speed and choosing terrain to challenge and engage myself just beyond my comfort zone (which varies day to day, and even during a ride), but the experience of flow in the context of a larger purpose and creative effort is far more satisfying and rewarding.

Books and Background

The best book for an introduction to the topic of intrinsic motivation and flow is:

Drive: The Surprising Truth About What Motivates Us by Daniel H. Pink
http://www.amazon.com/Drive-Surprising-Truth-About-Motivates/dp/1594484805

On an interesting side note this book features various stories about Atlassian, the company behind Jira, Confluence, and other software commonly used in projects based on OFBiz, and many software development projects in general these days. Atlassian has a policy of 20% time to work on anything desired, and various other policies that help foster and enable flow. There is some historical overlap between OFBiz and Jira, and Jira uses a customized version the Entity Engine from OFBiz.

For those interested in extreme sports and human performance in general, this is a great book:

The Rise of Superman: Decoding the Science of Ultimate Human Performance by Steven Kotler
http://www.amazon.com/The-Rise-Superman-Decoding-Performance/dp/1477800832

See also the Flow Genome Project (http://www.flowgenomeproject.co) which is based on this work, and in particular a great slideshow they put together that describes the concept of flow and trigger for it:

http://www.slideshare.net/StevenKotler/17-flow-triggers

Much of this is based on the extensive work of Mihaly Csikszentmihalyi. His most business-oriented book is:

Good Business: Leadership, Flow, and the Making of Meaning by Mihaly Csikszentmihalyi
http://www.amazon.com/Good-Business-Leadership-Making-Meaning-ebook/dp/B002J05GPS

For those who want to go deeper he has written various other books, and these are a couple of good ones to look into:

Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihalyi
http://www.amazon.com/Flow-The-Psychology-Optimal-Experience/dp/0061339202

Creativity: The Psychology of Discovery and Invention by Mihaly Csikszentmihalyi
http://www.amazon.com/Creativity-The-Psychology-Discovery-Invention/dp/0062283251

The Experience of Flow

Flow is a powerful experience of full engagement and focus. It is a state of consciousness, attention, and awareness focused on a particular activity. The parts of the mind and body that are essential for the activity are fully engaged while the remaining parts of the mind and body are suppressed.

There are many aspects of the experience and the resources above have much information about not only what people experience, but also correlated changes in brain chemistry and electrical (wave) state and areas of the brain that activate and (more importantly) deactivate. One aspect is that time perception changes, usually a sense of time slowing down or simply no awareness of the passing of time. This correlates with transient hypofrontality, or more specifically change or suppression of the parts of the brain that monitor time and control your perception of it.

In some flow experiences even the parts of your mind that perceive your self will change and the boundary between what is you and what is not you will shift. In some experiences a tool may seem to become part of you so that no conscious effort is required to use the tool, it is like it is part of you. In other experiences you may feel more connected to the environment or to people around you, as if you are part of a greater whole (and this is an important aspect of team flow... yes, people can flow in groups too!).

The most critical aspect of flow is that self evaluation, your inner critic, turns off. You experience no value judgment and confidence becomes a non-question... the part of your brain that might doubt is simply turned off. Impulse control goes away along with activation of impulse focus on the task at hand. This feels like a steady stream of impulse and action based on impulse, a literal flow of continual impulse and action.

In a creative effort the parts of the brain that are then able to impulse and flow include the parts related to pattern recognition, linking ideas together, generating new ideas, risk taking, and detailed memory of the experience. When needed for the task there may also be increases in awareness, observation, and input acceptance and processing.

That is all the performance side of the experience, which will generally result in extrinsic rewards, but what about the intrinsic rewards? This is where the real motivation for the experience kicks in. During and following flow experiences the brain has an increase in norepinepherine, dopamine, serotonin, and endorphins. It is like being on low levels of speed, cocaine, MDMA, and opiates all at once... but totally natural. It is part of your mind's built in reward for your efforts in learning, growing, creating, and unleashing cultivated abilities.

To Flow and Beyond

There are steps before and after flow that you should be aware of to understand how flow fits into the overall creative experience (and other flow experiences as well). Below are descriptions of the 4 main phases. Chances are you will recognize these from past creative and other experiences, and understanding them you can start to recognize them in future experiences.

1. Struggle: When first beginning an effort you have a lot of mental noise and scattered thoughts jumping among the value, purpose, and details of what you are doing. This is the phase to load relevant information into your mind by reading or conversing, to recall relevant information, and think about the goal you are trying to accomplish and the purpose of the effort. This is a necessary preparation for flow even if it does sometimes seem unpleasant. The inner critic that turns off during flow is active during the struggle phase. The dominant brain wave in this phase is the beta wave, and the most prominent chemicals in your mind are cortisol and norepinepherine. Focus your intentional effort on loading information and setting a clear goal and vision to reach that goal.

2. Clarity: In this phase the specific goal and vision for reaching the goal become more clear and you start to get your head around what you are trying to do. This is a key part of getting into flow and is the stage just before flow. If you don't have a clear enough vision of the effort you will never reach this phase and never transition into the flow phase. This phase may be brief or may last a while. To get here you need to relax and move your attention away from your thinking mind to let your mind do its thing. Intentional breathing, physical activity, or a simple distraction can help with this. You will eventually have a clear vision (not necessarily an image) of the goal, and what you need to do first becomes clear. Don't try to think through the whole effort in detail, just get the vision and the first step clear then start acting. Flow is all about engaging in that first step and letting the remaining steps "flow". What is literally happening is various parts of your mind are now doing the tasks you setup in phase 1 and coordinating with your conscious mind as needed by raising impulses for you to act on. Just focus on the first step of your effort, and let the rest come as you go. The prominent brain wave here is the alpha wave, and in this phase nitric oxide in the blood stream starts to increase, which in turn increases blood flow and the delivery of various chemicals to the brain that it needs to function optimally.

3. Flow: This is where the magic happens and you experience everything described in the previous section of this article. You start to feel fully conscious (associated with theta brain waves) and at the same time various parts of your mind become active while other parts of the mind that normally suppress these active parts become inactive (the inner critic turns off, time perception changes, etc). Most of the creative work moves to the background of your mind, your subconscious, leaving your conscious mind to act. You will start to efficiently process information and have more frequent and profound insights, which are associated with gamma brain waves. The more you can focus on the effort and let impulse and action flow the longer you will stay in this phase. This can be done with other people. Sometimes things others say and do will become a part of your flow, sometimes they will break your flow.

4. Detach and Recover: This phase always happens, and it is best if you allow the time and space for it instead of getting distracted or moving on immediately to something else. You need this phase to recover and learn from the effort, and to prepare for future flow. In this phase you may feel totally spaced out, empty minded. Your mind goes into this state as a natural way to recover from, and process what, happened during the flow phase. When your whole mind is focused on a certain task there may be memories, emotions, sensations, and observations that some part of your mind notices but that don't result in an impulse to your conscious mind because they are not relevant to the effort at hand. Those may come out during this phase. The prominent brain wave in this phase is the delta wave, and both serotonin and oxytocin may be elevated. This can be a very pleasant phase but can also be a let down from the high of flow. Either way it is a valuable phase for learning from your experience and preparing for the next time you do it. For those who meditate this is an excellent time to intentionally be mindful of what is going on in your mind and body. Your whole physiology is primed for mindful meditation in this phase, and doing so will maximize the benefits and the enjoyment that come from it.

Finding Flow

That sounds like a great experience, what can I do to get into flow, especially when doing something creative like developing software?

Ultimately flow is a mental state, something your mind does to respond to focused, high value effort. You can't force flow, but there is a lot you can do to create the conditions for it, to train yourself to more readily go into and stay in flow, and even change your brain chemistry and electrical state to facilitate it.

The Flow Genome Project has a list of 17 flow triggers, and there are three that are most critical to software development and similar creative efforts:

1. Sense of Control (autonomy + competence): Autonomy is all about independence and choice in the effort. The three main aspects of autonomy are time (when to do it, how long to spend doing it), task (what to do, how to do it), and team (who to do it with). Different people will consider different of these to be most important, and will be affected in terms of flow differently by each type of autonomy. Competence is the other side of the sense of control. With a higher level of experience and competence it is easier to get to a vision for how to go about the goal, and it is easier to quiet the inner critic that can block flow.

2. Strong Purpose and Clear Goal(s): A purpose that you care about will naturally engage you more. The more clear a goal is the more easily you will be able to put together a vision for reaching the goal and identify the first step to get there. The goal and your vision for achieving it is likely to change during an effort, and while it doesn't need to be perfect or even fully complete you need something to start with.

3. Challenge/Skills Ratio: For anything you might do you have a range of challenge (or intensity or stress) that you will handle well. There is a low end to this range below which you will have difficulty getting and remaining fully engaged. In other words you'll get bored and more easily distracted, it will be difficult to remain focused. There is a high end above which your skill and experience are not adequate and you will feel overwhelmed and doubtful or even fearful. The sweet spot, where it is most easy to get into flow, is a challenge level that is just a bit higher than your comfortable skill level. Flow happens best when you are fully engaged and this happens most naturally when you push yourself to new levels of performance and achievement.

Given these important conditions for getting into flow, how can you train and improve your ability to do so? One of the most powerful practices is meditation. The ability to be fully present in both time and place, focusing on the here and now, is cultivated with meditation and with practicing presence in everything you do. Even planning for the future or pondering the past can be done fully present, just chose the moments and focus on those things. If conditions are ideal for flow then it doesn't matter so much as your mind will shift into full presence, but it is much easier to learn to be present than to always try to setup perfect conditions or be limited to the perfect conditions. Being present reduces the impact of lack of control (both lack of autonomy and lack of competence), makes it easier to accept and embrace purposes and goals, quiets your internal critic, and widens the range of challenge that you will handle well.

When a challenge is well beneath your ability level increasing your attention will keep you engaged and present even though the intensity of the challenge doesn't push you there. When a challenge is beyond your comfortable ability being present will keep your mind from running to all the possible horrible outcomes, or the failures of the past. This is the essence of equanimity which is cultivated through meditation, various other mindfulness practices, and practicing presence and attention in everything you do. The ultimate experience of meditation is to detach your consciousness from your thinking mind, body, and emotions so that they are all in the background and your conscious mind is aware of them but not controlled by, or attached to, them. Creative flow is like a meditative experience in that you are more conscious and present in both, and being familiar with conscious awareness will help you get into flow.

One good book to get you started, if you are not already familiar with meditation, is:

Mindfulness Meditation in Everyday Life and Exercises & Meditations by Jon Kabat-Zinn
http://www.amazon.com/Mindfulness-Meditation-Everyday-Exercises-Meditations/dp/149151891X

Another tool that appears to have great potential, but that I have not personally tried, is neurofeedback training such as Brain Sport by SenseLabs (was Neurotopia).

Okay, that's great as an ideal, but what do I do to function effectively now while I'm practicing meditation and getting into flow? Be careful not to force flow, the extra stress will actually block it. Still, there is quite a bit you can do to "hack" flow. For example if a challenge is too easy you might intentionally make it more difficult, closer to the edge of your skill level, by doing it more elaborately, constraining it in some way (limit on time, size of result, etc), or even doing something passive at the same time such as listening to music or doing something physical (walking, stretching, etc). If a challenge is well beyond your skill level you can get help, train or study before you take it on, or identify the critical success factors and see if you can simplify the effort to something closer to the comfortable edge of your skill level.

A lack of autonomy or feeling of competence, or a purpose or goal that don't interest you, are a very different sort of challenge. These become exercises in acceptance. Acceptance is not about going along with things that are harmful to you or others, those are cases where you need to decide to be involved or not and what to do to set and enforce boundaries. Acceptance is about coming to terms with reality, letting reality be what it is without getting upset about it, and even without getting excited or happy about it. Just accept it for what it is, notice it in detail without any value judgment.

Once you understand a situation, internal or external, and are okay emotionally with what it is, then you can decide what to do with it and examine your feelings about it. By accepting a lack of autonomy and looking at the situation for what it is, you may find desire and fulfillment in the effort, and be able to flow fully with it even though it isn't ideal. By accepting a purpose or goal that doesn't interest you or even that seems undesirable at first, you may be able to see it and understand all aspects of it more clearly and start to feel interested and excited about it. It is natural when accepting something to be able to notice it more clearly, and natural when noticing something clearly to appreciate it for what it is and even feel gratitude and desire about it.

What if I want to get a boost while I'm doing inner work to be able to more fully and frequently flow? One way to suppress some of the same parts of your mind that are suppressed during flow is to use a tDCS device like the "foc.us gamer". This is a useful tool for concentration and can help with focus and turning off the inner critic, which can make it easier to get through the struggle phase into the clarity phase, which is often the most difficult part of getting into flow.

Another physical tool to help get into flow is nitric oxide (NO) boosting supplements. Nitric oxide naturally increases in the clarity phase and helps transition to the flow phase by increasing blood flow and delivering more of certain chemicals in the brain. There is a lot of research about nitric oxide and its role in mental and physical performance. There are common parts of fitness supplements that act as NO boosters such as L-Arginine and L-Citrulline. There are also more natural things that increase NO, including green leafy edibles, beets, garlic, cayenne, and good old fashioned exercise.

In general anything you can do to get the goal and details about it into your head, produce a vision for the effort, and focus intensely on the effort will help you get into flow. If you know a way to quiet the chatter in your mind effectively and safely then try that to help you get into flow. If you know ways to tune the intensity of a challenge to your skill and full engagement level, give it a try. Improving your ability to flow and the conditions for flow may involve working with others. These may be family, friends, or coworkers. Consider it an opportunity to improve your relationship with them, and maybe even get them interested in flow, presence, acceptance, and other things that will benefit them personally and professionally.

Breaking Down Goals for Ideal Flow

Software development involves lots of breaking down bigger goals into specific instructions and algorithm steps that a machine can execute. In a way it is ideal for getting into flow. Once you understand the goal and a general strategy for getting a machine to do that using whatever tools you have available you can get into the procedural flow of laying down one step at a time. Over time your mind gets so used to processes and rules that once you have the general idea of what needs to be done it is almost automatic for your mind to start breaking it down into structural and procedural chunks. Your mind trains well to send you a steady stream of impulses for you to act on as you tap out code.

For many of us this mental effort becomes so automatic that we can do it in spite of high pressure and distractions. We can also recover quickly and get back into flow after running into dilemmas and having to step back and observe the problem as a whole for a bit. In fact, we even get good at hopping between different levels of detail to work with higher and lower level processes and data structures and such, and getting into flow at varying levels of abstraction. There is a reason that once we develop some sound skill that we often thoroughly enjoy creating software.

What about higher level things, like gathering business requirements and designing user interfaces and other software development tasks where we don't have a nice clearly defined goal to work toward? What about when the task is to clearly define the actual implementation goals like screen designs, data structures, or business rules?

This is where levels of abstraction come into play. Business requirements are in effect just a high level, low detail abstraction of the software to eventually create, and preferably written in business terms as opposed to technical terms. Business requirements still live in the context of even higher level business objectives and rules. If you are using effective means of structuring and documenting requirements (such as those in HEMP, http://www.dejc.com/HEMP) then it will become a natural level of abstraction that you work with just as effectively and efficiently as code. It is a different sort of effort from coding as it is (or generally should be) a collaborative effort with business representatives. The potential when gathering requirements is to frame and direct the conversation in such a way that the whole group focuses on particular business objectives and processes and the whole group gets into flow together laying out the details of the business process.

Flow can be experienced in a wide variety of efforts. Even writing this article involved a few distinct periods of flow! Any large project or effort can be broken down into smaller efforts, some of which are efforts to define and break down the larger efforts. Over time breaking down larger efforts to optimize the opportunity for flow with each effort will be a natural part of your work planning and one of your flow facilitating skills.

Getting Started

Now you know what flow is and what to look for as you experience different phases of efforts leading up to flow, engaging in flow, and the detaching and recovering from flow. The best way to get started is to simply be more aware, start looking for the phases, sensations, and feelings of flow. Chances are you have experienced flow hundreds of times in your life, and maybe a few times as profound, sustained experiences that you recall clearly. Take a moment to sit in those memories and recall what it felt like, how you got there, similar experiences where it didn't work and what was different that got you fully engaged, present, and focused. In addition to experiencing flow in your work life and creative pursuits you can also experience it in personal efforts like pushing your limits in fitness or physical expression. Paying close attention to what you are doing and the sensations you feel as you do so can be a profound and euphoric experience as you get into flow, and as you get out of it.

You have also most likely had experiences of flow with other people, in personal or professional efforts. Those are special and powerful experiences, and teams that do this on a regular basis do amazing things and get profound satisfaction and fulfillment from it along the way. This is one thing people really enjoy about performing music, dancing, and other activities that involve people synchronizing and coordinating with constant engagement and feedback. In a business context this happens a lot during process-driven requirements gathering where people are focused on the overall business objective and work together to layout the steps to achieve it. It also happens during technical problem solving.

You can flow in a wide variety of efforts and circumstances, and some lend themselves to flow more than others. Practicing and enjoying flow in efforts that lend themselves to it will make it easier to get into flow in efforts where the conditions are less than ideal. These are often important things to do, critical for business operations and even certain parts of creative efforts and collaboration, and you can do them better and enjoy them more in flow. The experience may be one day a week where you work on whatever you want, in whatever way you want, for your employer. It may be unpaid contribution to free software projects like I have chosen, but it doesn't have to be, and it doesn't even have to be unpaid. The key is to set up the effort to use the triggers and follow the process for getting into flow.

Remember that going into flow states for important efforts is a natural part of the function and structure of your mind and body. Important is whatever you decide it is, or more accurately, whatever you tell your mind is important. You get to decide. Flow is the ideal way to learn and grow, to create and express, and your mind and body will reward you well for it.

David Joneshttps://firstname.lastname@example.com:blogger.com,1999:blog-5816842205727721694.post-17250302416867440072014-01-08T03:47:00.002-08:002014-01-08T03:47:54.299-08:00Moqui Ecosystem Application Boost and MentorshipOne of the big objectives right now is to build out the application ecosystem based on Moqui Framework and Mantle Business Artifacts.

To help move this along I'd like to start building more community around existing projects (HiveMind and PopCommerce), and support developers working on these and other projects. The general idea is you work on functionality and I will review your work, offer feedback and training along the way, and if applicable (for HiveMind, PopCommerce, Mantle, etc) work with you to get your changes committed to the GitHub repositories for these projects.

For HiveMind I've been keeping a list of ideas for additional functionality here, and for those interested this is one good place to start:

https://github.com/jonesde/HiveMind/blob/master/WikiSpace/DEMO.cwiki

For PopCommerce I have been working on some general ecommerce functionality and there is a lot of work to do based on what is now in place for payment processor integrations (Authorize.net, Cybersource, PayPal, BitPay, etc), shippers (UPS, FedEx, etc), and tax calculation (Vertex, Avalara, etc). My plan is for each of these integrations to be a separate add-on component, BTW, and not part of Mantle or PopCommerce (but they would implement the now existing service interfaces and used the configuration touch points in Mantle).

There are also general things like a more real-world friendly checkout process, cart/order based promotions (price rules are already in place), support for products with variants, better browsing and parameterized search help (using augmented ElasticSearch/Lucene search strings like in HiveMind task search), and so much more.

These are just some ideas and I'm open to others as well, for HiveMind and PopCommerce and for other projects such as the EZBiz concept which may be split into multiple applications, and should probably have a different name too.

If you are interested in participating please send me an email (firstname.lastname@example.com) describing what you'd like to work on and the relevant experience and skills you have.David Joneshttps://firstname.lastname@example.com:blogger.com,1999:blog-5816842205727721694.post-22126742671555587182013-12-27T22:40:00.001-08:002013-12-27T23:02:17.382-08:00Moqui Mini-Conf Jan 2014 Las Vegas
I now have some space in Las Vegas sufficient to host around 10 people for a conference, so planning to do some mini conference and training meetings here more regularly. The place is about 3 miles west of the LAS airport near highway 215. It has a good sized conference table and a connected room with projector setup that is a sort of lounge.

The first of these will be in late January 2014. I am open to feedback on dates and thinking of the 23-25 (Thu-Sat). The first day I'll offer general framework training and diving into more details based on questions and feedback during the training. The training can go into Mantle and HiveMind based on interest, but will be focused on Moqui Framework. The other two days will be general discussions and dev sessions in an un-conference format, in other words we'll start the conference with a huddle about what the rest of the conference will look like.

Some ideas for conference sessions and dev playing include the Mantle data model and services, playing with Drools rules (now used in Mantle for pricing, order shipping charges, and working on the tax calc side of it now) and jBPM workflows. The HiveMind project management and wiki functionality, ideas for improving it, and discussion about real-world use is another good topic right now.

Other fun topics might include ElasticSearch and a follow-up on the results of some ideas that came out of the last conference (the DataDocument, DataFeed, and DataSearch tools, and the Notification framework). For the notification framework a good topic of discussion would be using that with WebSocket, which I haven't done yet due to trouble finding a good library for WebSocket that is independent of the servlet container.

Given the legacy of Moqui/Mantle/etc in the Apache OFBiz project discussions around the two projects (differences, similarities, ideas for using them together, ideas for changing each to be more like the other, etc, etc) is another good topic for discussion.

The last conference was free, and the thanks goes to Hotwax Media for hosting the event. This conference will have a small charge of $50 for basic supplies and snacks and such, and $200 for the training day on Thursday for those interested.

Please comment on the Moqui Ecosystem LinkedIn group on general timing and interest, and contact me directly (email@example.com) if you would like to attend.

David Joneshttps://firstname.lastname@example.com:blogger.com,1999:blog-5816842205727721694.post-1293114629410034392013-11-27T09:52:00.002-08:002013-11-27T09:52:33.766-08:00Initial Releases of Mantle Business Artifacts and HiveMind Project ManagerMantle Business Artifacts 0.5.0 is now available for download through GitHub here:

https://github.com/jonesde/mantle/releases/tag/release-0.5.0

HiveMind PM (Project Manager) 1.0.0 is now available here:

https://github.com/jonesde/HiveMind/releases/tag/release-1.0.0

It is exciting to release these first versions of these two projects. They represent the first significant body of business functionality based on Moqui Framework and make Moqui and Mantle an excellent alternative to Apache OFBiz and other open source ERP, CRM, and eCommerce open source projects and commercial products.

Mantle Business Artifacts 0.5.0
This is the initial release of Mantle Business Artifacts (version 0.5.0). It is based on Moqui Framework 1.3.2. This version covers procure to pay, order to cash, and work plan to cash processes including:

 • Purchase and Sales Orders (for goods, services, materials, etc; POs for inventory and equipment/supplies/etc)
 • Project, Task, and Request management with time and expense recording, billable/payable rates by project/task/client/worker/etc
 • Incoming and Outgoing Invoices with a wide variety of item types and an XSL:FO template for print or email
 • Automatic invoice generation for purchase orders (AP), sales orders (AR), project client time and expenses (AR), project vendor/worker time and expenses (AP)
 • Payments, both manually recorded and automatic through payment processing interfaces; applying payments to invoices
 • Fulfillment of sales orders (including basic picking and packing) and receiving of purchase orders
 • Inventory management including issuance and receipt, and inventory reservation for sales orders
 • Automated GL account posting of incoming and outgoing invoices, outgoing and incoming payments, payment application, and inventory receipt and issuance
 • General GL functionality for time periods, validation of transactions to post, time period closing
 • Balance Sheet and Income Statement reports (and basic posted amounts and account balance by time period summaries)

The automated tests are a great example of functionality and a good reference for where data ends up. They include complete flows with service calls and data validation for purchase orders (procure to pay), sales orders (order to cash), and billable projects with client and vendor/worker invoice/payment (work plan to cash).

HiveMind PM 1.0.0
HiveMind PM version 1.0.0 is the first official release. It is based on Moqui Framework 1.3.2 and Mantle Business Artifacts 0.5.0. This initial version of HiveMind Project Manager includes:

 • Vendor, Internal Org, Client, Worker, and other User administration
 • Rate setup for client billing and vendor/worker payout by project, worker, etc.
 • Project management
 • Milestone management and planning
 • Task management (hierarchical, associated with project and optionally milestone)
 • Flexible task searching and all-in-one task summary
 • Request management, including creating tasks to address the request
 • Time entry by task
 • Expense entry by project
 • Invoices and payments to pay vendor/worker for time and expenses
 • Invoices and payments to bill clients and receive payment
 • Invoice PDF
 • GL posting for invoices and payments
 • Balance Sheet, Income Statement, and posted balance/summary reports
 • Wiki with attachments for requirements and designs, linked to tasks and requests
 • Consolidated searching across projects, tasks, requests, and wiki
 • Simple email notifications for task, wiki, etc updates

The HiveMind-1.0.0-src.zip and HiveMind-1.0.0.zip include Moqui Framework and Mantle Business Artifacts and are ready to go. The HiveMind-1.0.0.zip file is built and has a Derby database preloaded with demo data, so just run it (gradle run, ant run, or java -jar moqui-1.3.2.war) and in your browser go to:

http://localhost:8080/apps/hm/

David Joneshttps://email@example.com:blogger.com,1999:blog-5816842205727721694.post-60977049895813632082013-11-27T09:42:00.002-08:002013-11-27T09:42:26.772-08:00Latest Moqui Framework Release
Recent Releases Summary
It has been a while since I post about the latest in Moqui Framework, so here is a summary of major things in the last few releases (1.2.0, 1.3.0, 1.3.1, 1.3.2):

Moqui Framework 1.2.0 is a minor new feature release and a major quality improvement release. This release has undergone significantly more testing than previous releases because of a wider variety of functionality that has now been built and tested using the framework, and because of a unit testing effort (framework unit tests built using Spock).

The new features include popup menus (using the new jQueryUI menu widget), dynamic-options in XML Form drop-downs with dependency on other fields, automatic optimization of queries on view-entities to old select member entities necessary, support for UUID generated primary keys, expanded JCR support and an Example Content screen, and a number of small improvements that generally make the framework easier to use and more reliable.

Moqui Framework 1.3.0 is a major new feature and bug fix release. The major new features include the EntityFacade Data Document, Data Feed, and Data Search (based on ElasticSearch) features, the User Notification Message feature, and various improvements to XML Screens and Forms. This release is backward compatible with Moqui Framework release 1.2.0 with the exception that the StatusValidChange entity is deprecated by the new StatusFlowTransition entity.

Moqui Framework 1.3.2 is a minor new feature and bug fix release. The main new feature is a write-through per-transaction cache that effectively simulates the database for the scope of the transaction and does all DB updates with a single connection just before commit. This transaction cache is enabled on service definitions using the cache and force-cache options for the service.@transaction attribute. With this in place various Mantle services now run 2-3 times as fast with results validated by extensive automated tests.

Another set of new features covers internal profiling for artifact execution (entities, services, screens, transitions, etc). There are various forms of output available including a full artifact call tree with times, a consolidated tree to see own and total for artifacts in context, and a hot spot list by own or total time. This is similar to Java-level profiling tools but focuses on business level artifacts and with a low overhead gathers data always but only generates reports when needed.

OrientDB is now included in the framework by default instead of only in an addon component as before. This is useful as a general graph and document database and as an alternative through the Entity Facade for high-write entities like ArtifactHit.

Moqui Progress Commentary

While there are quite a few new features and bug fixes in Moqui Framework over the last few months, most of the work in the Moqui Ecosystem has gone into Mantle Business Artifacts and HiveMind Project Manager which are built on Moqui and are the main large scale projects based on it so far. I'll post separately about Mantle and HiveMind as both were released with a versioned release for the first time a few days ago.

The Moqui user community is expanding and the LinkedIn forum is starting to see more traffic. I am also starting to get more frequent calls and emails about new projects using them, and contracting and employment opportunities for projects based on Moqui (and often Mantle, and sometimes HiveMind).

Are you interested in getting more involved? The main thing Moqui and Mantle need now are applications built with them. These could be open source or commercial. The application should be something that benefits you, the better it is for you the better it will be for Moqui and Mantle as projects and products grow around them. Moqui and Mantle benefit from increased exposure, but also from feedback, bug reports, feature requests, patches, and so much more than existing efforts based on the projects have significantly helped with already (for around 2 years now).

What is coming next for Moqui Framework? This is often on my mind and is mostly driven by what is needed in applications that I am working on (Mantle, HiveMind, and PopCommerce now and then), technologies or features that people ask about and things that are just really cool or have huge potential to improve the flexibility and capability of enterprise automation systems.

One of these I have been researching more recently is the huge potential for rule and workflow tools in ERP apps. My interest in these goes back to the very early years of OFBiz, though neither the rule or workflow engines really worked out well and ended up being useful. Today there are extensive and very capable open source rule and workflow packages, and one (RedHat JBoss Drools and jBPM) where rules and workflow work together and share a knowledge base and such.

A couple of weeks ago I attended to Building Business Capability conference in Las Vegas and was inspired by how much progress has been made and all the great examples and case studies of applying these tools. This conference covers rules and workflow, and also requirements analysis and such that is another of my favorite topics in the enterprise software world.

I don't know when these things will show up in Moqui, but it will only be when there are real-world uses in place for them. Some early features in Mantle that I'd like to base on such tools include price calculation rules and order promotions rules (replacing the simple condition/action tables concept in OFBiz), order and invoice processing and approvals, and a more elaborate integration with HiveMind for managing the manual activities in workflow along with project tasks and such. There is potential for a lot more, but these would be good proof-of-concept sorts of features.

David Joneshttps://email@example.com:blogger.com,1999:blog-5816842205727721694.post-41582821114934072932013-07-03T23:10:00.000-07:002013-07-03T23:12:23.434-07:00HEMP Book Now AvailableA few years ago I started working on a refined approach to business analysis and system design to use with Apache OFBiz and other custom enterprise system development projects. This is based on my years of experience doing this work, starting as a developer often frustrated by inadequate and frequently changing designs, and non-existent or ineffective requirements, and later taking on consulting and active management for dozens of such projects.

The material I originally wrote was cobbled together and never cleaned up, but now I have written a book on the topic and it is available on Amazon.com:

http://www.amazon.com/dp/148418422X

Here is a blurb about the book: "HEMP is an agile approach to business analysis and system design for end users, project managers, business analysts, application designers, software architects, application developers, and quality assurance professionals. HEMP complements agile software development methodologies with an equally agile approach for gathering and documenting business requirements and producing system designs to drive application development that will meet the needs of end-user organizations. The practices and artifacts in HEMP are applicable for building new systems as well as customizing existing ones. HEMP is agnostic to programming languages and application frameworks so can be applied regardless of technology preference. This book includes case studies and numerous examples to help you understand the context of recommendations and how to apply them."David Joneshttps://firstname.lastname@example.com:blogger.com,1999:blog-5816842205727721694.post-8860627767978943942012-07-22T19:55:00.002-07:002012-07-22T19:55:49.116-07:00Moqui Framework 1.1.0 Now AvailableVersion 1.1.0 includes various bug fixes and library updates. It is also a minor new feature release with added functionality for anonymous authz, enhanced JSON and REST web service support, XML Form extension with database records (DbForm* entities) for all users or particular users, and an Apache Camel integration with Camel running embedded. This version also replaces the only LGPL library (Restone XML-RPC) in Moqui Framework with an Apache licensed library (Apache XML-RPC). This makes Moqui compatible with licensing requirements for projects that are part of the Apache Software Foundation (including Apache OFBiz).David Joneshttps://firstname.lastname@example.com:blogger.com,1999:blog-5816842205727721694.post-33644202499216261482011-11-21T09:11:00.001-08:002011-11-21T09:11:36.921-08:00Moqui Framework 1.0.0 Now AvailableThe initial production-ready version of the Moqui Framework was released on 21 Nov 2011. This release includes various fixes and new features to facilitate easy use based on more extensive testing and real-world development using the framework.

More examples of different recommended and useful patterns now exist in Moqui Framework itself, and in add-on projects including Mantle, POP Commerce, and others.

To download this release, and for Release Notes with more details about this and previous releases, go to:

https://sourceforge.net/projects/moqui/filesDavid Joneshttps://firstname.lastname@example.com:blogger.com,1999:blog-5816842205727721694.post-21220886234742905322011-08-03T18:46:00.000-07:002011-08-03T18:47:30.278-07:00Moqui Framework Release 1.0-rc1 Now AvailableThe first 1.0 release candidate of the Moqui Framework (version 1.0-rc1) was released on 3 August 2011.

This release includes various small new features based on feedback and actual use, including Apache Shiro for security (authc and authz), build using Gradle which supports Maven repositories and with directory layout changed to follow Maven conventions, the ability to run arbitrary SQL and get the results back in an EntityListIterator, and the Data View tool that allows users to build queries and data exports on the fly.

This release candidate also includes improvements based on more testing, including performance testing and profiling to dramatically increase the speed of various operations, especially those done frequently.

As a release candidate from this point only minor changes are expected before the 1.0 final production-ready release.

Release download files are available on SourceForge:

https://sourceforge.net/projects/moqui/files

Note that there is a file that also incudes a preview release of the Mantle Universal Data Model running on Moqui Framework.David Joneshttps://email@example.com:blogger.com,1999:blog-5816842205727721694.post-40096865418603535492011-07-14T11:07:00.000-07:002011-07-14T11:11:49.803-07:00Moqui Demo Site on Amazon Elastic BeanstalkThere is now a demo site for Moqui Framework at:

http://demo.moqui.org

This site is running on Amazon Web Service's Elastic Beanstalk service (as a war file in Tomcat 7) and uses the AWS RDS database (MySQL 5.5.12).

Deploying this demo site involved a couple of bug fixes for running on Apache Tomcat and on MySQL, and both are working well now.

Moqui also now includes some features to make it easier to create a war file with the runtime directory included, even if you just have the war file from the Moqui binary release and the new wartools.xml Ant build file. Just run "ant -f wartools.xml add-runtime" and a new war file will be created from the existing moqui-1.0.war file, your MoquiInit.properties file, and your runtime directory.

Enjoy the demo, and enjoy this new and easy way to deploy apps built on Moqui Framework.

Also, moqui.org and my business site dejc.com are now also running on Moqui Framework in another AWS Elastic Beanstalk instance.David Joneshttps://firstname.lastname@example.com:blogger.com,1999:blog-5816842205727721694.post-17905997299520240622011-04-01T19:40:00.001-07:002011-04-01T19:40:54.591-07:00Moqui Framework Release 1.0-beta1 Now AvailableThe first feature-complete release of the Moqui Framework version 1.0 is now in beta and available for download. This release represents a major milestone for Moqui Framework as it is ready to be used in development of web-based applications ranging from simple sites and applications with a few forms and some content to comprehensive corporate ERP, CRM, and eCommerce systems.

For details about what this release includes, and what has been implemented in previous releases, see the Release Notes here:

https://github.com/jonesde/moqui/blob/master/ReleaseNotes.txt

For general information about Moqui and the Moqui Framework see:

http://www.moqui.org/

To try Moqui Framework download it through SourceForge, and read the instructions in the RunDeploy.txt file included in the download:

http://sourceforge.net/projects/moqui/filesDavid Joneshttps://email@example.com:blogger.com,1999:blog-5816842205727721694.post-48118154818879765942011-03-31T10:35:00.000-07:002011-03-31T10:46:01.629-07:00Why would someone contribute to an open source project?
There is an interesting thread in the Open Source group on LinkedIn that started with the message: "why would someone contribute to open source project? what would programmer get in return?" Here is my response to this:

This question is a good one because it goes to the core of how open source software gets created. The fact that there have been so many replies to this question demonstrates its importance (even to those who seem offended by the idea that an individual needs a reason to contribute).

The factors of satisfaction, building skills, and better employment opportunities (for certain types of companies anyway) are, IMO, more symptoms of the underlying reason rather than the reason itself.

What is implied by the question and many of the answers is that intellectual property protection is the only way to earn a living making software. It seems clear to just about everyone the IP law is not good for innovation, which is best recognized by symptoms like satisfaction and greater value in a market.

Along with this IP law is also not in the best interest of software creators, and does not result in greater income for those of us who create software professionally. When we create software for an employer we get a salary and unless we're really lucky the salary is the minimum they can get away with paying for what is often considered a worldwide commodity skill that isn't worth much in the market.

IP law is great for investors, but bad for the software itself and bad for software creators. Open source and free software are the answers to that.

Those who give up on IP protection to make a living will make more money and have more opportunities for satisfying and skill-building work.

I like to consider myself a good example of that, so much so that after a decade of working on what is now Apache OFBiz all of my free time is going into the next generation of free software tools and applications for business use with Moqui and the projects based on it.

In all of this I've made 2-3 times as much over the last decade as I would have by working as an employee, unless perhaps I had hit a C-level position in a larger company by now (which I'm not sure I'm really that interested in anyway).

David Joneshttps://firstname.lastname@example.com:blogger.com,1999:blog-5816842205727721694.post-89639570641628418492011-03-01T16:40:00.001-08:002011-03-01T16:40:42.445-08:00Moqui Release 1.0-preview2 Now AvailableWith release 1.0-preview2 the Moqui Framework is now nearly complete and has sufficient functionality to build a wide variety of functional and useful enterprise, or less formal, applications. This release includes a functional example application with various screens demonstrating features of the framework and recommended practices and patterns to use when developing with Moqui.

While not feature-complete for the planned 1.0 feature set, the 1.0-preview2 release is ready for early adopters. For those interested, this is a great time to try out Moqui for a pet project or even a more formal project that is just getting started and won't be deployed in production for at least a few months.

Feedback on functionality and bugs by early adopters would be extremely helpful for the project at this point, both to validate (or invalidate...) designs and to more extensively test the implementation.

The release and release notes are available here:

http://sourceforge.net/projects/moqui/filesDavid Joneshttps://email@example.com:blogger.com,1999:blog-5816842205727721694.post-34331555534622137662011-02-21T21:50:00.000-08:002011-02-21T22:52:42.076-08:00Free as in FreedomIn his article about free software versus open source Richard Stallman expresses the importance of a focus on freedom:

http://www.gnu.org/philosophy/open-source-misses-the-point.html

I couldn't agree more. Freedom can be effectively applied as a solution to any modern problem, including software. On the other hand, freedom can also be ineffectively applied or downright misapplied and fail to solve problems in spite of the good goal and direction.

Some say Stallman's focus on freedom is dogmatic, other call it communist, and others utopian. I say Stallman doesn't go far enough.

When it comes to free software and open source I certainly started out in the open source camp where the utilitarian development was a higher priority than freedom. At the time I simply found the GNU GPL to be overly restrictive, and ironically because of that it is popular among commercial software companies who want a revenue stream from software licensing and also want to market their wares as "open source."

In the last decade my understanding of freedom and its importance in the world has changed, and I think I'm starting to understand Stallman's focus on freedom and his approach to achieving it. Understanding isn't agreement though, and in this case I don't agree with the approach at all. It doesn't really represent freedom at all in my opinion, and is in fact a misguided attempt to violently force people into freedom.

Violence? Force? Yep. The irony is the use of the "legitimate" force of intellectual property law as a means to promote freedom. The goal of freedom is spot on, but freedom must be chosen and anything that looks like freedom but is brought about through force will always have a hard time rising above mere compliance.

From a different perspective, namely that of law makers and enforcers, this idea is pure genius and because of that is promoted frequently and consistently in nearly all modern propaganda, including media and educational institutions. If you want something done, give someone the power to force it to happen. Those who want certain things done get to feel like something is getting done without doing much themselves, and those who want the power get what they want and usually have no liability or accountability to balance their power. The more we try to solve with force, no matter how legitimate it might seem, the more force and centralized power we'll get as a result.

Your mom was right: violence is not the answer. If your mom was really smart, she also taught you that government is little more than a monopoly on violence. In some cases, such as countering aggressive force, violence is entirely appropriate. In most cases it is absolutely not.

This is where we cross the line from ethics to morals. Ethics are morals within a certain context, and in the context of legitimate use of force through government violence is entirely ethical. In the more absolute context of morals, violence in response to the treatment of ideas (no matter how they are represented) is clearly not justifiable.

So which license is really the friend of freedom? Which open source or free software license rises above ethics into the realm of morals and does away with threats of violence? If the license is based on the concept of copyright, it is violent and antithetical to freedom. If the license tries to force people to do or not do certain things in order to comply with copyright law it cannot be a friend of freedom.

In general, and certainly with software, there is only one way to not feed the beast of centralized power: don't solicit it's services! If you want free software, with free as in freedom, then the only approach that is moral, and the only approach that will result in more freedom in the world instead of less is to not use copyright law at all. The only way is to disclaim your copy rights. Until there is no intellectual property law in the world, the only way is through no copyright and no license.

Let freedom start with you. Disclaim your copy rights. Put your works in the public domain. Don't feed the beast.

Not convinced this is a good idea? Consider what various corporations do that you don't like. Do you support the RIAA and the ruin of lives over copying of music? Do you support the big corps and their approach to protecting their "rights" with commercial software? Are you in favor of a $500,000 fine and 5 years in prison if you copy a movie, and the absurd amount of our money through taxes that go to enforce that? Are you in favor of DRM software, and laws against even revealing the details of DRM software? Do you think it's okay to throw people in a cage or steal money from them because they wore a t-shirt with a set of numbers and letters printed on it?

I hope your answer to those questions is no. If not, then why on earth are you reading this? So what is it that bothers you about those things?

All they are doing is applying copyright law to protect their interests in the "intellectual property" they own.

If you do the same, are you any better? Can you claim any moral, or even ethical, superiority? Why should people listen to you?

Let freedom start with you. Disclaim your copy rights. Put your works in the public domain. Don't feed the beast.David Joneshttps://firstname.lastname@example.com:blogger.com,1999:blog-5816842205727721694.post-80937800118350739472011-02-09T21:40:00.000-08:002011-02-09T21:42:59.137-08:00Moqui Release 1.0-preview1 Now AvailableThe first release of the Moqui Framework is now available for download through SourceForge at:

http://sourceforge.net/projects/moqui/files

This first release has many tools that are usable right now, but there are many features planned for the final 1.0 release that are not yet complete. See the release notes for details about what is included and what is not yet either in the distribution or on the download page linked to above.

This release includes a WAR file that is executable (like an executable JAR), or can be deployed in an app server or servlet container. For more details see the RunDeploy.txt file in the distribution, or online here:

http://moqui.svn.sourceforge.net/viewvc/moqui/trunk/moqui/RunDeploy.txt

Part of the purpose for this release is to get feedback, bug reports, and contributions. If you have any questions about those, feel free to contact me or post in the forums. Thanks to all for feedback so far, and for continued interest and support.David Joneshttps://email@example.com:blogger.com,1999:blog-5816842205727721694.post-80974558395766682612011-01-10T04:12:00.001-08:002011-01-10T04:16:35.489-08:00The Moqui Framework Web SiteI started work on design of the Moqui Framework in Feb 2010. Just a few weeks ago in late 2010 I decided the design was done (I made it through all of my TODOs), and started implementation. Right now implementation is under way, and I'm appreciating the power and flexibility of Groovy and as I get into higher level code also the features of the Moqui API and features.

Anyway, to the point of this post...

This weekend I decided it was finally time to get a web site together for the project. This initial web site has useful links and a good deal of content about the project. If you're wondering about what Moqui is or how it will be managed or what drove the design, then there are good time ahead for you at:

http://www.moqui.org/

Enjoy!
David Joneshttps://email@example.com:blogger.com,1999:blog-5816842205727721694.post-15555429041093316622010-02-07T12:51:00.000-08:002010-02-07T13:05:33.869-08:00Why Business Apps Are Difficult, and What to Do About ItThere are lots of questions and misunderstandings about the nature of business applications, and why Apache OFBiz is the way it is, and why it isn't go to hold your hand and guide to just what you want for your business. Sometimes people make comparisons to operating systems or other lower level tools, but there are some key differences that make all the difference and...

There are a few reasons why the business side of OFBiz (the applications) are a lot more complicated and difficult to learn than the technical side of OFBiz. The basic problem is the size of each, but that's over-simplifying things.

Read Before You Write: It's not really human nature to do this, and it takes a lot of patience. This is made worse because if individuals have a hard time with patience, organizations are simply incapable of it. The PHBs want results... and reading sure doesn't look like it's producing any. What's worse is if the individual manages to produce a result with a couple of dozen lines of configuration and bits of code instead of a couple of thousand lines of raw, meaty, manly Java then a semi-technical PHB may find it really unsatisfying to have paid for so much time to get so little, not realizing that the individual just saved him 10-100 times what the alternative would have cost initially and over its useful lifetime. Unfortunately some individuals DO realize this and build large, profitable businesses based on exploiting it (but that's another topic altogether).

Scratching the Surface: A business application is not like an operating system, or even a framework for building business applications (which is like an operating system, except the interfaces are tuned to a different type of input, a less technical and more business-oriented type of input). The difference is by nature there is no way to design an interface adequate to represent a business application, and that is what both operating systems and application frameworks are all about. Unfortunately business people don't like being told that an interface with a few little parameters is supposed to represent the entirety of options for ANY process in their business, even "standard" ones like billing or shipping. Business people don't like not be able to change and tune any part of their business that they want, and if the systems can't keep up then they don't get used. SAP and most ERPs out there are great examples of this. They are proprietary software works and you don't get all of the source code (and/or permission to change it), and can only change what they've decided it's okay to change (unless you want to rewrite something, usually more than you think). Those sorts of systems don't let you get below the surface, which is unfortunate because then you don't even have an option to Read Before You Write.

In other words, the way you go about adding value (via easy of reuse) in a business application is very different from how you go about adding value in an operating system or a business application framework. With the OFBiz framework you can learn the "interface" to it, but with the applications you pretty much have to deal with it all. On the other hand, there are more concise "interfaces" to it, like the data model and browsing things related to data model elements, which is made easier with the Artifact Info and other related tools in the OFBiz WebTools application.

And how do you apply that in your business? The basic answer is you don't. OFBiz is meant to adapted to businesses, not businesses to OFBiz. You can certainly run it OOTB, but that's not how it's meant to be used and you'll find that a painful experience. It's not going to hold your hand because it was never designed to run your business. Frankly, how could it be? Some systems claim they are in their marketing, but that marketing isn't honest because how do they know how you want to run your business? When you start trying to use those systems in your business you find out pretty quick that they really don't know.

So, your best bet is to define your business and then do a gap/overlap analysis with OFBiz to see what you can use, what needs to be adapted, and what needs to be built to fill gaps. If you really want a tuned system, like for a larger company or for a derivative work (like a commercial application targeted at a certain type of company) then you can define the business, design the application, and build it, and save resources building it by reusing as much as possible from something like OFBiz (which gets back to why OFBiz is organized like it is). To do these things effectively takes some experience, and to shorten the path certain tools are helpful like the HEMP approach (http://www.dejc.com/home/HEMP.html).

Stepping back a little... there is a bigger trick... and that is how many people believe what I wrote above Read Before You Write and Scratching the Surface? Well, not many (that I've had the pleasure to meet anyway). For those that do understand and agree OFBiz is great (could be better, lots better, because even many people involved with OFBiz don't believe or don't understand those two ideas and as the number of contributors increases that painful fact becomes more apparent). For those who don't understand or don't agree, they are destined to a life of making things painful for them and others they work with, whether they attempt to use OFBiz (probably won't last long) or whether they choose a likely painful commercial route filled with reasons to spend more and more money on more and more different software.

David Joneshttps://email@example.com:blogger.com,1999:blog-5816842205727721694.post-80677869735540192122009-06-23T13:48:00.000-07:002009-06-23T13:51:12.735-07:00

Open Source Community Collaboration Best Practices

WARNING: This is a long post, approaching a dissertation on the topic. I recommend that you glance over the headings, and then go get some tea and cakes, coffee and donuts, or whatever it is you enjoy consuming casually while having your brain tickled.

The Best of Practices

The title to this article falls a little bit short of accurate... I actually only want to talk about a single best practice that seems to consistently determine whether or not an interaction with others in the community will be successful or not. The idea of this give and take is really simple, and goes back to the basic definition of collaboration:

1. the action of working with someone to produce or create something

2. traitorous cooperation with an enemy

Both parts of this definition are interesting, because the practice that leads to success in community collaboration is one that aligns well with #1 and avoids any appearance of #2. On either side of the definition it comes down to who you choose to collaborate with, and that's the most important thing to keep in mind in an open source project: you are collaborating with people and expecting to both give and take as part of your interactions with them.

If you want other people to collaborate with you, first you need to collaborate with them. If you are hoping for some benefit of the collaboration you first need to set the stage for the collaboration and invite others to collaborate by starting first and giving what you have, then invite others to get involved. The important thing to keep in mind is that collaboration implies a two-way street and if you try to make it one way by not trying to collaborate with others, but still expecting them to collaborate with you, then you will most likely be disappointed by either no collaboration at all, or a good-will attempt by someone else to collaborate with you that will fail because no stage was set for the collaboration and they will likely help in a way you don't need.

Now a quick "anti-pattern" to explore what this implies... you may be wondering: "how can I be sure that other people will collaborate and I'm not just giving stuff away and will never get anything back?" That issue is certainly one that stands in the way of collaboration and basically represents a lack of confidence in the possibility of collaboration. The problem is that if you are unwilling to give it a chance and "cast your bread upon the waters" as it were, then there is not even a chance that you will be the fortunate recipient of collaboration in return.

If you can't give for the sake of fostering collaboration and good will, then community collaboration may not be for you. The best path may be to continue to collaborate through the financial and legal means that are the common operating mode of commercial software and result in a very inefficient form of collaboration (if you can even call it collaboration) that causes many of the problems that people and organizations face with the software they currently use. Unfortunately many commercial software organizations would consider open source collaboration to be firmly in the camp of definition #2 above.

One good concept to keep in mind when working with others is the "burden of proof." A good way to be generous with others and to make it clear to others that you are putting efforts into collaboration is to take upon yourself the burden of proof, and not ask others to take it on. When you do this you will communicate more clearly and others will tend to reciprocate and do their own research, puts their thoughts and effort into it, and make things flow back and forth more smoothly. What this means in daily practice is usually to just research things well and before proposing something or asking a question thoroughly present your research, including references and links where possible. In the Apache OFBiz Committer's Best Practices Guide this is referred to as "read before you write" and the burden of proof concept takes it one step further to sharing with others what you read so that you can collaborate on the writing side of things.

A Case for Collaboration

This reminds me of a quote from a movie scene (whose name I can't remember and google isn't helping): "Qui bono?" The line is from an old politician who has a clear set of priorities. I'm not referring to the "Qui bono" line from The Departed, though that one is more entertaining, and I guess almost equally as enlightening. Whatever the case, the point is: who benefits? I suppose the point from The Departed is also appropriate: who cares?

Commercial software organizations operate under a specific model and that is very understandable from their perspective with their investors and a wide variety of stakeholders that they need to make a profit and leverage whatever assets they have available in order to do so. Software is often considered such an asset, and treating it that way is extremely well supported by modern intellectual property laws. So, is that a good model or a bad model? In the abstract I think that's impossible to answer, and it depends on whose perspective you are looking at.

What about the perspective of the end-user? Which approach best benefits the end-user (individual or organization)? Is there a conflict between what benefits software producers and consumers? My opinion on this topic is that again the answers depend on who you ask and that nearly all large commercial software producers will answer in their favor, and some end-users may as well (perhaps because they are influenced by marketing messages) though for the most part they will answer differently based on actual experience with those large commercial software producers.

All of that introduces a lot of complexity, and it is possible to look at the simple flow of information under the assertion that the more end-users have influence over software the better it will meet their needs. Through open source collaboration end-users can very directly influence the direction of the software by participating in the project and collaborating with other contributors and users. And what about the crazy things that some companies do? The collaboration tends to be very effective for filtering out or refining ideas that aren't so great. On the other hand, sometimes the "crazy" ideas turn out to be a differentiator for the company and result in a huge benefit over competitors. With open source software they have the flexibility to implement such things anyway (and do so efficiently) and even keep those changes private if they desire (well, unless the software is GPL licensed, which I would assert is not a good license for business software that is meant to be customized).

On a more day-to-day note direct collaboration is powerful in many situations that users and developers run into. It allows new users to get feedback on what they are trying to do and either open the way for new functionality or get recommendations on how to better use existing functionality. On the other end of the spectrum, it allows experienced users and contributors to get feedback on both their requirements, designs and implementation approach and ultimately results in far better software that will generally meet current needs better and also be more likely to handle changing future needs. In other words, whether you are experienced or not direct community collaboration can very efficiently help you to resolve issues that you face, and exploit opportunities that arise.

In short the ultimate reason for direct collaboration, as opposed to collaboration through financial and legal means, is that it results in software that better meets the needs of end-users (more flexible), better protects the interests of end-users (more private), and is also less costly for end-users. That reason will always be true.

Right now there is another reason to consider more direct collaboration and that is that commercial software companies have become massive entities with a lot of influence over governments as well as end-user organizations... and this means that they are able to put their own interests above those of end-users and get their way as much as they want. Very large end-user organizations can sometimes stand up to them, but that is still a small minority, even in this modern world of business. Shifting that balance to something more in favour of end-user organizations will make non-software commerce more efficient and allow software to be more an enabling industry instead of a controlling one and ultimately enable general economic growth and stability.

For commercial software vendors there doesn't have to be a conflict with open source collaboration. They don't HAVE to consider that collaboration to fall under definition #2 above. It may require some adjustments, and ultimately by better serving their end-users they will offer better solutions and keep clients and customers for the long term. The downside is the sacrifice of short-term profits and the ability to boost profits by pushing clients to buy things at certain points in time, like scheduling releases and upgrades to boost revenue or introduce separate products instead of adding features to existing products and including them in free service packs. End-users don't like such practices and if they perceive a viable alternative they will leave... so why not change practices and find more profitable approaches that also better serve the end-user who ultimately pays all of our bills...

Collaboration on Software

Going beyond general collaboration there are certain things that must be done to more effectively collaborate when working specifically on software.

The most important is to collaborate on designs and not just on implementation, keeping in mind that to collaborate you need to start out by collaborating with others and giving them a chance to collaborate with you. In the software world that means don't just implement something and throw it out for everyone to try to digest and react to. Instead, write up what you want to do and give other people a chance to send their feedback. Depending on the complexity of what you are working on this could take from days to weeks.

So why do this? Won't it just delay your work? Consider that if you create a design on your own chances are you'll forget things or not be aware of requirements that are common and important to that design. If you leave those out and implement something then sooner or later what you implement will be changed, or thrown out and re-written. Why is that? Because important requirements were left out of the initial design, and those requirements won't just go away. If you're lucky the requirements will have a small impact and won't require significant changes to the design or the implementation. However, especially if you are not trying to make things as broadly applicable as possible then it is easy to ignore big things that will impact the design a lot, and then it may be impossible to just refactor and extend the implementation to support the new design.

How can we avoid this? The answer, as would be expected in an article about collaboration... is to collaborate in advance on requirements and get the design to a solid point before you start implementation. Your code will have a longer lifespan and almost always also be more useful to you and your clients.

Some Short How-To Scenarios

1. I want big feature XYZ to be developed and I would like to work with others on it to ensure the best possible design and so I don't have to implement all of it.

2. I want big feature ABC to be developed and I'm not a developer so I can't help with development.

3. I have a question and I'd like to get an answer through the community (I can't afford to pay someone to support me, or I think this is an issue that the community should address).

4. There is something that exists in the software that I think should work differently.

For all of these the pattern is the same. Start with research on what exists in OFBiz, the requirements driving what you want, what can already be done and what can't be done or that you can't figure out how to do, then present your findings and requests for help and collaboration that you would like to see happen.

Collaboration Anti-Patterns

In the software world one way to clearly not collaborate is to totally rewrite something instead of improving something that exists, especially if this involves no attempt to understand what already exists and make sure that the replacement is sufficiently better to be worth the change and also does everything that the old stuff did. To understand more of why this is bad for collaboration, and sometimes bad for design and implementation as well, consider some of the things that you would be implicitly doing:

1. throwing away the feedback (or potential feedback) from others on the mailing lists

2. throwing away the various fixes and improvements that people have put in

3. in doing #1 and #2 you are making it impossible for people to collaborate with you... as much as many people are trying when you take this approach you are not allowing people to do so

4. large scale re-writes when there are issues instead of addressing the issues usually results in things NEVER becoming refined (since the focus is on starting over instead of on refinement), and in addition leaves a very large wake of orphaned code

Final Summary

In short the best way to collaborate with others, especially in a volunteer situation like an open source project, is to start by investing in the direction you want and then giving that investment away and soliciting involvement from others (including a write up on what you've done and your vision of what it can/should be and perhaps even on how others might get involved). By "casting your bread upon the waters" in this way you open the way for others to join in and give back, to collaborate back with you. Others may not collaborate back in the way or on the timeline that you had in mind, so be patient on both aspects. Consider what others suggest and appreciate their suggestions and discuss them in the open. This will foster more collaboration and allow the end result to be far superior to what you are capable of on your own... no matter how talented and/or experienced you are.

This direct collaboration model is a powerful way of getting things done and maintaining them over long periods of time in inherently stable ways. It enables a high degree of innovation and eventually results in solutions that are eventually clean and efficient and effective. Again, be patient with it as things are generally not perfect on the first pass or during the height of the collaboration activity, but rather when the collaboration has taken its course.

David Joneshttps://firstname.lastname@example.com:blogger.com,1999:blog-5816842205727721694.post-68407778718788721782009-06-10T02:08:00.000-07:002009-06-10T02:10:45.306-07:00A Time for ChangeI have had the pleasure of working with a number of great people over the 8 years I've been involved with OFBiz. For the last 2.5 years I've been a part of a great and growing company, Hotwax Media, and it has been amazing to see the number of people involved with Apache OFBiz increase as well as the work done over the years (including excellent custom work and a large number of contributions back to the open source project).

Much of the world seems to be changing right now and more changes are coming as people adjust their priorities and move on to new opportunities. For me personally the time has certainly come to make some changes. I'm cutting back on both expenses and investments, and getting back to what I know best and enjoy doing most: independent consulting.

On Saturday June 6th I resigned from Hotwax Media, leaving behind a great group of people and even some cash on the table, and moving toward the many and growing opportunities for doing other OFBiz-related work. Apache OFBiz is a great solution in an economic environment (similar to the one it started in) where organizations are moving back to core values and focusing on accomplishing their core objectives. In some cases that means doing more with less, and in nearly all cases it means doing more of what distinguishes the organization, and doing that requires more control over the business and the software that helps automate and manage it.

While it's been great working with the people at Hotwax and with many clients through the company, I miss working more with others in the community and seeing more of what other service providers and end-users are doing. I'm truly looking forward to doing work similar to what I did a few years ago and working with a larger group of individuals and organizations.

Along with this I'm also looking forward to putting more time and effort into new objectives for Apache OFBiz, including adding collaboration on requirements and designs to the existing highly successful collaboration on implementation, and along with that creating some applications meant to be used out-of-the-box by specific types of organizations or individual end-users.

If you think I might be able to help you with something you have going, please look at my web site at http://www.dejc.com/ for contact information and more details on the types of services I am offering.

David Joneshttps://firstname.lastname@example.com:blogger.com,1999:blog-5816842205727721694.post-75380741703863054952009-05-12T01:18:00.000-07:002009-06-22T18:14:49.744-07:00Apache OFBiz at OSCON 2009

O'Reilly OSCON 2009 is taking place in San Jose, CA, USA on the 20-24 July 2009. For details on the conference see:

http://en.oreilly.com/oscon2009

Apache OFBiz was going to have a booth there but that has been cancelled because I was unable to line up enough resources to make it happen.

An OFBiz-related thing at the conference that is still happening is the presentation I will be giving on Thursday the 23rd at 2:35 PM. The title of the presentation is "Apache's Open For Business: Holistic Analysis and Design." For more details about the presentation please see the schedule here:

http://en.oreilly.com/oscon2009/public/schedule/detail/7453

I look forward to seeing everyone there and enjoying some conversation and collaboration during a bit of the Northern California Summer.

David Joneshttps://email@example.com:blogger.com,1999:blog-5816842205727721694.post-81079401308613403042009-04-13T10:38:00.000-07:002009-04-13T10:40:45.113-07:00Apache OFBiz Community Building Tour - Mid-western USA, April 2009As a follow-on to the April release branch, and to help encourage community growth and participation for Apache OFBiz, I'm planning a tour of the Mid-western United States. As part of this tour I'd like to visit with individuals and organizations who are current and prospective users, contributors, and others involved with or interested in OFBiz.

In these visits I will be available to spend 1-3 hours with you and answer questions about Apache OFBiz and how you can use it most effectively. I would be happy to speak with individuals or as many people from your organization as you would like.

If you would like to better leverage opportunities to collaborate with others in the community or there are specific things you'd like to see in OFBiz, or be able to do with OFBiz, this is a great time to chat about it. Also if you'd like general business level or technical help with the software I'm happy to go over those sorts of things as well.

I am doing this as the PMC Chair of Apache Open For Business with the intent of helping grow the community and not in my role as an officer of Hotwax Media. If you are interested in the services of Hotwax I'll be happy to briefly answer questions and refer you to the Hotwax sales people.

Below is the rough schedule I have in mind and the general areas I plan to be in. I'll be changing it as needed to accommodate what people are available for. If you're around these areas and available around these times, please let me know!

17 April (Fri): Omaha NE, Des Moines IA, Kansas City MO
20 April (Mon): St. Louis MO
22 April (Wed): Indianapolis IN, Louisville KY (maybe Chicago IL)
24 April (Fri): Memphis TN, Nashville TN
27 April (Mon): Dallas TX, Oklahoma City OK

Please contact me directly by email if you're interested in a visit. If you know of someone else who might be interested in a visit, please make an introduction and if they are interested I'm happy to play along. My schedule is flexible on this trip so morning, lunch and evening visits along with normal business hours are fine.

There is no fee for this, but I won't refuse a free meal if offered. I'm traveling in a 40' motorhome, so hints for parking somewhat nearby are also appreciated.

I am planning to do this in other areas in the near future, but don't have firm plans yet. The next likely area will be the north-western USA in July (around the time and place of OSCON which I'll be speaking at on July 23rd in San Jose, CA).David Joneshttps://email@example.com:blogger.com,1999:blog-5816842205727721694.post-45230350864998021982008-01-31T17:34:00.000-08:002008-01-31T17:47:41.470-08:00Re-Reference Post: Community versus Code and Glass CathedralsSome feeds missed this post (or weren't setup yet), so this is a short post to point back to it. There are some ideas of interest to the open source world, and as a bonus I've made an attempt at coining a new term: Glass Cathedral.

http://osofbiz.blogspot.com/2008/01/glass-cathedrals-and-community-versus.htmlDavid Joneshttps://firstname.lastname@example.com:blogger.com,1999:blog-5816842205727721694.post-3855096497918335172008-01-30T21:51:00.000-08:002008-01-31T17:40:15.979-08:00Glass Cathedrals and Community versus Code
Collaboration

From the proverbial "Day One" of thinking about OFBiz it was clear to me that I couldn't do it alone, and in the financial environment of the day (early 2001) it was also clear that there was no way I could raise the money necessary to make the dream a reality. That was especially true for me because I had nothing in my background other than a couple of years of research and failed commercial attempts to set me apart and make me of interest to prospective investors and partners.

Enterprise systems in general are large, complex things and require hundreds of thousands of man-hours to implement. On top of that with such a wide variety of businesses and real-world requirements designing something that would be flexible enough to be a good starting point and that would not require rewriting significant parts of the software would require a body of knowledge and experience that would be almost impossible to pay for. To start from scratch and build such a system would require a lot of collaboration.

The traditional means of collaboration in the commercial software world is to pay for a license and hopefully influence the vendor to add or fix things. There is little influence in this. Some vendors will accept payment for development of specific features, but for the most part customizations and specific features are built outside of the core product and never shared. This is a very limiting form of collaboration.

I worked with open source software before getting into all of this enterprise systems stuff as part of a company called Lineo that was creating products for embedded systems based on Linux, and in college as well. While doing R&D for an ecommerce startup I also ran into a number of open source alternatives, but mostly in infrastructure software, there just wasn't anything real happening in enterprise automation at the time.

The collaboration problem and the open source solution seemed the perfect match. Collaboration through a non-profit, open source effort seemed like a significantly more efficient way to go about things that collaboration through commercial licensing and the often disposable results of consulting engagements. With no financial entanglements collaboration can focus on solving problems and creating solutions with a long life span. Speaking of life span, the likelihood of survival for a piece of software is much greater when no one company can fall and take the software with it.

And there was more. I saw quickly that in addition to making the development of such a system from scratch possible, it also made the results of the development effort far better than any individual or static team working in isolation ever could. I started to see the lack of funding and the necessity of working on contracts to survive as a great benefit to the effort rather than a distraction from it. In short if I had personally had all the time and money I needed to site in a room and build this system, or even just the framework part of the system, it would not be anything like the real world need driven framework and application set that it is today.

The collaboration was just amazing. So many people suggested things over time and even though the majority of the suggestion never yielded anything immediately fruitful, there were so many that were critical and that pushed us in the direction we wanted to go by paths we hadn't even considered. I'm comfortable admitting that there is no way I could have built OFBiz the way it is now on my own. Over time I have also learned to accept that in many cases things I built and thought were great were inferior to existing alternatives or ideas about better ways of doing things. In the first 2-3 years of OFBiz we threw out as many lines of code as we kept. There was continual housekeeping and refinement, and there still is today even though these days the patterns and practices are more established and tried and proven, so the need for this is less frequent (on a large scale at least...).

After running OFBiz this way for years there were various people and organizations involved and this means of collaboration was proving to be very successful and stable. We were certainly not the only ones to run a software project this way and in 2006 some people from the Apache Software Foundation approached us, recognizing the similarities in philosophy, and inviting us to join the ASF. The more I read about Apache the more I came to see things this way as well, and the more I could see that they had the same emphasis on how to structure an open source project that I had come to. The great thing was that they had a much better organization and much better legal infrastructure (including the Apache License 2.0).

One of the main tenets of the Apache Software Foundation is that the community is the most important thing, and if you get that right then good code and other things naturally follow. In other words, if people are brought together in a way that enables minimally encumbered collaboration they will create something good, and something far better than if that collaboration had not been present.

Code

This may seem obvious to many people these days. These sorts of concepts have come a long way in recent years, even outside of the once fairly limited open source development circles. So why am I bringing this up now, and writing about all of this nearly 7 years after the inception of OFBiz?

The answer is that the principles and efforts of community driven open source projects have as much impact today as ever, and are a key to distinguishing efforts in the so called "open source" world.

There are some in the real open source world that don't focus on community and collaboration, and suffer because of it. One big potential problem for open source projects is a forked code base, or more importantly: a forked community. Sometimes a community degenerates or there never really was a strong community at all and a fork is appropriate.

In many cases though people fail to recognize the importance and value of the community and collaboration within it. For whatever reason they decide that they can do better on their own (often along with select others). They decide that the code is more important than the community.

In the OFBiz world there are various examples this failure to collaborate resulting in projects largely based on OFBiz but that have chosen to go in different directions. Many of these are open source projects, but organized and licensed in a way that fails to enable the collaboration necessary for success.

Glass Cathedrals

That's the main point of this blog entry, but I have a little more on my mind related to this and commercial dual licensing and the GPL license, and of course the dozens of variations on the license.

In general I agree with the ideals behind the GPL and the philosophy of Richard Stallman and others he works with on this. The idea of making software free and keeping it free is great, especially for certain types of software like infrastructure software that is used en-masse but not frequently customized (ie the improvements are nearly always generic enough to be shared). The reason that I originally pushed for the MIT license, and later the Apache License 2.0, is that these are more commercial and proprietary derivative work friendly licenses. When creating software that is meant to be customized it wouldn't be wise to legally or technically encumber those efforts.

What I really wonder is what Richard Stallman thinks about the practice of dual-licensing using the GPL and a commercial license. For these sorts of so called "open source" projects the only reason they want to use the GPL is its terms are the most onerous and are most likely to lead people to pay for a commercial license. In my opinion this is a deceitful corruption of valuable open source principles.

The development on these products (not really open source projects...) is generally done by a small group of paid designers and developers and there is little community interaction. Many choose to collaborate only financially instead of bringing their unique requirements and ideas to the table to enhance the core project. There isn't a lot of incentive to try to contribute back or collaborate when it is made clear from the beginning that there is one player who wants to own everything and that you don't really have a chance of being that player or competing with them in their own game.

The code becomes more important than the community. It's a bit like putting the cart before the horse in that there is a failure to realize the cause and effect and an attempt to get the affect (the code) with the cause (the collaboration in the community).

This is a major case where the use of the GPL breaks down collaboration instead of enabling it. This does happen in purely open source projects as well though, with GPL and other licenses too. Eric Raymond wrote a lot about this with his parables of cathedrals and bazaars. With cathedrals collaboration is limited and that is the biggest problem, whereas the collaboration possible in the bazaar is the real power in the model.

I would argue that this happens even with publicly developed open source projects if there is no incentive for or focus on enablement of collaboration, ie no real community that one can become a part of and influence and improve by just being positively involved. Some purely open source projects are this way, but most open/commercial dual-licensed products are this way. Even the "open source" parts are developed in a sort of "glass cathedral". People can see what is going on, and if they really want to they can walk in and participate, but most choose to stand outside and watch and in fact pay to not get too involved.

So, in closing, here's to Glass Cathedrals and the opportunity they give to community driven open source projects to differentiate ourselves. It also brings to mind that old saying... something about stones and those who live in Glass Cathedrals....

David Joneshttps://email@example.com:blogger.com,1999:blog-5816842205727721694.post-54737022175348646212007-06-14T22:37:00.000-07:002007-06-14T22:58:52.834-07:00Thoughts on OFBiz Derivative Works, the PMC, and Opentaps Past and PresentIn the email Si sent about resigning from the PMC he referenced reasons described in emails between Si and Andrew. I got with Andrew to review these and just wanted to comment briefly on them and what seems to be the issue.

From my point of view this is just the most recent incarnation of a problem that has been around for at least a couple of years now, and I've been more concerned over time about it but had decided to give it time and see how things have progressed. Initially this started with the financials module that was developed as an investment to be licensed for income until the development cost was recovered, but Si at one point decided he would rather put what Undersun had worked on back into OFBiz, and take full ownership of the rest to dual license (commercial and GPL open source). This resulted in something that is core to the mission of OFBiz being part of an outside project, which at the time seemed a reasonable compromise.

At the time and at various times since then I have had conversations with Si to warn him that this is not a tenable long term business model and eventually something would be developed as part of OFBiz to satisfy these requirements and encouraged him to consider licensing these back to OFBiz to be included in the project should a large user come along that had a sufficient budget and desire to re-develop it anyway.

Over time the scope of the financials application expanded to include refactorings and rewrite of functionality in OFBiz. The crmsfa component was also added to implement a SalesForce or SugarCRM type of sales management application (this was a piece that was originally designed for a client and proposed to be added back to OFBiz, but Si underbid the implementation to retain the IP and add it to the dual-licensed modules. More recently additional modules and rewrites have been added to the Open Source Strategies library of OFBiz extensions.

The reason these have become a problem is because they are within the established scope for OFBiz and this represent a competition for resources to build and maintain them. Various people have complained to me personally about this, and a few times various people have complained more generally on the OFBiz mailing lists. Things that have prompted these complaints include things like: requests on the OFBiz mailing lists for people to work on and contribute to opentaps/OSS components instead of to OFBiz, statements that represent the scope of OFBiz being limited to not conflict with what is being developed by Open Source Strategies (ie that it is a low level set of tools and application elements and not meant to be used by end users), statements about the nature of the OFBiz community and management process, etc.

I spent a bit of time with Andrew reviewing the emails between Andrew and Si. The main thing Andrew was complaining about was this conflict of interest and that it did not seem appropriate for someone to be on the OFBiz management committee who was, in order to further their own business interests, was trying to limit the scope of the project and recruit resources from the project community. Based on this Andrew expressed to Si that PMC members really should be advocates of the project and not send mixed messages, so it might be best to resign from the PMC if we was going to continue and expand these operations.

It should be noted that this was not a request by the OFBiz PMC in any official way, or even by Andrew as I understand it, but rather communication between two PMC members about a concern over something that is having an impact on the project. That said, as should be clear by my short history behind this conflict I definitely agree with Andrew that it is a problem and I think it is good as it is starting to have a greater impact that something was done.

Back to my thoughts on this... Part of the motivation for choosing the MIT license originally, and moving to the Apache 2.0 license as part of the ASF move, was to facilitate use of the software and participation in the project by a large number and variety of individuals and organizations (Person and PartyGroup in OFBiz lingo ;) ).

This means that according to the license what Open Source Strategies is doing is totally fine. From a community building perspective I think it is also okay as it is better than nothing. In other words if this is the only way we can get help from the people at Open Source Strategies, then so be it, we'll still take it! This is why I personally have decided not to do anything about this. Of course, the more they separate from OFBiz and fork certain components the less this will be true, and at some point the competition and dilution of resources that might contribute to OFBiz is more than the benefit to OFBiz from the indirect use.

I don't know if we've reached that point with either Neogia or Opentaps, which are the two main projects based on OFBiz that have forked certain parts, and extended independent of OFBiz. The reason I say that is that the OFBiz community is still strong and making good progress and is in fact growing rapidly and getting a lot of end user attention that is translating into even more contributor attention. We are also seeing a trend that those experienced with OFBiz are doing more dedicated work based on OFBiz and that is resulting in more contributions and more time spent on the project.

In general less involved users like this are great for the project, but really in order for the project to progress and fill the intended scope we need contributor individuals and organizations that practice a process of operation that meets client requirements by starting with generic development that goes back into OFBiz, and then continues with configuration or customization to meet the non-generic aspects of the requirements.

As for what is best for businesses trying to make a profit while working with the open source project, there are many models and many of them are viable and sustainable, and which one is best for the company the market (the customers) is yet to be seen. Here are some of them (a small selection):

1. dual licensed components or whole applications (commercial and generally GPL on the open source side, though opentaps using HPL which is more restrictive AND which is not truly "open source" as it is NOT OSI approved)
1.a. general purpose software
1.b. industry (niche industry or business type) specific solutions

2. commercial derivative works
2.a. general purpose software
2.b. industry (niche industry or business type) specific solutions

3. services and custom solutions

Based on talking with a lot of people there seems to be a continuum of opinion about open source versus commercial development models. To be clear, for this to make sense the goal is to create and maintain software that individuals or organizations can use. We're not talking about how to make a company that can produce a profit, but rather create an organization and collaboration model for the creation and maintenance and use of software. Some are totally on the open source side and think that is the answer to every question. Some are on the commercial side and believe _that_ is the answer to every question. Think of it kind of like the Kinsey scale, and just as with the Kinsey scale most people fall somewhere around one side or the other but not right at either side, and not so much right in the middle either. Perhaps someday this scale will have an official name and even an official diagnosis test to determine where someone's opinions lie on the scale. This might be an ente
rtaining research project.

At Hotwax Media, Inc. we have chosen #3 for now and we are growing quickly and having great success with a growingly impressive set of sites and companies we are working with. We believe, and are proving, that this is the best model for our company and for OFBiz itself as well. It allows us to stay close to the project, collaborate well with others, efficiently meet client requirements, and contribute major sets of functionality back to OFBiz. We are also working on extending OFBiz to implement software to support our own operations and make them more efficient, and that means even more goes back to the project, and is cheaper for us to develop and maintain.

I should make it clear that another commercial model that I've had in mind since the beginning of OFBiz is to create commercial derivative works for niche industries based on the generic open source software. The idea here is that the open source model doesn't work so well because in many industries the companies are too small and need too much software to customize it for a single business or for people from the various companies to collaborate on creating the software.

In other words many prospective users of OFBiz just can't effectively use the generic software as it is OOTB because it is way more than the need and probably too much for them to maintain as well. In order for those companies to use OFBiz they will need something customized for their type of business, and unable to collaborate directly in creating and maintaining that what makes the most sense is to collaborate through commercial means. Given the basis on open source generic enterprise applications these solutions can compete well because for a reasonable development expense something that targets a very specific market can be created. The customer gets a system that effectively automates all information management they need while still remaining highly affordable. Of course, this model is mostly theoretical as only very little has been done with it so far...David Joneshttps://email@example.com