Money Matters: How do we measure the value of great software?
Facilitated by Greg Wolff, The UnaMesa Association
Should society reward the innovators and entrepreneurs who improve the quality of life for social service workers and their clients? Can we imagine a service economy that goes beyond sustainability and strives to create thriving communities? How do you survive today as a technologist serving in a non-profit world? What are your dreams for tomorrow? Together we'll look at what's working, what's not working, and what has yet to be tried in business models, property rights, and pricing mechanisms that reflect the true worth of technology to communities.
(slightly confusing)Notes: money matters
How do we see the problem of how we value of (free)software(how the participants are coming to this discussion): -how is open source going to change the model from a UI perspective, where proprietary software doesn't concentrate on UI because they can sell support. -challenges of negotiating value of freelance design and implementation. -there is a different layer of value in FLOSS that is hard to understand and convey to people. -from an admin perspective, figuring out how to convey a sense of value to end users of free software. they think the dollars means software works well. -from a documentation standpoint, if FLOSS had more professional and comprehensive documentation, people might value it more.--flossmanuals.org. o'riely is a good indication that documentation has a value, since people buy books about free software. -the value is assessed from lots of different metrics from software function, to developer know-how, to time spent. -how do we put value on man-years of coding effort in a product and how do you make a business model from it. -develop business models around open source and support models for FLOSS. -how do we talk about the value of the community who creates FLOSS
documentation is proxy for the value of the underlying software
process of valuing FLOSS: assess the value of free software in respect to the other products any given org is using, including support, licenses, etc. do a return on investment analysis is tough especially for new projects. comparative costs, or relative value based on commercial products- but is hard when users only have experience with one product credentialization- name dropping companies or orgs who use certain software. notion of attention dollars, how much time and money is being focused on a project. how many developer eyes are there?
- of people using the software and how much activity equals some semblance of support community.
the dominant conception of how much money software is worth is largely an artifact of proprietary software and companies and how these business structures function. its tough to evaluate features on different projects because quality metrics are dependent on usage and deeper knowledge.
where expectations are set are a driving point of value.
There are skills from people coming from proprietary software consulting that the FLOSS community does not come with on it's own. The people coming from proprietary software have a methodology of valuing the process of software creation.
things happen so fast that by the time you create a value assessment study, the tech will change and render that assessment obsolete. Must be a dynamic feedback system.
3 take-aways: -think of it as rish as opposed to value -documentation as a proxy for the value or the community -what people think they should pay for is moving up the stack.(above the API level)