On 02/07/2014 02:27 PM, Maciej Sumiński wrote: > On 02/07/2014 09:00 PM, Dick Hollenbeck wrote: >> On 02/07/2014 02:45 AM, Maciej Sumiński wrote: >>> On 02/06/2014 11:48 PM, Dick Hollenbeck wrote: >>>> On 02/06/2014 04:26 PM, Maciej Sumiński wrote: >>>> >>>>> It is not my intention to increase the number of bits in m_VisibleElements - I prefer >>>>> to leave it as it is now, particularly that it is saved as a 32-bit number in >>>>> .kicad_pcb files and I would like to preserve compatibility (so if older versions >>>>> expect 32-bit number there >>>> >>>> Note, that if we were always bound to allow older versions of KiCad to load newer files, >>>> then it would be impossible to add new features which needed saving on disk. >>>> >>>> I value new features far more. We can all stop writing code and wasting time on a mailing >>>> list if we are not to write features requiring file format changes. It would essentially >>>> mean that we could only make improvements which do not require change. >>>> >>>> The pay is too low already. If you can find a way to make improvements without also >>>> making changes, then I am in the wrong universe. >>> >>> Sure, I am aware that to improve you need to change, but not always the >>> file format. In this case, one cannot even benefit from saving the >>> visibility settings for netname layers, as they are turned on/off >>> together with copper layers. To take advantage of that, we need to add >>> some checkboxes first. >>> We could put in a document all the changes that we want to introduce to >>> the file format and then change it every e.g. 6 months according to the >>> paper. In this way, users will not be bothered by so frequent file >>> format changes. Especially that the majority seems to be using the >>> stable version, so they would not be able to open files done with the >>> newest product (and getting the freshest product is still beyond >>> capabilities of many users). >> >> >> Orson, >> >> I am very impressed with your skill set, and I think that your time on the project is >> extremely valuable to its future longevity. You have my profound respect and hopes for >> the future. You are one of the bright spots in the project moving forward. >> >> Your employer is paying for your time. I am paying for my time. >> >> Therefore, my time is more important than anything, and I am insanely intolerant of it >> being wasted or disrespected. But it also gives you a view of the lens from which I see >> things. >> >> You think our users are the most important thing. I think our developers are the most >> important thing. >> >> Note that I run a company. In that world, the users are the most important thing. >> >> Here, in open source, you've got squat without developers. > > Thank you for the words of appreciation. I can only imagine that running > a company is far from recreation and sometimes I really wonder how do > you manage to still find time for KiCad development. > I believe that in the open source world users and developers are equally > valuable, they just have different roles. And I know that development > costs much more time than filling out bug reports (if user decides to > give any feedback at all), but without having users you lose the > sensation of contribution and (sometimes) gratitude from users side. It > always improves my mood when I see some positive words from happy users. Think about it. I will take an Orson or a Wayne over 20,000 users any day of the week. One Orson or one Wayne can bring in 20,000 new users in 6 months with new features, each. You guys are quality developers. On the other hand, 20,000 users could not fund one developer for 6 months. So it looks to me like an Orson or a Wayne is worth more than 20,000 users. You will see that the future of the project depends on team building. A team is comprised of people you can work with, not just anyone. We can disagree now. That's OK. But if you build it, they will come. (Especially if its free.) And getting the builders in place, and taking care of the ones already here are the key aspects of success.